[cfe-dev] Inline attribute

Richard Smith richard at metafoo.co.uk
Sun Mar 23 11:46:11 PDT 2014


On Sun, Mar 23, 2014 at 11:28 AM, Renato Golin <renato.golin at linaro.org>wrote:

> On 23 March 2014 17:42, Richard Smith <richard at metafoo.co.uk> wrote:
> > 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20140323/50a03513/attachment.html>


More information about the cfe-dev mailing list