From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id C45F73858431; Mon, 30 Aug 2021 20:54:32 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org C45F73858431 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 20:54:32 +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 20:54:32 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D101918 --- Comment #17 from Steve Kargl = --- On Mon, Aug 30, 2021 at 07:08:07PM +0000, rimvydas.jas at gmail dot com wro= te: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D101918 >=20 > --- Comment #16 from Rimvydas (RJ) --- > (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=3D8) or > real(kind=3D16) or ISO_C_BINDING ones other than default plain REAL. From > -ftree-dump-original dumps it is seen that even plain REAL or DOUBLE PREC= ISION > are assigned REAL(KIND=3DN) for all types, like > static real(kind=3D8) b[4] =3D {[0 ... 3]=3D1.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=20 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. >=20 > > COMMON, EQUIVALENCE, and BOZ are not legacy features. > > These are full fledged features of modern Fortran.=20 > Some people still prefer to use Hollerith constants, implicit types, stat= ement > functions, arithmetic if's, shared do terminations, fixed source form, ev= en > PAUSE and there is nothing wrong with it. Still, these are not related t= o this > PR. >=20 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.=