Michael Meissner <meiss...@linux.ibm.com> writes:
> On Fri, Jul 06, 2018 at 10:16:34AM -0300, Tulio Magno Quites Machado Filho
> wrote:
>> I suggest to test with the following program:
>>
>> #include <math.h>
>>
>> int
>> main ()
>> {
>> return !isinfl(__builtin_infl());
>> }
>>
>> Build it with:
>> gcc -mabi=ieeelongdouble -fno-builtin -Wno-psabi -lm test-ldbl.c
>>
>> If the execution of the program returns 0, your math library supports IEEE
>> long
>> double.
>
> Thanks, but I suspect that it won't work for building cross compilers
Indeed.
> or for building where the compiler built uses the Advance Toolchain libraries
> and
> shared library loader instead of the system versions using the configuration
> option --with-advance-toolchain=atx.y.
It should work. Maybe with extra compiler flags.
> The issue is you need to test whether the target GLIBC has the support when
> configuring the compiler, but if you are building for a cross target, you
> can't
> run the resulting binary.
Agreed.
> So I used the GLIBC version tests that were already part of the GCC
> configuration.
I understand, but those versions are incorrect. Let me elaborate:
1) There should be no special code for the Advance Toolchain because it uses
the same glibc as everyone else.
2) While glibc is under development, its version is based on the last released
version, e.g.: current master code has version 2.27.9000. That's why the
Advance Toolchain libraries you accessed had a minor version of 27.
So, when you say minor version 28, are you referring to 2.28, which doesn't
support IEEE long double or 2.28.9000 which will support IEEE long double?
> If there is a simple method that works for cross compilers or where a
> specified
> sysroot is used, it would be simpler than having version checks.
Ideally we would have a macro to identify this, but it's hard to rely
on a macro when the code is not upstream yet.
--
Tulio Magno
