[Bug tree-optimization/97164] New: incorrect offset on structure member where type of that member has aligned attribute

[Bug tree-optimization/97164] New: incorrect offset on structure member where type of that member has aligned attribute

[jan.smets at nokia dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97164

            Bug ID: 97164
           Summary: incorrect offset on structure member where type of
                    that member has aligned attribute
           Product: gcc
           Version: 10.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: jan.smets at nokia dot com
  Target Milestone: ---

Created attachment 49256
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49256&action=edit
testcase

Following testcase produces invalid code with GCC 10.2, 9.3, 8.4, 7.5
Works with GCC 6.5

GCC 6:
    movq    FPAPools+143752(%rdi), %rax

GCC 10 : 
    movq    FPAPools+143744(%rbx), %rax


Testcase compiled with : -fno-builtin -nostdinc -march=core2 -m64 -O2 
-mno-red-zone -fno-omit-frame-pointer -Wall -Wextra

Target: x86_64-linux-gnu
Configured with: /usr/src/gcc/configure --build=x86_64-linux-gnu
--disable-multilib --enable-languages=c,c++,fortran,go
gcc version 10.2.0 (GCC)

[Bug tree-optimization/97164] incorrect offset on structure member where type of that member has aligned attribute

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97164

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Bisection points to r238468 aka PR71901 fix.

[Bug tree-optimization/97164] incorrect offset on structure member where type of that member has aligned attribute

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97164

--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Reduced testcase for -O2:
typedef struct { int *a; char b[64]; } A __attribute__((aligned (64)));
struct B { A d[4]; } b;
void foo (void);

int *
bar (void)
{
  struct B *h = &b;
  if (h->d[1].a)
    foo ();
  return h->d[1].a;
}
Not really sure about the validity of the testcase (both original and reduced),
it works fine if one uses
typedef struct __attribute__((aligned (64))) A { int *a; char b[64]; } A;
instead.  The problem is that above, the (anonymous) struct has different
alignment from the typedef and we end up using the type without the increased
alignment for one of those accesses.

[Bug tree-optimization/97164] [8/9/10/11 Regression] incorrect offset on structure member where type of that member has aligned attribute

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97164

Richard Biener <rguenth at gcc dot gnu.org> 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 <rguenth at gcc dot gnu.org> ---
I will have a look.

[Bug tree-optimization/97164] [8/9/10/11 Regression] incorrect offset on structure member where type of that member has aligned attribute

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97164

Richard Biener <rguenth at gcc dot gnu.org> 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 <rguenth at gcc dot gnu.org> ---
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

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97164

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
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

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97164

--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 49260
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49260&action=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

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97164

--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
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.

[Bug tree-optimization/97164] [8/9/10/11 Regression] incorrect offset on structure member where type of that member has aligned attribute

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97164

--- Comment #8 from Richard Biener <rguenth at gcc dot gnu.org> ---
(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

[jan.smets at nokia dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97164

--- Comment #9 from Jan Smets <jan.smets at nokia dot com> ---
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

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97164

Richard Biener <rguenth at gcc dot gnu.org> 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

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97164

--- Comment #10 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:50bc94898fac1bd9cc1dabf227208fb5d369c4c4

commit r11-4282-g50bc94898fac1bd9cc1dabf227208fb5d369c4c4
Author: Jakub Jelinek <jakub@redhat.com>
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  <jakub@redhat.com>

            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 Regression] incorrect offset on structure member where type of that member has aligned attribute

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97164

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[8/9/10/11 Regression]      |[8/9/10 Regression]
                   |incorrect offset on         |incorrect offset on
                   |structure member where type |structure member where type
                   |of that member has aligned  |of that member has aligned
                   |attribute                   |attribute

--- Comment #11 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Fixed on the trunk, probably undesirable for backporting.

[Bug tree-optimization/97164] [9/10 Regression] incorrect offset on structure member where type of that member has aligned attribute

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97164

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|8.5                         |9.4

--- Comment #12 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 8 branch is being closed.

[Bug tree-optimization/97164] [9/10 Regression] incorrect offset on structure member where type of that member has aligned attribute

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97164

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|9.4                         |9.5

--- Comment #13 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 9.4 is being released, retargeting bugs to GCC 9.5.

[Bug tree-optimization/97164] [10 Regression] incorrect offset on structure member where type of that member has aligned attribute

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97164

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|9.5                         |10.4

--- Comment #14 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 9 branch is being closed

[Bug tree-optimization/97164] [10 Regression] incorrect offset on structure member where type of that member has aligned attribute

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97164

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|10.4                        |10.5

--- Comment #15 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 10.4 is being released, retargeting bugs to GCC 10.5.

[Bug tree-optimization/97164] [10 Regression] incorrect offset on structure member where type of that member has aligned attribute

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97164

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
      Known to work|                            |11.1.0
      Known to fail|                            |10.5.0
         Resolution|---                         |FIXED
   Target Milestone|10.5                        |11.0

--- Comment #16 from Richard Biener <rguenth at gcc dot gnu.org> ---
Fixed in GCC 11.