Re: [REPOST] Invalid Code when reading from unaligned zero-sized array

[Eric Botcazou <ebotcazou at adacore dot com>]

> That sounds less conservative though.  Anyway, that was just some thought
> to fix the eventual fallout of making more types have BLKmode.

In the end I was too optimistic...  Testing a revised patch on x86 revealed a 
obscure case where the new BLKmode triggered a layout change (I presume that 
there is some randomness in struct-layout-1.exp because I didn't see it for 
the earlier runs).  The culprit is:

int
x86_field_alignment (tree field, int computed)
{
  enum machine_mode mode;
  tree type = TREE_TYPE (field);

  if (TARGET_64BIT || TARGET_ALIGN_DOUBLE)
    return computed;
  mode = TYPE_MODE (strip_array_types (type));
  if (mode == DFmode || mode == DCmode
      || GET_MODE_CLASS (mode) == MODE_INT
      || GET_MODE_CLASS (mode) == MODE_COMPLEX_INT)
    return MIN (32, computed);
  return computed;
}

which of course blatantly violates the do-not-rely-on-mode rule.  Although the 
layout change apparently occurs very rarely, I think that this rules out the 
direct mode change in stor-layout.c... <snip>

At this point, I'd agree with either of the following 2 solutions:

 1. Instead of changing the mode, we set a flag on the type (conveniently we 
can reuse the TYPE_NO_FORCE_BLK bit since it's only set for types with BLKmode 
already) and test it during RTL expansion to force BLKmode,

 2. Bernd's latest patch, but with the new boolean parameter explicitly called 
KEEP_UNALIGNED_MEMORY and a fat comment along the lines of:

  If KEEP_UNALIGNED_MEMORY is true, we don't adjust a returned MEM rtx that
  wouldn't be sufficient aligned for its mode; instead, it's up to the caller
  to deal with it afterwards.  This is used to make sure that unaligned base
  objects for which out-of-bounds accesses are supported, for example record
  types with trailing arrays, aren't realigned behind the back of the caller.
  The normal operating mode is to pass FALSE for this parameter.

-- 
Eric Botcazou