gcc 3.3.5 arm-elf .. which multilib for soft-float?

[Joel Sherrill <joel@OARcorp.com>]

Richard Earnshaw wrote:
> On Tue, 2004-11-02 at 12:24, Joel Sherrill  wrote:
> 
>>Richard Earnshaw wrote:
>>
>>>On Tue, 2004-11-02 at 00:21, Joel Sherrill  wrote:
>>>
>>>
>>>>Hi,
>>>>
>>>>It looks like btween gcc 3.3.3 and 3.3.5, the file config/arm/t-arm-elf
>>>>was reworked.  I am getting linking errors which indicate that the
>>>>default libc.a is hard-float.
>>>>
>>>>The gcc documentation states that -mhard-float is the default for the
>>>>compiler and I only see these libc.a's
>>>>
>>>
>>>
>>>-mhard-float has *never* been the default for the arm-elf
>>>configuration.  In fact, AFAIK the only supported configuration of gcc
>>>on ARM that still uses the FPA hard-float format is Linux.
>>
>>I rather suspected this because I didn't recall any RTEMS user CPU model
>>I had ever looked at having hard float.
>>
>>But the gcc documentation states that hard-float is ALWAYS the default:
> 
> 
> The documentation is out of date.  There is a time when that was correct
> for all the (then) supported configurations, but it's now far from the
> truth.

Now things are becoming clearer.   Can you correct the 
soft-float/hard-float documentation?  You understand the situation better.

>>Given all that, why can't I link code when I use the -msoft-float flag.
>> From your description, it is redundant but it results in a string
>>of link errors like this:
>>
>>/../../arm-rtems4.7/bin/ld: failed to merge target specific data of file 
>>/opt/rtems-4.7/lib/gcc-lib/arm-rtems4.7/3.3.5/libgcc.a(_pack_sf.o)
>>
>>$ cat j.c
>>#include <math.h>
>>float f( float x)
>>{
>>   return sin(x);
>>
>>}
>>
>>$ /opt/rtems-4.7/bin/arm-rtems4.7-gcc j.c -O2 -lm
>># WORKS
>>$ /opt/rtems-4.7/bin/arm-rtems4.7-gcc -msoft-float  j.c -O2 -lm
>># FAILS with ERRORS
>>
> 
> 
> Ah!  I suspect you are trying to link some object compiled with
> -msoft-float with objects that were compiled with neither -msoft-float
> nor -mhard-float explicitly mentioned on the command line.  Gas assumes
> (incorrectly in this case) that if you don't specify -msoft-float you
> meant -mhard-float (the compiler makes the opposite assumption, but
> fails to pass on this information).

That makes sense.

Another similar side issue we have seen in the RTEMS world is that
there often should be come cpp predefine set when you switch a
CPU CFLAG and sometimes there isn't.  We have caught a number of these
over the past few years related to not being able to tell if
soft or hardware FP was selected.

It is important to make sure that gcc provides enough information for
libraries to tailor themselves to different multilibs.  RTEMS uses
multilibs to distinguish CPU issues -- soft float/hard float,
instruction presence (m68k especially here), register layour (mips),
etc.  Knowing the architectural variant correctly from the cpp
predefines is important.

> Ralf's patch should fix that issue, since it always passes something to
> the assembler; but you will have to rebuild any objects built without
> his patch applied.

It's not a problem to rebuild everything -- we have the source. :)

Ralf... I will rebuild with your patch and follow up.  With any luck,
we can beg Richard to review it and get things right on 3.3, 3.4 and the
head.

Ralf's patch addresses a similar side issue we have caught with RTEMS.
There should be come cpp predefine set when you switch a
CPU CFLAG and sometimes there isn't.  We have caught a number of these
over the past few years related to not being able to tell if
soft or hardware FP was selected.

It is important to make sure that gcc provides enough information for
libraries to tailor themselves to different multilibs.  RTEMS uses
multilibs to distinguish CPU issues -- soft float/hard float,
instruction presence (m68k especially here), register layour (mips),
etc.  Knowing the architectural variant correctly from the cpp
predefines is important.

There are other libraries that make similar distinctions.   I believe
the Standard C++ library is making pretty heavy use of multilib
distinguishing predefines in places.

> R.

--joel