On Tue, 31 Jan 2017, Jeff Law wrote: > 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...
As objc builds just fine on x86_64 which does define ADJUST_FIELD_ALIGN including tm.h can't be the whole story here... In fact preprocessed source on x86_64 with -dD shows no ADJUST_FIELD_ALIGN but instead #define rs6000_special_adjust_field_align_p(FIELD,COMPUTED) 0 which means it must be sth powerpc specific... FRV for example has /* @@@ A hack, needed because libobjc wants to use ADJUST_FIELD_ALIGN for some reason. */ #ifdef IN_TARGET_LIBS #define BIGGEST_FIELD_ALIGNMENT 64 #else /* An expression for the alignment of a structure field FIELD if the alignment computed in the usual way is COMPUTED. GCC uses this value instead of the value in `BIGGEST_ALIGNMENT' or `BIGGEST_FIELD_ALIGNMENT', if defined, for structure fields only. */ #define ADJUST_FIELD_ALIGN(FIELD, COMPUTED) \ frv_adjust_field_align (FIELD, COMPUTED) #endif Similar x86_64. So it seems on power this might be an issue and thus I'd need to adjust the macro use - but not sure what to pass as "type" here... I'll try to build a cross to ppc64 and see what happens. Richard.
