AW: [avr-gcc-list] Re: [Bug target/31786] error: unable to find a register to spill in class 'BASE_POINTER_REGS'

[Haase Bjoern (PT/EMM)]

Hi all,

I think that we could resolve this ICE by adding an unnamed pattern like

(define_insn "*strangeMovhi"
  [(set (mem:HI (plus:HI (reg:HI 28)
                         (const_int 1)))
        (match_operand:HI 0 "general_operand" "r"))]
  ""
  "st %A0,y+1 \n\t st %B0,y+2"
  [(set_attr "length" "2")])


to the machine description "avr.md" . That might cure the symptoms and does not 
resolve the underlying problem with reload, but this might be a fix for the 
immediate issue.

Note that above remark is untested pseudo-code.

Yours,

Bjoern.

P.S.: Eric, you might add this remark to the bugzilla entry.


-----Ursprüngliche Nachricht-----
Von: address@hidden [mailto:address@hidden Im Auftrag von Joel Sherrill
Gesendet: Donnerstag, 3. Mai 2007 22:39
An: Eric Weddington
Cc: address@hidden; 'Ralf Corsepius'
Betreff: [avr-gcc-list] Re: [Bug target/31786] error: unable to find a register 
to spill in class 'BASE_POINTER_REGS'

Eric Weddington wrote:
>  
>
>   
>> -----Original Message-----
>> From: Joel Sherrill [mailto:address@hidden 
>> Sent: Thursday, May 03, 2007 11:59 AM
>> To: Eric Weddington
>> Cc: 'Ralf Corsepius'; address@hidden
>> Subject: Re: [Bug target/31786] error: unable to find a 
>> register to spill in class 'BASE_POINTER_REGS'
>>
>>
>> But none of this justifies ignoring the original bug just because the 
>> code was
>> in newlib not avr-libc.  It is still a compiler bug and could 
>> eventually 
>> show
>> up somewhere else in code you really do care about.
>>     
>
> Of course not. I did not mean to imply that. Just as you well know, time and
> volunteers are hard to come by. I was hoping that perhaps a workaround (even
> as large as using avr-libc instead of newlib) would be a faster way to get
> you where you want to go. I have no idea how long it will take to fix this
> issue.
>
>   
We keep pushing RTEMS into smaller and smaller spaces so someday we 
might be in a
position to consider this.  But today it would just be a distraction.
> Another alternative would be to fall back to using 3.4.6, as that version
> seems to be fairly stable.
>   
Luckily one of the the things Ralf has contributed to RTEMS is an RPM 
infrastructure
that makes every targets tool versions and patch set independent.  They 
are generally
kept in sync but it does allow us to handle this possibility.  With 
tools provided for 11
target  architectures that is a necessity.

Right now, we are using gcc 4.0.3 for the avr with this same newlib.    And
it looks like 4.2.0 won't compile all RTEMS code for the PowerPC so the 
PowerPC
is likely to stay at 4.1.x until that bug is resolved.

--joel
> Eric
>
>   



_______________________________________________
AVR-GCC-list mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list