On 01/31/2017 02:01 AM, Richard Biener wrote:
This amends ADJUST_FIELD_ALIGN to always get the type of the field
as argument but make the field itself optional. All actual target
macro implementations only look at the type of the field but FRV
(which seems to misuse ADJUST_FIELD_ALIGN to do bitfield layout
rather than using one of the three standard ways - Alex/Nick?).
Didn't we deprecate FRV? Oh, that was MEP.. Nevermind.
This speeds up min_align_of_type (no longer needs to build a FIELD_DECL)
and thus (IMHO) makes it usable from get_object_alignment. This
causes us no longer to return bogus answers for indirect accesses to
doubles on i?86 and expand to RTL with proper MEM_ALIGN. (it also
makes the previous fix for PR79256 no longer necessary)
Bootstrap and regtest running on x86_64-unknown-linux-gnu - is this ok
for trunk at this stage?
grep found a ADJUST_FIELD_ALIGN use in libobjc/encoding.c but that
is fed a C string(!?) as FIELD_DECL so I discounted it as unrelated
(and grep didn't find a way this macro could be defined there)?
Presumably this is the code that takes the structure and encodes
information about it for the runtime. Though taking a string sounds
horribly broken.
I suspect it gets included via tm.h.
I bet if someone built a cross far enough to build libobjc we could see
it in action. It does make one wonder how this part of libobjc could
possibly be working on targets that define ADJUST_FIELD_ALIGN.
I'll note it's been that way since libobjc was moved into its own
directory, but wasn't like that prior to moving into its own directory.
I have no idea what to do here...
Jeff
