https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101918
--- Comment #17 from Steve Kargl <sgk at troutmask dot apl.washington.edu> --- On Mon, Aug 30, 2021 at 07:08:07PM +0000, rimvydas.jas at gmail dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101918 > > --- Comment #16 from Rimvydas (RJ) <rimvydas.jas at gmail dot com> --- > (In reply to Steve Kargl from comment #15) > > I'm also the person that made these options work > > for some definition of "work", and I have always considered > > these options to be broken because of what you are re-discovering. > > The words of caution for -freal-* and family of options also > > applies to the -fdefault-* options. I suspect much of work > > done on the intrinsics modules is done independently and > > obliviously to these options. > Statement like this implies that gfortran does *not* properly support > variables > using explicit kinds like selected_real_kind(13,300) or real(kind=8) or > real(kind=16) or ISO_C_BINDING ones other than default plain REAL. From > -ftree-dump-original dumps it is seen that even plain REAL or DOUBLE PRECISION > are assigned REAL(KIND=N) for all types, like > static real(kind=8) b[4] = {[0 ... 3]=1.0e+0}; gfortran works just fine if one DOES NOT USE DUBIOUS OPTIONS to try to change the precision of a type to another precision. There is Fortran code in libgfortran that is compiled by gfortran when the compiler is built. Whether that code works as intended when someone uses -fdefault-* or -freal-* family options remains to be seen. The ISO C Binding module is built on-the-fly, so will likely work except it cannot change the properties of the companion C types. REAL(c_float) should map to C's float. Fortunately, -fdefault-real-8 does not promote REAL(c_float) (aka REAL(4)) to REAL(8); OTOH -freal-4-real-8 will do the promotion. The IEEE ARITHMETIC module is partially built on-the-fly when compiling code with some information coming from files in gcc/libgfortran/ieee. Those files are compiled when gfortran is builti. I don't know if anyone has extensively tried these options with IEEE modules. > > > COMMON, EQUIVALENCE, and BOZ are not legacy features. > > These are full fledged features of modern Fortran. > Some people still prefer to use Hollerith constants, implicit types, statement > functions, arithmetic if's, shared do terminations, fixed source form, even > PAUSE and there is nothing wrong with it. Still, these are not related to > this > PR. > Of course, these new red herring aren't related to this PR. COMMON, EQUIVALENCE, BOZ, external subprogram, etc are related because these are affected by mucking around with storage assocation and the ABI.