Folks,
Behan sent me a piece of code in the kernel with a parsing issue in
Clang related to attributes:
This works on GCC, but not on Clang:
typedef unsigned char u8;
int func(int len, int mask) {
return len + (mask & ~(__alignof__(u8 __attribute__ ((aligned))) - 1));
}
Clang's warning on the first is:
* 'aligned' attribute ignored when parsing type
This fixes on Clang, too:
typedef unsigned char u8;
int func(int len, int mask) {
typedef u8 __attribute__ ((aligned)) u8_aligned;
return len + (mask & ~(__alignof__(u8_aligned) - 1));
}
I'm guessing Clang doesn't like inlined attributes. Is there a reason
why this is not implemented, or is this just a case that nobody has
seen before?
If the former, what reason? If the latter, how simple would it be to
implement it?
cheers,
--renato
This essentially is a design difference. Clang does not really have an
'aligned' attribute on types, it has an 'aligned' attribute on declarations
(including typedef declarations). Adding support for this is possible, but
it's a poorly-designed feature, especially when it interacts with C++ (the
attribute is *not* part of the canonical type, and GCC silently ignores it
in lots of places), so I'd be somewhat hesitant. We could probably support
it in the operand of __alignof__ as a special case.
Adding support for this is possible, but
it's a poorly-designed feature, especially when it interacts with C++ (the
attribute is *not* part of the canonical type, and GCC silently ignores it
in lots of places),
The worse I can think of here is name mangling, but that is "solved"
in GCC, AFAIK, by simply ignoring it and letting the user deal with
the issues.
I don't like this approach either, but there could be maybe a
compatibility mode where this would be accepted?
That said, I don't think this code is fantastic, and the extra line
adds nothing to the source or the generated output, so it could very
well be changed in the source.
so I'd be somewhat hesitant. We could probably support
it in the operand of __alignof__ as a special case.
This sounds as poor decision as ignoring alignment mangling, and not
directly relevant to the problem at hand.
cheers,
--renato
> Adding support for this is possible, but
> it's a poorly-designed feature, especially when it interacts with C++
(the
> attribute is *not* part of the canonical type, and GCC silently ignores
it
> in lots of places),
The worse I can think of here is name mangling, but that is "solved"
in GCC, AFAIK, by simply ignoring it and letting the user deal with
the issues.
The worst case that I can think of is that the attribute is silently
removed when the type is used as a template argument. That said, we already
have these issues for typedefs with alignment attributes, and we can
probably reject the cases where the attribute has no effect, so maybe this
isn't so bad.
I don't like this approach either, but there could be maybe a
compatibility mode where this would be accepted?
That said, I don't think this code is fantastic, and the extra line
adds nothing to the source or the generated output, so it could very
well be changed in the source.
> so I'd be somewhat hesitant. We could probably support
> it in the operand of __alignof__ as a special case.
This sounds as poor decision as ignoring alignment mangling, and not
directly relevant to the problem at hand.
I'm confused... this would exactly solve the problem at hand. The only case
you've presented of this is the attribute being used in the operand of
__alignof__, where the attribute arguably does make some sense. It wouldn't
silently do surprising things in any case, unlike GCC's approach.
You'd be creating a special behaviour for the operand of __alignof__,
which would create confusion if the user were to change the operand,
or move it outside, etc.
Supporting extensions is already risky business, because they're never
well documented on the complete meaning and where they're undefined
(like most of the standards), so it ends up most of the time being
whatever the other compilers implement.
I don't have access to ICC, but I'd be interested in which syntaxes it supports.
cheers,
--renato