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
