[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
rjmccall at apple.com
Thu Oct 6 17:47:50 PDT 2011
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.
More information about the cfe-commits
mailing list