On Tue, Sep 13, 2016 at 6:42 AM, Bernd Schmidt <bschmidt@redhat.com> wrote:
> On 09/12/2016 08:58 PM, Jason Merrill wrote:
>>
>> TARGET_ABSOLUTE_BIGGEST_ALIGNMENT is documented to be the largest
>> alignment possible for any type or variable, and defaults to
>> BIGGEST_ALIGNMENT.  But MAX_OFILE_ALIGNMENT is typically much larger
>> than BIGGEST_ALIGNMENT, and is documented as the limit for __attribute
>> ((aligned)).  Shouldn't it be considered in the default for
>> absolute_biggest_alignment?  But if we make that change, I expect that
>> your ACCEL_COMPILER streamer-in change would become a no-op.  What was
>> that change intended to accomplish?  I'm not finding anything about it
>> in gcc-patches.
>
> https://gcc.gnu.org/ml/gcc-patches/2014-11/msg00003.html
>
> Its only purpose is to limit alignments when offloading to a different
> target. You may be right about having to use MAX_OFILE_ALIGNMENT; I suppose
> defining it to 64 on nvptx would still work.

That might be problematic; looking in nvptx I see

/* Copied from elf.h and other places.  We'd otherwise use
   BIGGEST_ALIGNMENT and fail a number of testcases.  */
#define MAX_OFILE_ALIGNMENT (32768 * 8)

But we could define TARGET_ABSOLUTE_BIGGEST_ALIGNMENT on nvptx instead
of on x86; is this OK?

I'm still not sure why you need an alignment cap on nvptx, but I'm not
going to worry about it anymore.  :)