> 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