Support may_alias in processTypeAttrs() #11454
Comments
|
It's arguably an improvement over what we did before (i.e. ignore them). |
|
Going back to specifically ignoring this would be an okay short-term hack if we don't otherwise have this working for 3.0. |
|
Attributes are by their nature an implementation-specific thing. When using standard C++ attribute syntax, implementations are required to successfully translate programs using attributes with which the implementation is unfamiliar. I see no reason that this should not apply similarly to non-standard attribute syntax. We should have unknown attributes be at the very least a warning by default, and of course have an appropriate diagnostic group. |
|
I'm very bothered by this. It regresses essentially all Linux builds w/ Clang. =[ Ignoring this attribute wasn't breaking any of the Linux users, even if its the wrong thing to do here. I'm looking at a quick fix in the hope that we don't need to revert the original patch, but I think it's really bad to just regress on two platforms two weeks before 3.0's release.... |
I've done this in r141381 while we sort out what the correct solution is here. For reference, regardless of the 3.0 release, this regressed trunk too significantly to leave un-patched for long. It's really unclear to me what we should do with this attribute on a cast. I don't like just warning because I agree that these types of attributes must be supported if they are ever used. However, I also don't know what (if any) semantics to give such a cast in C++... |
may_alias is semantically a type qualifier: it's something that changes the semantics of operations on lvalues with the given qualifier, like volatile or restrict or __attribute((aligned(1))), and it gets stripped off as part of the lvalue-to-rvalue conversion. The tricky bit is how exactly pointer conversions work with this, i.e. do we allow an implicit conversion from int __attribute((may_alias))* to int* or vice versa. |
|
Yeah, note that the use of may_alias in Nico's example code is completely useless; this is something we would likely want to warn about. If we followed the usual subtyping rules, we would allow an implicit conversion from int* to int may_alias*. This is safe because it makes the optimizers strictly more cautious. IR-generation would implement the semantics of may_alias by suppressing the use of TBAA annotations on operations on such l-values. This is something that works in C++ just as well as it does in C. |
|
Closing, since |
Extended Description
clang now complains about unsupported attributes on types. As a consequence, it complains about may_alias in cast expressions such as here:
void g(int p attribute((may_alias))) {}
void f() {
int a = 0;
g((int attribute((may_alias)))a);
}
hummer:clang thakis$ ../../Release+Asserts/bin/clang -Wall test.c -c
test.c:5:25: error: 'may_alias' attribute ignored when parsing type
g((int attribute((may_alias)))a);
^~~~~~~~~
1 error generated.
This is used in glib, see e.g. here:
http://codesearch.google.com/#cZwlSNS7aEw/external/bluetooth/glib/glib/gatomic.h&q=%5C(g_atomic_pointer_set%5C)%5C%20%5C(%5C(volatile%5C%20gpointer%5C%20G_GNUC_MAY_ALIAS%5C%20%5C*%5C)%5C%20%5C(void%5C%20%5C*%5C)%5C%20%5C(atomic%5C),%5C%20%5C(newval%5C)%5C)%5C)&type=cs&l=76
The text was updated successfully, but these errors were encountered: