> On 1 Feb 2017, at 08:42, Richard Biener <rguent...@suse.de> 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 >>> (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…
It also builds fine on powerpc-darwin9 (Darwin builds libobjc and tests both gnu-runtime and next-runtime [the latter with the system pre-installed NeXT runtime]). > 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. */ the (intended) reason is to get correct input for @encode which is supposed to be able to describe the layout of an object, to and from a description presented as the encoding string - this is, naturally, target-specific. (however, perhaps that is broken in some way that we don’t test :( ) > #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. I’m also in the process of trying to get powerpc64-darwin to build on trunk (that will also test libobjc); although from Jeff’s commment about this being present for a long time, I can say that powerpc64-darwin9 does at least build a working libobjc for 6.3.0 .. will subscribe to the PR - but not 100% clear what change you want to make, Iain
