https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68649
Joost VandeVondele <Joost.VandeVondele at mat dot ethz.ch> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|WAITING |UNCONFIRMED Depends on| |68560 Ever confirmed|1 |0 --- Comment #5 from Joost VandeVondele <Joost.VandeVondele at mat dot ethz.ch> --- (In reply to Dominique d'Humieres from comment #4) > I think it is a duplicate of pr68560. seems certainly related, but PR68560 doesn't yield the worrying 'code may be misoptimized unless -fno-strict-aliasing is used'. I'll just add a dependency. > > > This smells like a fortran front-end issue where _gfortran_reshape_r8's decl > > is created twice with two different argument types. > > I don't think so. I think -Wlto-type-mismatch does not know part of the > Fortran syntax. I'm thinking the issue is on the Fortran FE side, LTO shouldn't know the language involved. I guess some middle end person might need to have a look however. I'm guessing it is related to the fact that _gfortran_reshape_r8 is being called with different pointer arguments (from -fdump-tree-original): struct array1_real(kind=8) parm.0; _gfortran_reshape_r8 (&parm.0, D.3433, D.3437, 0B, 0B); struct array2_real(kind=8) parm.4; _gfortran_reshape_r8 (&parm.4, D.3446, D.3450, 0B, 0B); maybe for correctness there should be some casts ? Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68560 [Bug 68560] [6 Regression] The test gfortran.dg/shape_8.f90 now fails when compiled with -flto