[Bug fortran/68649] [6 Regression] note: code may be misoptimized unless -fno-strict-aliasing is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68649
--- Comment #13 from Richard Biener ---
Note that the cast doesn't help in itself (but for the warning) as Jakub
notices.
The deeper issue is type-based aliasing here. IMHO libgfortran would need to
use
struct A { float *base_addr; size_t offset; long dtype; struct D dim[1]; }
*desc;
aka a pointer to a descriptor with flexible array member. Which I hope ends
up aliasing with one with a different size. Well, we treat 'dim' as flexible
array member in any case but I'm not aware of any code in alias.c that makes
this work.
struct Xflex { int n; int a[1]; };
struct Xspecific { int n; int a[7]; } x;
int foo (struct Xflex *f)
{
f->a[6] = 2;
x.a[6] = 1;
return f->a[6];
}
returns 2 with -fstrict-aliasing :(
Thus even the proposed fix won't end up working.
[Bug fortran/68649] [6 Regression] note: code may be misoptimized unless -fno-strict-aliasing is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68649 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P4
[Bug fortran/68649] [6 Regression] note: code may be misoptimized unless -fno-strict-aliasing is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68649
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #12 from Jakub Jelinek ---
This is of course Fortran FE bug.
What is the Fortran FE emitting right now is kind like invalid C (and invalid
middle-end) below. It wouldn't be invalid C++, but for C++ that would be
different baz functions and name mangling would differentiate those; that is
not what is going on in C or in what libgfortran expects:
typedef __SIZE_TYPE__ size_t;
struct D { long stride, lower_bound, ubound; };
struct A { float *base_addr; size_t offset; long dtype; struct D dim[7]; };
struct A1 { float *base_addr; size_t offset; long dtype; struct D dim[1]; };
struct A2 { float *base_addr; size_t offset; long dtype; struct D dim[2]; };
void
foo (void)
{
extern void baz (struct A1 *);
struct A1 a1 = { 0, 0, 0, { { 0, 0, 0 } } };
baz (&a1);
}
void
bar (void)
{
extern void baz (struct A2 *);
struct A2 a2 = { 0, 0, 0, { { 0, 0, 0 }, { 0, 0, 0 } } };
baz (&a2);
}
Above, A stands for generic real(8) array descriptor type that supports up to
maximum number of dimensions, A1 for rank 1 and A2 for rank 2 real(8) array
descriptor. IMHO you want instead:
typedef __SIZE_TYPE__ size_t;
struct D { long stride, lower_bound, ubound; };
struct A { float *base_addr; size_t offset; long dtype; struct D dim[7]; };
struct A1 { float *base_addr; size_t offset; long dtype; struct D dim[1]; };
struct A2 { float *base_addr; size_t offset; long dtype; struct D dim[2]; };
void
foo (void)
{
extern void baz (struct A *);
struct A1 a1 = { 0, 0, 0, { { 0, 0, 0 } } };
baz ((struct A *) &a1);
}
void
bar (void)
{
extern void baz (struct A *);
struct A2 a2 = { 0, 0, 0, { { 0, 0, 0 }, { 0, 0, 0 } } };
baz ((struct A *) &a2);
}
and ensure that A/A1/A2 etc. (the various types created by
gfc_get_array_type_bounds) have the same TYPE_ALIAS to make the alias oracle
happy.
I hope only the libgfortran intrinsics that handle various ranks by the same
function are a problem, therefore I'd say you should be marking the symbols for
those intrinsics with some flag that you want to treat their arguments like
assumed rank arrays, and then just cast the addresses of the descriptors you
want to pass to them to some reference type to assumed rank descriptor type
(dunno if just array7_real(kind=8) (i.e. maximum rank), or something else).
Now, the question is if this affects just the intrinsic routines from
libgfortran, or user written functions/subroutines too. I hope the latter only
should be called with the right rank except for assumed
[Bug fortran/68649] [6 Regression] note: code may be misoptimized unless -fno-strict-aliasing is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68649 --- Comment #11 from Joost VandeVondele --- (In reply to Jerry DeLisle from comment #10) > This PR is tagged as a regression. Has anyone determined when it last > worked or is it longstanding bug uncovered by recent non-fortran fe changes? For users it is a regression in the sense that packages that compiled with -flto -Werror with 5.3 will now stop building. The underlying FE issue is much older, I guess.
[Bug fortran/68649] [6 Regression] note: code may be misoptimized unless -fno-strict-aliasing is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68649 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at gcc dot gnu.org --- Comment #10 from Jerry DeLisle --- This PR is tagged as a regression. Has anyone determined when it last worked or is it longstanding bug uncovered by recent non-fortran fe changes?
[Bug fortran/68649] [6 Regression] note: code may be misoptimized unless -fno-strict-aliasing is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68649 --- Comment #9 from Dominique d'Humieres --- See also pr68717 for more warnings after r231239.
[Bug fortran/68649] [6 Regression] note: code may be misoptimized unless -fno-strict-aliasing is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68649
--- Comment #8 from Dominique d'Humieres ---
Further reduced test
REAL*8 :: a8(16),b8(4,4), c8(16), d8(4,4)
c8=RESHAPE(b8,(/16/))
d8=RESHAPE(a8,(/4,4/))
END
> Notice the difference in size of the records.
How do they relate to the array sizes?
From https://gcc.gnu.org/onlinedocs/gfortran/RESHAPE.html#RESHAPE
Description:
Reshapes SOURCE to correspond to SHAPE. If necessary, the new array may be
padded with elements from PAD or permuted as defined by ORDER.
> In libgfortran there is
> void
> reshape_r8 (gfc_array_r8 * const restrict ret,
> gfc_array_r8 * const restrict source,
> shape_type * const restrict shape,
> gfc_array_r8 * const restrict pad,
> shape_type * const restrict order)
>
> ideally the fortran-fe produced declaration of reshape_r8 should be just one
> per
> unit and interoperable with the declaration above that is pointer to:
> #define GFC_ARRAY_DESCRIPTOR(r, type) \
> struct {\
> type *base_addr;\
> size_t offset;\
> index_type dtype;\
> descriptor_dimension dim[r];\
> }
Are you meaning that fortran-fe should produce one reshape_r8xx per shape of
source?
[Bug fortran/68649] [6 Regression] note: code may be misoptimized unless -fno-strict-aliasing is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68649
--- Comment #7 from Jan Hubicka ---
The function is:
>
QI
size
unit size
align 8 symtab 0 alias set -1 structural equality
attributes
value >>
arg-types
chain
chain
chain
chain chain >
pointer_to_this >
addressable public external QI file a.f90 line 3 col 0 align 8 context
>
Second decl is:
>
QI
size
unit size
align 8 symtab 0 alias set -1 structural equality
attributes
value >>
arg-types
chain
chain
chain
chain chain >
pointer_to_this >
addressable public external QI file a.f90 line 4 col 0 align 8 context
>
The reason is that the declaration is duplicated (that by itself is a bug
violating one-decl rule) and we warn because reference type 0x76cc3888 is
not compatible with reference type 0x76cc33f0. They point to different type
of structure:
unit size
align 64 symtab 0 alias set -1 canonical type 0x76cc3690
fields
unsigned DI file a.f90 line 3 col 0
size
unit size
align 64 offset_align 128
offset
bit offset context
chain >
reference_to_this chain >
unsigned DI size unit size
align 64 symtab 0 alias set 6 structural equality>
compared to:
unit size
align 64 symtab 0 alias set -1 canonical type 0x76cc31f8
fields
unsigned DI file a.f90 line 4 col 0
size
unit size
align 64 offset_align 128
offset
bit offset context
chain >
reference_to_this chain >
unsigned DI size unit size
align 64 symtab 0 alias set 7 structural equality>
Notice the difference in size of the records.
This will indeed make TBAA code to believe that those two pointers are not
compatible. In libgfortran there is
void
reshape_r8 (gfc_array_r8 * const restrict ret,
gfc_array_r8 * const restrict source,
shape_type * const restrict shape,
gfc_array_r8 * const restrict pad,
shape_type * const restrict order)
ideally the fortran-fe produced declaration of reshape_r8 should be just one
per unit and interoperable with the declaration above that is pointer to:
#define GFC_ARRAY_DESCRIPTOR(r, type) \
struct {\
type *base_addr;\
size_t offset;\
index_type dtype;\
descriptor_dimension dim[r];\
}
[Bug fortran/68649] [6 Regression] note: code may be misoptimized unless -fno-strict-aliasing is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68649 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #6 from Dominique d'Humieres --- > 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. IMO these warnings are false positive (aka bogus). The minimal set of options to get the warning for the test in comment 1 is '-flto -fstrict-aliasing'. > 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. IMO the first step is to understand why LTO is emitting these warning on valid Fortran code. Then, if this not due to a bug in LTO, it will be time to find how Fortran intrinsics have to be "decorated" to avoid the warnings.
[Bug fortran/68649] [6 Regression] note: code may be misoptimized unless -fno-strict-aliasing is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68649 Richard Biener changed: What|Removed |Added Target Milestone|--- |6.0
[Bug fortran/68649] [6 Regression] note: code may be misoptimized unless -fno-strict-aliasing is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68649 Joost VandeVondele changed: What|Removed |Added Status|WAITING |UNCONFIRMED Depends on||68560 Ever confirmed|1 |0 --- Comment #5 from Joost VandeVondele --- (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
[Bug fortran/68649] [6 Regression] note: code may be misoptimized unless -fno-strict-aliasing is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68649 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2015-12-02 Ever confirmed|0 |1 --- Comment #4 from Dominique d'Humieres --- I think it is a duplicate of pr68560. > 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.
[Bug fortran/68649] [6 Regression] note: code may be misoptimized unless -fno-strict-aliasing is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68649 --- Comment #3 from Joost VandeVondele --- Grepping the list of 'note:' in our build process, it triggers for at least these functions: _gfortran_matmul_r8 _gfortran_reshape_4 _gfortran_reshape_c4 _gfortran_reshape_c8 _gfortran_reshape_r4 _gfortran_reshape_r8 _gfortran_unpack1 so it is somewhat general.
[Bug fortran/68649] [6 Regression] note: code may be misoptimized unless -fno-strict-aliasing is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68649 Andrew Pinski changed: What|Removed |Added Component|middle-end |fortran --- Comment #2 from Andrew Pinski --- This smells like a fortran front-end issue where _gfortran_reshape_r8's decl is created twice with two different argument types.
