[Bug fortran/68649] [6 Regression] note: code may be misoptimized unless -fno-strict-aliasing is used

[Joost.VandeVondele at mat dot ethz.ch]

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