On Wed, 1 Feb 2017, Iain Sandoe wrote:
>
> > 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
The change is
* doc/tm.texi.in (ADJUST_FIELD_ALIGN): Adjust to take additional
type parameter.
thus the target macro ADJUST_FIELD_ALIGN takes three parameters now,
in second place we insert a always-non-NULL TREE_TYPE of the field
(old and new first parameter, after the change may be NULL).
libobjc passes a const char * as first argument - I have no idea
what to pass as second ;) I _suppose_ the argument is supposed
to be never looked at so we could just pass NULL for both first
and new second parameter?
Wasn't successful in making a cross to ppc64-linux build its libobjc.
Richard.
