https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94586
--- Comment #34 from Steve Kargl <sgk at troutmask dot apl.washington.edu> --- On Wed, Apr 22, 2020 at 04:02:01PM +0000, dave.anglin at bell dot net wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94586 > > --- Comment #33 from dave.anglin at bell dot net --- > On 2020-04-22 10:54 a.m., foreese at gcc dot gnu.org wrote: > > If you have a functional gfortran you can also generate it with > > "$GCCSOURCE/libgfortran/mk-kinds-h.sh gfortran". This header is supposed to > > expose the core type which gfortran uses for REAL(16) according to the > > target. > Looking at script, I see it has same logic to disambiguate long double and > float128: > 16) if [ $long_double_kind -eq 10 ]; then > ctype="__float128" > cplxtype="_Complex float __attribute__((mode(TC)))" > suffix="q" > else > ctype="long double" > cplxtype="complex long double" > suffix="l" > fi ;; > > It always selects long double when both are REAL(16). > Which is the correct assumption that I already explained. Both the ISO C binding module and the IEEE 754 modules assume a C99 type mapping. There are only 2 cases: REAL(4) <--> float ! f suffix REAL(8) <--> double ! no suffix REAL(10) <--> long double ! l suffix REAL(16) <--> __float128 ! q suffix or REAL(4) <--> float ! f suffix REAL(8) <--> double ! no suffix REAL(16) <--> long double ! l suffix (if long double exists) I suspect that having HPUX map REAL(4) <--> float ! f suffix REAL(8) <--> double ! no suffix REAL(16) <--> __float128 ! q suffix may cause issues with either ISO C binding or IEEE 754 module or both.
