rity: P3
Component: 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=16728&action=view)
A more involved testcase.
This testcase shows the preserving behaviour on multiple call-cl
--- 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
--- 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=14374&action=view)
A complete testcase.
I compiled with gcc -ggdb3 file.c -o file, no optimization flags.
--
n: 4.2.1
Status: UNCONFIRMED
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 trip
--- 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, enu
--- 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, enu
--- 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
: UNCONFIRMED
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=16403&action=view)
This is the first testcase.
compile with gcc -O2 -W -Wall -Wstrict-overflow=5
--
--- 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
> th
--- 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 gener
--- 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
--- 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.
--- 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 g
--- 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 s
--- 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
--- 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
--- 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 #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
--- 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 test
--- 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 #47 from alexandre dot nunes at gmail dot com 2009-03-06 15:29
---
Any news on the subject?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31849
--- 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=17638&action=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
--- 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 in
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://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=14532&action=view)
the original file from the bug report.
gcc -DNOINLINES -W -Wall -Winline -Wshadow -Werror -O -
--- 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?
--- 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 #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
> mi
--- 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://gc
--- 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 do
--- 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 #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
42 matches
Mail list logo
