* [Bug target/52488] avr-*: internal compiler error: in extract_insn, at recog.c:2123
2012-03-05 7:40 [Bug target/52488] New: avr-*: internal compiler error: in extract_insn, at recog.c:2123 ralf_corsepius at rtems dot org
@ 2012-03-11 22:31 ` gjl at gcc dot gnu.org
2012-03-12 6:22 ` ralf_corsepius at rtems dot org
` (14 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: gjl at gcc dot gnu.org @ 2012-03-11 22:31 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52488
Georg-Johann Lay <gjl at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |WAITING
Last reconfirmed| |2012-03-11
CC| |gjl at gcc dot gnu.org
Ever Confirmed|0 |1
--- Comment #1 from Georg-Johann Lay <gjl at gcc dot gnu.org> 2012-03-11 22:30:17 UTC ---
Would you please add a test case following the instructions in
http://gcc.gnu.org/bugs/#need
BTW, this appreas to be a frame pointer adjustment for a device with 8-bit SP.
Allocating 2050 bytes of stack space on a device with 8-bit SP is not going to
produce a reasonable executable, anyway.
^ permalink raw reply [flat|nested] 17+ messages in thread* [Bug target/52488] avr-*: internal compiler error: in extract_insn, at recog.c:2123
2012-03-05 7:40 [Bug target/52488] New: avr-*: internal compiler error: in extract_insn, at recog.c:2123 ralf_corsepius at rtems dot org
2012-03-11 22:31 ` [Bug target/52488] " gjl at gcc dot gnu.org
@ 2012-03-12 6:22 ` ralf_corsepius at rtems dot org
2012-03-12 11:12 ` gjl at gcc dot gnu.org
` (13 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: ralf_corsepius at rtems dot org @ 2012-03-12 6:22 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52488
--- Comment #2 from Ralf Corsepius <ralf_corsepius at rtems dot org> 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)
gcc from gcc-4_7-branch
../gcc-4.7.0-RC-20120302/configure --prefix=/opt/rtems-4.11
--bindir=/opt/rtems-4.11/bin --exec_prefix=/opt/rtems-4.11
--includedir=/opt/rtems-4.11/include --libdir=/opt/rtems-4.11/lib
--libexecdir=/opt/rtems-4.11/libexec --mandir=/opt/rtems-4.11/share/man
--infodir=/opt/rtems-4.11/share/info --datadir=/opt/rtems-4.11/share
--build=x86_64-unknown-linux-gnu --host=x86_64-unknown-linux-gnu
--target=avr-rtems4.11 --disable-libstdcxx-pch --with-gnu-as --with-gnu-ld
--verbose --with-newlib --with-system-zlib --disable-nls
--without-included-gettext --disable-win32-registry
--enable-version-specific-runtime-libs --enable-threads --disable-lto
--disable-plugin --enable-newlib-io-c99-formats --enable-newlib-iconv
--enable-languages=c
...
make
...
/builddir/build/BUILD/rtems-4.11-avr-rtems4.11-gcc-4.7.0/build/./gcc/xgcc
-B/builddir/build/BUILD/rtems-4.11-avr-rtems4.11-gcc-4.7.0/build/./gcc/
-nostdinc
-B/builddir/build/BUILD/rtems-4.11-avr-rtems4.11-gcc-4.7.0/build/avr-rtems4.11/tiny-stack/newlib/
-isystem
/builddir/build/BUILD/rtems-4.11-avr-rtems4.11-gcc-4.7.0/build/avr-rtems4.11/tiny-stack/newlib/targ-include
-isystem
/builddir/build/BUILD/rtems-4.11-avr-rtems4.11-gcc-4.7.0/gcc-4.7.0-RC-20120302/newlib/libc/include
-B/opt/rtems-4.11/avr-rtems4.11/bin/ -B/opt/rtems-4.11/avr-rtems4.11/lib/
-isystem /opt/rtems-4.11/avr-rtems4.11/include -isystem
/opt/rtems-4.11/avr-rtems4.11/sys-include -mmcu=at90s2313
-DPACKAGE_NAME=\"newlib\" -DPACKAGE_TARNAME=\"newlib\"
-DPACKAGE_VERSION=\"1.20.0\" -DPACKAGE_STRING=\"newlib\ 1.20.0\"
-DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -I.
-I../../../../../../gcc-4.7.0-RC-20120302/newlib/libc/posix -Os
-DPREFER_SIZE_OVER_SPEED -mcall-prologues -D_COMPILING_NEWLIB -DMALLOC_PROVIDED
-DEXIT_PROVIDED -DSIGNAL_PROVIDED -DREENTRANT_SYSCALLS_PROVIDED
-DHAVE_NANOSLEEP -DHAVE_BLKSIZE -DHAVE_FCNTL -DHAVE_ASSERT_FUNC -D_NO_GETLOGIN
-D_NO_GETPWENT -D_NO_GETUT -D_NO_GETPASS -D_NO_SIGSET -D_NO_WORDEXP -D_NO_POPEN
-fno-builtin -D_GNU_SOURCE -g -O2 -c -o lib_a-glob.o `test -f 'glob.c' ||
echo '../../../../../../gcc-4.7.0-RC-20120302/newlib/libc/posix/'`glob.c
../../../../../../gcc-4.7.0-RC-20120302/newlib/libc/posix/glob.c: In function
'glob':
../../../../../../gcc-4.7.0-RC-20120302/newlib/libc/posix/glob.c:206:1: error:
unrecognizable insn:
(insn/f 305 304 306 2 (set (reg:QI 28 r28)
(plus:QI (reg:QI 28 r28)
(const_int -2050 [0xfffffffffffff7fe])))
../../../../../../gcc-4.7.0-RC-20120302/newlib/libc/posix/glob.c:160 -1
(expr_list:REG_CFA_ADJUST_CFA (set (reg/f:HI 28 r28)
(plus:HI (reg/f:HI 28 r28)
(const_int -2050 [0xfffffffffffff7fe])))
(nil)))
../../../../../../gcc-4.7.0-RC-20120302/newlib/libc/posix/glob.c:206:1:
internal compiler error: in extract_insn, at recog.c:2123
One-tree-style bootstrap (comprising newlib), using
avr-rtems4.11-binutils-2.22, newlib-1.20 + rtems patches (glob.c is part of
newlib)
on fedora-16-x86_64.
^ permalink raw reply [flat|nested] 17+ messages in thread* [Bug target/52488] avr-*: internal compiler error: in extract_insn, at recog.c:2123
2012-03-05 7:40 [Bug target/52488] New: avr-*: internal compiler error: in extract_insn, at recog.c:2123 ralf_corsepius at rtems dot org
2012-03-11 22:31 ` [Bug target/52488] " gjl at gcc dot gnu.org
2012-03-12 6:22 ` ralf_corsepius at rtems dot org
@ 2012-03-12 11:12 ` gjl at gcc dot gnu.org
2012-03-12 12:38 ` gjl at gcc dot gnu.org
` (12 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: gjl at gcc dot gnu.org @ 2012-03-12 11:12 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52488
Georg-Johann Lay <gjl at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |ice-on-valid-code
Priority|P3 |P4
Status|WAITING |NEW
Version|unknown |4.7.0
Target Milestone|--- |4.7.1
--- Comment #3 from Georg-Johann Lay <gjl at gcc dot gnu.org> 2012-03-12 11:11:49 UTC ---
Confirmed for the followin test case
void bar (char*);
void foo (void)
{
char c[2000];
bar (c);
}
and compiled with
$ avr-gcc sp.c -S -mmcu=attiny2313
The program should not run into ICE, there should be a proper error message.
^ permalink raw reply [flat|nested] 17+ messages in thread* [Bug target/52488] avr-*: internal compiler error: in extract_insn, at recog.c:2123
2012-03-05 7:40 [Bug target/52488] New: avr-*: internal compiler error: in extract_insn, at recog.c:2123 ralf_corsepius at rtems dot org
` (2 preceding siblings ...)
2012-03-12 11:12 ` gjl at gcc dot gnu.org
@ 2012-03-12 12:38 ` gjl at gcc dot gnu.org
2012-03-12 12:55 ` jakub at gcc dot gnu.org
` (11 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: gjl at gcc dot gnu.org @ 2012-03-12 12:38 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52488
--- Comment #4 from Georg-Johann Lay <gjl at gcc dot gnu.org> 2012-03-12 12:37:24 UTC ---
Created attachment 26878
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26878
pr52488.diff
Does this patch fix the ICE for you?
^ permalink raw reply [flat|nested] 17+ messages in thread* [Bug target/52488] avr-*: internal compiler error: in extract_insn, at recog.c:2123
2012-03-05 7:40 [Bug target/52488] New: avr-*: internal compiler error: in extract_insn, at recog.c:2123 ralf_corsepius at rtems dot org
` (3 preceding siblings ...)
2012-03-12 12:38 ` gjl at gcc dot gnu.org
@ 2012-03-12 12:55 ` jakub at gcc dot gnu.org
2012-03-12 14:16 ` gjl at gcc dot gnu.org
` (10 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: jakub at gcc dot gnu.org @ 2012-03-12 12:55 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52488
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jakub at gcc dot gnu.org
--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-03-12 12:55:14 UTC ---
+ size_max = (1 << GET_MODE_BITSIZE (GET_MODE (my_fp))) - 1;
+ if (size >= size_max)
Do you have a guarantee that GET_MODE_BITSIZE here is never 32 or more?
(1 << GET_MODE_BITSIZE (GET_MODE (my_fp))) - 1 is GET_MODE_MASK (GET_MODE
(my_fp)). And, why >= ? Subtracting 255 for 8-bit fp or 65535 for 16-bit fp
should still work.
^ permalink raw reply [flat|nested] 17+ messages in thread* [Bug target/52488] avr-*: internal compiler error: in extract_insn, at recog.c:2123
2012-03-05 7:40 [Bug target/52488] New: avr-*: internal compiler error: in extract_insn, at recog.c:2123 ralf_corsepius at rtems dot org
` (4 preceding siblings ...)
2012-03-12 12:55 ` jakub at gcc dot gnu.org
@ 2012-03-12 14:16 ` gjl at gcc dot gnu.org
2012-03-13 3:28 ` ralf_corsepius at rtems dot org
` (9 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: gjl at gcc dot gnu.org @ 2012-03-12 14:16 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52488
--- Comment #6 from Georg-Johann Lay <gjl at gcc dot gnu.org> 2012-03-12 14:15:48 UTC ---
(In reply to comment #5)
> + size_max = (1 << GET_MODE_BITSIZE (GET_MODE (my_fp))) - 1;
> + if (size >= size_max)
> Do you have a guarantee that GET_MODE_BITSIZE here is never 32 or more?
Yes, Pmode is HImode is 16 bits. For 8-bit SP targets only the lower 8 bits of
the SP hard register are changed which saves some bytes of code and avoids
writing the SP_H register which is not present on these devices. For teh latter
case, mode is QImode.
> (1 << GET_MODE_BITSIZE (GET_MODE (my_fp))) - 1 is GET_MODE_MASK (GET_MODE
> (my_fp)).
Not exactly; the latter is unsigned.
> And, why >= ? Subtracting 255 for 8-bit fp or 65535 for 16-bit fp
> should still work.
This line saturates to 255 instead of to 256 because the next line effectively
does size = size % 256 which would yield size = 0 for specific values. This
lead to yet another ICE because it results in SP = SP insn which does not
exist.
I tried to keep the change minimal.
Therefore, the patch uses 255 instead of 256. As of the hardware layout of
these small devices, there is already some margin for sane memory sizes resp.
SP offsets: The device in question has a RAM of 128 bytes located at
0x60..0xbf. The next bigger devices have 256 bytes of RAM located at
0x60..0x15f and RAM crosses the 0x100 border so that these devices use a 16-bit
SP.
My intention was to be conservative and not to put too much effort and changes
to support insane code that definitely breaks if executed.
avr-gcc 4.7 implements PR51345 which result in new multilib variants for tiny
devices with only 8-bit SP.
newlib derives its build configury from -print-multi-directory or whatever and
tries to build insane code with 2050 bytes of stack for device(s) with only 128
bytes of RAM.
^ permalink raw reply [flat|nested] 17+ messages in thread* [Bug target/52488] avr-*: internal compiler error: in extract_insn, at recog.c:2123
2012-03-05 7:40 [Bug target/52488] New: avr-*: internal compiler error: in extract_insn, at recog.c:2123 ralf_corsepius at rtems dot org
` (5 preceding siblings ...)
2012-03-12 14:16 ` gjl at gcc dot gnu.org
@ 2012-03-13 3:28 ` ralf_corsepius at rtems dot org
2012-03-13 5:38 ` eric.weddington at atmel dot com
` (8 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: ralf_corsepius at rtems dot org @ 2012-03-13 3:28 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52488
--- Comment #7 from Ralf Corsepius <ralf_corsepius at rtems dot org> 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.c:206:1: error:
allocating 2050 bytes of stack is more than 'at90s2313' can provide
make[8]: *** [lib_a-glob.o] Error 1
=> Progress, at least no ICE.
However, this warning still leaves users in unclearity as GCC doesn't tell the
maximum of stack it can provide.
(In reply to comment #6)
> avr-gcc 4.7 implements PR51345 which result in new multilib variants for tiny
> devices with only 8-bit SP.
>
> newlib derives its build configury from -print-multi-directory
Yes, that's the way multilibs are being built ever since multilibs exists (> 20
years?).
> or whatever and
> tries to build insane code with 2050 bytes of stack for device(s) with only 128
> bytes of RAM.
Well, my view is different: The avr's default set of multilib variants is
non-suitable as general default set of multlib variants. It probably is
suiteable as set of multilibs for bare-metal targets, but does not meet the
demands of OSes.
That said, I feel RTEMS needs to implement custom multilibs for the avr.
^ permalink raw reply [flat|nested] 17+ messages in thread* [Bug target/52488] avr-*: internal compiler error: in extract_insn, at recog.c:2123
2012-03-05 7:40 [Bug target/52488] New: avr-*: internal compiler error: in extract_insn, at recog.c:2123 ralf_corsepius at rtems dot org
` (6 preceding siblings ...)
2012-03-13 3:28 ` ralf_corsepius at rtems dot org
@ 2012-03-13 5:38 ` eric.weddington at atmel dot com
2012-03-13 6:17 ` ralf_corsepius at rtems dot org
` (7 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: eric.weddington at atmel dot com @ 2012-03-13 5:38 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52488
--- Comment #8 from Eric Weddington <eric.weddington at atmel dot com> 2012-03-13 05:37:45 UTC ---
(In reply to comment #7)
> ../../../../../../gcc-4.7.0-RC-20120302/newlib/libc/posix/glob.c:206:1: error:
> allocating 2050 bytes of stack is more than 'at90s2313' can provide
> make[8]: *** [lib_a-glob.o] Error 1
>
> => Progress, at least no ICE.
>
> However, this warning still leaves users in unclearity as GCC doesn't tell the
> maximum of stack it can provide.
You can look up in the device datasheet to see how much RAM it has.
Or do you want GCC to print out how much RAM each device has?
>
> > or whatever and
> > tries to build insane code with 2050 bytes of stack for device(s) with only 128
> > bytes of RAM.
> Well, my view is different: The avr's default set of multilib variants is
> non-suitable as general default set of multlib variants. It probably is
> suiteable as set of multilibs for bare-metal targets, but does not meet the
> demands of OSes.
Do you have recommendations? Or better still, a patch?
^ permalink raw reply [flat|nested] 17+ messages in thread* [Bug target/52488] avr-*: internal compiler error: in extract_insn, at recog.c:2123
2012-03-05 7:40 [Bug target/52488] New: avr-*: internal compiler error: in extract_insn, at recog.c:2123 ralf_corsepius at rtems dot org
` (7 preceding siblings ...)
2012-03-13 5:38 ` eric.weddington at atmel dot com
@ 2012-03-13 6:17 ` ralf_corsepius at rtems dot org
2012-03-13 7:03 ` j at uriah dot heep.sax.de
` (6 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: ralf_corsepius at rtems dot org @ 2012-03-13 6:17 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52488
--- Comment #9 from Ralf Corsepius <ralf_corsepius at rtems dot org> 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 another.
> Or do you want GCC to print out how much RAM each device has?
No, I would expect GCC to print its rationale for this rejection.
e.g. something like
"allocating 2050 byte of stack exceeds maximum stack size (1024 bytes) ..."
> > Well, my view is different: The avr's default set of multilib variants is
> > non-suitable as general default set of multlib variants. It probably is
> > suiteable as set of multilibs for bare-metal targets, but does not meet the
> > demands of OSes.
>
> Do you have recommendations? Or better still, a patch?
We will see, I am currently looking into implementing custom multilibs for
avr-RTEMS, which may result into a patch addressing this as a side-effect.
However, the avr's multilib implementation diverges from what is used almost
elsewhere in GCC to an extend, this is a tedious.
^ permalink raw reply [flat|nested] 17+ messages in thread* [Bug target/52488] avr-*: internal compiler error: in extract_insn, at recog.c:2123
2012-03-05 7:40 [Bug target/52488] New: avr-*: internal compiler error: in extract_insn, at recog.c:2123 ralf_corsepius at rtems dot org
` (8 preceding siblings ...)
2012-03-13 6:17 ` ralf_corsepius at rtems dot org
@ 2012-03-13 7:03 ` j at uriah dot heep.sax.de
2012-03-13 11:26 ` gjl at gcc dot gnu.org
` (5 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: j at uriah dot heep.sax.de @ 2012-03-13 7:03 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52488
Joerg Wunsch <j at uriah dot heep.sax.de> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |j at uriah dot heep.sax.de
--- Comment #10 from Joerg Wunsch <j at uriah dot heep.sax.de> 2012-03-13 07:02:51 UTC ---
(In reply to comment #9)
> > Or do you want GCC to print out how much RAM each device has?
> No, I would expect GCC to print its rationale for this rejection.
>
> e.g. something like
> "allocating 2050 byte of stack exceeds maximum stack size (1024 bytes) ..."
There is no fixed stack size in GCC. It's just the SRAM size sets an
upper limit for the largest possible stack size. Thus Eric's question
about printing out the RAM size.
^ permalink raw reply [flat|nested] 17+ messages in thread* [Bug target/52488] avr-*: internal compiler error: in extract_insn, at recog.c:2123
2012-03-05 7:40 [Bug target/52488] New: avr-*: internal compiler error: in extract_insn, at recog.c:2123 ralf_corsepius at rtems dot org
` (9 preceding siblings ...)
2012-03-13 7:03 ` j at uriah dot heep.sax.de
@ 2012-03-13 11:26 ` gjl at gcc dot gnu.org
2012-03-13 11:29 ` gjl at gcc dot gnu.org
` (4 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: gjl at gcc dot gnu.org @ 2012-03-13 11:26 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52488
--- Comment #11 from Georg-Johann Lay <gjl at gcc dot gnu.org> 2012-03-13 11:25:04 UTC ---
(In reply to comment #7)
> However, this warning still leaves users in unclearity as GCC doesn't tell the
> maximum of stack it can provide.
The compiler does not know. It can estimate the RAM size from the width of the
stack pointer, but it's just a guess.
> The avr's default set of multilib variants is non-suitable as general
> default set of multlib variants. It probably is suiteable as set of
> multilibs for bare-metal targets, but does not meet the demands of OSes.
>
> That said, I feel RTEMS needs to implement custom multilibs for the avr.
There is a patch at
http://gcc.gnu.org/ml/gcc-patches/2012-03/msg00811.html
that is less strict and allows to build insane code without error. If user
wants to ensure reasonable code, he can use
-Wlarger-than=len
-Wframe-larger-than=len
-Wstack-usage=len
or whatever to let the compiler complain if unappropriate code will be
generated.
BTW: The -mmcu=at90s2313 from above is fallout from -print-multi-lib. The first
two configurations are phantom configurations that should not be there.
tiny-stack;@mmcu=at90s2313
avr25/tiny-stack;@mmcu=attiny13
.;
avr25;@mmcu=avr25
avr3;@mmcu=avr3
avr31;@mmcu=avr31
avr35;@mmcu=avr35
avr4;@mmcu=avr4
avr5;@mmcu=avr5
avr51;@mmcu=avr51
avr6;@mmcu=avr6
avrxmega2;@mmcu=avrxmega2
avrxmega4;@mmcu=avrxmega4
avrxmega5;@mmcu=avrxmega5
avrxmega6;@mmcu=avrxmega6
avrxmega7;@mmcu=avrxmega7
tiny-stack;@mtiny-stack
avr25/tiny-stack;@mmcu=avr25@mtiny-stack
^ permalink raw reply [flat|nested] 17+ messages in thread* [Bug target/52488] avr-*: internal compiler error: in extract_insn, at recog.c:2123
2012-03-05 7:40 [Bug target/52488] New: avr-*: internal compiler error: in extract_insn, at recog.c:2123 ralf_corsepius at rtems dot org
` (10 preceding siblings ...)
2012-03-13 11:26 ` gjl at gcc dot gnu.org
@ 2012-03-13 11:29 ` gjl at gcc dot gnu.org
2012-03-13 17:04 ` ralf_corsepius at rtems dot org
` (3 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: gjl at gcc dot gnu.org @ 2012-03-13 11:29 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52488
--- Comment #12 from Georg-Johann Lay <gjl at gcc dot gnu.org> 2012-03-13 11:28:32 UTC ---
Author: gjl
Date: Tue Mar 13 11:28:25 2012
New Revision: 185329
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=185329
Log:
PR target/52488
* config/avr/avr.c (avr_prologue_setup_frame): Cut down stack
offset (size) to a value the insns can deal with.
(expand_epilogue): Ditto.
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/avr/avr.c
^ permalink raw reply [flat|nested] 17+ messages in thread* [Bug target/52488] avr-*: internal compiler error: in extract_insn, at recog.c:2123
2012-03-05 7:40 [Bug target/52488] New: avr-*: internal compiler error: in extract_insn, at recog.c:2123 ralf_corsepius at rtems dot org
` (11 preceding siblings ...)
2012-03-13 11:29 ` gjl at gcc dot gnu.org
@ 2012-03-13 17:04 ` ralf_corsepius at rtems dot org
2012-03-13 18:19 ` gjl at gcc dot gnu.org
` (2 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: ralf_corsepius at rtems dot org @ 2012-03-13 17:04 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52488
--- Comment #13 from Ralf Corsepius <ralf_corsepius at rtems dot org> 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 configuration.
FYI: I could provide an alternative configuration for RTEMS, but avr-gcc-4.7.0
currently does not build at all due to
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52925 rsp.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52575.
^ permalink raw reply [flat|nested] 17+ messages in thread* [Bug target/52488] avr-*: internal compiler error: in extract_insn, at recog.c:2123
2012-03-05 7:40 [Bug target/52488] New: avr-*: internal compiler error: in extract_insn, at recog.c:2123 ralf_corsepius at rtems dot org
` (12 preceding siblings ...)
2012-03-13 17:04 ` ralf_corsepius at rtems dot org
@ 2012-03-13 18:19 ` gjl at gcc dot gnu.org
2012-03-22 15:13 ` gjl at gcc dot gnu.org
2012-03-22 15:36 ` gjl at gcc dot gnu.org
15 siblings, 0 replies; 17+ messages in thread
From: gjl at gcc dot gnu.org @ 2012-03-13 18:19 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52488
--- Comment #14 from Georg-Johann Lay <gjl at gcc dot gnu.org> 2012-03-13 18:16:04 UTC ---
(In reply to comment #13)
> FYI: I could provide an alternative configuration for RTEMS, but avr-gcc-4.7.0
> currently does not build at all due to
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52925 rsp.
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52575.
52925 does not exists. You mean PR50925 ?
These bugs are hard to fix and open since over 2 years now, see PR42204
You might get around these by building with -fno-caller-saves which avoids the
spill fails in some situations. I don't know if someone is working on these
issues. AVR with its register layout is real stress test for the register
allocator, but AVR is neither primary nor secondary platform so that such bugs
are outside the focus of GCC developers.
^ permalink raw reply [flat|nested] 17+ messages in thread* [Bug target/52488] avr-*: internal compiler error: in extract_insn, at recog.c:2123
2012-03-05 7:40 [Bug target/52488] New: avr-*: internal compiler error: in extract_insn, at recog.c:2123 ralf_corsepius at rtems dot org
` (13 preceding siblings ...)
2012-03-13 18:19 ` gjl at gcc dot gnu.org
@ 2012-03-22 15:13 ` gjl at gcc dot gnu.org
2012-03-22 15:36 ` gjl at gcc dot gnu.org
15 siblings, 0 replies; 17+ messages in thread
From: gjl at gcc dot gnu.org @ 2012-03-22 15:13 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52488
--- Comment #15 from Georg-Johann Lay <gjl at gcc dot gnu.org> 2012-03-22 15:07:31 UTC ---
Author: gjl
Date: Thu Mar 22 15:06:57 2012
New Revision: 185697
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=185697
Log:
libgcc/
Backport from 2012-03-07 mainline r185033.
PR target/52507
* config/avr/lib1funcs.S (__movmemx_hi): Fix loop label in RAM-part.
Backport from 2012-03-07 mainline r185031.
PR target/52505
* config/avr/lib1funcs.S (__xload_1): Don't read unintentionally
from RAM.
Backport from 2012-03-07 mainline r185030.
PR target/52461
PR target/52508
* config/avr/lib1funcs.S (__do_copy_data): Clear RAMPZ after usage
if RAMPZ affects reading from RAM.
(__tablejump_elpm__): Ditto.
(.xload): Ditto.
(__movmemx_hi): Ditto.
(__do_global_ctors): Right condition for RAMPZ usage is "have ELPM".
(__do_global_dtors): Ditto.
(__xload_1, __xload_2, __xload_3, __xload_4): Ditto.
(__movmemx_hi): Ditto.
gcc/
Backport from 2012-03-22 mainline r185692.
PR target/52496
* config/avr/avr.md (unspec): Remove UNSPEC_MEMORY_BARRIER.
(unspecv): Add UNSPECV_MEMORY_BARRIER.
(cli_sei): Use unspec_volatile instead of unspec for memory barrier.
(delay_cycles_1, delay_cycles_2): Ditto.
(delay_cycles_3, delay_cycles_4): Ditto.
(nopv, *nopv): Ditto.
(sleep, *sleep): Ditto.
(wdr, *wdr): Ditto.
Backport from 2012-03-21 mainline r185605.
PR rtl-optimization/52543
PR target/52461
* config/avr/avr-protos.h (avr_load_lpm): New prototype.
* config/avr/avr.c (avr_mode_dependent_address_p): New function.
(TARGET_MODE_DEPENDENT_ADDRESS_P): New define.
(avr_load_libgcc_p): Restrict to __flash loads.
(avr_out_lpm): Only handle 1-byte loads from __flash.
(avr_load_lpm): New function.
(avr_find_unused_d_reg): Remove.
(avr_out_lpm_no_lpmx): Remove.
(adjust_insn_length): Handle ADJUST_LEN_LOAD_LPM.
* config/avr/avr.md (unspec): Add UNSPEC_LPM.
(load_<mode>_libgcc): Use UNSPEC_LPM instead of MEM.
(load_<mode>, load_<mode>_clobber): New insns.
(mov<mode>): For multi-byte move from non-generic
16-bit address spaces: Expand to load_<mode> resp.
load_<mode>_clobber.
(load<mode>_libgcc): Remove expander.
(split-lpmx): Remove split.
Backport from 2012-03-13 mainline r185329.
PR target/52488
* config/avr/avr.c (avr_prologue_setup_frame): Cut down stack
offset (size) to a value the insns can deal with.
(expand_epilogue): Ditto.
Backport from 2012-03-12 mainline r185256.
PR target/52499
* config/avr/avr.c (avr_mode_code_base_reg_class): Change return
type from reg_class_t to enum reg_class.
* config/avr/avr-protos.h (avr_mode_code_base_reg_class): Ditto.
Backport from 2012-03-12 mainline r185253.
PR target/52148
* config/avr/avr.c (avr_out_movmem): Fix typo in output template
for the case ADDR_SPACE_FLASH and AVR_HAVE_LPMX introduced in
r184615 from 2012-02-28.
Backport from 2012-03-08 mainline r185105.
* config/avr/avr.md (*addhi3, addhi3_clobber): Add "w" alternative
for constants in [-63,63].
Backport from 2012-03-08 mainline r185100.
PR target/52496
* config/avr/avr.c (avr_mem_clobber): New static function.
(avr_expand_delay_cycles): Add memory clobber operand to
delay_cycles_1, delay_cycles_2, delay_cycles_3, delay_cycles_4.
* config/avr/avr.md (unspec): Add UNSPEC_MEMORY_BARRIER.
(enable_interrupt, disable_interrupt): New expander.
(nopv, sleep, wdr): New expanders.
(delay_cycles_1): Add memory clobber.
(delay_cycles_2): Add memory clobber.
(delay_cycles_3): Add memory clobber.
(delay_cycles_4): Add memory clobber.
(cli_sei): New insn from former "enable_interrupt",
"disable_interrupt" with memory clobber.
(*wdt): New insn from former "wdt" with memory clobber.
(*nopv): Similar, but for "nopv".
(*sleep): Similar, but for "sleep".
Backport from 2012-03-07 mainline r185043.
PR target/52484
* config/avr/avr.md (xload<mode>_A): Add R22... to register footprint.
Backport from 2012-03-07 mainline r185032.
PR target/52506
* gcc/config/avr/avr.c (expand_epilogue): Fix order of restoration
to: RAMPZ, RAMPY, RAMPX, RAMPD.
(expand_prologue): Only clear RAMPZ if it has effect on RAM-read.
Backport from 2012-03-07 mainline r185031.
PR target/52505
* config/avr/avr.c (avr_out_xload): Don't read unintentionally
from RAM.
* config/avr/avr.md (xload_8): Adjust insn length.
Backport from 2012-03-07 mainline r185030.
PR target/52461
* gcc/config/avr/avr.c (avr_out_lpm): Clear RAMPZ after usage
if RAMPZ affects reading from RAM.
Backport from 2012-03-05 mainline r184919.
* config/avr/avr.md (*umaddqihi4.2): New insn-and-split.
Modified:
branches/gcc-4_7-branch/gcc/ChangeLog
branches/gcc-4_7-branch/gcc/config/avr/avr-protos.h
branches/gcc-4_7-branch/gcc/config/avr/avr.c
branches/gcc-4_7-branch/gcc/config/avr/avr.md
branches/gcc-4_7-branch/libgcc/ChangeLog
branches/gcc-4_7-branch/libgcc/config/avr/lib1funcs.S
^ permalink raw reply [flat|nested] 17+ messages in thread* [Bug target/52488] avr-*: internal compiler error: in extract_insn, at recog.c:2123
2012-03-05 7:40 [Bug target/52488] New: avr-*: internal compiler error: in extract_insn, at recog.c:2123 ralf_corsepius at rtems dot org
` (14 preceding siblings ...)
2012-03-22 15:13 ` gjl at gcc dot gnu.org
@ 2012-03-22 15:36 ` gjl at gcc dot gnu.org
15 siblings, 0 replies; 17+ messages in thread
From: gjl at gcc dot gnu.org @ 2012-03-22 15:36 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52488
Georg-Johann Lay <gjl at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #16 from Georg-Johann Lay <gjl at gcc dot gnu.org> 2012-03-22 15:32:41 UTC ---
Fixed in 4.7.1
^ permalink raw reply [flat|nested] 17+ messages in thread