Re: [PATCH] Fix PR79278, amend ADJUST_FIELD_ALIGN interface

[Richard Biener <rguenther at suse dot de>]

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.