On Mon, 16 Dec 2013, Eric Botcazou wrote: > 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>
Well - makes such a change unsuitable for 4.9. Longer-term we still want to avoid ABIs depending on modes of structs / unions / arrays (and depending on modes of vectors can also have undesired effects in some cases - I took care when working on the ARM hard-float ABI variant to avoid the ABI for argument passing of GCC generic vectors depending on whether NEON vector support was enables). That suggests to me: * Produce a list of all ABI-affecting target macros and hooks that might, wrongly, use modes to determine the ABI (struct layout, alignment, argument passing, function return, etc.). * Put that on a wiki page along with a description of the problem (when it's OK to use modes in determining the ABI and when it isn't). Also make sure the documentation of the macros / hooks in the internals manual is clear about not using modes inappropriately. * Put a table of target architectures on the wiki page with a column for architecture maintainers to record whether they have checked for and fixed any problematic uses of modes. * Ask architecture maintainers to do the checks and fixes. Fixes may be nontrivial in some cases, as compatibility means that if the ABI did depend on the mode you may need to replicate the relevant bits of stor-layout.c logic that determined the mode inside the back end. * After a while (pinging maintainers as needed), obsolete then remove any architectures that have not been checked. -- Joseph S. Myers jos...@codesourcery.com
