> Frankly speaking, I do not understand, what's wrong here. > IMHO, this change is pretty mechanical: we just extend maximal aligment > available. Because of 512-bit data types we now extend maximal aligment to > 512 bits.
Nothing wrong per se, but... > I suspect that an issue is here: > if (opt > && AGGREGATE_TYPE_P (type) > && TYPE_SIZE (type) > && TREE_CODE (TYPE_SIZE (type)) == INTEGER_CST > && (TREE_INT_CST_LOW (TYPE_SIZE (type)) >= (unsigned) max_align > > || TREE_INT_CST_HIGH (TYPE_SIZE (type))) > > && align < max_align) > align = max_align; ...yes, bumping max_align has the unexpected side effect of changing the behavior for sizes between the old value and the new value because of this code. I'm no x86 specialist, but I think that this should be fixed. > Maybe we can split it and handle 256-bit aggregates separately? Probably, and we should also add a warning just before the declaration of max_align, as well as investigate whether this didn't already happen when max_align was bumped from 128 to 256. -- Eric Botcazou
