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

Krister Walfridsson <kristerw at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|INVALID                     |FIXED

--- Comment #4 from Krister Walfridsson <kristerw at gcc dot gnu.org> ---
The struct is 64-bit aligned in the C semantics, but the GIMPLE semantics is
more permissive (see the recent discussions on the mailing list [1][2]), and
several passes create misaligned pointers. For example, ivopts decides to
calculate &u.buf[off] as:

  union 
{
  char buf[31];
  long long int align_int;
  long double align_fp;
} * _13;
  _14 = (sizetype) off_4(D);
  _13 = &u + _14;

when compiling the function

static union {
  char buf[31];
  long long align_int;
  long double align_fp;
} u;

void check (int off)
{
  char *q;
  int i;

  q = u.buf;
  for (i = 0; i < off; i++, q++)
    if (*q != 'a')
      __builtin_abort ();
}

which makes _13 misaligned when off is not a multiple of 8.

So I claim the store-merging pass is not allowed to use the alignment of the
pointer to do the optimization. But it may of course be the case that it's
store-merging that is correct, and ivopts, etc. that are wrong. In that case, I
need some additional information about what the correct GIMPLE semantics is, so
I can report the real issues...

References:
 1. https://gcc.gnu.org/pipermail/gcc/2025-March/245763.html
 2. https://gcc.gnu.org/pipermail/gcc/2025-April/245870.html

Reply via email to