Evgeny Karpov <evgeny.kar...@microsoft.com> writes: > Thursday, October 17, 2024 > Richard Sandiford <richard.sandif...@arm.com> wrote: > >>>>> For instance: >>>>> float __attribute__((aligned (32))) large_aligned_array[3]; >>>>> >>>>> BIGGEST_ALIGNMENT could be up to 512 bits on x64. >>>>> This patch has been added to cover this case without needing to >>>>> change the FFmpeg code. >>>> >>>> What goes wrong if we don't do this? I'm not sure from the description >>>> whether it's a correctness fix, a performance fix, or whether it's about >>>> avoiding wasted space. >>> >>> It is a correctness fix. >> >> But you could you explain what goes wrong if you don't do this? >> (I realise it might be very obvious when you've seen it happen :) >> But I'm genuinely unsure.) > > It will generate an error if ASM_OUTPUT_ALIGNED_LOCAL is not declared. > > error: requested alignment for ‘large_aligned_array’ is greater than > implemented alignment of 16 > 7 | float __attribute__((aligned (32))) large_aligned_array[3];
Ah, ok, thanks. >> Why do we ignore the alignment if it is less than BIGGEST_ALIGNMENT? > > If ASM_OUTPUT_ALIGNED_LOCAL uses an alignment less than BIGGEST_ALIGNMENT, > it might trigger a relocation issue. > > relocation truncated to fit: IMAGE_REL_ARM64_PAGEOFFSET_12L Sorry to press the issue, but: why does that happen? >> Better to use "auto" rather than "unsigned". > It looks like "auto" cannot be used there. What goes wrong if you use it? The reason for asking for "auto" was to avoid silent truncation. Thanks, Rihard
