> On Oct 29, 2018, at 10:54 AM, Martin Sebor <mse...@gmail.com> 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
