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
