[PATCH, Fortran] Revert to non-multilib-specific ISO_Fortran_binding.h

Sandra Loosemore sandra@codesourcery.com
Mon Sep 13 16:59:05 GMT 2021


On 9/13/21 10:51 AM, Jakub Jelinek wrote:
> On Mon, Sep 13, 2021 at 06:32:56PM +0200, Tobias Burnus wrote:
>> On 13.09.21 17:56, Gerald Pfeifer wrote:
>>> This broke bootstrap on i586-unknown-freebsd11:
>>>
>>>     In file included from .../GCC-HEAD/libgfortran/runtime/ISO_Fortran_binding.c:30:
>>>     .../GCC-HEAD/libgfortran/ISO_Fortran_binding.h:255:2:
>>>     error: #error "Can't determine kind of long double"
>>>     255 | #error "Can't determine kind of long double"
>>>         |  ^~~~~
>>>
>>> Does this work on i586-*-linux?
>>>
>>>
>>> % egrep -r '#define.*LDBL_(MANT_DIG|MIN_EXP|MAX_EXP)' /usr/include/
>>> /usr/include/x86/float.h:#define LDBL_MANT_DIG  64
>>> /usr/include/x86/float.h:#define LDBL_MIN_EXP   (-16381)
>>> /usr/include/x86/float.h:#define LDBL_MAX_EXP   16384
>>>
>>> This looks like it matches existing Linux case already in place?
>>
>> Can you run 'echo | cpp -E -g3|grep DBL' to (or in the build dir: echo |
>> ./gcc/cc1 -E -g3 -dD|grep DBL) to check what's the output?
>>
>> It might be that /usr/include/x86/float.h is not used; e.g. there is
>> $(gcc-src)/ginclude/float.h which undef's the LDBL_MAX_EXP to replace it
>> by a #define using __LDBL_MAX_EXP. Thus, if those are different from the
>> values under /usr/include, it might be the reason for the fail?
>>
>> I think it works under Linux, at least the "x86-64 -m32"
>> libgfortran.{so,a}  build and the -m32 testsuite runs do work.
> 
> Wouldn't it be better to use the __LDBL_* macros anyway and not rely on
> float.h?  The header doesn't want to test what float.h tells about the
> long double type, but what the compiler knows about it.

I originally wrote the code to use the internal GCC __LDBL_* macros as 
you suggest, but Tobias complained that then the gfortran-provided .h 
file could not be used to compile the C parts of the program with some 
other C compiler.  (I guess there are people out in the real world who 
want to mash up clang-compiled C code with gfortran programs).  Maybe it 
needs to first check the internal macros and then look for the float.h 
versions if it can't find them?

-Sandra


More information about the Fortran mailing list