https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101918
--- Comment #14 from Rimvydas (RJ) <rimvydas.jas at gmail dot com> --- (In reply to Steve Kargl from comment #13) > The -fdefault-* options change the storage association rules > in a way that breaks Fortran. Places of concern include, but > are not limited, to COMMON, EQUIVALENCE, maybe the TRANSFER > intrinsic, BOZ conversion, calling external routines, etc. Actually the https://gcc.gnu.org/onlinedocs/gfortran/Fortran-Dialect-Options.html and gfortran.1 manpage list this definition for -freal-*-real-* options, while: -fdefault-real-8 Set the default real type to an 8 byte wide type. This option also affects the kind of non-double real constants like 1.0. This option promotes the default width of DOUBLE PRECISION and double real constants like 1.d0 to 16 bytes if possible. If -fdefault-double-8 is given along with fdefault-real-8, DOUBLE PRECISION and double real constants are not promoted. Unlike -freal-4-real-8, fdefault-real-8 does not promote variables with explicit kind declarations. > And, no, I'm not wasting my time contriving examples to prove > that these options should be avoided. Fair enough, but these Fortran legacy features like COMMON, EQUIVALENCE, BOZ and calling external user routines without interface have nothing in common with original PR report or more trivial _gfortran_reshape_r8 example in Comment #8 I tried to get more information with lto-dump(1) tool, however lto-dump -dump-body=foo foo.o lto-dump -dump-body=bar bar.o outputs do not indicate any tree differences either. Is there a way to get more LTO information to understand the issue at hand?
