https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103095
Tom de Vries <vries at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Ever confirmed|0 |1
Status|RESOLVED |REOPENED
Resolution|INVALID |---
Last reconfirmed| |2021-11-07
Target|x86_64 |
--- Comment #3 from Tom de Vries <vries at gcc dot gnu.org> ---
This is not an x86_64-specific feature request, so removing the x86_64 from the
target field.
Thanks for pointing out -malign-data=abi, that's interesting.
I think though that it doesn't entirely match the feature request I've
described here.
Let's call the new one -fprecise-align for the moment. It may be that
-fprecise-align should imply -malign-data=abi, I'm not sure, but for the
purposes of this discussion, I'll assume not.
AFAIU, the -malign-data=abi option has the effect that the compiler doesn't
require more alignment than required by the abi (which is one interpretation of
no overalignment).
The additional idea of this feature request is that the toolchain guarantees
that if some alignment is required, the actual address fits that alignment, but
not a greater alignment (which is another interpretation of no overalignment.
Perhaps there's a better term for what I'm describing here?).
To be more concrete, take a float var, according to abi: size 4, alignment 4.
If we use -malign-data=abi and the variable at runtime is found at address 0x8,
we consider that the option is obeyed.
In contrast, if we use -malign=abi and -fprecise-align, and the variable at
runtime is found at address 0x8, we consider that the latter option is not
obeyed.
