Re: GCC bug?
Browsing the GCC source, I found this in gcc/config/avr/avr.c if (AVR_HAVE_RAMPZ && TEST_HARD_REG_BIT (set, REG_Z) && TEST_HARD_REG_BIT (set, REG_Z + 1)) { emit_push_sfr (rampz_rtx, false /* frame */, AVR_HAVE_RAMPD, treg); } I wont pretend to fully understand this part of the compiler, but that AVR_HAVE_RAMPD looks shady to me? Anyone with deeper knowledge want to have a look? -Ian Hi Ian, the code is as intended: It's during ISR prologue where we determine whether RAMPZ has to be saved / restored. Conditions are that: 1) RAMPZ exists and 2) Z register is used. The call to emit_push_sfr() to push RAMPZ has argument clr_p = HAVE_RAMPD (sic!) because we have two cases when RAMPZ might occur: A) The hardware has RAMPZ but none of the other RAMP* registers. This is the case on devices with more than 64 KiB of flash and with RAM less than 64 KiB. RAMPZ is only used to augment ELPM. The rule is that any insn may use and clobber RAMPZ as needed *without* the requirement to restore the previous value. B) The hardware has more than 64 KiB of RAM and all RAMP registers are present. The convention is that all RAMP* registers contain a value of zero. If an insn clobbers RAMP*, it has to restore its value. Consequently, upon entering an ISR, some RAMPZ might be non-zero, but the compiler expects all RAMP registers to contain zero. As both cases A) and B) have RAMPZ, AVR_HAVE_RAMPZ cannot be used to discriminate these cases, but AVR_HAVE_RAMPD *does* discriminate. There are similar use cases of AVR_HAVE_RAMPD in the startup code or after using ELPM, for example at the end of avr.cc::avr_out_lpm(): if (xop[4] == xstring_e && AVR_HAVE_RAMPD) { /* Reset RAMPZ to 0 so that EBI devices don't read garbage from RAM. */ xop[0] = zero_reg_rtx; avr_asm_len ("out %i6,%0", xop, plen, 1); } xop[6] is RAMPZ, and xop[4] == xstring_e if ELPM was used. Johann
Re: GCC bug?
Ah, this becomes (somewhat) clearer now. And then not... Following it through, it seems that its possible to generate two slightly differing prologues; ignoring other registers, and assuming a tmp reg (r0), you get: move treg, rampd push treg move rampd, 0 ... move treg, rampz push treg if AVR_HAVE_RAMP{D,Z} but this: mov treg, rampz push treg mov rampz, 0 if only AVR_HAVE_RAMPZ is set, with an extra clear of the z register that weasnt there before. So on AVRs with both RAMPD and RAMPZ, RAMPD is cleared, but RAMPZ is not. I presume then that the compiler treats RAMPZ specially on those parts, never assuming it to be zero. ...but then why doesn't that apply on parts with RAMPZ, but without RAMPD (most AVRs?) I dont see anything in the gcc-avr ABI docs that states it treats RAMPZ differently on different AVRs... Its also counter to the comment a few lines above that reads: /* Push and clear RAMPD/X/Y/Z if present and low-part register is used. ??? There are no dwarf2 columns reserved for RAMPD/X/Y/Z. */ which seems to imply that RAMPZ is to be zeroed unconditionally. -Ian On 17/12/2021 22:01, Bruce D. Lightner wrote: > Ian, > > Trying again... :-) > > No, the "last one" should NOT be AVR_HAVE_RAMPZ. > > The Z register and the RAMPD register are used together to address > memory in an AVR part which supports RAMPD. > > Some later AVR micrcontrollers have a "Z" register (i.e., AVR_HAVE_RAMPZ > is set). Newer, more capable versions of those same AVR parts can ALSO > have a "RAMPD" register (i.e., AVR_HAVE_RAMPD is set). If the AVR part > has a "RAMPD" register then it will ALWAYS have a "Z" register. > > The code you referenced changes the behavior of "emit_push_sfr()" > depending upon whether the AVR part has both registers or only the Z > register. > > If there is no Z register then there NEVER is a RAMPD register. In that > case neither AVR_HAVE_RAMPZ or AVR_HAVE_RAMPD will be set and > "emit_push_sfr()" will never be called in the context you referenced. > > Best regards, > > Bruce > > > On 12/17/2021 1:33 PM, Ian Molton wrote: >> Ok, I don't want to sound rude, but did anyone actually *read* what I wrote? >> >> I'll highlight the parts of lines in question this time, perhaps that >> will help... >> >> if (AVR_HAVE_RAMPZ >> ^^ >>&& TEST_HARD_REG_BIT (set, REG_Z) >>&& TEST_HARD_REG_BIT (set, REG_Z + 1)) >> { >>emit_push_sfr (rampz_rtx, false /* frame */, AVR_HAVE_RAMPD, >> ^^ >> treg); >> } >> >> OVER HERE ->--^ >> >> >> Either I'm missing something here, or someone needs to explain to me why >> a test for AVR_HAVE_RAMPZ preceeds the use of AVR_HAVE_RAMPD in the code. >> >> Shouldn't that last one also be RAMPZ ? >> >> If not, why? >> >> -Ian >> >> >> On 17/12/2021 16:53, Bruce D. Lightner wrote: >>> Ian, >>> >>> I apologize if I was being obtuse! :-) >>> >>> The AVR_HAVE_RAMPD #define tells the routine "emit_push_sfr()" to save >>> the RAMPD register, but only if the third parameter to the call is >>> non-zero. The constant AVR_HAVE_RAMPD will be non-zero if the AVR >>> micro-architecture supports a RAMPD register. >>> >>> That's why you see the code you reported. Much older versions of >>> avr-gcc have "emit_push_sfr()" source code with one less parameter >>> (i.e., no AVR_HAVE_RAMPD reference) because the RAMPD "paging" register >>> is a relatively "new" AVR feature. >>> >>> Best regards, >>> >>> Bruce >>> >>> >>> On 12/17/2021 5:39 AM, Ian Molton wrote: I think you misunderstood me; I know this is where the compiler will save RAMPZ where needed. So why is it referencing RAMP *D* ? On 17/12/2021 00:50, Bruce D. Lightner wrote: > Ian, > > Just from a purely AVR architecture point of view, the AVR_HAVE_RAMPD > #define indicates that the AVR chip in question supports the "RAMP" > paging register, described as follows: > > *RAMPD* > Register concatenated with the Z-register enabling direct addressing > of the whole data space on MCUs > with more than 64KB data space. > > Eventually the originally tiny AVR chips' addressable memory got so big > that we needed a "paging" register. (That's a repeating theme with > every 8-bit/16-bit microcontroller family.) > > So the "RAMPD" register needs to be saved along with the X, Y and Z > "special function" registers, if it is present. > > Best regards, > > Bruce > > > On 12/16/2021 3:46 PM, Ian Molton wrote: >> Browsing the GCC source, I found this in gcc/config/avr/avr.c >>
Re: GCC bug?
Ian, Trying again... :-) No, the "last one" should NOT be AVR_HAVE_RAMPZ. The Z register and the RAMPD register are used together to address memory in an AVR part which supports RAMPD. Some later AVR micrcontrollers have a "Z" register (i.e., AVR_HAVE_RAMPZ is set). Newer, more capable versions of those same AVR parts can ALSO have a "RAMPD" register (i.e., AVR_HAVE_RAMPD is set). If the AVR part has a "RAMPD" register then it will ALWAYS have a "Z" register. The code you referenced changes the behavior of "emit_push_sfr()" depending upon whether the AVR part has both registers or only the Z register. If there is no Z register then there NEVER is a RAMPD register. In that case neither AVR_HAVE_RAMPZ or AVR_HAVE_RAMPD will be set and "emit_push_sfr()" will never be called in the context you referenced. Best regards, Bruce On 12/17/2021 1:33 PM, Ian Molton wrote: Ok, I don't want to sound rude, but did anyone actually *read* what I wrote? I'll highlight the parts of lines in question this time, perhaps that will help... if (AVR_HAVE_RAMPZ ^^ && TEST_HARD_REG_BIT (set, REG_Z) && TEST_HARD_REG_BIT (set, REG_Z + 1)) { emit_push_sfr (rampz_rtx, false /* frame */, AVR_HAVE_RAMPD, ^^ treg); } OVER HERE ->--^ Either I'm missing something here, or someone needs to explain to me why a test for AVR_HAVE_RAMPZ preceeds the use of AVR_HAVE_RAMPD in the code. Shouldn't that last one also be RAMPZ ? If not, why? -Ian On 17/12/2021 16:53, Bruce D. Lightner wrote: Ian, I apologize if I was being obtuse! :-) The AVR_HAVE_RAMPD #define tells the routine "emit_push_sfr()" to save the RAMPD register, but only if the third parameter to the call is non-zero. The constant AVR_HAVE_RAMPD will be non-zero if the AVR micro-architecture supports a RAMPD register. That's why you see the code you reported. Much older versions of avr-gcc have "emit_push_sfr()" source code with one less parameter (i.e., no AVR_HAVE_RAMPD reference) because the RAMPD "paging" register is a relatively "new" AVR feature. Best regards, Bruce On 12/17/2021 5:39 AM, Ian Molton wrote: I think you misunderstood me; I know this is where the compiler will save RAMPZ where needed. So why is it referencing RAMP *D* ? On 17/12/2021 00:50, Bruce D. Lightner wrote: Ian, Just from a purely AVR architecture point of view, the AVR_HAVE_RAMPD #define indicates that the AVR chip in question supports the "RAMP" paging register, described as follows: *RAMPD* Register concatenated with the Z-register enabling direct addressing of the whole data space on MCUs with more than 64KB data space. Eventually the originally tiny AVR chips' addressable memory got so big that we needed a "paging" register. (That's a repeating theme with every 8-bit/16-bit microcontroller family.) So the "RAMPD" register needs to be saved along with the X, Y and Z "special function" registers, if it is present. Best regards, Bruce On 12/16/2021 3:46 PM, Ian Molton wrote: Browsing the GCC source, I found this in gcc/config/avr/avr.c if (AVR_HAVE_RAMPZ && TEST_HARD_REG_BIT (set, REG_Z) && TEST_HARD_REG_BIT (set, REG_Z + 1)) { emit_push_sfr (rampz_rtx, false /* frame */, AVR_HAVE_RAMPD, treg); } I wont pretend to fully understand this part of the compiler, but that AVR_HAVE_RAMPD looks shady to me? Anyone with deeper knowledge want to have a look? -Ian -- *Bruce D. Lightner* *Lightner Engineering* La Jolla, California 92037-3044 Email: light...@lightner.net URL: http://www.lightner.net/lightner/bruce/
Re: GCC bug?
Ok, I don't want to sound rude, but did anyone actually *read* what I wrote? I'll highlight the parts of lines in question this time, perhaps that will help... if (AVR_HAVE_RAMPZ ^^ && TEST_HARD_REG_BIT (set, REG_Z) && TEST_HARD_REG_BIT (set, REG_Z + 1)) { emit_push_sfr (rampz_rtx, false /* frame */, AVR_HAVE_RAMPD, ^^ treg); } OVER HERE ->--^ Either I'm missing something here, or someone needs to explain to me why a test for AVR_HAVE_RAMPZ preceeds the use of AVR_HAVE_RAMPD in the code. Shouldn't that last one also be RAMPZ ? If not, why? -Ian On 17/12/2021 16:53, Bruce D. Lightner wrote: > Ian, > > I apologize if I was being obtuse! :-) > > The AVR_HAVE_RAMPD #define tells the routine "emit_push_sfr()" to save > the RAMPD register, but only if the third parameter to the call is > non-zero. The constant AVR_HAVE_RAMPD will be non-zero if the AVR > micro-architecture supports a RAMPD register. > > That's why you see the code you reported. Much older versions of > avr-gcc have "emit_push_sfr()" source code with one less parameter > (i.e., no AVR_HAVE_RAMPD reference) because the RAMPD "paging" register > is a relatively "new" AVR feature. > > Best regards, > > Bruce > > > On 12/17/2021 5:39 AM, Ian Molton wrote: >> I think you misunderstood me; >> >> I know this is where the compiler will save RAMPZ where needed. >> >> So why is it referencing RAMP *D* ? >> >> On 17/12/2021 00:50, Bruce D. Lightner wrote: >>> Ian, >>> >>> Just from a purely AVR architecture point of view, the AVR_HAVE_RAMPD >>> #define indicates that the AVR chip in question supports the "RAMP" >>> paging register, described as follows: >>> >>> *RAMPD* >>> Register concatenated with the Z-register enabling direct addressing >>> of the whole data space on MCUs >>> with more than 64KB data space. >>> >>> Eventually the originally tiny AVR chips' addressable memory got so big >>> that we needed a "paging" register. (That's a repeating theme with >>> every 8-bit/16-bit microcontroller family.) >>> >>> So the "RAMPD" register needs to be saved along with the X, Y and Z >>> "special function" registers, if it is present. >>> >>> Best regards, >>> >>> Bruce >>> >>> >>> On 12/16/2021 3:46 PM, Ian Molton wrote: Browsing the GCC source, I found this in gcc/config/avr/avr.c if (AVR_HAVE_RAMPZ && TEST_HARD_REG_BIT (set, REG_Z) && TEST_HARD_REG_BIT (set, REG_Z + 1)) { emit_push_sfr (rampz_rtx, false /* frame */, AVR_HAVE_RAMPD, treg); } I wont pretend to fully understand this part of the compiler, but that AVR_HAVE_RAMPD looks shady to me? Anyone with deeper knowledge want to have a look? -Ian >>> > > -- > *Bruce D. Lightner* > *Lightner Engineering* > La Jolla, CA > Email: light...@lightner.net > URL: http://www.lightner.net/lightner/bruce/
Re: GCC bug?
Ian, I apologize if I was being obtuse! :-) The AVR_HAVE_RAMPD #define tells the routine "emit_push_sfr()" to save the RAMPD register, but only if the third parameter to the call is non-zero. The constant AVR_HAVE_RAMPD will be non-zero if the AVR micro-architecture supports a RAMPD register. That's why you see the code you reported. Much older versions of avr-gcc have "emit_push_sfr()" source code with one less parameter (i.e., no AVR_HAVE_RAMPD reference) because the RAMPD "paging" register is a relatively "new" AVR feature. Best regards, Bruce On 12/17/2021 5:39 AM, Ian Molton wrote: I think you misunderstood me; I know this is where the compiler will save RAMPZ where needed. So why is it referencing RAMP *D* ? On 17/12/2021 00:50, Bruce D. Lightner wrote: Ian, Just from a purely AVR architecture point of view, the AVR_HAVE_RAMPD #define indicates that the AVR chip in question supports the "RAMP" paging register, described as follows: *RAMPD* Register concatenated with the Z-register enabling direct addressing of the whole data space on MCUs with more than 64KB data space. Eventually the originally tiny AVR chips' addressable memory got so big that we needed a "paging" register. (That's a repeating theme with every 8-bit/16-bit microcontroller family.) So the "RAMPD" register needs to be saved along with the X, Y and Z "special function" registers, if it is present. Best regards, Bruce On 12/16/2021 3:46 PM, Ian Molton wrote: Browsing the GCC source, I found this in gcc/config/avr/avr.c if (AVR_HAVE_RAMPZ && TEST_HARD_REG_BIT (set, REG_Z) && TEST_HARD_REG_BIT (set, REG_Z + 1)) { emit_push_sfr (rampz_rtx, false /* frame */, AVR_HAVE_RAMPD, treg); } I wont pretend to fully understand this part of the compiler, but that AVR_HAVE_RAMPD looks shady to me? Anyone with deeper knowledge want to have a look? -Ian -- *Bruce D. Lightner* *Lightner Engineering* La Jolla, CA Email: light...@lightner.net URL: http://www.lightner.net/lightner/bruce/
Re: GCC bug?
Maybe one day even a problem in 32bit architectures. On Thu, Dec 16, 2021 at 7:50 PM Bruce D. Lightner wrote: > Ian, > > Just from a purely AVR architecture point of view, the AVR_HAVE_RAMPD > #define indicates that the AVR chip in question supports the "RAMP" paging > register, described as follows: > >*RAMPD* >Register concatenated with the Z-register enabling direct addressing of > the whole data space on MCUs >with more than 64KB data space. > > Eventually the originally tiny AVR chips' addressable memory got so big > that we needed a "paging" register. (That's a repeating theme with every > 8-bit/16-bit microcontroller family.) > > So the "RAMPD" register needs to be saved along with the X, Y and Z > "special function" registers, if it is present. > > Best regards, > > Bruce > > -- > On 12/16/2021 3:46 PM, Ian Molton wrote: > > Browsing the GCC source, I found this in gcc/config/avr/avr.c > > if (AVR_HAVE_RAMPZ > && TEST_HARD_REG_BIT (set, REG_Z) > && TEST_HARD_REG_BIT (set, REG_Z + 1)) > { > emit_push_sfr (rampz_rtx, false /* frame */, AVR_HAVE_RAMPD, > treg); > } > > > I wont pretend to fully understand this part of the compiler, but that > AVR_HAVE_RAMPD looks shady to me? > > Anyone with deeper knowledge want to have a look? > > -Ian > > > > > -- > *Bruce D. Lightner* > *Lightner Engineering* > 8551 La Jolla Shores Drive > La Jolla, California 92037-3044 > Mobile/SMS: +1-858-228-7579 > Voice: +1-858-551-0770 ext. 2 > Email: light...@lightner.net > URL: http://www.lightner.net/lightner/bruce/ > > *CONFIDENTIALITY NOTICE: This e-mail and any attachments may contain > confidential information intended solely for the use of the addressee. If > the reader of this message is not the intended recipient, any distribution, > copying, or use of this e-mail or its attachments is prohibited. If you > received this message in error, please notify the sender immediately by > e-mail and delete this message and any copies. Thank you.* >
Re: GCC bug?
Ian, Just from a purely AVR architecture point of view, the AVR_HAVE_RAMPD #define indicates that the AVR chip in question supports the "RAMP" paging register, described as follows: *RAMPD* Register concatenated with the Z-register enabling direct addressing of the whole data space on MCUs with more than 64KB data space. Eventually the originally tiny AVR chips' addressable memory got so big that we needed a "paging" register. (That's a repeating theme with every 8-bit/16-bit microcontroller family.) So the "RAMPD" register needs to be saved along with the X, Y and Z "special function" registers, if it is present. Best regards, Bruce On 12/16/2021 3:46 PM, Ian Molton wrote: Browsing the GCC source, I found this in gcc/config/avr/avr.c if (AVR_HAVE_RAMPZ && TEST_HARD_REG_BIT (set, REG_Z) && TEST_HARD_REG_BIT (set, REG_Z + 1)) { emit_push_sfr (rampz_rtx, false /* frame */, AVR_HAVE_RAMPD, treg); } I wont pretend to fully understand this part of the compiler, but that AVR_HAVE_RAMPD looks shady to me? Anyone with deeper knowledge want to have a look? -Ian -- *Bruce D. Lightner* *Lightner Engineering* 8551 La Jolla Shores Drive La Jolla, California 92037-3044 Mobile/SMS: +1-858-228-7579 Voice: +1-858-551-0770 ext. 2 Email: light...@lightner.net URL: http://www.lightner.net/lightner/bruce/ /CONFIDENTIALITY NOTICE: This e-mail and any attachments may contain confidential information intended solely for the use of the addressee. If the reader of this message is not the intended recipient, any distribution, copying, or use of this e-mail or its attachments is prohibited. If you received this message in error, please notify the sender immediately by e-mail and delete this message and any copies. Thank you./
GCC bug?
Browsing the GCC source, I found this in gcc/config/avr/avr.c if (AVR_HAVE_RAMPZ && TEST_HARD_REG_BIT (set, REG_Z) && TEST_HARD_REG_BIT (set, REG_Z + 1)) { emit_push_sfr (rampz_rtx, false /* frame */, AVR_HAVE_RAMPD, treg); } I wont pretend to fully understand this part of the compiler, but that AVR_HAVE_RAMPD looks shady to me? Anyone with deeper knowledge want to have a look? -Ian
[avr-gcc-list] Ways to fix gcc bug - builtin_return_address
Anatoly and others. Well the next bug on list of testsuite execute/torture failures for AVR is for gcc's builtin_return_address. This function is rarely used. But instead of ignoring it, it would be better to fix it, that change test to exclude AVR. Target is supposed to tell gcc the RTL address of the return address on the stack - from frame level. But at present it just adds 1 to frame pointer. So its wrong if anything is saved on stack - and/or there are local variables on stack) - duh! We don't need any backs traces and there are other targets that only give return address for current frame. So only level 0 matters. The correct way is to get frame size and subtract that from frame pointer. Frame size is only known in late stages of compilation - so there needs to be a forward reference. There would appear to be 3 ways I can do this 1) Create UNSPEC instruction that loads register with frame size (which will be known when instructions is output) 2) Create UNSPEC instruction that defines symbol= frame_size. 3) Find some way to get gcc output (2) rather than use UNSPEC. What do you suggest ? Andy ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
[avr-gcc-list] AVR GCC bug #34932
Hi All, For those who are interested, I filed GCC bug #34932: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34932 Which is from WinAVR bug #1860717: https://sourceforge.net/tracker/index.php?func=detailaid=1860717group _id=68108atid=520074 This is also now listed in the AVR toolchain bug list. Eric Weddington ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
[avr-gcc-list] avr-gcc bug 18251 not resolved (ice-on-valid-code)
Greetings, Bug 18251 as discussed in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18251 is afaict not fully resolved in gcc HEAD as of today. It compiles on 3.4.3 with no problems so this appears to be a 4.x regression. I have not filed a bug report with gcc bugzilla as I have never done this and I don't want to bug the developers with stupid errors on my part. The code snippet used to be part of an MD5 transform function but I have stripped it down to the point where it is still valid C code but does not do anything useful any more. In this state removing any of the remaining lines usually prevents the ICE from occurring, most notably the LPM macro (taken from avr-libc HEAD). Shall I file this with bugzilla? And more importantly, what's causing it and how can I fix this? Cheers, Stephan The code snippet below yields the following ICE: $ avr-gcc -Os -mmcu=atmega162 -c test.c test.c: In function 'test': test.c:46: error: unable to find a register to spill in class 'POINTER_REGS' test.c:46: error: this is the insn: (insn 18 115 20 0 (set (reg/v:SI 56 [ a ]) (mem:SI (post_inc:HI (reg/f:HI 22 r22 [orig:59 D.1226 ] [59])) [2 S4 A8])) 14 {*movsi} (insn_list:REG_DEP_TRUE 115 (nil)) (expr_list:REG_INC (reg/f:HI 22 r22 [orig:59 D.1226 ] [59]) (nil))) test.c:46: internal compiler error: in spill_failure, at reload1.c:1897 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. Compiler version: $ avr-gcc -v Using built-in specs. Target: avr Configured with: ../configure --target=avr --prefix=/home/eisvogel/avr --enable-languages=c,c++ --disable-nls Thread model: single gcc version 4.1.0 20050422 (experimental) --- TEST CASE START --- #define __LPM_enhanced__(addr) \ ({ \ unsigned int __addr16 = (unsigned int)(addr); \ unsigned char __result; \ __asm__ \ ( \ lpm %0, Z \n\t \ : =r (__result) \ : z (__addr16)\ ); \ __result; \ }) void test ( unsigned long *state ) { unsigned long a, b, c, d, temp; unsigned char i; a = state[0]; b = state[1]; c = state[2]; d = state[3]; for ( i=0 ; i2 ; i++ ) { temp = a; switch ( i ) { case 1: temp += (((b) (d)) | ((c) (~d))); } temp += __LPM_enhanced__( 0 ); a = d; d = c; c = b; b = temp; } state[0] += a; state[1] += b; state[2] += c; state[3] += d; } --- TEST CASE END --- ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] avr-gcc bug 18251 not resolved (ice-on-valid-code)
Stephan Eisvogel wrote: Greetings, Bug 18251 as discussed in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18251 is afaict not fully resolved in gcc HEAD as of today. It compiles on 3.4.3 with no problems so this appears to be a 4.x regression. I have not filed a bug report with gcc bugzilla as I have never done this and I don't want to bug the developers with stupid errors on my part. It won't bother the developers, in fact, any reports at all help tremendously. You don't need to worry about it. I would suggest that you go to that bug report and take all the information below and put it into the Additional Comments box and then save it. If you don't have a login name/password you'll have to create one; don't worry it's easy because the login is based on an email address. It's *very* important to get this information in the bug report itself, otherwise stuff like this gets lost in all the email traffic. Thanks Eric The code snippet used to be part of an MD5 transform function but I have stripped it down to the point where it is still valid C code but does not do anything useful any more. In this state removing any of the remaining lines usually prevents the ICE from occurring, most notably the LPM macro (taken from avr-libc HEAD). Shall I file this with bugzilla? And more importantly, what's causing it and how can I fix this? Cheers, Stephan The code snippet below yields the following ICE: $ avr-gcc -Os -mmcu=atmega162 -c test.c test.c: In function 'test': test.c:46: error: unable to find a register to spill in class 'POINTER_REGS' test.c:46: error: this is the insn: (insn 18 115 20 0 (set (reg/v:SI 56 [ a ]) (mem:SI (post_inc:HI (reg/f:HI 22 r22 [orig:59 D.1226 ] [59])) [2 S4 A8])) 14 {*movsi} (insn_list:REG_DEP_TRUE 115 (nil)) (expr_list:REG_INC (reg/f:HI 22 r22 [orig:59 D.1226 ] [59]) (nil))) test.c:46: internal compiler error: in spill_failure, at reload1.c:1897 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. Compiler version: $ avr-gcc -v Using built-in specs. Target: avr Configured with: ../configure --target=avr --prefix=/home/eisvogel/avr --enable-languages=c,c++ --disable-nls Thread model: single gcc version 4.1.0 20050422 (experimental) --- TEST CASE START --- #define __LPM_enhanced__(addr) \ ({ \ unsigned int __addr16 = (unsigned int)(addr); \ unsigned char __result; \ __asm__ \ ( \ lpm %0, Z \n\t \ : =r (__result) \ : z (__addr16)\ ); \ __result; \ }) void test ( unsigned long *state ) { unsigned long a, b, c, d, temp; unsigned char i; a = state[0]; b = state[1]; c = state[2]; d = state[3]; for ( i=0 ; i2 ; i++ ) { temp = a; switch ( i ) { case 1: temp += (((b) (d)) | ((c) (~d))); } temp += __LPM_enhanced__( 0 ); a = d; d = c; c = b; b = temp; } state[0] += a; state[1] += b; state[2] += c; state[3] += d; } --- TEST CASE END --- ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list