> -----Original Message----- > From: > avr-libc-dev-bounces+eric.weddington=atmel....@nongnu.org > [mailto:avr-libc-dev-bounces+eric.weddington=atmel....@nongnu. > org] On Behalf Of Wouter van Gulik > Sent: Thursday, June 17, 2010 1:18 PM > To: avr-libc-dev@nongnu.org > Subject: Re: [avr-libc-dev] LPM instructionsin optimized code > causes unintended behavior in execution > > On 17/06/10 10:15, Thomas Carsten Franke wrote: > > Am 17.06.2010 09:38, schrieb Wouter van Gulik: > > > >> Wouter van Gulik schreef: > >> > >>> Joerg Wunsch schreef: > >>> > >>>> As Wouter van Gulik wrote: > >>>> > >>>> > >>>>>> IMHO, the respective code is hand-crafted asm code in avr-libc. > >>>>>> > >>>>> Are you sure? The code is about a jump table, is that > in avr-libc? > >>>>> > >>>> Errm, you are right... > >>>> > >>> We should probably file a bug report at binutils as well. gas is > >>> excepting an 'illegal' instruction. This could mean gcc/gas also > >>> happily generates the undefined LD files? > >>> > >>> > > Just right now I added a problem report to gcc 4.3.3 > version describing > > the problem. > > Just for the record the gcc bug id is:44564 > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44564 > I think this is a nasty bug, but it is hard to recreate the > problem. I > did a quick scan of GCC but I can't find a reference to a lpm r?, Z+ > other than those to __temp_reg__.
Thanks for the bug ID. You can put me on the CC list of any bug. In a bug comment I asked for the generated assembly output from using -save-temps. This is important because there is another bug in the *disassembler*; IIRC, it spits out an "LPM r, Z+", when in reality it is an "LPM r, Z". That disassembler bug is not fixed yet. As a matter of fact.... (checking code and instruction set) The code you have in the bug report shows: 5808: f4 91 lpm r31, Z+ Take a long hard look at the hex instruction. Reverse the bytes: 91 F4 The LPM instruction in the instruction set document (page 91) shows this is Form 2 (ii) of the LPM instruction which is "LPM, r, Z", which is without the plus sign. Therefore this is not undefined. You've just rediscovered a different bug in binutils. Eric Weddington _______________________________________________ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev