On Mon, 23 Nov 2020, Thomas Koenig wrote: > > Well it does not: > > > > In file included from .../libgfortran/generated/maxval_r4.c:26: > > .../libgfortran/generated/maxval_r4.c: In function 'maxval_r4': > > .../libgfortran/libgfortran.h:292:30: warning: target format does not > > support infinity > > 292 | # define GFC_REAL_4_INFINITY __builtin_inff () > > | ^~~~~~~~~~~~~~ > > This is guarded with > > #ifdef __FLT_HAS_INFINITY__ > # define GFC_REAL_4_INFINITY __builtin_inff () > #endif > > I don't know how or why __FLT_HAS_INFINITY is set for a target which > does not support it, but if you get rid of that macro, that particular > problem should be solved.
Thanks for the hint; I didn't look into it any further not to distract myself from the scope of the project. I have now, and the check you have quoted is obviously broken (as are all the remaining similar ones), given: $ vax-netbsdelf-gcc -E -dM - < /dev/null | sort | grep _HAS_ #define __DBL_HAS_DENORM__ 0 #define __DBL_HAS_INFINITY__ 0 #define __DBL_HAS_QUIET_NAN__ 0 #define __FLT_HAS_DENORM__ 0 #define __FLT_HAS_INFINITY__ 0 #define __FLT_HAS_QUIET_NAN__ 0 #define __LDBL_HAS_DENORM__ 0 #define __LDBL_HAS_INFINITY__ 0 #define __LDBL_HAS_QUIET_NAN__ 0 $ which looks reasonable to me. This seems straightforward to fix to me, so I'll include it along with verification I am about to schedule (assuming that this will be enough for libgfortran to actually build; obviously it hasn't been tried by anyone with such a setup for a while now, as these libgfortran checks date back to 2009). Maciej
