[cfe-dev] GCC 6 Warnings

Richard Smith via cfe-dev cfe-dev at lists.llvm.org
Thu Sep 8 13:43:10 PDT 2016

On Thu, Sep 8, 2016 at 1:20 PM, Renato Golin <renato.golin at linaro.org>

> On 8 September 2016 at 21:07, Milian Wolff <mail at milianw.de> wrote:
> > I think this could be related:
> >
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71463
> Hum, it does look like the same problem.

I don't think so. The difference is, in that case, there is an attribute on
the entity that's part of the sugared type and gets erased through the
template argument. In this case, there is not.

I don't have GCC 6.1.1 so I can't put together a reduced testcase, but as
far as I can see, it would be something like this:

struct alignas(8) S {};
template<typename T> struct id { typedef T type; };
template<typename T> struct X {};
X<id<const S*>::type> x;

Note that the error GCC gives is for the template argument to X, not the
template argument to id, so somehow passing 'const S*' through a template
parameter and a typedef has made GCC incorrectly decide that there's an
attribute on the sugared type.

Eric, one of the comments was:
> "The attribute isn't properly part of the C++ type, so in the testcase
> below A<fna> needs to be the same type as A<fn>, and so they share a
> member function.  So we have to choose which type to use as the
> canonical type, and we choose the type without the attribute.  And
> that's what the "ignoring attributes" warning is telling you.
> typedef int fn();
> typedef int fna() __attribute ((warn_unused_result));"
> Do we use the Casting classes with Stmt (which has alignment
> attribute) as well as with other classes that don't have any
> attributes?
> Anyway, this seems like a silly warning in templates, as you're
> expected to use it with multiple types and they can have different
> attributes anyway.
> How is c++17 attributes going to work in this case? I assume they're
> going to be different types (in decltype's eyes), so GCC could do a
> similar implementation.
> cheers,
> --renato
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20160908/192a236d/attachment.html>

More information about the cfe-dev mailing list