[cfe-commits] r140931 - in /cfe/trunk: include/clang/Basic/DiagnosticSemaKinds.td include/clang/Sema/AttributeList.h include/clang/Sema/Sema.h lib/Sema/SemaDeclAttr.cpp lib/Sema/SemaExpr.cpp lib/Sema/SemaType.cpp test/Parser/MicrosoftExtensions.c

[John McCall]

On Oct 6, 2011, at 5:34 PM, Nico Weber wrote:
> On Thu, Oct 6, 2011 at 11:31 AM, John McCall <rjmccall at apple.com> wrote:
>> On Oct 6, 2011, at 11:21 AM, Nico Weber wrote:
>>> this breaks the build of every project that uses glib and -Werror:
>>> 
>>> In file included from /usr/include/glib-2.0/glib/gasyncqueue.h:34:
>>> /usr/include/glib-2.0/glib/gthread.h:348:27: error: 'may_alias'
>>> attribute ignored when parsing type
>>>  if G_LIKELY ((gpointer) g_atomic_pointer_get (value_location) != NULL)
>>>     ~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>> /usr/include/glib-2.0/glib/gatomic.h:73:46: note: expanded from:
>>>  (g_atomic_pointer_get) ((volatile gpointer G_GNUC_MAY_ALIAS *) (void
>>> *) (atomic)))
>>>                                             ^
>>> /usr/include/glib-2.0/glib/gmacros.h:111:43: note: expanded from:
>>> #  define G_GNUC_MAY_ALIAS __attribute__((may_alias))
>>>                                          ^
>>> /usr/include/glib-2.0/glib/gmacros.h:273:25: note: expanded from:
>>> #define G_LIKELY(expr) (expr)
>>>                        ^~~~
>>> 
>>> Thoughts? Should this be a disablable warning?
>> 
>> All warnings should be disablable, but this specific problem should be fixed by making clang recognize may_alias.
> 
> Thanks, I opened http://llvm.org/bugs/PR11082 for that. It looks like
> type attributes are usually translated into Qualifiers, but according
> to test/CodeGen/may-alias.c and
> http://gcc.gnu.org/ml/gcc-patches/2008-01/msg01161.html , may_alias
> shouldn't really affect a type.

It's definitely a natural qualifier — lvalue-to-rvalue drops it, T* is a
subtype of T may_alias *, it propagates along member accesses, etc.

We don't always follow GCC's lead on canonical typing;  notably,
noreturn and calling conventions are part of a canonical function
type in Clang, although unfortunately we don't mangle them right
now.  I'm okay with that applying here, too, although I do think we
should mangle it.  Mostly, I think it's going to be pretty uncommon
to see this sort of thing in C++, so technically breaking interoperation
for conceptual purity is not a big deal.

Anyway, it would also be (temporarily) acceptable to just recognize
the attribute to suppress this warning.

John.