On Wed, 18 Aug 2021, Sandra Loosemore wrote:
> I realized last week that having multilib-specific versions of
> ISO_Fortran_binding.h (generated by running the compiler to ask what kinds it
> supports) was still broken outside of the test support; the directory where
> it's being installed isn't on GCC's normal search path. It seemed to me that
> it was better to try to find some other solution for this problem than to
> venture down what appears to be a rat hole.
> 
> I've come up with this patch to return to a single ISO_Fortran_binding.h file
> that uses preprocessor magic to identify the Fortran kind corresponding to the
> standard C long double type and the GCC extension types __float128 and
> int128_t.
:
>  2021-08-18  Sandra Loosemore  <san...@codesourcery.com>
>    
>   libgfortran/
>       * ISO_Fortran_binding-1-tmpl.h: Deleted.
>       * ISO_Fortran_binding-2-tmpl.h: Deleted.
>       * ISO_Fortran_binding-3-tmpl.h: Deleted.
>       * ISO_Fortran_binding.h: New file to replace the above.
>       * Makefile.am (gfor_cdir): Remove MULTISUBDIR.
>       (ISO_Fortran_binding.h): Simplify to just copy the file.
>       * Makefile.in: Regenerated.
>       * mk-kinds-h.sh: Revert pieces no longer needed for
>       ISO_Fortran_binding.h.

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?


Hmm, I wonder whether this may be related to the bootstrap compiler,
which is clang 10.0.1 on FreeBSD 11 and 12.  Apparently not, since 
even setting CC and CXX to recent GCC builds the same issue occurs.

(Note this happens after stage 3, so in hindsight not too surprising
that it's independent of the bootstrap compiler.)

Gerald

Reply via email to