rtems gcc 4.6.1 can not compile stop at check TLS

[Ralf Corsepius]

On 08/29/2011 05:47 PM, Sebastien Bourdeauducq wrote:
> On Wed, 2011-08-24 at 16:26 +0200, Ralf Corsepius wrote:
>> I regret having to say so, my feel about this patch is "short-sighted
>> featuritis", blowing up the toolchain beyond reason.
> This patch actually _decreases_ software bloat where it matters, namely
> on the embedded system targeted by RTEMS. Using software emulation of
> the divider (or the other CPU features we want multilibs for) when the
> hardware divider is available only makes code slower and larger. Newlib
> does make use of these features.
Adding multilibs needs to be carefully balanced and compromises to be 
taken. i.e. on one hand, toolchain implementors need to find balanced 
compromises between "speed", "size", "number of multilibs" and "number 
of users", on the other hand, users need to learn to live with 
"sub-optimality".

It's the same, what you do when using a mainstream OS - You are using 
binaries which have been compiled by a setup to support a "main-stream" 
target audience, which means it, is using a compromise between several 
factors.

Simply adding a mulitlib for each and every flag a compiler supports 
simply not useful - Think about the zoo of cpu variants/instruction-set 
variants the i?86 cpu-family consists of. It's simply unmanageable to 
implement a multilib for each of them, nor is it useful, because most of 
these variants would only provide microscopic gains.

> If you do not want too many multilibs (which aren't much of a problem
> given the cost of mainstream CPUs and storage those days) just build one
> lib with all the CPU options enabled. This is what we (the Milkymist
> project) implement, and we are by far the largest user of the LM32
> target (the only other LM32 BSP, lm32_evr, is - by the words of its
> developer - "not really used yet for anything serious"). Currently, we
> cannot use your LM32 toolchain binaries because they lack this feature
> we need. What is the point of shipping software that almost no one uses?
>
> This multilib patch is upstream GCC already.
ROTFL, implemented, submitted and commited by you!

If gcc-4.6.1 would build (which it, as I told you several times before, 
it doesn't), I likely already would have implemented custom multilibs 
for lm32-rtems (Which is what we already do for many targets), which 
likely would revert this change.

> In a nutshell: just build the libraries with all the CPU options enabled
> into the LM32 RTEMS toolchain. It is the right thing to do.
This is the first time I am hearing this-Patch proposals welcome.

Ralf