From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 60CB23858414; Mon, 30 Aug 2021 18:26:20 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 60CB23858414 From: "sgk at troutmask dot apl.washington.edu" To: gcc-bugs@gcc.gnu.org Subject: [Bug fortran/101918] LTO type mismatches for runtime library functions in mixed -fdefault-real-8 projects Date: Mon, 30 Aug 2021 18:26:20 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: fortran X-Bugzilla-Version: 11.2.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: sgk at troutmask dot apl.washington.edu X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: gcc-bugs@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-bugs mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Aug 2021 18:26:20 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D101918 --- Comment #15 from Steve Kargl = --- On Mon, Aug 30, 2021 at 05:11:12PM +0000, rimvydas.jas at gmail dot com wro= te: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D101918 >=20 > --- Comment #14 from Rimvydas (RJ) --- > (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, whil= e: 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 af= fects > 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-rea= l-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=20 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 comm= on > with original PR report or more trivial _gfortran_reshape_r8 example in C= omment > #8 COMMON, EQUIVALENCE, and BOZ are not legacy features. These are full fledged features of modern Fortran.=20 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=20 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.=