From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
 id 030DE3858417; Mon, 30 Aug 2021 15:23:59 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 030DE3858417
From: "rimvydas.jas at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
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 15:23:59 +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: rimvydas.jas at gmail dot com
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: <bug-101918-4-Ckqk3ofDBf@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-101918-4@http.gcc.gnu.org/bugzilla/>
References: <bug-101918-4@http.gcc.gnu.org/bugzilla/>
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 <gcc-bugs.gcc.gnu.org>
List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc-bugs>,
 <mailto:gcc-bugs-request@gcc.gnu.org?subject=unsubscribe>
List-Archive: <https://gcc.gnu.org/pipermail/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-request@gcc.gnu.org?subject=help>
List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc-bugs>,
 <mailto:gcc-bugs-request@gcc.gnu.org?subject=subscribe>
X-List-Received-Date: Mon, 30 Aug 2021 15:24:00 -0000

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D101918

--- Comment #12 from Rimvydas (RJ) <rimvydas.jas at gmail dot com> ---
(In reply to kargl from comment #11)
> One of these is no like the others. Yes, the behavior is documented,
> and the unlike other result is likely the result that is no desired
> unless the user enjoys chancing numerical precision issues.
$ cat foo.f90=20
program foo
   implicit none
   real(kind=3D4) :: a, b
   real :: x, y
   x =3D 1.
   y =3D 3.14159
   a =3D 1._4
   b =3D 3.14159_4
   print *, a / b
   print *, x/ y
end program foo
$ gfortran foo.f90 && ./a.out
  0.318310142=20=20=20=20
  0.318310142=20=20=20=20
$ gfortran foo.f90 -fdefault-real-8 && ./a.out
  0.318310142=20=20=20=20
  0.31831015504887655=20=20=20=20=20
$ gfortran foo.f90 -freal-4-real-8 && ./a.out
  0.31831015504887655=20=20=20=20=20
  0.31831015504887655

Looks pretty consistent for me if proper types are used to match the kinds =
used
in constants like 3.14159_4. The same would apply for plain DOUBLE PRECISION
and 3.14159D numerical constants. Is this the only catch for -fdefault-* fa=
mily
of options?

> You need to use -fdefault-real-8 -fdefault-double-8 when compiling both
> files.  How is the 2nd invocation of gfortran to know that your first
> invocation of gfortran used incompatible options?
Incompatible how?  As far as executable linking is concerned the final link
could be performed by plain ld(1) on both foo.o and bar.o (or foo.o libbar.=
a)
provided that user links in the libgfortran.so too.  The -fdump-tree-origin=
al
-c outputs on both sources indicate that dump trees are identical (including
calls to _gfortran_reshape_r8() in libgfortran.so).=