--- Comment #4 from alexandre dot nunes at gmail dot com 2009-04-14 20:04
---
Created an attachment (id=17638)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17638action=view)
Testcase for gcc 4.4.0
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9831
--- Comment #5 from alexandre dot nunes at gmail dot com 2009-04-14 20:07
---
See the attached pqp.c file.
With gcc 4.3.3, on such simplistic examples, peephole ldm and stm works:
sum:
ldr r2, .L3
ldmia r2, {r1, r3}@ phole ldm
add r3, r0, r3
--- Comment #6 from alexandre dot nunes at gmail dot com 2009-04-14 20:11
---
(In reply to comment #5)
See the attached pqp.c file.
[cut]
With gcc 4.4.0 branch, built on 20090413, it fails:
This seems to be caused by the register order allocation. If I replace the
source code
--- Comment #3 from alexandre dot nunes at gmail dot com 2008-11-25 20:01
---
Still fails as of gcc 4.3.2
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26850
: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: alexandre dot nunes at gmail dot com
GCC target triplet: arm-unknown-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38203
--- Comment #1 from alexandre dot nunes at gmail dot com 2008-11-20 16:52
---
Created an attachment (id=16728)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16728action=view)
A more involved testcase.
This testcase shows the preserving behaviour on multiple call-clobbered
--- Comment #32 from alexandre dot nunes at gmail dot com 2008-10-21 18:37
---
I was considering using C++ for an arm-elf target, but I'm dropping that in
favour of plain C because of this silly thing. This sucks, because other than
that g++ does a pretty decent job when generating
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: alexandre dot nunes at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37642
--- Comment #1 from alexandre dot nunes at gmail dot com 2008-09-24 17:29
---
Created an attachment (id=16403)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16403action=view)
This is the first testcase.
compile with gcc -O2 -W -Wall -Wstrict-overflow=5
--
http://gcc.gnu.org
--- Comment #3 from alexandre dot nunes at gmail dot com 2008-09-24 20:42
---
(In reply to comment #2)
Subject: Re: New: GCC applies signed strict-overflow rules to unsigned short
type
When doing addition unsigned short is promoted to an signed int. So
this is not a bug
--- Comment #2 from alexandre dot nunes at gmail dot com 2008-06-19 13:21
---
(In reply to comment #1)
Works for me with
GNU C (Debian 4.3.1-2) version 4.3.1 (i486-linux-gnu)
and current trunk.
Yes, 4.3.x is not affected, even pre-releases of 4.3.0 worked fine for me
--- Comment #37 from alexandre dot nunes at gmail dot com 2008-03-03 14:30
---
If PR31849 is right, shouldn't this be reopened or marked as something other
than fixed ?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31360
--- Comment #8 from alexandre dot nunes at gmail dot com 2008-02-14 22:06
---
(In reply to comment #7)
Yes, so for packed structs (which are a GCCism), GCC sets the rule. Better
documentation is certainly appreciated, but - what is the bug here? Did
the behavior change (I think
--- Comment #10 from alexandre dot nunes at gmail dot com 2008-02-14 23:15
---
(In reply to comment #9)
We can't change the current behavior/ABI obviously. But the request for
better
documentation is correct.
Would it be feasibly to have a non-fatal testcase for this, so
--- Comment #36 from alexandre dot nunes at gmail dot com 2008-02-12 13:13
---
I think it's worth to note here the implications of the fix to PR31849.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31360
--- Comment #4 from alexandre dot nunes at gmail dot com 2008-02-11 21:10
---
(In reply to comment #2)
Also using a volatile pointer may prevent optimization, so don't use it if
not strictly needed (or at least don't expect optimized code).
Can you try 4.3 as suggested?
Ok
--- Comment #3 from alexandre dot nunes at gmail dot com 2008-02-11 21:34
---
(In reply to comment #2)
(In reply to comment #1)
I've seem the same error building for arm-elf. Perhaps I need a newer
(experimental) binutils?
Just a wild guess, could this be a typo?
[EMAIL
--- Comment #5 from alexandre dot nunes at gmail dot com 2008-02-11 21:31
---
I tested on i686 (-march=athlon-xp -O2) with gcc 4.3 revision 132072 (older
than the one I tried at arm), and it seems to misbehave there.
I'm not sure tought of the implications, since that's a superscalar
--- Comment #33 from alexandre dot nunes at gmail dot com 2008-02-12 00:32
---
I compiled gcc 4.3 for arm-unknown-elf (today's trunk, not sure about the rev).
Compiling three in three firmware images gave me size regressions with -Os;
with -O2, gcc 4.3 produces smaller code than 4.2.3
--- Comment #1 from alexandre dot nunes at gmail dot com 2008-02-11 20:12
---
I've seem the same error building for arm-elf. Perhaps I need a newer
(experimental) binutils?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35071
--- Comment #7 from alexandre dot nunes at gmail dot com 2008-02-12 00:45
---
It is not what you think it is. ;)
movl%edx, -536821760
means:
(set (mem:SI (const_int -536821760 [0xe000c000]))(reg/v:SI 1 dx))
IOW, put %edx to constant address.
It actually
--- Comment #4 from alexandre dot nunes at gmail dot com 2008-02-08 16:51
---
I suggest closing this unless reproductible on gcc 4.3.x, since at least
vanilla arm-elf-gcc 4.2.2 is correct:
foo:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: alexandre dot nunes at gmail dot com
GCC host triplet: i686-unknow-linux
GCC target triplet: arm-*-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35141
--- Comment #3 from alexandre dot nunes at gmail dot com 2008-02-08 20:48
---
(In reply to comment #2)
Also using a volatile pointer may prevent optimization, so don't use it if
not strictly needed (or at least don't expect optimized code).
Sorry for lefting it in there: Tought
--- Comment #6 from alexandre dot nunes at gmail dot com 2008-01-15 17:40
---
This seems to work as of gcc 4.2.2 (vanilla), using the original commands to
reproduce. Anyone denies/confirms this?
--
alexandre dot nunes at gmail dot com changed:
What|Removed
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: alexandre dot nunes at gmail dot com
GCC host triplet: i686-unknow-linux
GCC target triplet: arm-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34800
--- Comment #7 from alexandre dot nunes at gmail dot com 2008-01-15 17:55
---
(In reply to comment #6)
This seems to work as of gcc 4.2.2 (vanilla), using the original commands to
reproduce. Anyone denies/confirms this?
... and please see bug 34800 .
--
http://gcc.gnu.org
--- Comment #5 from alexandre dot nunes at gmail dot com 2008-01-15 17:58
---
(In reply to comment #4)
won't fix in GCC-4.0.x. Adjusting milestone.
For anyone interested, I think this is fixed for at least gcc 4.2.2; I couldn't
reproduce it.
--
alexandre dot nunes at gmail dot
--- Comment #16 from alexandre dot nunes at gmail dot com 2008-01-15 18:03
---
vanilla gcc 4.2.2 seems to compile this testcase ok (all five symbols are
emmited and externally visible, no warnings)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28744
--- Comment #9 from alexandre dot nunes at gmail dot com 2008-01-15 18:12
---
(In reply to comment #8)
Fixed on the trunk.
For anyone else wondering, this is still reproductible on vanilla gcc 4.2.2.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28755
--- Comment #29 from alexandre dot nunes at gmail dot com 2007-11-13 17:35
---
(In reply to comment #28)
(In reply to comment #26)
(In reply to comment #25)
[cut]
Mark does not actually read the full list of messages when changing the target
milestone. I think this should
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: alexandre dot nunes at gmail dot com
GCC build triplet: i486-linux-gnu
GCC host triplet: i486-linux-gnu
GCC target triplet: i486-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34076
--- Comment #1 from alexandre dot nunes at gmail dot com 2007-11-12 19:46
---
Created an attachment (id=14532)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14532action=view)
the original file from the bug report.
gcc -DNOINLINES -W -Wall -Winline -Wshadow -Werror -O -c pqp.c
gcc
--- Comment #23 from alexandre dot nunes at gmail dot com 2007-11-12 20:11
---
(In reply to comment #20)
Change target milestone to 4.2.3, as 4.2.2 has been released.
Does this means it'll get fixed by 4.2.3, or the 4.2.x series will stay bugged
indefinitely?
--
http
--- Comment #26 from alexandre dot nunes at gmail dot com 2007-11-12 20:40
---
(In reply to comment #25)
... but the audit trail suggests otherwise. :S
Ok, now I'm confused :-)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29478
--- Comment #6 from alexandre dot nunes at gmail dot com 2007-11-02 16:58
---
From the gcc internals
(http://gcc.gnu.org/onlinedocs/gccint/Storage-Layout.html):
Target Hook: bool TARGET_MS_BITFIELD_LAYOUT_P (tree record_type)
This target hook returns true if bit-fields
--- Comment #3 from alexandre dot nunes at gmail dot com 2007-10-20 12:20
---
(In reply to comment #2)
The standard puts all the burden on the implementation (See 6.7.2.1/10).
The GCC manual in turn says the behavior is specified by the ABI (4.9
Structures, unions, enumerations
--- Comment #4 from alexandre dot nunes at gmail dot com 2007-10-20 12:55
---
(In reply to comment #2)
The standard puts all the burden on the implementation (See 6.7.2.1/10).
The GCC manual in turn says the behavior is specified by the ABI (4.9
Structures, unions, enumerations
--- Comment #5 from alexandre dot nunes at gmail dot com 2007-10-20 13:35
---
(In reply to comment #4)
(In reply to comment #2)
The standard puts all the burden on the implementation (See 6.7.2.1/10).
The GCC manual in turn says the behavior is specified by the ABI (4.9
--- Comment #1 from alexandre dot nunes at gmail dot com 2007-10-20 01:49
---
Created an attachment (id=14374)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14374action=view)
A complete testcase.
I compiled with gcc -ggdb3 file.c -o file, no optimization flags.
--
http
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: alexandre dot nunes at gmail dot com
GCC build triplet: i486-linux-gnu
GCC host triplet: i486-linux-gnu
GCC target triplet: i486-linux-gnu
http
41 matches
Mail list logo
