Re: [avr-gcc-list] crosstool-NG

[Georg-Johann Lay]

Weddington, Eric schrieb:
> > -----Original Message----- From: Georg-Johann Lay
> > [mailto:address@hidden Sent: Friday, March 04, 2011 10:37 AM To:
> > Weddington, Eric Cc: Omar Choudary; address@hidden 
> > Subject: Re: [avr-gcc-list] crosstool-NG
> >
> > Besides that, I was astonished that fixing bugs resp. backporting
> > them is unwanted by GCC's avr backend maintainers. Would be great
> > if you would shed some light on that so I can understand it. How
> > should we get rid of bugs if not by fixing them?
>
>
> It's not that they are unwanted. It's how much effort should be
> involved in backporting to versions that are unlikely to be used by a
> majority of users. There are tradeoffs involved, that is all.

hmmm, I just wondered because the patches in question were ready to commit.

> Most users are using 4.4.x (via different toolchain distros). But
> 4.5.x is likely to come out next.

I don't know what toolchain versions avr developers actually prefer; 
maybe I am a bit WinAVR-centered (as far as Win32-hosts are concerned) 
and the newest version is the still GCC-supported 4.3.

But you are right. avr backend is short of developers, and effort should 
focus on newer versions.

> As much as we can make 4.5.x work and get bugs fixed there, then I
> think (but this is just IMHO) that would have the greatest impact on
> the most users.

The issue with 4.5 is that avr backend is lying in many places. Target 
avr has done this ever, but as gcc evolves we now see the penalties, 
i.e. inefficient code that I would not like in my projects. I don't know 
how important this is for other projcets, but it reveals many 
shortcomings in avr backend which imlpy the need of recrafting many 
parts of avr BE (constraint costs, address legitimation, no fake 
instructions, etc.). This is much work and needs extensive testing. 
Moreover, code growth does not show up in testsuite results.

May I ask what parts you are working on? It's just because I don't see 
it in svn logs yet.

Johann