From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 6C7533858010; Mon, 30 Aug 2021 14:34:16 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 6C7533858010 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 14:34:16 +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 14:34:16 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D101918 --- Comment #9 from Steve Kargl -= -- On Mon, Aug 30, 2021 at 10:26:59AM +0000, rimvydas.jas at gmail dot com wro= te: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D101918 >=20 > --- Comment #7 from Rimvydas (RJ) --- > The suggested removal of -fdefault-real-8 -fdefault-double-8 options woul= d be > very problematic for many climate modeling libraries where similar '-r8' = option > works as users expect in different compilers: promoting only default types > where no explicit kind is provided. Often coupling interfaces between > different climate modeling software libraries are already using explicit = kinds > for correct data passing, while types in intermediate internal computatio= ns are > left at compiler default types. This allows the use of narrower types for > operational climate simulations (when quicker model execution time is > necessary) and use wider types for more precise calculations in offline r= uns, > without extensive use of C preprocessor that is not a standard Fortran fe= ature. And, here is the problem with these options. Users think it is a great idea to try to promote types without understanding what the options, so they then just naively use those options and complain when something goes wrong. If you use these options with any one file in a project, you must use them with all files. > It is puzzling that some of gfortran developers often are advocating > the use of options like -freal-4-real-8 or -freal-8-real-4 instead. > These options are as useful as -finteger-4-integer-8 for anything > but simple single source programs. These options are preferred (at least by me) because they=20 promote all real(4) to real(8) (or real(8) to real(4))=20 regardless of declarations in the code. There is no ambiguity. There is no breaking the storage association rules of Fortran; where the -fdefault-* break storage association. But, again, if you compile one file with one of these option, then likely you must compile all files with these options. > Consider the following with -O0 -finteger-4-integer-8 > -fdump-tree-original -c: >=20 > program foo > integer :: t > call bar(t) > end program >=20 > subroutine bar(n) ! C callable > use iso_c_binding,only: c_int > implicit none > character(len=3D4) :: mode =3D 'test' > integer(kind=3Dc_int) :: n > n =3D -floor(6.) > call c_func(n, mode) > end subroutine >=20 > might as well promote integer types in main() too. It is nearly > impossible to use -freal-* -finteger-* options when code needs to > link with libraries like BLAS/LAPACK or optimized variants like > OpenBLAS, especially when these options prevents *any* use of the > given type kind and even break fundamental feature like ISO_C_BINDING > without giving some indication that frontend is doing this.=20 It is assumed that the user reads the documentation that comes with his compiler. Quoting from gfortran.info -freal-* family of options ... These options should be used with care and may not be suitable for your codes. Areas of possible concern include calls to external procedures, alignment in 'EQUIVALENCE' and/or 'COMMON', generic interfaces, BOZ literal constant conversion, and I/O and calls to intrinsic procedures when passing a value to the 'kind=3D' dummy argument. Inspection of the intermediate representation of the translated Fortran code, produced by '-fdump-fortran-original' or '-fdump-tree-original', is suggested.=