On Mon, Feb 22, 2016 at 03:07:09PM +0000, Alan Lawrence wrote:
> On 22/01/16 17:16, Alan Lawrence wrote:
> >
> >On 21/01/16 17:23, Alan Lawrence wrote:
> >>On 18/01/16 17:10, Eric Botcazou wrote:
> >>>
> >>>Could you post the list of files that differ? How do they differ exactly?
> >>
> >>Hmmm. Well, I definitely had this failing to bootstrap once. I repeated
> >>that, to
> >>try to identify exactly what the differences were....and it succeeded even
> >>with
> >>my pre-AAPCS64-update host compiler. So, this is probably a false alarm; I'm
> >>bootstrapping again, after a rebase, to make sure...
> >>
> >>--Alan
> >
> >Ok, rebased onto a more recent build, and bootstrapping with Ada posed no
> >problems. Sorry for the noise.
> >
> >However, I had to drop the assert that TYPE_FIELDS was non-null because of
> >some
> >C++ testcases.
> >
> >Is this version OK for trunk?
> >
> >--Alan
> >
> >gcc/ChangeLog:
> >
> > * gcc/config/aarch64/aarch64.c (aarch64_function_arg_alignment):
> > Rewrite, looking one level down for records and arrays.
> >---
> > gcc/config/aarch64/aarch64.c | 31 ++++++++++++++++---------------
> > 1 file changed, 16 insertions(+), 15 deletions(-)
> >
> >diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
> >index 9142ac0..b084f83 100644
> >--- a/gcc/config/aarch64/aarch64.c
> >+++ b/gcc/config/aarch64/aarch64.c
> >@@ -1925,22 +1925,23 @@ aarch64_vfp_is_call_candidate (cumulative_args_t
> >pcum_v, machine_mode mode,
> > static unsigned int
> > aarch64_function_arg_alignment (machine_mode mode, const_tree type)
> > {
> >- unsigned int alignment;
> >+ if (!type)
> >+ return GET_MODE_ALIGNMENT (mode);
> >+ if (integer_zerop (TYPE_SIZE (type)))
> >+ return 0;
> >
> >- if (type)
> >- {
> >- if (!integer_zerop (TYPE_SIZE (type)))
> >- {
> >- if (TYPE_MODE (type) == mode)
> >- alignment = TYPE_ALIGN (type);
> >- else
> >- alignment = GET_MODE_ALIGNMENT (mode);
> >- }
> >- else
> >- alignment = 0;
> >- }
> >- else
> >- alignment = GET_MODE_ALIGNMENT (mode);
> >+ gcc_assert (TYPE_MODE (type) == mode);
> >+
> >+ if (!AGGREGATE_TYPE_P (type))
> >+ return TYPE_ALIGN (TYPE_MAIN_VARIANT (type));
> >+
> >+ if (TREE_CODE (type) == ARRAY_TYPE)
> >+ return TYPE_ALIGN (TREE_TYPE (type));
> >+
> >+ unsigned int alignment = 0;
> >+
> >+ for (tree field = TYPE_FIELDS (type); field; field = DECL_CHAIN (field))
> >+ alignment = std::max (alignment, DECL_ALIGN (field));
> >
> > return alignment;
> > }
> >
>
>
> Ping.
>
> If this is not appropriate for GCC6, then is it OK for Stage 1 of GCC 7?
I think this needs to be a GCC 7 fix at this point.
Additionally, I'd like to fully understand PR69841 before we take this
patch.
In particular, under what circumstances can the C++ front end set DECL_ALIGN
of a type to be wider than we expect. Can we ever end up with 128-bit
alignment of a template parameter when we were expecting 32- or 64-bit
alignment, and if we can what are the implications on this patch?
Thanks,
James
