avr-gcc-list
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [avr-gcc-list] Compiler bug ?


From: Marek Michalkiewicz
Subject: Re: [avr-gcc-list] Compiler bug ?
Date: Thu, 17 Apr 2003 22:57:27 +0200
User-agent: Mutt/1.4i

Hi,

On Thu, Apr 17, 2003 at 10:40:17PM +0400, Denis Chertykov wrote:
> > > foo.s foo.c: In function `DoDeadBand': foo.c:21: error: unable to
> > > generate reloads for: (insn:QI 31 28 32 2 006B7390 (set (cc0)
> > >         (compare (sign_extend:HI (reg/v:QI 24 r24 [42]))
> > >             (const_int -20 [0xffffffec]))) 94 {*cmpqi_sign_extend}
> > > (nil)
> > >     (nil))
> > > foo.c:21: internal compiler error: in find_reloads, at
> > > gcc/reload.c:3636

Looks like the second operand of *cmpqi_sign_extend is negatve, so
it doesn't meet the "M" constraint (value >= 0 && value <= 0xff).
It's not clear to me why is this insn needed at all - what does it
do that the second "cmpqi" alternative doesn't already?  Or should
a more selective predicate be used instead of immediate_operand?

     An operand whose predicate accepts only constant values is safe
     provided its constraints include the letter `i'.  If any possible
     constant value is accepted, then nothing less than `i' will do; if
     the predicate is more selective, then the constraints may also be
     more selective.

> > I'm trying to get a new WinAVR release out this week to address 
> > another compiler bug that was reported on avr-gcc-list earlier.
> 
> Please ! Collect all bugs in avr-gcc and send to me. I will try
> to fix all bugs.

Not that many bugs really :) - the previous bug (optimizing away
I/O port writes, as if there was no "volatile") has been fixed
(couldn't reproduce it in current 3.3 CVS).  I didn't do anything
to fix it, it must have been somewhere outside the AVR target.
The init_integral_libfuncs bug in CVS mainline is gone, too.

I can try to help with the easier bugs, leaving only the most
interesting ones for you ;)

There is one bug in binutils (bad ihex output from ld directly,
conversion from elf to ihex works fine).  Are there any good
reasons why in bfd/elf32-avr.c (elf_avr_howto_table) most of the
masks are 0xffff (IMHO should be 0x0f0f for all LDI relocs)?

Thanks,
Marek



reply via email to

[Prev in Thread] Current Thread [Next in Thread]