This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: "aligned" attribute with too-large argument


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]