rtems gcc 4.6.1 can not compile stop at check TLS

[Ralf Corsepius]

On 08/29/2011 11:45 PM, Sebastien Bourdeauducq wrote:
> On Mon, 2011-08-29 at 16:27 -0500, Joel Sherrill wrote:
>> + Is this a reasonable and meaningful set?
>>
>> /opt/rtems-4.11/lm32-rtems4.11/lib/mmultiply-enabled/libc.a
>> /opt/rtems-4.11/lm32-rtems4.11/lib/mmultiply-enabled/mbarrel-shift-enabled/libc.a
>> /opt/rtems-4.11/lm32-rtems4.11/lib/libc.a
>> /opt/rtems-4.11/lm32-rtems4.11/lib/mbarrel-shift-enabled/libc.a
>
> As far as we are concerned, we only need:
> mbarrel-shift-enabled/mmultiply-enabled/mdivide-enabled/msign-extend-enabled

I've added a patch implementing this to today's/yesterday's update of 
the lm32-rtems4.11 toolchains. Shouldn't somebody complain or this 
trigger bugs somewhere, I intend to propagate this change into upstream 
GCC-4_5-branch/4_6-branch and trunk in near future (say, end of this month).

[FYI: GCC-4_6-branch and GCC-trunk both still ICE for lm32 targets.]

> I'm not opposed to keeping the other libraries, nor even having all 16
> possible combinations (this number is unlikely to grow, as most of the
> LM32 opcodes are already used) - on desktop computers, CPU and storage
> are dirt cheap those days.

Agreed, as far as "mainstream desktops" are concerned, but not agreed 
wrt. "small mass market systems" (phones, routers, mp3-players etc) and 
embedded systems. For them, storage and CPU are a major cost factor 
and/or major factor reducing "system reliabilty".

> It may seem a bit weird, though, that someone
> would ever use e.g. a CPU with only the divider and nothing else, so if
> you want to be picky, some combinations can definitely be left out.
OK, if you say so - I am not sufficiently familiar with the lm32 to have 
an opinion on this. May-be upstream FSF GCC should consider this thought 
and reconsider their multilibs?

Ralf