[Bug fortran/101918] New: LTO type mismatches for runtime library functions in mixed -fdefault-real-8 projects

[Bug fortran/101918] New: LTO type mismatches for runtime library functions in mixed -fdefault-real-8 projects

[rimvydas.jas at gmail dot com]

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

            Bug ID: 101918
           Summary: LTO type mismatches for runtime library functions in
                    mixed -fdefault-real-8 projects
           Product: gcc
           Version: 11.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: rimvydas.jas at gmail dot com
  Target Milestone: ---

$ cat bar.f90
program bar
implicit none
logical :: mask(2,3)
integer :: ai(2,3), vi(5)
real :: ar(2,3), vr(2)
double precision :: ad(2,3), vd(2)
ai = 0
ai(1,1:2) = (/ 1, 2 /)
ar = ai
ad = ai
mask = ai .ne. 0
vi = PACK(ai, ai .gt. 0, vector=(/1,2,3,4,5/))
vd = PACK(ad, mask)
vr = PACK(ar, mask)
call foo()
end program

$ cat foo.f90
subroutine foo
implicit none
real :: ar(2,3), v(1)
ar = 0.
ar(1,1) = 1.
v = PACK(ar, ar > 0.)
end subroutine

$ gfortran -Wall -Wextra -flto -fdefault-real-8 -c foo.f90
$ gfortran -flto -Wall -Wextra foo.o bar.f90
bar.f90:14:19: warning: type of '_gfortran_pack' does not match original
declaration [-Wlto-type-mismatch]
   14 | vr = PACK(ar, mask)
      |                   ^
bar.f90:13:19: warning: type of '_gfortran_pack' does not match original
declaration [-Wlto-type-mismatch]
   13 | vd = PACK(ad, mask)
      |                   ^
bar.f90:12:46: warning: type of '_gfortran_pack' does not match original
declaration [-Wlto-type-mismatch]
   12 | vi = PACK(ai, ai .gt. 0, vector=(/1,2,3,4,5/))
      |                                              ^
foo.f90:6:21: note: '_gfortran_pack' was previously declared here
    6 | v = PACK(ar, ar > 0.)
      |                     ^
foo.f90:6:21: note: code may be misoptimized unless '-fno-strict-aliasing' is
used

In medium sized mixed C/Fortran codebase there are more instances for:
 _gfortran_matmul_r8
 _gfortran_pack
 _gfortran_reshape_r8
 _gfortran_set_convert
 _gfortran_shape_4
 _gfortran_unpack0
 _gfortran_unpack1

Does this mean -flto cannot be used in mixed -fdefault-real-8 and usual modes?

[Bug fortran/101918] LTO type mismatches for runtime library functions in mixed -fdefault-real-8 projects

[rimvydas.jas at gmail dot com]

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

--- Comment #1 from Rimvydas (RJ) <rimvydas.jas at gmail dot com> ---
Also several programs report spurious warnings:
<built-in>: warning: type of '__builtin_realloc' does not match original
declaration [-Wlto-type-mismatch]
/opt/nwp/gcc11/include/stdlib.h:550:14: note: type mismatch in parameter 1
  550 | extern void *realloc (void *__ptr, size_t __size)
      |              ^
/opt/nwp/gcc11/include/stdlib.h:550:14: note: 'realloc' was previously declared
here
/opt/nwp/gcc11/include/stdlib.h:550:14: note: code may be misoptimized unless
'-fno-strict-aliasing' is used

that seem to go away if arguments are swapped at gcc/fortran/f95-lang.c:982
  ftype = build_function_type_list (pvoid_type_node,
                                    size_type_node, pvoid_type_node, <---
                                    NULL_TREE);

So far could not extract reasonably sized test-case.

[Bug fortran/101918] LTO type mismatches for runtime library functions in mixed -fdefault-real-8 projects

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kargl at gcc dot gnu.org

--- Comment #2 from kargl at gcc dot gnu.org ---
(In reply to Rimvydas (RJ) from comment #0)

> $ gfortran -Wall -Wextra -flto -fdefault-real-8 -c foo.f90
> $ gfortran -flto -Wall -Wextra foo.o bar.f90

This should be closed as WONTFIX.  If you compile foo.f90
with -fdefault-real-8, then you must compile bar.f90 with
-fdefault-real-8.  You're changing the ABI for foo.f90, 
but not bar.f90.

> Does this mean -flto cannot be used in mixed -fdefault-real-8
> and usual modes?

It means "Don't use -fdefault-real-8".  It is a broken
unfixable option that I tried to remove years ago, but
that was voted down.

If you have code that requires this option, then the
code should be properly ported to REAL(8).

[Bug fortran/101918] LTO type mismatches for runtime library functions in mixed -fdefault-real-8 projects

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
Now I wonder, since libgfortran doesn't change itself, why the fortran FE does
not properly change _gfortran_pack to resolve to _gfortran_pack_r8?  IIRC there
was a related PR requesting those -fdefault-* flags to simply reflect into the
AST of the current TU and IIRC that was done - but maybe handling of intrinsics
is missing?

[Bug fortran/101918] LTO type mismatches for runtime library functions in mixed -fdefault-real-8 projects

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #4 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Mon, Aug 16, 2021 at 09:15:11AM +0000, rguenth at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101918
> 
> --- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
> Now I wonder, since libgfortran doesn't change itself, why the fortran
> FE does not properly change _gfortran_pack to resolve to _gfortran_pack_r8?

The answer to your question lies in iresolve.c(gfc_resolve_pack).
A call to _gfortran_pack_r8 is never generated.  See the output
after compiling 

subroutine foo4
  implicit none
  real(4) :: ar(2,3), v(1)
  ar = 0.
  ar(1,1) = 1.
  v = PACK(ar, ar > 0.)
end subroutine

subroutine foo8
  implicit none
  real(8) :: ar(2,3), v(1)
  ar = 0.
  ar(1,1) = 1.
  v = PACK(ar, ar > 0.)
end subroutine

with the "gfortran -c -fdump-tree-original".

Essentially, a combination of in-line generated code and
converting the array of REAL(4) or REAL(8) to a stream of
bytes allows for a single library routine instead of the
combinatoric number of all combinations of argument kind
types (see the packing of the parm.0 and parm.1 structs
in -fdump-tree-original output). 

If someone wants to use -fdefault-* options, then all
code must be compiled with that option.

[Bug fortran/101918] LTO type mismatches for runtime library functions in mixed -fdefault-real-8 projects

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |anlauf at gcc dot gnu.org

--- Comment #5 from anlauf at gcc dot gnu.org ---
(In reply to Steve Kargl from comment #4)

> subroutine foo4
>   implicit none
>   real(4) :: ar(2,3), v(1)

That should have read:

  real :: ar(2,3), v(1)

> with the "gfortran -c -fdump-tree-original".

and this:

"gfortran -c -fdump-tree-original -fdefault-real-8"

Which then gives apparently identical dump trees for both subroutines,
as is likely expected by the user.

> If someone wants to use -fdefault-* options, then all
> code must be compiled with that option.

Which the leads to the question: what exactly happens with that code when
lto is used?  Is there a way to compare the "lto representation" to the
dump tree the gfortran developers may know better?

[Bug fortran/101918] LTO type mismatches for runtime library functions in mixed -fdefault-real-8 projects

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #6 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Mon, Aug 16, 2021 at 06:49:54PM +0000, anlauf at gcc dot gnu.org wrote:
> 
> > subroutine foo4
> >   implicit none
> >   real(4) :: ar(2,3), v(1)
> 
> That should have read:
> 
>   real :: ar(2,3), v(1)
> 

Ah, yes!  Another reason that -fdefault-real-8 should be
deleted from gfortran.  Presumably, the real(4) version
will break with -freal-4-real-8.  Oh well, these option
are meant to be aidis while someone ports a code from
one precision to another.

[Bug fortran/101918] LTO type mismatches for runtime library functions in mixed -fdefault-real-8 projects

[rimvydas.jas at gmail dot com]

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

--- Comment #7 from Rimvydas (RJ) <rimvydas.jas at gmail dot com> ---
The suggested removal of -fdefault-real-8 -fdefault-double-8 options would 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 computations 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 runs,
without extensive use of C preprocessor that is not a standard Fortran feature.
 Note, there is no option to silence warnings about numerical constants (not
using explicit kinds) when constants can be converted without loss of precision
including for powers of 2 in floating types.

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.
 Consider the following with -O0 -finteger-4-integer-8 -fdump-tree-original -c:

program foo
integer :: t
call bar(t)
end program

subroutine bar(n) ! C callable
use iso_c_binding,only: c_int
implicit none
character(len=4) :: mode = 'test'
integer(kind=c_int) :: n
n = -floor(6.)
call c_func(n, mode)
end subroutine

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. 
In many bigger climate packages it is common to use different kinds for IO,
computation, coupling etc:
ones based on defaults for given architecture/ABI:
  logical
  integer
  real
  double precision
  quad precision (when it becomes part of the standard, since hardware is
becoming available for scientific computations)
ones based on minimal precision required:
  real, parameter :: jprf = selected_real_kind(6,37)
  real, parameter :: jprd = selected_real_kind(13,300)
  integer, parameter :: jpii = selected_int_kind(9)
  integer, parameter :: jpil = selected_int_kind(13)
ones based on Fortran internal storage (a.k.a "works on compilers tested"):
  real, parameter :: jpr4 = 4
  real, parameter :: jpr8 = 8
  integer, parameter :: jpi4 = 4
  integer, parameter :: jpi8 = 8
ones based on C/Fortran bindings through iso_c_binding
  integer(kind=c_int)
  integer(kind=c_long)
  real(kind=c_float)
  real(kind=c_double)

Users usually do not expect numeric kinds to match between all these groups for
all architectures/ABIs, but it is expected that the compiler should convert
variable types (including numeric constants) with different kinds or give a
diagnostic when it is not possible, otherwise whole use of different explicit
kinds is redundant if those internally map to the same kind that can be
overridden silently by a single option.  If it is indeed just an LTO
implementation limitation, then users need to be careful when checking what
dynamic or static different climate libraries (possibly using -flto) are being
used when linking final executables.
Even added diagnostics when the user makes a typo like:
  integer(kind=selected_real_kind(13,300)) :: i
would help a lot.  At least some common examples of what to look for in
documentation about "gfortran -fdefault-real-8 -fdefault-double-8" limitations
(if these options are really that broken) would be very appreciated by the
software porters :)

[Bug fortran/101918] LTO type mismatches for runtime library functions in mixed -fdefault-real-8 projects

[rimvydas.jas at gmail dot com]

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

--- Comment #8 from Rimvydas (RJ) <rimvydas.jas at gmail dot com> ---
If we can agree that use of -fdefault-real-8 -fdefault-double-8 with -flto does
not magically recompile intrinsic subroutines in runtime libgfortran.so
library, it looks like it is a frontend issue not providing correct information
for LTO.  Somewhat more trivial example for different intrinsic runtime call:
$ cat foo.f90
program foo
implicit none
double precision, dimension (1:4) :: b = 1
double precision, dimension (1:2, 1:2) :: h
h = reshape( b, (/ 2, 2 /))
call bar()
end program

$ cat bar.f90
subroutine bar
implicit none
real, dimension (1:4) :: b = 1
real, dimension (1:2, 1:2) :: h
h = reshape( b, (/ 2, 2 /))
end subroutine

$ gfortran -Wall -Wextra -flto -fdefault-real-8 -fdefault-double-8 -c bar.f90
$ gfortran -Wall -Wextra -flto foo.f90 bar.o
bar.f90:5:27: warning: type of '_gfortran_reshape_r8' does not match original
declaration [-Wlto-type-mismatch]
    5 | h = reshape( b, (/ 2, 2 /))
      |                           ^
foo.f90:5:27: note: '_gfortran_reshape_r8' was previously declared here
    5 | h = reshape( b, (/ 2, 2 /))
      |                           ^
foo.f90:5:27: note: code may be misoptimized unless '-fno-strict-aliasing' is
used

The -fdump-tree-original match exactly and both report: _gfortran_reshape_r8/4
function body not available.  The same happens even when bar.f90 is using
real(c_double) from ISO_C_BINDINGS.
Maybe it would be possible to provide interfaces for calls to intrinsics in the
runtime library, even if that would require use of "!GCC$ ATTRIBUTES
NO_ARG_CHECK :: VARIABLE" like it is already done for "USE MPI" bindings?

[Bug fortran/101918] LTO type mismatches for runtime library functions in mixed -fdefault-real-8 projects

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #9 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Mon, Aug 30, 2021 at 10:26:59AM +0000, rimvydas.jas at gmail dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101918
> 
> --- Comment #7 from Rimvydas (RJ) <rimvydas.jas at gmail dot com> ---
> The suggested removal of -fdefault-real-8 -fdefault-double-8 options would 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 computations 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 runs,
> without extensive use of C preprocessor that is not a standard Fortran feature.

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 
promote all real(4) to real(8) (or real(8) to real(4)) 
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:
> 
> program foo
> integer :: t
> call bar(t)
> end program
> 
> subroutine bar(n) ! C callable
> use iso_c_binding,only: c_int
> implicit none
> character(len=4) :: mode = 'test'
> integer(kind=c_int) :: n
> n = -floor(6.)
> call c_func(n, mode)
> end subroutine
> 
> 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. 

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=' dummy
   argument.  Inspection of the intermediate representation of the
   translated Fortran code, produced by '-fdump-fortran-original' or
   '-fdump-tree-original', is suggested.

[Bug fortran/101918] LTO type mismatches for runtime library functions in mixed -fdefault-real-8 projects

[kargl at gcc dot gnu.org]

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

--- Comment #10 from kargl at gcc dot gnu.org ---
(In reply to Rimvydas (RJ) from comment #8)
> If we can agree that use of -fdefault-real-8 -fdefault-double-8 with -flto
> does not magically recompile intrinsic subroutines in runtime libgfortran.so
> library, it looks like it is a frontend issue not providing correct
> information for LTO.

No, it is not a frontend issue.  It is a user expectation issues.


> $ gfortran -Wall -Wextra -flto -fdefault-real-8 -fdefault-double-8 -c bar.f90
> $ gfortran -Wall -Wextra -flto foo.f90 bar.o

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 imcompatiable options?

[Bug fortran/101918] LTO type mismatches for runtime library functions in mixed -fdefault-real-8 projects

[kargl at gcc dot gnu.org]

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

--- Comment #11 from kargl at gcc dot gnu.org ---
(In reply to Rimvydas (RJ) from comment #7)
At least some common examples of what to look for in
> documentation about "gfortran -fdefault-real-8 -fdefault-double-8"
> limitations (if these options are really that broken) would be very
> appreciated by the software porters :)

% cat foo.f90
program foo
   x = 1.
   y = 3.14159
   a = 1._4
   b = 3.14159_4
   print *, a / b
   print *, x/ y
end program foo
% gfcx -o z a.f90 && ./z
  0.318310142    
  0.318310142    
% gfcx -o z -fdefault-real-8 a.f90 && ./z
  0.31831014305159744     
  0.31831015504887655     
% gfcx -o z -freal-4-real-8 a.f90 && ./z
  0.31831015504887655     
  0.31831015504887655     

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.

[Bug fortran/101918] LTO type mismatches for runtime library functions in mixed -fdefault-real-8 projects

[rimvydas.jas at gmail dot com]

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

--- 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 
program foo
   implicit none
   real(kind=4) :: a, b
   real :: x, y
   x = 1.
   y = 3.14159
   a = 1._4
   b = 3.14159_4
   print *, a / b
   print *, x/ y
end program foo
$ gfortran foo.f90 && ./a.out
  0.318310142    
  0.318310142    
$ gfortran foo.f90 -fdefault-real-8 && ./a.out
  0.318310142    
  0.31831015504887655     
$ gfortran foo.f90 -freal-4-real-8 && ./a.out
  0.31831015504887655     
  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-* family
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-original
-c outputs on both sources indicate that dump trees are identical (including
calls to _gfortran_reshape_r8() in libgfortran.so).

[Bug fortran/101918] LTO type mismatches for runtime library functions in mixed -fdefault-real-8 projects

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #13 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Mon, Aug 30, 2021 at 03:23:59PM +0000, rimvydas.jas at gmail dot com wrote:
> 
> > 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-original
> -c outputs on both sources indicate that dump trees are identical (including
> calls to _gfortran_reshape_r8() in libgfortran.so).
> 

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.

And, no, I'm not wasting my time contriving examples to prove
that these options should be avoided.

[Bug fortran/101918] LTO type mismatches for runtime library functions in mixed -fdefault-real-8 projects

[rimvydas.jas at gmail dot com]

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:

-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.

> 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

I tried to get more information with lto-dump(1) tool, however
lto-dump -dump-body=foo foo.o
lto-dump -dump-body=bar bar.o
outputs do not indicate any tree differences either.  Is there a way to get
more LTO information to understand the issue at hand?

[Bug fortran/101918] LTO type mismatches for runtime library functions in mixed -fdefault-real-8 projects

[sgk at troutmask dot apl.washington.edu]

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.

[Bug fortran/101918] LTO type mismatches for runtime library functions in mixed -fdefault-real-8 projects

[rimvydas.jas at gmail dot com]

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

--- Comment #16 from Rimvydas (RJ) <rimvydas.jas at gmail dot com> ---
(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=8) or
real(kind=16) or ISO_C_BINDING ones other than default plain REAL.  From
-ftree-dump-original dumps it is seen that even plain REAL or DOUBLE PRECISION
are assigned REAL(KIND=N) for all types, like
static real(kind=8) b[4] = {[0 ... 3]=1.0e+0};

> COMMON, EQUIVALENCE, and BOZ are not legacy features.
> These are full fledged features of modern Fortran. 
Some people still prefer to use Hollerith constants, implicit types, statement
functions, arithmetic if's, shared do terminations, fixed source form, even
PAUSE and there is nothing wrong with it.  Still, these are not related to this
PR.

> 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.
ABI in this case can not be broken because no data is exchange between foo()
and bar(), nor libgfortran.so.5.0.0 is being recompiled.  Only thing that might
affect the runtime is:
  static integer(kind=4) options.4[7] = {2116, 4095, 0, 1, 1, 0, 31};
  _gfortran_set_options (7, &options.4[0]);
and based on
https://gcc.gnu.org/onlinedocs/gfortran/_005fgfortran_005fset_005foptions.html
these should not influence how runtime library should handle default
integer/real/logical/character types without explicit kind.

Again question is what is getting broken and what is the scope of this?  Is it
limited to LTO compilation only?  Any help to understand the actual problem
would very likely lead to a simple one line fix in the source code.

[Bug fortran/101918] LTO type mismatches for runtime library functions in mixed -fdefault-real-8 projects

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #17 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Mon, Aug 30, 2021 at 07:08:07PM +0000, rimvydas.jas at gmail dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101918
> 
> --- Comment #16 from Rimvydas (RJ) <rimvydas.jas at gmail dot com> ---
> (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=8) or
> real(kind=16) or ISO_C_BINDING ones other than default plain REAL.  From
> -ftree-dump-original dumps it is seen that even plain REAL or DOUBLE PRECISION
> are assigned REAL(KIND=N) for all types, like
> static real(kind=8) b[4] = {[0 ... 3]=1.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 
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.

> 
> > COMMON, EQUIVALENCE, and BOZ are not legacy features.
> > These are full fledged features of modern Fortran. 
> Some people still prefer to use Hollerith constants, implicit types, statement
> functions, arithmetic if's, shared do terminations, fixed source form, even
> PAUSE and there is nothing wrong with it.  Still, these are not related to this
> PR.
> 

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.

[Bug fortran/101918] LTO type mismatches for runtime library functions in mixed -fdefault-real-8 projects

[rimvydas.jas at gmail dot com]

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

--- Comment #18 from Rimvydas (RJ) <rimvydas.jas at gmail dot com> ---
(In reply to Steve Kargl from comment #17)
> 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.
Someone in this same PR previously recommended that only -freal-*-real-*
options should be used.  Now even those are getting flagged as being broken.

> 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.
This is observed behavior and a main reason why -freal-*-real-* options
(including integer ones) are virtually unusable in any bigger project that
interfaces to C or even Rust modules.

> 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 built. I don't know if anyone has extensively
> tried these options with IEEE modules.
We have used IEEE_ARITHMETIC and IEEE_EXCEPTIONS modules, seem to be performing
OK, except for handling inexact exceptions, but it is a minor issue.

> COMMON, EQUIVALENCE, BOZ, external subprogram, etc are related
> because these are affected by mucking around with storage
> association and the ABI.
These are not an issue if one is using modern portable Fortran code where
system and sometimes vendor specific tuning/optimizations/hacks can be more
easily implemented in pure C using interface safety provided by ISO_C_BINDING
intrinsic module, thus keeping Fortran part of the project portable.

However, none of these actually help to get closer to the actual issue in this
PR.  There are many things that could go wrong in the world, but this PR is
about trying to get the bottom of this single issue.

The -ftree-dump-original from Comment #8 in bar.f90.005t.original:
__attribute__((fn spec (". ")))
void bar ()
{
  static real(kind=8) b[4] = {[0 ... 3]=1.0e+0};
  real(kind=8) h[4];

  {
    struct array02_real(kind=8) parm.0;
    struct array01_real(kind=8) parm.1;
    struct array01_real(kind=8) * D.3962;
    static integer(kind=8) A.2[2] = {2, 2};
    struct array01_integer(kind=8) parm.3;
    struct array01_integer(kind=8) * D.3971;

    parm.0.span = 8;
    parm.0.dtype = {.elem_len=8, .rank=2, .type=3};
    parm.0.dim[0].lbound = 1;
    parm.0.dim[0].ubound = 2;
    parm.0.dim[0].stride = 1;
    parm.0.dim[1].lbound = 1;
    parm.0.dim[1].ubound = 2;
    parm.0.dim[1].stride = 2;
    parm.0.data = (void *) &h[0];
    parm.0.offset = -3;
    parm.1.span = 8;
    parm.1.dtype = {.elem_len=8, .rank=1, .type=3};
    parm.1.dim[0].lbound = 1;
    parm.1.dim[0].ubound = 4;
    parm.1.dim[0].stride = 1;
    parm.1.data = (void *) &b[0];
    parm.1.offset = -1;
    D.3962 = &parm.1;
    parm.3.span = 8;
    parm.3.dtype = {.elem_len=8, .rank=1, .type=1};
    parm.3.dim[0].lbound = 1;
    parm.3.dim[0].ubound = 2;
    parm.3.dim[0].stride = 1;
    parm.3.data = (void *) &A.2[0];
    parm.3.offset = -1;
    D.3971 = &parm.3;
    _gfortran_reshape_r8 (&parm.0, D.3962, D.3971, 0B, 0B);
  }
}

The tree dump for foo.f90 is identical + call to bar() and main() ofc.  The
most puzzling bit is why LTO sees a different information for
_gfortran_reshape_r8() runtime intrinsic function?

[Bug fortran/101918] LTO type mismatches for runtime library functions in mixed -fdefault-real-8 projects

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #19 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Mon, Aug 30, 2021 at 09:23:46PM +0000, rimvydas.jas at gmail dot com wrote:
> (In reply to Steve Kargl from comment #17)
> > 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.
> Someone in this same PR previously recommended that only -freal-*-real-*
> options should be used.  Now even those are getting flagged as being broken.
> 

The -fdefault-* family of options is broken.

The -freal-* family of options is broken.

The -freal-* family of options is less broken than the
-fdefault-* family of options.

Neither family of options can be fixed for all situations
that one might encounter.

These options should never be used (withi the possible
exception of porting from one precision to another).

I think I'm done here.

[Bug fortran/101918] LTO type mismatches for runtime library functions in mixed -fdefault-real-8 projects

[rimvydas.jas at gmail dot com]

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

--- Comment #20 from Rimvydas (RJ) <rimvydas.jas at gmail dot com> ---
Full -fdump-tree-original foo.f90.005t.original from Comment #8 example:

__attribute__((fn spec (". ")))
void foo ()
{
  static real(kind=8) b[4] = {[0 ... 3]=1.0e+0};
  real(kind=8) h[4];

  {
    struct array02_real(kind=8) parm.0;
    struct array01_real(kind=8) parm.1;
    struct array01_real(kind=8) * D.3962;
    static integer(kind=8) A.2[2] = {2, 2};
    struct array01_integer(kind=8) parm.3;
    struct array01_integer(kind=8) * D.3971;

    parm.0.span = 8;
    parm.0.dtype = {.elem_len=8, .rank=2, .type=3};
    parm.0.dim[0].lbound = 1;
    parm.0.dim[0].ubound = 2;
    parm.0.dim[0].stride = 1;
    parm.0.dim[1].lbound = 1;
    parm.0.dim[1].ubound = 2;
    parm.0.dim[1].stride = 2;
    parm.0.data = (void *) &h[0];
    parm.0.offset = -3;
    parm.1.span = 8;
    parm.1.dtype = {.elem_len=8, .rank=1, .type=3};
    parm.1.dim[0].lbound = 1;
    parm.1.dim[0].ubound = 4;
    parm.1.dim[0].stride = 1;
    parm.1.data = (void *) &b[0];
    parm.1.offset = -1;
    D.3962 = &parm.1;
    parm.3.span = 8;
    parm.3.dtype = {.elem_len=8, .rank=1, .type=1};
    parm.3.dim[0].lbound = 1;
    parm.3.dim[0].ubound = 2;
    parm.3.dim[0].stride = 1;
    parm.3.data = (void *) &A.2[0];
    parm.3.offset = -1;
    D.3971 = &parm.3;
    _gfortran_reshape_r8 (&parm.0, D.3962, D.3971, 0B, 0B);
  }
  bar ();
}


__attribute__((externally_visible))
integer(kind=4) main (integer(kind=4) argc, character(kind=1) * * argv)
{
  static integer(kind=4) options.4[7] = {2116, 4095, 0, 1, 1, 0, 31};

  _gfortran_set_args (argc, argv);
  _gfortran_set_options (7, &options.4[0]);
  foo ();
  return 0;
}

[Bug fortran/101918] LTO type mismatches for runtime library functions in mixed -fdefault-real-8 projects

[rimvydas.jas at gmail dot com]

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

--- Comment #21 from Rimvydas (RJ) <rimvydas.jas at gmail dot com> ---
After long poking with gdb the tree t1 and t2 structures in
lto-symtab.c:warn_type_compatibility_p() just before "lev |5" is returned, it
looks like trees are are almost identical except for t1->decl_common.off_align
== 1 vs 2.  This looks suspicious since these are in call to already type/rank
specific runtime library function _gfortran_reshape_r8().  Sadly the
lto-dump(1) tool is unable to dump type information about called functions
arguments.

Looking at gcc/fortran/intrinsic.c it is seen that -fdefault-real-*
-fdefault-integer-* options have same effect as -freal-M-real-N or
-finteger-M-integer-N options.  This does not look intentional as this breaks
use of certain (more archaic forms) intrinsics with variables and numeric
constants that have explicit kinds.

[Bug fortran/101918] LTO type mismatches for runtime library functions in mixed -fdefault-real-8 projects

[rimvydas.jas at gmail dot com]

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

--- Comment #22 from Rimvydas (RJ) <rimvydas.jas at gmail dot com> ---
Created attachment 51398
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51398&action=edit
proposed patch

[Bug fortran/101918] LTO type mismatches for runtime library functions in mixed -fdefault-real-8 projects

[rimvydas.jas at gmail dot com]

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

--- Comment #23 from Rimvydas (RJ) <rimvydas.jas at gmail dot com> ---
Created attachment 51399
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51399&action=edit
additional patch, for previous behavior

[Bug fortran/101918] LTO type mismatches for runtime library functions in mixed -fdefault-real-8 projects

[rimvydas.jas at gmail dot com]

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

--- Comment #24 from Rimvydas (RJ) <rimvydas.jas at gmail dot com> ---
Created attachment 51400
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51400&action=edit
alog() intrinsic testcases

[Bug fortran/101918] LTO type mismatches for runtime library functions in mixed -fdefault-real-8 projects

[rimvydas.jas at gmail dot com]

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

--- Comment #25 from Rimvydas (RJ) <rimvydas.jas at gmail dot com> ---
Created attachment 51401
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51401&action=edit
testcase with ice deep in rtl code for sign extend

[Bug fortran/101918] LTO type mismatches for runtime library functions in mixed -fdefault-real-8 projects

[rimvydas.jas at gmail dot com]

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

Rimvydas (RJ) <rimvydas.jas at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #51398|0                           |1
        is obsolete|                            |
  Attachment #51399|0                           |1
        is obsolete|                            |
  Attachment #51400|0                           |1
        is obsolete|                            |
  Attachment #51401|0                           |1
        is obsolete|                            |

--- Comment #26 from Rimvydas (RJ) <rimvydas.jas at gmail dot com> ---
Created attachment 51442
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51442&action=edit
proper patch with more fixes and tests

see short summary above the patch