On Wed, Feb 01, 2017 at 09:42:08AM +0100, Richard Biener wrote: > 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
Yeah, this is all rather horrifying, but that actually "works" because libobjc/encoding.c redefines the tree accessor macros it needs to work with the strings. > > > (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. It does. > > 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 i386.h conditions the definition on IN_TARGET_LIBS > but instead > > #define rs6000_special_adjust_field_align_p(FIELD,COMPUTED) 0 > > which means it must be sth powerpc specific... FRV for example has Yeah, different targets deal with this mess in different ways, looks like frv uses a different macro and ppc redefines macros as needed rs6000_special_adjust_field_align_p is also defined in ppc headers. > > /* @@@ 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... Sorry but I seem to have successfully purged my brain of the details on how this works. Trev > > I'll try to build a cross to ppc64 and see what happens. > > Richard.
