http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52488
--- Comment #13 from Ralf Corsepius
2012-03-13 14:16:10 UTC ---
(In reply to comment #11)
> (In reply to comment #7)
> BTW: The -mmcu=at90s2313 from above is fallout from -print-multi-lib.
Well, IMO, --print-multi-lib is the only legitmate conf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52575
--- Comment #3 from Ralf Corsepius 2012-03-13
14:08:21 UTC ---
(In reply to comment #2)
> There are already spill fails reported for AVR, it's a known problem.
>
> At this point it cannot be said if this PR is really the same as PR50925, but
> i
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52575
--- Comment #1 from Ralf Corsepius 2012-03-13
08:11:56 UTC ---
FWIW: As things currently appear, this breakdown is not restricted to the
-mmcu=avr25 multilib-variant, but affects all RTEMS multilibs.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52575
Bug #: 52575
Summary: avr*: error: unable to find a register to spill in
class 'POINTER_REGS
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIR
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52488
--- Comment #9 from Ralf Corsepius 2012-03-13
06:16:03 UTC ---
(In reply to comment #8)
> (In reply to comment #7)
> You can look up in the device datasheet to see how much RAM it has.
Well, datasheets is one thing, GCC's internal notion is yet
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52488
--- Comment #7 from Ralf Corsepius 2012-03-13
03:28:39 UTC ---
Result with your patch applied:
...
./../../../../../gcc-4.7.0-RC-20120302/newlib/libc/posix/glob.c: In function
'glob':
../../../../../../gcc-4.7.0-RC-20120302/newlib/libc/posix/glob
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52488
--- Comment #2 from Ralf Corsepius 2012-03-12
06:21:42 UTC ---
Created attachment 26876
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26876
*.i of the file triggering the ICE
This *.i was created from today's (ca. 2012-03-12 05:00 UTC)
gc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52488
Bug #: 52488
Summary: avr-*: internal compiler error: in extract_insn, at
recog.c:2123
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52481
Bug #: 52481
Summary: m68k-*: internal compiler error: in extract_insn, at
recog.c:2123
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52466
Bug #: 52466
Summary: gcc-4.7.0-RC-20120302 fails to build for
--target=lm32-rtems4.11
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51969
--- Comment #3 from Ralf Corsepius 2012-01-24
07:05:03 UTC ---
Thanks, Markus, Jakub.
Despite I don't understand this patch, it patch seems to work for me :)
--- Comment #4 from ralf_corsepius at rtems dot org 2007-05-04 06:36
---
Using GT64260eth.c from attachment 13505, I am able to reproduce the race with
gcc-4.2.0-20070430 for arm-rtems, bfin-rtems, powerpc-rtems, i386-rtems.
=> I assume this issue to be target independent and
--- Comment #3 from ralf_corsepius at rtems dot org 2007-05-04 06:29
---
Created an attachment (id=13505)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13505&action=view)
Stripped down example to expose the issue on all targets
--
http://gcc.gnu.org/bugzilla/show_bug
--- Comment #7 from ralf_corsepius at rtems dot org 2007-05-03 15:20
---
FYI: Vanilla gcc-4.1.2 without newlib also exposes this issue with the code
fragment from comment #6:
./avr-gcc -o tmp.o -c init.c -O2
init.c: In function 'init_array':
init.c:12: error: unable to find
--- Comment #6 from ralf_corsepius at rtems dot org 2007-05-03 14:07
---
This is the minimised *.c having been extracted from newlib's file exposing the
bug:
-- snip --
extern void (*array_start []) (void);
extern void (*array_end []) (void);
void
init_array (void)
{
int
--- Comment #2 from ralf_corsepius at rtems dot org 2007-05-03 10:47
---
Created an attachment (id=13503)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13503&action=view)
*.i of the breakdown above
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31787
--- Comment #2 from ralf_corsepius at rtems dot org 2007-05-03 10:45
---
Created an attachment (id=13502)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13502&action=view)
*.i of the breakdown above
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31797
--- Comment #3 from ralf_corsepius at rtems dot org 2007-05-03 10:43
---
Created an attachment (id=13501)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13501&action=view)
*.i of the breakdown above
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31786
--- Comment #2 from ralf_corsepius at rtems dot org 2007-05-03 10:27
---
I can also reproduce the bug with 4.2.0-20070501.
It also is related to optimization levels. Newlib is being compiled with -O2,
which triggers this breakdown. Using -O1 or -Os to build init.c lets the
breakdown
--- Comment #1 from ralf_corsepius at rtems dot org 2007-05-03 09:36
---
Using -O1 instead of -O2 causes the hogging to vanish.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31797
nedTo: unassigned at gcc dot gnu dot org
ReportedBy: ralf_corsepius at rtems dot org
GCC target triplet: powerpc-rtems*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31797
--- Comment #1 from ralf_corsepius at rtems dot org 2007-05-02 17:05
---
I've been trying to attach the *.i of this breakdown, but creating attachments
seems to be broken right now. I am always receiving this:
undef error - Undefined subroutine Fh::slice at
data/template/templa
Summary: bfin: Dreg expected for CLI. Input text was P0.
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ralf_corsep
--- Comment #36 from ralf_corsepius at rtems dot org 2007-05-02 14:16
---
(In reply to comment #35)
> Now, bootstrapping 4.2.0 fails with a similar error
Filed as http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31786
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18251
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ralf_corsepius at rtems dot org
GCC target triplet: avr-rtems*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31786
--- Comment #35 from ralf_corsepius at rtems dot org 2007-05-02 14:07
---
Now, bootstrapping 4.2.0 fails with a similar error
/builddir/build/BUILD/rtems-4.8-avr-rtems4.8-gcc-4.2.0/build/./gcc/xgcc
-B/builddir/build/BUILD/rtems-4.8-avr-rtems4.8-gcc-4.2.0/b
../../../../../../gcc-4.2.0
--- Additional Comments From ralf_corsepius at rtems dot org 2004-11-04 05:16
---
Thanks, yes, 15342 looks very similar.
And yes, it does not ice at -O2 (This is what I had meant by writing "it does
not ice at optimization levels < 3").
--
http://gcc.gnu
--- Additional Comments From ralf_corsepius at rtems dot org 2004-11-04 04:42
---
Created an attachment (id=7470)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7470&action=view)
*.i of a real world source files triggering the ICE
--
http://gcc.gnu.org/bugzilla/show_bug
ummary: ICE
Product: gcc
Version: 3.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ralf_corsepius at rtems dot org
CC: gcc-bugs at gcc dot
--
What|Removed |Added
CC||joel at oarcorp dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18251
--- Additional Comments From ralf_corsepius at rtems dot org 2004-10-31 12:53
---
Created an attachment (id=7441)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7441&action=view)
example code to reproduce the breakdown.
The example code is a stripped down version of a much
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ralf_corsepius at rtems dot org
CC: gcc-bugs at gcc dot gnu dot org
GCC target triplet: avr*
http://gcc.gnu.org
--- Additional Comments From ralf_corsepius at rtems dot org 2004-10-17 20:07
---
(In reply to comment #7)
> *** Bug 18039 has been marked as a duplicate of this bug. ***
I can confirm that the bug I had reported in PR 18039, does not occur anymore with
today's GCC from gcc-3
--- Additional Comments From ralf_corsepius at rtems dot org 2004-10-17 09:09
---
Created an attachment (id=7367)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7367&action=view)
Stripped down, preprocessed source code to trigger the ICE.
--
http://gcc.gnu.org/b
cc dot gnu dot org
ReportedBy: ralf_corsepius at rtems dot org
CC: gcc-bugs at gcc dot gnu dot org,joel at oarcorp dot com
GCC target triplet: avr-*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18039
--- Additional Comments From ralf_corsepius at rtems dot org 2004-10-13 14:41
---
(In reply to comment #7)
> > Eric, do you happen to know when this bug first appeared?
I noticed it for the first time shortly before submitting this PR (Opened:
2004-03-17; cf. above;).
I don&#x
--- Additional Comments From ralf_corsepius at rtems dot org 2004-10-04 13:22
---
1. I am used to my patches being ignored :(
Therefore I usually attach them to a PR they are trying to solve to prevent them
from being ignored.
2. Note that http://gcc.gnu.org/contribute.html doesn&#
--- Additional Comments From ralf_corsepius at rtems dot org 2004-10-04 12:51
---
1. The PR is against 3.4-branch, because this is what I am using, what I tested
the patch with and what I am reporting the bug against.
2. The patch applies to HEAD without changes.
3. Why is GCC asking
38 matches
Mail list logo
