[Top][All Lists]
[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
Re: [avr-gcc-list] Compiler bug ?, E. Weddington, 2003/04/16