"aligned" attribute with too-large argument

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

"aligned" attribute with too-large argument

Paul Koning-6
I noticed an inconsistency in the handling of the aligned attribute.  When applied to variables, I get an error message if the alignment is too large for the platform.  But when applied to functions, there is no error check.  The same applies to label alignment (from the -falign-labels switch).

The result is an ICE in my target code because it is asked to output assembly language for an alignment not supported by the target.

Should these cases also produce error messages?  Or should the back end ignore attempts to align too much?

        paul

Reply | Threaded
Open this post in threaded view
|

Re: "aligned" attribute with too-large argument

Martin Sebor-2
On 10/29/2018 07:45 AM, Paul Koning wrote:
> I noticed an inconsistency in the handling of the aligned attribute.  When applied to variables, I get an error message if the alignment is too large for the platform.  But when applied to functions, there is no error check.  The same applies to label alignment (from the -falign-labels switch).
>
> The result is an ICE in my target code because it is asked to output assembly language for an alignment not supported by the target.
>
> Should these cases also produce error messages?  Or should the back end ignore attempts to align too much?

check_user_alignment() in c-attribs.c rejects excessive alignments
the same for functions and variables:

   else if (i >= HOST_BITS_PER_INT - LOG2_BITS_PER_UNIT)
     {
       error ("requested alignment is too large");
       return -1;
     }

so I don't immediately see where this inconsistency comes from
Is there different/more restrictive handling for variables in
the back end? (a test case would be great).

That said, attribute problems aren't handled perfectly consistently
in GCC.  Some result in errors, others in warnings, and some are
silently ignored.  I've been tracking the problems I notice in
Bugzilla (those with "aligned" in their title are: 87524, 84185,
82914, 81566, 69502, 65055, 61939).  In my view, silently ignoring
problems without as much as a warning is a bug.  But whether they
should result in warnings or errors can be debated on a case by
case basis.  For instance, it might be appropriate to give
an error when a negative alignment is specified but just a warning
when the specified alignment is less than the minimum for the symbol
for the target.  For the case you mention I think an argument could
be for either, but given the check_user_alignment handling I'd say
an error would seem to be in line with the current practice.

Martin
Reply | Threaded
Open this post in threaded view
|

Re: "aligned" attribute with too-large argument

Paul Koning-6


> On Oct 29, 2018, at 10:54 AM, Martin Sebor <[hidden email]> wrote:
>
> On 10/29/2018 07:45 AM, Paul Koning wrote:
>> I noticed an inconsistency in the handling of the aligned attribute.  When applied to variables, I get an error message if the alignment is too large for the platform.  But when applied to functions, there is no error check.  The same applies to label alignment (from the -falign-labels switch).
>>
>> The result is an ICE in my target code because it is asked to output assembly language for an alignment not supported by the target.
>>
>> Should these cases also produce error messages?  Or should the back end ignore attempts to align too much?
>
> check_user_alignment() in c-attribs.c rejects excessive alignments
> the same for functions and variables:
>
>  else if (i >= HOST_BITS_PER_INT - LOG2_BITS_PER_UNIT)
>    {
>      error ("requested alignment is too large");
>      return -1;
>    }

Yes, but that code merely verifies that the requested alignment can be represented on the host doing the compiling.

> so I don't immediately see where this inconsistency comes from
> Is there different/more restrictive handling for variables in
> the back end? (a test case would be great).

The error I get for variables comes from varasm.c, align_variable:

  if (align > MAX_OFILE_ALIGNMENT)
    {
      error ("alignment of %q+D is greater than maximum object "
             "file alignment %d", decl,
             MAX_OFILE_ALIGNMENT/BITS_PER_UNIT);
      align = MAX_OFILE_ALIGNMENT;
    }

There are some other references to MAX_OFILE_ALIGNMENT, but they all seem to be related to variables.  I would think that the same check should also be applied to other objects that are mentioned in the output file, specifically code (functions and labels).  

I'll attach a test case.  On Intel, the max alignment is 32768 so the declaration of variable "ag" fails on the above error check.  But if I comment out that line, the function alignment is silently accepted and generates the corresponding assembly file directive (".align 16").  And the assembler accepts that because apparently 64k alignment IS allowed...

> That said, attribute problems aren't handled perfectly consistently
> in GCC.  Some result in errors, others in warnings, and some are
> silently ignored.  I've been tracking the problems I notice in
> Bugzilla (those with "aligned" in their title are: 87524, 84185,
> 82914, 81566, 69502, 65055, 61939).  In my view, silently ignoring
> problems without as much as a warning is a bug.  But whether they
> should result in warnings or errors can be debated on a case by
> case basis.  For instance, it might be appropriate to give
> an error when a negative alignment is specified but just a warning
> when the specified alignment is less than the minimum for the symbol
> for the target.  For the case you mention I think an argument could
> be for either, but given the check_user_alignment handling I'd say
> an error would seem to be in line with the current practice.
>
> Martin

Ok, I'll enter a PR.

        paul


Reply | Threaded
Open this post in threaded view
|

Re: "aligned" attribute with too-large argument

Paul Koning-6
In reply to this post by Martin Sebor-2


> On Oct 29, 2018, at 10:54 AM, Martin Sebor <[hidden email]> wrote:
>
> On 10/29/2018 07:45 AM, Paul Koning wrote:
>> I noticed an inconsistency in the handling of the aligned attribute.  When applied to variables, I get an error message if the alignment is too large for the platform.  But when applied to functions, there is no error check.  The same applies to label alignment (from the -falign-labels switch).
>>
>> The result is an ICE in my target code because it is asked to output assembly language for an alignment not supported by the target.
>>
>> Should these cases also produce error messages?  Or should the back end ignore attempts to align too much?
>
> check_user_alignment() in c-attribs.c rejects excessive alignments
> the same for functions and variables:
>
> else if (i >= HOST_BITS_PER_INT - LOG2_BITS_PER_UNIT)
>   {
>     error ("requested alignment is too large");
>     return -1;
>   }
>
> so I don't immediately see where this inconsistency comes from
> Is there different/more restrictive handling for variables in
> the back end? (a test case would be great).
I forgot to attach it.  Here it is.

        paul





testalign.c (326 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: "aligned" attribute with too-large argument

Paul Koning-6
In reply to this post by Paul Koning-6


> On Oct 29, 2018, at 11:18 AM, Paul Koning <[hidden email]> wrote:
>
> ...
>
>> That said, attribute problems aren't handled perfectly consistently
>> in GCC.  Some result in errors, others in warnings, and some are
>> silently ignored.  I've been tracking the problems I notice in
>> Bugzilla (those with "aligned" in their title are: 87524, 84185,
>> 82914, 81566, 69502, 65055, 61939).  In my view, silently ignoring
>> problems without as much as a warning is a bug.  But whether they
>> should result in warnings or errors can be debated on a case by
>> case basis.  For instance, it might be appropriate to give
>> an error when a negative alignment is specified but just a warning
>> when the specified alignment is less than the minimum for the symbol
>> for the target.  For the case you mention I think an argument could
>> be for either, but given the check_user_alignment handling I'd say
>> an error would seem to be in line with the current practice.
>>
>> Martin
>
> Ok, I'll enter a PR.

Done.  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87795

        paul


Reply | Threaded
Open this post in threaded view
|

Re: "aligned" attribute with too-large argument

Martin Sebor-2
In reply to this post by Paul Koning-6
On 10/29/2018 09:19 AM, Paul Koning wrote:

>
>
>> On Oct 29, 2018, at 10:54 AM, Martin Sebor <[hidden email]> wrote:
>>
>> On 10/29/2018 07:45 AM, Paul Koning wrote:
>>> I noticed an inconsistency in the handling of the aligned attribute.  When applied to variables, I get an error message if the alignment is too large for the platform.  But when applied to functions, there is no error check.  The same applies to label alignment (from the -falign-labels switch).
>>>
>>> The result is an ICE in my target code because it is asked to output assembly language for an alignment not supported by the target.
>>>
>>> Should these cases also produce error messages?  Or should the back end ignore attempts to align too much?
>>
>> check_user_alignment() in c-attribs.c rejects excessive alignments
>> the same for functions and variables:
>>
>> else if (i >= HOST_BITS_PER_INT - LOG2_BITS_PER_UNIT)
>>   {
>>     error ("requested alignment is too large");
>>     return -1;
>>   }
>>
>> so I don't immediately see where this inconsistency comes from
>> Is there different/more restrictive handling for variables in
>> the back end? (a test case would be great).
>
> I forgot to attach it.  Here it is.

I don't see any errors with the test case on x86_64.  In GDB I see
the alignment for ag is 524288 and MAX_OFILE_ALIGNMENT is 2147483648.
What target do you see the error with?

Martin


Reply | Threaded
Open this post in threaded view
|

Re: "aligned" attribute with too-large argument

Paul Koning-6


> On Oct 29, 2018, at 4:08 PM, Martin Sebor <[hidden email]> wrote:
>
> On 10/29/2018 09:19 AM, Paul Koning wrote:
>>
>>
>>> On Oct 29, 2018, at 10:54 AM, Martin Sebor <[hidden email]> wrote:
>>>
>>> On 10/29/2018 07:45 AM, Paul Koning wrote:
>>>> I noticed an inconsistency in the handling of the aligned attribute.  When applied to variables, I get an error message if the alignment is too large for the platform.  But when applied to functions, there is no error check.  The same applies to label alignment (from the -falign-labels switch).
>>>>
>>>> The result is an ICE in my target code because it is asked to output assembly language for an alignment not supported by the target.
>>>>
>>>> Should these cases also produce error messages?  Or should the back end ignore attempts to align too much?
>>>
>>> check_user_alignment() in c-attribs.c rejects excessive alignments
>>> the same for functions and variables:
>>>
>>> else if (i >= HOST_BITS_PER_INT - LOG2_BITS_PER_UNIT)
>>>  {
>>>    error ("requested alignment is too large");
>>>    return -1;
>>>  }
>>>
>>> so I don't immediately see where this inconsistency comes from
>>> Is there different/more restrictive handling for variables in
>>> the back end? (a test case would be great).
>>
>> I forgot to attach it.  Here it is.
>
> I don't see any errors with the test case on x86_64.  In GDB I see
> the alignment for ag is 524288 and MAX_OFILE_ALIGNMENT is 2147483648.
> What target do you see the error with?
>
> Martin

There are two related issues.

One is that GCC says the max alignment for variables on x86 is 32768 (MAX_OFILE_ALIGNMENT is 32768).  And it enforces that, for variables.  But a request to align a function to 65536 is permitted.  Since the assembler doesn't actually complain, no errors appear.

On pdp11, MAX_OFILE_ALIGNMENT is 2.  So in the test file I sent, the aligned(2) entries are legal and the others are not.  Since the target doesn't know how to generate assembly code for alignment greater than 2, the overly aligned function results in an ICE.  But the overly aligned variables generate error messages, as expected.

What I want is for function and label alignment to honor MAX_OFILE_ALIGNMENT.  The only alternative is to silently ignore excessive function alignment in the target code.

        paul