rtems gcc 4.6.1 can not compile stop at check TLS

[Joel Sherrill]

Just to try to wrap this up:

+ There are both multiply-enabled and
mmultiply-enabled/mbarrel-shift-enabled lm32-rtems
multilib variants in both the 4.10 and 4.11 RPMs.  Is
this the desired set?

+ 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

+ The number of multilib variants per target varies from
1 to 15 for 4.11.  lm32 is at 4.  The distribution of number
of variants per architecture is:

Count Variants
       2     1
       1     2
       2     4
       1     5
       4     6
       1     7
       1     9
       1   11
       1   14
       1   15

I am not saying that any variant is not justified but 4 is
far from the worst case.  Taken a broad view, 10 of 15
targets have 6 or less.

Multilib variants are always a hot topic and justifying new
ones is always required.

I personally don't recall comparing the set for CPU-rtems with
the set produced by the related CPU-elf in a long time.  This
could result in discussing adding or deleting variants. But I
recall in the past we have had variants which were completely
justifiable but not in the CPU-elf target for unknown reasons.
So it wouldn't be an automatic decision to do anything.  Just
a discussion point on differences.

--joel

On 08/29/2011 12:46 PM, Sebastien Bourdeauducq wrote:
> On Mon, 2011-08-29 at 18:54 +0200, Ralf Corsepius wrote:
>> 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.
> And here the "main-stream" audience is mostly composed of... Milkymist
> users? isn't it?
>
>> 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.
> LM32 isn't x86. We are not talking about a "zoo" of options here.
>
>>> This multilib patch is upstream GCC already.
>> ROTFL, implemented, submitted and commited by you!
> This does not make this modification illegitimate.
>
>> If gcc-4.6.1 would build (which it, as I told you several times before,
>> it doesn't
> I never questioned that fact. I actually spent a few days trying to
> resolve the issue, without much success. If someone has a solution, I
> would be happy to apply it in a timely fashion - which does represent a
> progress compared to the total lack of interest for LM32 by the other
> GCC maintainers.
>
>> users need to learn to live with  "sub-optimality".
>> ), 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.
> You seem to have some fundamental disagreement with us trying to make a
> good and fast product...
>
> S.
>
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-users


-- 
Joel Sherrill, Ph.D.             Director of Research&  Development
joel.sherrill at OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
    Support Available             (256) 722-9985