@@ -416,6 +416,12 @@ added in the future:
This calling convention, like the `PreserveMost` calling convention, will
be
used by a future version of the ObjectiveC runtime and should be considered
experimental at this time.
+"``preserve_nonecc``" - The `PreserveNone`
pinskia wrote:
One question since the attribute is applied to types is there a way to get the
nolock/noalloc from type?.
e.g.
```
template [[nolock(T)]] void f(T a) { a(); }
```
Will the above work or is there no way to implement that currently?
Since you mention it is attached to the type, is
pinskia wrote:
Note the corresponding GCC bug is at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99312 (and there was a patch
posted but never reviewed;
https://gcc.gnu.org/pipermail/gcc-patches/2021-March/566322.html).
https://github.com/llvm/llvm-project/pull/81493
_
pinskia wrote:
Does it make sense to have some C testcases too? Likewise some testcases
testing the __attribute__ style attribute?
I would say more testcases the better really.
https://github.com/llvm/llvm-project/pull/84983
___
cfe-commits mailing li
pinskia wrote:
https://github.com/itanium-cxx-abi/cxx-abi/issues/74
https://github.com/llvm/llvm-project/pull/89446
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
pinskia wrote:
Reference to https://github.com/llvm/llvm-project/issues/55894 .
https://github.com/llvm/llvm-project/pull/89807
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
pinskia wrote:
Note the corresponding GCC patch:
https://gcc.gnu.org/pipermail/gcc-patches/2024-May/650664.html
https://github.com/llvm/llvm-project/pull/91022
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailm
pinskia wrote:
I don't think you can use x16 and x17 for argument passing due to them being
reserved for PLTs and call veneers.
https://github.com/llvm/llvm-project/pull/91046
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.
@@ -5658,17 +5658,20 @@ experimental at this time.
def PreserveNoneDocs : Documentation {
let Category = DocCatCallingConvs;
let Content = [{
-On X86-64 target, this attribute changes the calling convention of a function.
+On X86-64 and AArch64 targets, this attribute chang
pinskia wrote:
Well assume attribute is a good example of where gcc and clang disagree and
might cause issues. Gcc implemented the assume attribute just the same as the
standard one. While clang implemented before standardization and now they
differ and could cause issues. This is why I reques
pinskia wrote:
Note the C++ issue with NRVO is
https://cplusplus.github.io/CWG/issues/2868.html .
https://github.com/llvm/llvm-project/pull/101038
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/
pinskia wrote:
>From my point of view this looks like a decent documentation of this
>extension. Note I filed the original bug because I noticed both GCC and clang
>didn't document this extension. (I filed GCC here:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117689 which I got try fix next
pinskia wrote:
Note GCC already treats `void*` as being compatiable with all other pointers
and has since GCC 6 (when it started to disambiguates accesses to different
pointers). I don't think it is documented though.
Another example where clang/LLVM handles void pointers differently from GCC:
pinskia wrote:
Note GCC's testcase testsuite/gcc.dg/alias-14.c is testcase for this extension:
"as an extension we consider void * universal. Writes to it should alias."
https://github.com/llvm/llvm-project/pull/122116
___
cfe-commits mailing list
cfe
pinskia wrote:
What is the definition of current target? Is it the current subtarget? Or is it
returning true even when NOT using `#pragma GCC target` (or the target
attribute) even if the builtin is not work for the subtarget?
This is unrelated to offloading but is similar issue.
With respect
pinskia wrote:
Maybe the problem with the name I am having is the word `has`. Maybe
`__can_use_builtin` seems like a better name. And that seems like would be a
good context sensative clue.
https://github.com/llvm/llvm-project/pull/126324
___
cfe-com
pinskia wrote:
I submitted https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118882 to ask the
other GCC folks about what they think is a good idea because I have no other
thoughts on this; I just think something needs to be done.
https://github.com/llvm/llvm-project/pull/126324
___
@@ -0,0 +1,17 @@
+// RUN: %clang_cc1 -std=c99 -fsyntax-only -verify %s
pinskia wrote:
> This feels like a pretty bare bones set of tests, I think we can do better.
>
> For example, it has been discussed that there should not be side effects,
> let's verify that
pinskia wrote:
Note the GCC implementtion of __builtin_is_modifiable_lvalue that I have
implemented (unlike __builtin_constant_p which in some but not all cases)
throws away the full expression that is inside __builtin_is_modifiable_lvalue
since it is fully implemented in the parser rather tha
@@ -12985,6 +12985,16 @@ bool IntExprEvaluator::VisitBuiltinCallExpr(const
CallExpr *E,
assert(Src.isInt());
return Success((Src.getInt() & (Alignment - 1)) == 0 ? 1 : 0, E);
}
+ case Builtin::BI__builtin_is_modifiable_lvalue: {
+const Expr *Arg = E->getArg(0);
pinskia wrote:
Shouldn't this be part of -Wstrict-overflow instead of -Wtautological-compare ?
https://github.com/llvm/llvm-project/pull/120480
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-
21 matches
Mail list logo
