[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
rtems gcc 4.6.1 can not compile stop at check TLS
- Date: Tue, 06 Sep 2011 13:03:17 +0200
- From: ralf.corsepius at rtems.org (Ralf Corsepius)
- Subject: rtems gcc 4.6.1 can not compile stop at check TLS
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?
> As far as we are concerned, we only need:
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?