https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101918
--- Comment #15 from Steve Kargl <sgk at troutmask dot apl.washington.edu> --- On Mon, Aug 30, 2021 at 05:11:12PM +0000, rimvydas.jas at gmail dot com wrote: > 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: When g95 was imported into GCC, I am the person that changed g95's -r8 option into gfortran's -fdefault-real-8 (along with -i8) option. 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. > -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. 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. Feel free to update the documentation. It may be prudent to add a sentence that states "These options are intended to be used as aids when porting code from one precision to another, and may not be suitable for production use." or similar. > > 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 COMMON, EQUIVALENCE, and BOZ are not legacy features. These are full fledged features of modern Fortran. While COMMON and EQUIVALENCE may be frowned upon with an eye toward usings MODULEs, BOZ is quite different and alive. In particular, I wrote the BOZ support and rewrote to conform to the F2018 standard. F202x is extending where and how BOZ can/should be handled. The original problem is simply another manifestation of why these options should be avoided, if not removed from gfortran. In your original example, you have changed the ABI between foo.o and bar.o, which now confuses lto.
