[Bug tree-optimization/97164] [8/9/10/11 Regression] incorrect offset on structure member where type of that member has aligned attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97164 --- Comment #10 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:50bc94898fac1bd9cc1dabf227208fb5d369c4c4 commit r11-4282-g50bc94898fac1bd9cc1dabf227208fb5d369c4c4 Author: Jakub Jelinek Date: Fri Oct 23 10:05:17 2020 +0200 stor-layout: Reject forming arrays with elt sizes not divisible by elt alignment [PR97164] As mentioned in the PR, since 2005 we reject if array elements are smaller than their alignment (i.e. overaligned elements), because such arrays don't make much sense, only their first element is guaranteed to be aligned as user requested, but the next element can't be. The following testcases show something we've been silent about but is equally bad, the 2005 case is just the most common special case of that the array element size is not divisible by the alignment. In those arrays too only the first element is guaranteed to be properly aligned and the second one can't be. This patch rejects those cases too, but keeps the existing wording for the old common case. Unfortunately, the patch breaks bootstrap, because libbid uses this mess (forms arrays with 24 byte long elements with 16 byte element alignment). I don't really see justification for that, so I've decreased the alignment to 8 bytes instead. 2020-10-23 Jakub Jelinek PR tree-optimization/97164 gcc/ * stor-layout.c (layout_type): Also reject arrays where element size is constant, but not a multiple of element alignment. gcc/testsuite/ * c-c++-common/pr97164.c: New test. * gcc.c-torture/execute/pr36093.c: Move ... * gcc.dg/pr36093.c: ... here. Add dg-do compile and dg-error directives. * gcc.c-torture/execute/pr43783.c: Move ... * gcc.dg/pr43783.c: ... here. Add dg-do compile, dg-options and dg-error directives. libgcc/config/libbid/ * bid_functions.h (UINT192): Decrease alignment to 8 bytes.
[Bug tree-optimization/97164] [8/9/10/11 Regression] incorrect offset on structure member where type of that member has aligned attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97164 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug tree-optimization/97164] [8/9/10/11 Regression] incorrect offset on structure member where type of that member has aligned attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97164 --- Comment #9 from Jan Smets --- Thanks for the quick resolution everyone. Our codebase apparenty has a handful of these issues.
[Bug tree-optimization/97164] [8/9/10/11 Regression] incorrect offset on structure member where type of that member has aligned attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97164
--- Comment #8 from Richard Biener ---
(In reply to Jakub Jelinek from comment #7)
> With additional
> --- libgcc/config/libbid/bid_functions.h.jj 2020-01-14 20:02:48.619582332
> +0100
> +++ libgcc/config/libbid/bid_functions.h 2020-09-23 01:12:02.672546190
> +0200
> @@ -81,7 +81,7 @@ ALIGN (16)
> #define SQRT80 sqrtw
> #endif
>
> - typedef ALIGN (16)
> + typedef ALIGN (8)
> struct {
> UINT64 w[3];
> } UINT192;
> it bootstrapped on x86_64-linux, with
> gcc.c-torture/execute/pr36093.c and gcc.c-torture/execute/pr43783.c tests
> that use the same things regressing (guess they'd need to be removed).
> Is libgcc always compiled with the new compiler rather than with system
> compiler though? If not, that might be a blocker for building older gcc
> versions with the new one.
Yes, libgcc is always built with the built compiler since it's a target
library.
The exception might be for canadian cross but IIRC we do not support mixing
compiler versions there?
[Bug tree-optimization/97164] [8/9/10/11 Regression] incorrect offset on structure member where type of that member has aligned attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97164
--- Comment #7 from Jakub Jelinek ---
With additional
--- libgcc/config/libbid/bid_functions.h.jj 2020-01-14 20:02:48.619582332
+0100
+++ libgcc/config/libbid/bid_functions.h2020-09-23 01:12:02.672546190
+0200
@@ -81,7 +81,7 @@ ALIGN (16)
#define SQRT80 sqrtw
#endif
- typedef ALIGN (16)
+ typedef ALIGN (8)
struct {
UINT64 w[3];
} UINT192;
it bootstrapped on x86_64-linux, with
gcc.c-torture/execute/pr36093.c and gcc.c-torture/execute/pr43783.c tests that
use the same things regressing (guess they'd need to be removed).
Is libgcc always compiled with the new compiler rather than with system
compiler though? If not, that might be a blocker for building older gcc
versions with the new one.
[Bug tree-optimization/97164] [8/9/10/11 Regression] incorrect offset on structure member where type of that member has aligned attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97164 --- Comment #6 from Jakub Jelinek --- Created attachment 49260 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49260=edit gcc11-pr97164.patch I've tried the above patch overnight, unfortunately libbid uses such construct, so it broke bootstrap.
[Bug tree-optimization/97164] [8/9/10/11 Regression] incorrect offset on structure member where type of that member has aligned attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97164 --- Comment #5 from Jakub Jelinek --- Indeed, if in the above testcase one uses b[40] instead of b[64], then it is rejected with that error message. Note, this isn't a FE diagnostics, but stor-layout.c one. We won't be able to diagnose this if the element is variable length, but at least diagnosing it for for the constant sizes might be sufficient, variable length structures are except for maybe Ada very rarely used.
[Bug tree-optimization/97164] [8/9/10/11 Regression] incorrect offset on structure member where type of that member has aligned attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97164
Richard Biener changed:
What|Removed |Added
CC||jsm28 at gcc dot gnu.org,
||rguenth at gcc dot gnu.org
Keywords||accepts-invalid
Assignee|rguenth at gcc dot gnu.org |unassigned at gcc dot
gnu.org
Status|ASSIGNED|NEW
--- Comment #4 from Richard Biener ---
So the issue is we do
/* But record element size in units of the type alignment. */
temp.op2 = TREE_OPERAND (ref, 3);
temp.align = eltype->type_common.align;
if (! temp.op2)
temp.op2 = size_binop (EXACT_DIV_EXPR, TYPE_SIZE_UNIT (eltype),
size_int (TYPE_ALIGN_UNIT (eltype)));
and compute EXACT_DIV of 72 (unit size) by 64 (alignment). That computes
without ICEing but it will result in a badly reconstructed element size, 64,
and thus a badly reconstructed effective offset. We do this "dance" because
op2 is measured in alignment units of the element type and to reconstruct
the offset we do
tree
array_ref_element_size (tree exp)
{
tree aligned_size = TREE_OPERAND (exp, 3);
tree elmt_type = TREE_TYPE (TREE_TYPE (TREE_OPERAND (exp, 0)));
location_t loc = EXPR_LOCATION (exp);
/* If a size was specified in the ARRAY_REF, it's the size measured
in alignment units of the element type. So multiply by that value. */
if (aligned_size)
{
/* ??? tree_ssa_useless_type_conversion will eliminate casts to
sizetype from another type of the same width and signedness. */
if (TREE_TYPE (aligned_size) != sizetype)
aligned_size = fold_convert_loc (loc, sizetype, aligned_size);
return size_binop_loc (loc, MULT_EXPR, aligned_size,
size_int (TYPE_ALIGN_UNIT (elmt_type)));
so there's no TREE_OPERAND (array-ref, 2) that "correctly" represents the
ARRAY_REF and IMHO the fact that we expand it "correctly" is pure luck.
For C arrays the element type has to be aligned so its size is a multiple
of it (thus all elements can be correctly aligned). And C arrays have no
"padding".
Not sure what to do here, the FE could reject this or the layout would need
to insert padding, but IIRC we reject arrays of overaligned types:
typedef int aligned_int __attribute__((aligned(8)));
aligned_int x[4];
> ./cc1 -quiet t5.c
t5.c:15:1: error: alignment of array elements is greater than element size
15 | aligned_int x[4];
| ^~~
IMHO this should be expanded to "size of array element is not a multiple
of its alignment"?
[Bug tree-optimization/97164] [8/9/10/11 Regression] incorrect offset on structure member where type of that member has aligned attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97164 Richard Biener changed: What|Removed |Added Summary|incorrect offset on |[8/9/10/11 Regression] |structure member where type |incorrect offset on |of that member has aligned |structure member where type |attribute |of that member has aligned ||attribute Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Known to work||6.5.0 Known to fail||7.5.0 Keywords||wrong-code Status|UNCONFIRMED |ASSIGNED Target Milestone|--- |8.5 Last reconfirmed||2020-09-22 --- Comment #3 from Richard Biener --- I will have a look.
