]> git.ipfire.org Git - thirdparty/gcc.git/commit
tree: Fix up component_ref_sam_type handling of arrays of 0 sized elements [PR109215]
authorJakub Jelinek <jakub@redhat.com>
Tue, 21 Mar 2023 10:06:20 +0000 (11:06 +0100)
committerJakub Jelinek <jakub@redhat.com>
Tue, 21 Mar 2023 10:06:20 +0000 (11:06 +0100)
commit03041e0361cbdd7f541f2f39060759aad866ed58
treeeb6ed004893ae83f1b0fbc80296d8eabb2b75d59
parent0395e1364dd969e5845d4b9198e6f8c28b297d36
tree: Fix up component_ref_sam_type handling of arrays of 0 sized elements [PR109215]

Our documentation sadly talks about elt_type arr[0]; as zero-length arrays,
not arrays with zero elements.  Unfortunately, those aren't the only arrays
which can have zero size, the same size can be also result of zero-length
element, like in GNU C struct whatever {} or in GNU C/C++ if the element
type is [0] array or combination thereof (dunno if Ada doesn't allow
something similar too).  One can't do much with them, taking address of
their elements, (no-op) copying of the elements in and out.  But they
behave differently from arr[0] arrays e.g. in that using non-zero indexes
in them (as long as they are within bounds as for normal arrays) is valid.

I think this naming inaccuracy resulted in Martin designing
special_array_member in an inconsistent way, mixing size zero array members
with array members of one or two or more elements and then using the
size zero interchangeably with zero elements.

The following patch changes that (but doesn't do any
documentation/diagnostics renaming, as this is really a corner case),
such that int_0/trail_0 for consistency is just about [0] arrays
plus [] for the latter, not one or more zero sized elements case.

The testcase has one xfailed case for where perhaps in later GCC versions
we could add extra code to handle it, for some reason we don't diagnose
out of bounds accesses for the zero sized elements cases.  It will be
harder because e.g. FRE will canonicalize &var.fld[0] and &var.fld[10]
to just one of them because they are provably the same address.
But the important thing is to fix this regression (where we warn on
completely valid code in the Linux kernel).  Anyway, for further work
on this we don't really need any extra help from special_array_member,
all code can just check integer_zerop (TYPE_SIZE_UNIT (TREE_TYPE (type))),
it doesn't depend on the position of the members etc.

2023-03-21  Jakub Jelinek  <jakub@redhat.com>

PR tree-optimization/109215
* tree.h (enum special_array_member): Adjust comments for int_0
and trail_0.
* tree.cc (component_ref_sam_type): Clear zero_elts if memtype
has zero sized element type and the array has variable number of
elements or constant one or more elements.
(component_ref_size): Adjust comments, formatting fix.

* gcc.dg/Wzero-length-array-bounds-3.c: New test.
gcc/testsuite/gcc.dg/Wzero-length-array-bounds-3.c [new file with mode: 0644]
gcc/tree.cc
gcc/tree.h