[PATCH] D137044: [ClangFE] Add support for option -mno-pic-data-is-text-relative

2022-11-22 Thread Wang Pengcheng via Phabricator via cfe-commits
pcwang-thead added a comment.

The test `clang/test/Driver/pic.c` failed when we compiled Clang/LLVM with 
`-DCLANG_DEFAULT_PIE_ON_LINUX=False`.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D137044/new/

https://reviews.llvm.org/D137044

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D138402: [clang-format] Correctly count a tab's width in a comment

2022-11-22 Thread Björn Schäpers via Phabricator via cfe-commits
HazardyKnusperkeks marked an inline comment as done.
HazardyKnusperkeks added inline comments.



Comment at: clang/unittests/Format/FormatTestComments.cpp:736
+  "//* 0.2)",
+  "//\t\t\t\tofMap(message.velocity, 0, 127, 0, ofGetWidth() * 0.2)");
 }

owenpan wrote:
> ```
> error: reference to type 'const clang::format::FormatStyle' could not bind to 
> an lvalue of type 'const char[61]'
>   "//\t\t\t\tofMap(message.velocity, 0, 127, 0, ofGetWidth() * 0.2)");
>   ^~
> ```
Just needs the verifyFormat from D138263.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D138402/new/

https://reviews.llvm.org/D138402

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D138377: add clang_Type_getFullyQualifiedName

2022-11-22 Thread Anders Langlands via Phabricator via cfe-commits
anderslanglands updated this revision to Diff 477085.
anderslanglands added a comment.

Now tested by adding a -print-qualified-type-names flag to c-index-test and 
creating a (small) dedicated test in print-qualified-type.cpp


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D138377/new/

https://reviews.llvm.org/D138377

Files:
  clang/docs/ReleaseNotes.rst
  clang/include/clang-c/Index.h
  clang/test/Index/print-qualified-type.cpp
  clang/tools/c-index-test/c-index-test.c
  clang/tools/libclang/CXType.cpp
  clang/tools/libclang/libclang.map

Index: clang/tools/libclang/libclang.map
===
--- clang/tools/libclang/libclang.map
+++ clang/tools/libclang/libclang.map
@@ -413,6 +413,7 @@
 clang_CXXMethod_isDeleted;
 clang_CXXMethod_isCopyAssignmentOperator;
 clang_CXXMethod_isMoveAssignmentOperator;
+clang_Type_getFullyQualifiedName;
 };
 
 # Example of how to add a new symbol version entry.  If you do add a new symbol
Index: clang/tools/libclang/CXType.cpp
===
--- clang/tools/libclang/CXType.cpp
+++ clang/tools/libclang/CXType.cpp
@@ -20,6 +20,7 @@
 #include "clang/AST/DeclTemplate.h"
 #include "clang/AST/Expr.h"
 #include "clang/AST/Type.h"
+#include "clang/AST/QualTypeNames.h"
 #include "clang/Basic/AddressSpaces.h"
 #include "clang/Frontend/ASTUnit.h"
 
@@ -309,6 +310,22 @@
   return cxstring::createDup(OS.str());
 }
 
+CXString clang_Type_getFullyQualifiedName(CXType CT) {
+  QualType T = GetQualType(CT);
+  if (T.isNull())
+return cxstring::createEmpty();
+
+  CXTranslationUnit TU = GetTU(CT);
+  SmallString<64> Str;
+  llvm::raw_svector_ostream OS(Str);
+  PrintingPolicy PP(cxtu::getASTUnit(TU)->getASTContext().getLangOpts());
+
+  std::string qname = clang::TypeName::getFullyQualifiedName(
+  T, cxtu::getASTUnit(TU)->getASTContext(), PP);
+
+  return cxstring::createDup(qname);
+}
+
 CXType clang_getTypedefDeclUnderlyingType(CXCursor C) {
   using namespace cxcursor;
   CXTranslationUnit TU = cxcursor::getCursorTU(C);
Index: clang/tools/c-index-test/c-index-test.c
===
--- clang/tools/c-index-test/c-index-test.c
+++ clang/tools/c-index-test/c-index-test.c
@@ -373,6 +373,19 @@
   return CommentSchemaFile;
 }
 
+static int parse_print_qualified_type_names(int argc, const char **argv) {
+  const char *PrintQualifiedTypeNamesArg = "-print-qualified-type-names";
+  const char *PrintQualifiedTypeNames = 0;
+
+  if (argc == 0)
+return PrintQualifiedTypeNames;
+
+  if (!strncmp(argv[0], PrintQualifiedTypeNamesArg, strlen(PrintQualifiedTypeNamesArg)))
+PrintQualifiedTypeNames = 1;
+
+  return PrintQualifiedTypeNames;
+}
+
 /**/
 /* Pretty-printing.   */
 /**/
@@ -1300,6 +1313,7 @@
   CXTranslationUnit TU;
   enum CXCursorKind *Filter;
   const char *CommentSchemaFile;
+  int PrintQualifiedTypeNames;
 } VisitorData;
 
 
@@ -1507,13 +1521,17 @@
 /* Typekind testing.  */
 /**/
 
-static void PrintTypeAndTypeKind(CXType T, const char *Format) {
+static void PrintTypeAndTypeKind(CXType T, const char *Format,
+ int PrintQualifiedName) {
   CXString TypeSpelling, TypeKindSpelling;
 
-  TypeSpelling = clang_getTypeSpelling(T);
+  if (PrintQualifiedName != 0) {
+TypeSpelling = clang_Type_getFullyQualifiedName(T);
+  } else {
+TypeSpelling = clang_getTypeSpelling(T);
+  }
   TypeKindSpelling = clang_getTypeKindSpelling(T.kind);
-  printf(Format,
- clang_getCString(TypeSpelling),
+  printf(Format, clang_getCString(TypeSpelling),
  clang_getCString(TypeKindSpelling));
   clang_disposeString(TypeSpelling);
   clang_disposeString(TypeKindSpelling);
@@ -1525,7 +1543,8 @@
 return CXVisit_Continue;
 }
 
-static void PrintTypeTemplateArgs(CXType T, const char *Format) {
+static void PrintTypeTemplateArgs(CXType T, const char *Format,
+  int PrintQualifiedName) {
   int NumTArgs = clang_Type_getNumTemplateArguments(T);
   if (NumTArgs != -1 && NumTArgs != 0) {
 int i;
@@ -1534,7 +1553,8 @@
 for (i = 0; i < NumTArgs; ++i) {
   TArg = clang_Type_getTemplateArgumentAsType(T, i);
   if (TArg.kind != CXType_Invalid) {
-PrintTypeAndTypeKind(TArg, " [type=%s] [typekind=%s]");
+PrintTypeAndTypeKind(TArg, " [type=%s] [typekind=%s]",
+ PrintQualifiedName);
   }
 }
 /* Ensure that the returned type is invalid when indexing off-by-one. */
@@ -1577,7 +1597,9 @@
 CXType PT = clang_get

[PATCH] D136811: [-Wunsafe-buffer-usage] WIP: RFC: NFC: User documentation.

2022-11-22 Thread Balázs Benics via Phabricator via cfe-commits
steakhal added a comment.

As I was reading I'll highlighted some typos.
`compile time` -> `compile-time` /g

By the looks of it, this document is not referenced anywhere.
I believe `clang/docs/index.rst` should refer to this document in some place.

Thanks for the huge effort driving this you all!




Comment at: clang/docs/SafeBuffers.rst:27
+annotate sections of code as either already-hardened or not-to-be-hardened,
+enabling incremental adoption and and providing “escape hatches”
+when unsafety is necessary;





Comment at: clang/docs/SafeBuffers.rst:38
+at runtime against buffer overflows. This changes buffer overflows from
+extremely dangerous undefined behavior to predictable runtime crash.
+  - Finally, in order to avoid bugs in newly converted code, the





Comment at: clang/docs/SafeBuffers.rst:45
+hardened libc++ can be used as a “sanitizer” to find buffer overflow bugs in
+existing code. The static analyzer checker is also universally useful,
+not tied to this programming model. The warning may be desired independently,





Comment at: clang/docs/SafeBuffers.rst:56
+
+At a glance it seems reasonable to ask the compiler to make raw pointer
+operations crash on out-of-bounds accesses at runtime. And in case of C, this





Comment at: clang/docs/SafeBuffers.rst:63
+either in a system of attributes significantly more advanced than
+the current solution, or a significant change in runtime representation
+of all pointers.

aaron.ballman wrote:
> It would be helpful to have some details here about why a user would pick 
> these proposed features over use of a sanitizer like asan or hwasan, which 
> also finds out of bounds accesses.




Comment at: clang/docs/SafeBuffers.rst:88
+   allocated with ``new[]``; it doesn’t assume unique ownership so you can copy
+   such span if you want, just like a raw pointer, but of course you’ll have to
+   manually ``delete[]`` it when appropriate.





Comment at: clang/docs/SafeBuffers.rst:108
+   Say, ``std::vector`` or ``std::span`` may turn out to be poorly suitable
+   for your needs, and this is fine. In such cases the same guidelines apply.
+   You may have to use the opt-out pragma on the implementation of





Comment at: clang/docs/SafeBuffers.rst:127
+  - Addition or subtraction of a number to/from a raw pointer with operators
+  ``+``, ``-``, ``+=``, ``-=``,
+  - unless that number is a compile time constant ``0``;

Sphinx is picky about indentation, and it also complains about the missing 
new-line prior to the sub-list.
The same also applies to the very next sub-list.



Comment at: clang/docs/SafeBuffers.rst:134
+  - a number of C/C++ standard library buffer manipulation functions
+(such as std::memcpy() or std::next()) are hardcoded to act
+as if they had the attribute.





Comment at: clang/docs/SafeBuffers.rst:138
+The warning doesn’t warn on single pointer use in general, such as
+dereference with operations like * and -> or [0]. If such operation causes
+a buffer overflow, there’s probably another unsafe operation nearby,

aaron.ballman wrote:
> 




Comment at: clang/docs/SafeBuffers.rst:148
+but only when the function is annotated with the attribute. The attribute gets
+auto-attached by automatic fixits, which let the warning and the fixes 
propagate
+across function boundaries, and the users are encouraged to annotate their

What does //auto-attached// mean?



Comment at: clang/docs/SafeBuffers.rst:176
+but also provide essential “escape hatches” when the programming model
+is undesirable for a section of code (such as tight loop in 
performance-critical
+code, or implementation of a custom container). In such cases sections of code





Comment at: clang/docs/SafeBuffers.rst:216
+outside the function are well-formed. For example, function ``bar()`` below
+doesn’t need an attribute, because assuming buf is well-formed (has size that
+fits the original buffer it refers to), hardened libc++ protects this function

aaron.ballman wrote:
> 




Comment at: clang/docs/SafeBuffers.rst:321
+
+In spirit of our guidelines, the automatic fixit would prefer this function
+to accept a span instead of raw buffer, so that the span didn't need to be





Comment at: clang/docs/SafeBuffers.rst:362
+of bounds checks. Variable ``size`` does not *have* to carry the size of the
+buffer (or the size of *that* buffer) just becaused it's named "size".
+The compiler will avoid making guesses about that.





Comment at: clang/docs/S

[PATCH] D138402: [clang-format] Correctly count a tab's width in a comment

2022-11-22 Thread Owen Pan via Phabricator via cfe-commits
owenpan added inline comments.



Comment at: clang/unittests/Format/FormatTestComments.cpp:736
+  "//* 0.2)",
+  "//\t\t\t\tofMap(message.velocity, 0, 127, 0, ofGetWidth() * 0.2)");
 }

HazardyKnusperkeks wrote:
> owenpan wrote:
> > ```
> > error: reference to type 'const clang::format::FormatStyle' could not bind 
> > to an lvalue of type 'const char[61]'
> >   "//\t\t\t\tofMap(message.velocity, 0, 127, 0, ofGetWidth() * 0.2)");
> >   ^~
> > ```
> Just needs the verifyFormat from D138263.
I see. Do you want to stack this patch onto D138263 (which I might not be able 
to get to for a while) or copy the needed code from there to here?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D138402/new/

https://reviews.llvm.org/D138402

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D138402: [clang-format] Correctly count a tab's width in a comment

2022-11-22 Thread Owen Pan via Phabricator via cfe-commits
owenpan added inline comments.



Comment at: clang/unittests/Format/FormatTestComments.cpp:736
+  "//* 0.2)",
+  "//\t\t\t\tofMap(message.velocity, 0, 127, 0, ofGetWidth() * 0.2)");
 }

owenpan wrote:
> HazardyKnusperkeks wrote:
> > owenpan wrote:
> > > ```
> > > error: reference to type 'const clang::format::FormatStyle' could not 
> > > bind to an lvalue of type 'const char[61]'
> > >   "//\t\t\t\tofMap(message.velocity, 0, 127, 0, ofGetWidth() * 0.2)");
> > >   ^~
> > > ```
> > Just needs the verifyFormat from D138263.
> I see. Do you want to stack this patch onto D138263 (which I might not be 
> able to get to for a while) or copy the needed code from there to here?
Nvm. It's stacked now.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D138402/new/

https://reviews.llvm.org/D138402

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D126818: Itanium ABI: Implement mangling for constrained friends

2022-11-22 Thread David Friberg via Phabricator via cfe-commits
dfrib added a comment.

In D126818#3941201 , @erichkeane 
wrote:

> [...] particularly since the suggested wording says the opposite of what I 
> THOUGHT the discussion was doing at the end?
> [...] We might find ourselves wanting to hold off until CWG comes up with 
> actual wording?

Same reflection, and agreed.

> I think perhaps we need to wait on CWG to clarify what they mean, at least by 
> including a wording consistent with that top thing.  The unfortunate part 
> here is that Clang implements 1/2 of this at the moment: we implement the 
> SEMA changes, but not the mangling changes for the current wording.

Should consider asking on the CWG reflector to make sure they are aware of 
Clang's quite far-going implementation experience with fixing this defect (in 
the way originally proposed), and of Itanium C++'s/@rjmccall's view that the 
proposed ABI updates looks reasonable?


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D126818/new/

https://reviews.llvm.org/D126818

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D127762: [Clang][AArch64] Add ACLE attributes for SME.

2022-11-22 Thread Richard Sandiford via Phabricator via cfe-commits
rsandifo-arm added inline comments.



Comment at: clang/include/clang/Basic/DiagnosticSemaKinds.td:2000
   "overridden virtual function is here">;
+def err_conflicting_overriding_attributes : Error<
+  "virtual function %0 has different attributes "

aaron.ballman wrote:
> rsandifo-arm wrote:
> > rsandifo-arm wrote:
> > > aaron.ballman wrote:
> > > > aaron.ballman wrote:
> > > > > rsandifo-arm wrote:
> > > > > > sdesmalen wrote:
> > > > > > > aaron.ballman wrote:
> > > > > > > > sdesmalen wrote:
> > > > > > > > > aaron.ballman wrote:
> > > > > > > > > > This error and the one below make me wonder whether an 
> > > > > > > > > > attribute spelling is the appropriate way to surface this 
> > > > > > > > > > functionality as opposed to a keyword. Attributes don't 
> > > > > > > > > > typically don't cause errors in these situations, but 
> > > > > > > > > > because these attributes are strongly coupled to their type 
> > > > > > > > > > system effects I can see why you want these to be errors.
> > > > > > > > > > This error and the one below make me wonder whether an 
> > > > > > > > > > attribute spelling is the appropriate way to surface this 
> > > > > > > > > > functionality as opposed to a keyword. 
> > > > > > > > > I'm not sure I understand what you mean, do you have an 
> > > > > > > > > example?
> > > > > > > > `override` and `final` could have been surfaced via attributes, 
> > > > > > > > and in Clang we semantically express them as such (see `Final` 
> > > > > > > > and `Override` in Attr.td), but instead they are surfaced to 
> > > > > > > > the user as keywords in the language standard. You're not under 
> > > > > > > > the same constraints as the standard (you're making a 
> > > > > > > > vendor-specific attribute). We're not super consistent with 
> > > > > > > > whether we use the same approach as the standard (we have some 
> > > > > > > > type attributes that are spelled as attributes like 
> > > > > > > > `vector_size` and others that are spelled via keywords like 
> > > > > > > > `_Nullable`.
> > > > > > > > 
> > > > > > > > So you could spell your type attributes the way you have been 
> > > > > > > > with `__attribute__`, or you could come up with keywords for 
> > > > > > > > them (so instead of using `GNU<"whatever">` for the attribute, 
> > > > > > > > you could use `Keyword<_Whatever>` or `Keyword<__whatever>` 
> > > > > > > > (you'd also need to add them as recognized keyword tokens, 
> > > > > > > > parse them as appropriate, etc).
> > > > > > > > 
> > > > > > > > Note: I don't insist on you using a keyword for these, but I am 
> > > > > > > > wondering if that approach was considered or not given how 
> > > > > > > > non-portable the attributes are (if an implementation ignores 
> > > > > > > > this attribute, it sounds like the program semantics are 
> > > > > > > > unlikely to be correct).
> > > > > > > @rsandifo-arm can you shed some light on whether using a keyword 
> > > > > > > instead of an `attribute` was considered?
> > > > > > Thanks @aaron.ballman for the reviews.
> > > > > >  
> > > > > > Yeah, we did consider using keywords instead.  The main reason for 
> > > > > > sticking with GNU attributes is that they were specifically 
> > > > > > designed as an extensible way of attaching information or 
> > > > > > requirements to the source code, and they provide well-settled 
> > > > > > semantics.  It seemed better to reuse an existing mechanism rather 
> > > > > > than invent something new.
> > > > > > 
> > > > > > Also, as C++ evolves, the semantics of GNU attributes evolve to 
> > > > > > match.  If we surface the SME features as GNU attributes, we 
> > > > > > inherit this development in the underlying semantics, without 
> > > > > > having to maintain our own evolving specification for where the 
> > > > > > keywords can be placed.  For example, when lambdas were introduced, 
> > > > > > GNU attributes were extended to support lambdas.  Something similar 
> > > > > > could happen in future.
> > > > > > 
> > > > > > We could have defined the semantics of the keywords to be that they 
> > > > > > behave exactly like GNU attributes.  However:
> > > > > > 
> > > > > > # If we do that, the advantage of using a keyword is less obvious.  
> > > > > > (I can see the argument that the syntax looks nicer though.)
> > > > > > # Like you say in the review, the semantics of GNU attributes carry 
> > > > > > some historical baggage.  If would be difficult to justify keeping 
> > > > > > that historical baggage for something that is ostensibly new and 
> > > > > > not a GNU attribute as such.
> > > > > > 
> > > > > > A minor, but still nontrivial, reason is that there is less 
> > > > > > appetite in the GCC community for supporting target-specific 
> > > > > > extensions to the core language.  Adding a target-specific keyword 
> > > > > > is likely to be rejected.  It would be acceptable to make the 
> > > > > > “keyword” be a predefined macro that

[PATCH] D138289: [clang][Parse] Remove constant expression from if condition

2022-11-22 Thread Timm Bäder via Phabricator via cfe-commits
tbaeder added a comment.

Yeah, just removing the `MaybeTypeCast` worked, but switching to `isTypeCast` 
doens't.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D138289/new/

https://reviews.llvm.org/D138289

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] 0cf2286 - [LoongArch] Fix issue on CMake Xcode build configuration

2022-11-22 Thread via cfe-commits

Author: gonglingqin
Date: 2022-11-22T16:49:50+08:00
New Revision: 0cf2286cb8f881e814f3eb42593d1cc7c817b19b

URL: 
https://github.com/llvm/llvm-project/commit/0cf2286cb8f881e814f3eb42593d1cc7c817b19b
DIFF: 
https://github.com/llvm/llvm-project/commit/0cf2286cb8f881e814f3eb42593d1cc7c817b19b.diff

LOG: [LoongArch] Fix issue on CMake Xcode build configuration

Add missing dependency for loongarch-resource-headers. This patch refers to 
D126892 to repair same error.

Differential Revision: https://reviews.llvm.org/D138403

Added: 


Modified: 
clang/lib/Headers/CMakeLists.txt

Removed: 




diff  --git a/clang/lib/Headers/CMakeLists.txt 
b/clang/lib/Headers/CMakeLists.txt
index b756dfed19abb..4206ef27e4ec3 100644
--- a/clang/lib/Headers/CMakeLists.txt
+++ b/clang/lib/Headers/CMakeLists.txt
@@ -394,6 +394,7 @@ add_dependencies("clang-resource-headers"
  "hexagon-resource-headers"
  "hip-resource-headers"
  "hlsl-resource-headers"
+ "loongarch-resource-headers"
  "mips-resource-headers"
  "ppc-resource-headers"
  "ppc-htm-resource-headers"



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D138403: [LoongArch] Fix issue on CMake Xcode build configuration

2022-11-22 Thread Gong LingQin via Phabricator via cfe-commits
This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rG0cf2286cb8f8: [LoongArch] Fix issue on CMake Xcode build 
configuration (authored by gonglingqin).

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D138403/new/

https://reviews.llvm.org/D138403

Files:
  clang/lib/Headers/CMakeLists.txt


Index: clang/lib/Headers/CMakeLists.txt
===
--- clang/lib/Headers/CMakeLists.txt
+++ clang/lib/Headers/CMakeLists.txt
@@ -394,6 +394,7 @@
  "hexagon-resource-headers"
  "hip-resource-headers"
  "hlsl-resource-headers"
+ "loongarch-resource-headers"
  "mips-resource-headers"
  "ppc-resource-headers"
  "ppc-htm-resource-headers"


Index: clang/lib/Headers/CMakeLists.txt
===
--- clang/lib/Headers/CMakeLists.txt
+++ clang/lib/Headers/CMakeLists.txt
@@ -394,6 +394,7 @@
  "hexagon-resource-headers"
  "hip-resource-headers"
  "hlsl-resource-headers"
+ "loongarch-resource-headers"
  "mips-resource-headers"
  "ppc-resource-headers"
  "ppc-htm-resource-headers"
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D138473: clang/HIP: Inline frexp/frexpf implementations

2022-11-22 Thread Jon Chesterfield via Phabricator via cfe-commits
JonChesterfield accepted this revision.
JonChesterfield added a comment.
This revision is now accepted and ready to land.

Noisy diff! Getting rid of the openmp special case handling here is nice.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D138473/new/

https://reviews.llvm.org/D138473

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D138391: clang/HIP: Add new header test for math IR gen

2022-11-22 Thread Jon Chesterfield via Phabricator via cfe-commits
JonChesterfield accepted this revision.
JonChesterfield added a comment.
This revision is now accepted and ready to land.

Good call adding this test, thanks.

I think some of the skipping is glibc quirk related and some was to avoid 
clobbering the user's namespace for openmp. The math header defines various 
functions at global scope which can collide with user symbols. In practice that 
may not be a big deal.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D138391/new/

https://reviews.llvm.org/D138391

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D134176: Add MC support of RISCV Zcf Extension

2022-11-22 Thread Xinlong Wu via Phabricator via cfe-commits
VincentWu updated this revision to Diff 477112.
VincentWu added a comment.

rebase


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D134176/new/

https://reviews.llvm.org/D134176

Files:
  clang/test/Preprocessor/riscv-target-features.c
  llvm/lib/Support/RISCVISAInfo.cpp
  llvm/lib/Target/RISCV/RISCV.td
  llvm/lib/Target/RISCV/RISCVInstrInfoC.td
  llvm/lib/Target/RISCV/RISCVSubtarget.h
  llvm/test/MC/RISCV/compress-rv32f.s
  llvm/test/MC/RISCV/rv32fc-valid.s

Index: llvm/test/MC/RISCV/rv32fc-valid.s
===
--- llvm/test/MC/RISCV/rv32fc-valid.s
+++ llvm/test/MC/RISCV/rv32fc-valid.s
@@ -3,41 +3,52 @@
 # RUN: llvm-mc -filetype=obj -triple=riscv32 -mattr=+c,+f < %s \
 # RUN: | llvm-objdump --mattr=+c,+f -M no-aliases -d -r - \
 # RUN: | FileCheck --check-prefix=CHECK-ASM-AND-OBJ %s
+# RUN: llvm-mc %s -triple=riscv32 -mattr=+experimental-zcf,+f -riscv-no-aliases -show-encoding \
+# RUN: | FileCheck -check-prefixes=CHECK-ASM,CHECK-ASM-AND-OBJ %s
+# RUN: llvm-mc -filetype=obj -triple=riscv32 -mattr=+experimental-zcf,+f < %s \
+# RUN: | llvm-objdump --mattr=+experimental-zcf,+f -M no-aliases -d -r - \
+# RUN: | FileCheck --check-prefix=CHECK-ASM-AND-OBJ %s
 #
 # RUN: not llvm-mc -triple riscv32 -mattr=+c \
 # RUN: -riscv-no-aliases -show-encoding < %s 2>&1 \
 # RUN: | FileCheck -check-prefixes=CHECK-NO-EXT-F %s
+# RUN: not llvm-mc -triple riscv32 -mattr=+experimental-zcf \
+# RUN: -riscv-no-aliases -show-encoding < %s 2>&1 \
+# RUN: | FileCheck -check-prefixes=CHECK-NO-EXT-F %s
 # RUN: not llvm-mc -triple riscv32 \
 # RUN: -riscv-no-aliases -show-encoding < %s 2>&1 \
 # RUN: | FileCheck -check-prefixes=CHECK-NO-EXT-FC %s
 # RUN: not llvm-mc -triple riscv64 -mattr=+c,+f \
 # RUN: -riscv-no-aliases -show-encoding < %s 2>&1 \
 # RUN: | FileCheck -check-prefixes=CHECK-NO-RV32 %s
+# RUN: not llvm-mc -triple riscv64 -mattr=+experimental-zcf,+f \
+# RUN: -riscv-no-aliases -show-encoding < %s 2>&1 \
+# RUN: | FileCheck -check-prefixes=CHECK-NO-RV32 %s
 
 # FIXME: error messages for rv64fc are misleading
 
 # CHECK-ASM-AND-OBJ: c.flwsp  fs0, 252(sp)
 # CHECK-ASM: encoding: [0x7e,0x74]
 # CHECK-NO-EXT-F:  error: instruction requires the following: 'F' (Single-Precision Floating-Point){{$}}
-# CHECK-NO-EXT-FC:  error: instruction requires the following: 'C' (Compressed Instructions), 'F' (Single-Precision Floating-Point){{$}}
+# CHECK-NO-EXT-FC:  error: instruction requires the following: 'C' (Compressed Instructions) or 'Zcf' (Compressed Single-Precision Floating-Point Instructions), 'F' (Single-Precision Floating-Point){{$}}
 # CHECK-NO-RV32:  error: instruction requires the following: RV32I Base Instruction Set{{$}}
 c.flwsp  fs0, 252(sp)
 # CHECK-ASM-AND-OBJ: c.fswsp  fa7, 252(sp)
 # CHECK-ASM: encoding: [0xc6,0xff]
 # CHECK-NO-EXT-F:  error: instruction requires the following: 'F' (Single-Precision Floating-Point){{$}}
-# CHECK-NO-EXT-FC:  error: instruction requires the following: 'C' (Compressed Instructions), 'F' (Single-Precision Floating-Point){{$}}
+# CHECK-NO-EXT-FC:  error: instruction requires the following: 'C' (Compressed Instructions) or 'Zcf' (Compressed Single-Precision Floating-Point Instructions), 'F' (Single-Precision Floating-Point){{$}}
 # CHECK-NO-RV32:  error: instruction requires the following: RV32I Base Instruction Set{{$}}
 c.fswsp  fa7, 252(sp)
 
 # CHECK-ASM-AND-OBJ: c.flw  fa3, 124(a5)
 # CHECK-ASM: encoding: [0xf4,0x7f]
 # CHECK-NO-EXT-F:  error: instruction requires the following: 'F' (Single-Precision Floating-Point){{$}}
-# CHECK-NO-EXT-FC:  error: instruction requires the following: 'C' (Compressed Instructions), 'F' (Single-Precision Floating-Point){{$}}
+# CHECK-NO-EXT-FC:  error: instruction requires the following: 'C' (Compressed Instructions) or 'Zcf' (Compressed Single-Precision Floating-Point Instructions), 'F' (Single-Precision Floating-Point){{$}}
 # CHECK-NO-RV32:  error: instruction requires the following: RV32I Base Instruction Set{{$}}
 c.flw  fa3, 124(a5)
 # CHECK-ASM-AND-OBJ: c.fsw  fa2, 124(a1)
 # CHECK-ASM: encoding: [0xf0,0xfd]
 # CHECK-NO-EXT-F:  error: instruction requires the following: 'F' (Single-Precision Floating-Point){{$}}
-# CHECK-NO-EXT-FC:  error: instruction requires the following: 'C' (Compressed Instructions), 'F' (Single-Precision Floating-Point){{$}}
+# CHECK-NO-EXT-FC:  error: instruction requires the following: 'C' (Compressed Instructions) or 'Zcf' (Compressed Single-Precision Floating-Point Instructions), 'F' (Single-Precision Floating-Point){{$}}
 # CHECK-NO-RV32:  error: instruction requires the following: RV32I Base Instruction Set{{$}}
 c.fsw  fa2, 124(a1)
Index: llvm/test/MC/RISCV/compress-rv32f.s
===
--- llvm/test/MC/RISCV/compress-rv32f.s
+++ llvm/test/MC/RISCV/compress-rv32f.s
@@ -8,6 +8,16 @@
 # RUN: llvm-mc -trip

[PATCH] D137836: [Support] Move getHostNumPhysicalCores to Threading.h

2022-11-22 Thread Francesco Petrogalli via Phabricator via cfe-commits
fpetrogalli added inline comments.



Comment at: llvm/unittests/Support/Host.cpp:33
 
-class HostTest : public testing::Test {
-  Triple Host;
-
-protected:
-  bool isSupportedArchAndOS() {
-// Initially this is only testing detection of the number of
-// physical cores, which is currently only supported/tested on
-// some systems.
-return (Host.isOSWindows() && llvm_is_multithreaded()) ||
-   Host.isOSDarwin() || (Host.isX86() && Host.isOSLinux()) ||
-   (Host.isOSLinux() && !Host.isAndroid()) ||
-   (Host.isSystemZ() && Host.isOSzOS());
-  }
-
-  HostTest() : Host(Triple::normalize(sys::getProcessTriple())) {}
-};
-
-TEST_F(HostTest, NumPhysicalCoresSupported) {
-  if (!isSupportedArchAndOS())
-GTEST_SKIP();
-  int Num = sys::getHostNumPhysicalCores();
-  ASSERT_GT(Num, 0);
-}
-
-TEST_F(HostTest, NumPhysicalCoresUnsupported) {
-  if (isSupportedArchAndOS())
-GTEST_SKIP();
-  int Num = sys::getHostNumPhysicalCores();
-  ASSERT_EQ(Num, -1);
-}
+class HostTest : public testing::Test {};
 

Is this needed? 



Comment at: llvm/unittests/Support/Host.cpp:401
 
 TEST_F(HostTest, DummyRunAndGetCommandOutputUse) {
   // Suppress defined-but-not-used warnings when the tests using the helper are

I think you can remove the class `HostTest` and convert the test fixture into 
just `TEST(` instead of `TEST_F(`. It is kind of awkward to have this: `class 
HostTest : public testing::Test {};`



Comment at: llvm/unittests/Support/Threading.cpp:30
 
+class ThreadingTest : public testing::Test {
+  Triple Host;

I don't think you need to derive from `testing:Test`? The functionality of 
`isSupportedArchAndOS could be achieved just with a function.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D137836/new/

https://reviews.llvm.org/D137836

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D127762: [Clang][AArch64] Add ACLE attributes for SME.

2022-11-22 Thread Sander de Smalen via Phabricator via cfe-commits
sdesmalen updated this revision to Diff 477116.
sdesmalen marked 10 inline comments as done.
sdesmalen added a comment.

Addressed review comments. These include:

- Allow dropping the arm_preserves_za attribute.
- Added tests for serializing/deserializing the AST.
- Changed descriptions in documentation.

Also fixed an issue where the attributes would previously be silently be 
dropped when the function being converted to did not have a function prototype.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D127762/new/

https://reviews.llvm.org/D127762

Files:
  clang/include/clang/AST/Type.h
  clang/include/clang/AST/TypeProperties.td
  clang/include/clang/Basic/Attr.td
  clang/include/clang/Basic/AttrDocs.td
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Sema/Sema.h
  clang/lib/AST/Type.cpp
  clang/lib/AST/TypePrinter.cpp
  clang/lib/Basic/Targets/AArch64.cpp
  clang/lib/Basic/Targets/AArch64.h
  clang/lib/CodeGen/CGCall.cpp
  clang/lib/CodeGen/CodeGenModule.cpp
  clang/lib/Sema/SemaDecl.cpp
  clang/lib/Sema/SemaDeclAttr.cpp
  clang/lib/Sema/SemaDeclCXX.cpp
  clang/lib/Sema/SemaExpr.cpp
  clang/lib/Sema/SemaOverload.cpp
  clang/lib/Sema/SemaType.cpp
  clang/test/AST/ast-dump-sme-attributes.cpp
  clang/test/CodeGen/aarch64-sme-intrinsics/aarch64-sme-attrs.cpp
  clang/test/Misc/pragma-attribute-supported-attributes-list.test
  clang/test/Sema/aarch64-sme-attrs-no-sme.c
  clang/test/Sema/aarch64-sme-func-attrs.c

Index: clang/test/Sema/aarch64-sme-func-attrs.c
===
--- /dev/null
+++ clang/test/Sema/aarch64-sme-func-attrs.c
@@ -0,0 +1,278 @@
+// RUN: %clang_cc1 -triple aarch64-none-linux-gnu -target-feature +sme -fsyntax-only -verify %s
+// RUN: %clang_cc1 -triple aarch64-none-linux-gnu -target-feature +sme -fsyntax-only -verify=expected-cpp -x c++ %s
+
+// Valid attributes
+
+__attribute__((arm_streaming)) void sme_arm_streaming(void);
+__attribute__((arm_streaming_compatible)) void sme_arm_streaming_compatible(void);
+
+__attribute__((arm_new_za)) void sme_arm_new_za(void);
+__attribute__((arm_shared_za)) void sme_arm_shared_za(void);
+__attribute__((arm_preserves_za)) void sme_arm_preserves_za(void);
+
+__attribute__((arm_streaming, arm_new_za)) void sme_arm_streaming_new_za(void);
+__attribute__((arm_streaming, arm_shared_za)) void sme_arm_streaming_shared_za(void);
+__attribute__((arm_streaming, arm_preserves_za)) void sme_arm_streaming_preserves_za(void);
+
+__attribute__((arm_streaming_compatible, arm_new_za)) void sme_arm_sc_new_za(void);
+__attribute__((arm_streaming_compatible, arm_shared_za)) void sme_arm_sc_shared_za(void);
+__attribute__((arm_streaming_compatible, arm_preserves_za)) void sme_arm_sc_preserves_za(void);
+
+__attribute__((arm_shared_za, arm_preserves_za)) void sme_arm_shared_preserves_za(void);
+
+__attribute__((arm_locally_streaming)) void sme_arm_locally_streaming(void) { }
+__attribute__((arm_locally_streaming, arm_streaming)) void sme_arm_streaming_and_locally_streaming(void) { }
+__attribute__((arm_locally_streaming, arm_streaming_compatible)) void sme_arm_streaming_and_streaming_compatible(void) { }
+
+__attribute__((arm_locally_streaming, arm_new_za)) void sme_arm_ls_new_za(void) { }
+__attribute__((arm_locally_streaming, arm_shared_za)) void sme_arm_ls_shared_za(void) { }
+__attribute__((arm_locally_streaming, arm_preserves_za)) void sme_arm_ls_preserves_za(void) { }
+
+// Valid attributes on function pointers
+
+void __attribute__((arm_streaming)) streaming_ptr(void);
+typedef __attribute__((arm_streaming)) void (*fptrty1) (void);
+fptrty1 call_streaming_func() { return streaming_ptr; }
+
+void __attribute__((arm_streaming_compatible)) streaming_compatible_ptr(void);
+typedef __attribute__((arm_streaming_compatible)) void (*fptrty2) (void);
+fptrty2 call_sc_func() { return streaming_compatible_ptr; }
+
+void __attribute__((arm_new_za)) new_za_ptr(void);
+typedef __attribute__((arm_new_za)) void (*fptrty3) (void);
+fptrty3 call_new_za_func() { return new_za_ptr; }
+
+void __attribute__((arm_shared_za)) shared_za_ptr(void);
+typedef __attribute__((arm_shared_za)) void (*fptrty4) (void);
+fptrty4 call_shared_za_func() { return shared_za_ptr; }
+
+void __attribute__((arm_preserves_za)) preserves_za_ptr(void);
+typedef __attribute__((arm_preserves_za)) void (*fptrty5) (void);
+fptrty5 call_preserve_za_func() { return preserves_za_ptr; }
+
+void __attribute__((arm_shared_za, arm_preserves_za)) shared_preserves_za_ptr(void);
+typedef __attribute__((arm_shared_za, arm_preserves_za)) void (*fptrty6) (void);
+fptrty6 call_shared_preserve_za_func() { return shared_preserves_za_ptr; }
+
+typedef void (*fptrty7) (void);
+fptrty7 cast_ls_func_to_normal() { return sme_arm_locally_streaming; }
+
+// FIXME: Add invalid function pointer assignments such as assigning:
+//   1. A streaming compatible function to a normal function pointer,
+//   2. A locally stre

[PATCH] D127762: [Clang][AArch64] Add ACLE attributes for SME.

2022-11-22 Thread Sander de Smalen via Phabricator via cfe-commits
sdesmalen added inline comments.



Comment at: clang/include/clang/AST/Type.h:3940
+/// on declarations and function pointers.
+unsigned AArch64SMEAttributes : 8;
+

erichkeane wrote:
> sdesmalen wrote:
> > erichkeane wrote:
> > > We seem to be missing all of the modules-storage code for these.  Since 
> > > this is modifying the AST, we need to increment the 'breaking change' AST 
> > > code, plus add this to the ASTWriter/ASTReader interface.
> > > Since this is modifying the AST, we need to increment the 'breaking 
> > > change' AST code
> > Could you give me some pointers on what you expect to see changed here? I 
> > understand your point about adding this to the ASTWriter/Reader interfaces 
> > for module-storage, but it's not entirely clear what you mean by "increment 
> > the breaking change AST code". 
> > 
> > I see there is also an ASTImporter, I guess this different from the 
> > ASTReader?
> > 
> > Please apologise my ignorance here, I'm not as familiar with the Clang 
> > codebase.
> See VersionMajor here: 
> https://clang.llvm.org/doxygen/ASTBitCodes_8h_source.html
> 
> Yes, ASTReader/ASTWriter and ASTImporter are different unfortunately.  I'm 
> not completely sure of the difference, but doing this patch changing the type 
> here without doing those will break modules.
So I tried to create some tests for this (see 
clang/test/AST/ast-dump-sme-attributes.cpp) and realised that the 
serialization/deserialization works out-of-the-box.

Does that mean all is needed is an increment of the VERSION_MAJOR or 
VERSION_MINOR number?



Comment at: clang/include/clang/AST/Type.h:4008
 bool HasTrailingReturn : 1;
+unsigned AArch64SMEAttributes : 8;
 Qualifiers TypeQuals;

aaron.ballman wrote:
> erichkeane wrote:
> > sdesmalen wrote:
> > > aaron.ballman wrote:
> > > > So functions without prototypes cannot have any of these attributes?
> > > Yes, the ACLE explicitly states that 
> > > [[https://github.com/ARM-software/acle/pull/188/commits/59751df91d9630400531a64108f179e3951c3b89#diff-516526d4a18101dc85300bc2033d0f86dc46c505b7510a7694baabea851aedfaR503|here]]:
> > > > The function type attributes cannot be used with K&R-style 
> > > > “unprototyped” C function types
> > Are they aware that includes; `void Baz();` ?
> FWIW, the linked docs say:
> ```
> > Functions like `some_func` and `another_func` are referred to as
> > (K&R-style) “unprototyped” functions. The first C standard categorized
> > them as an obsolescent feature and C18 removed all remaining support
> > for them.
> ```
> That's not quite accurate. They've always been obsolete in standard C (both 
> ANSI and ISO C), so that's correct. But it's C2x that removes all remaining 
> support for them. (Also, there's no such release as C18, there's C11, C17, 
> and expected to be C23).
> 
> > Are they aware that includes; void Baz(); ?
> 
> Just to expound on this question: this means `void baz();` in C17 mode cannot 
> have the attribute but `void baz();` in C2x mode can. Folks coming from C++ 
> tend to expect the C2x behavior to be the default and so it's plausible to 
> see such signatures in older language modes. Will that cause any pain or 
> confusion for you?
@rsandifo-arm explained to me that it is indeed a deliberate choice not to 
support the attribute on unprototyped functions, as these are an obsolescent 
feature that will be removed in C2x. The mitigation should be trivial for new 
code that is written and it makes new code compliant with the next version of 
the standard.



Comment at: clang/include/clang/Basic/Attr.td:2322
 
+def ArmStreamingCompatible : DeclOrTypeAttr, TargetSpecificAttr 
{
+  let Spellings = [Clang<"arm_streaming_compatible">];

aaron.ballman wrote:
> sdesmalen wrote:
> > aaron.ballman wrote:
> > > sdesmalen wrote:
> > > > aaron.ballman wrote:
> > > > > sdesmalen wrote:
> > > > > > aaron.ballman wrote:
> > > > > > > `DeclOrTypeAttr` is only intended to be used for attributes which 
> > > > > > > were historically a declaration attribute but are semantically 
> > > > > > > type attributes (like calling conventions). It seems to me that 
> > > > > > > each of these is purely a type attribute and we shouldn't allow 
> > > > > > > them to be written in the declaration position. WDYT?
> > > > > > In this case, I believe the attribute is valid on both the type and 
> > > > > > the declaration, because the SME ACLE explicitly specifies that the 
> > > > > > attributes can be applied to both declarations and types.
> > > > > > 
> > > > > > The 
> > > > > > [[https://github.com/ARM-software/acle/pull/188/commits/ce878cf6c43fd824ffc634526e5dfec1ddc1839e#diff-516526d4a18101dc85300bc2033d0f86dc46c505b7510a7694baabea851aedfaR8283-R8294|specification]]
> > > > > >  says:
> > > > > > ```Some of the attributes described in this section apply to 
> > > > > > function types.
> > > > > > Their semantics are as follows

[PATCH] D138472: clang/cmake: Use installed gtest libraries for stand-alone builds

2022-11-22 Thread Konrad Wilhelm Kleine via Phabricator via cfe-commits
kwk added inline comments.



Comment at: clang/CMakeLists.txt:103
 if (LLVM_LIT AND LLVM_UTILS_PROVIDED)
-  set(UNITTEST_DIR ${LLVM_THIRD_PARTY_DIR}/utils/unittest)
-  if(EXISTS ${UNITTEST_DIR}/googletest/include/gtest/gtest.h
- AND NOT EXISTS 
${LLVM_LIBRARY_DIR}/${CMAKE_STATIC_LIBRARY_PREFIX}gtest${CMAKE_STATIC_LIBRARY_SUFFIX}
- AND EXISTS ${UNITTEST_DIR}/CMakeLists.txt)
-add_subdirectory(${UNITTEST_DIR} third-part/unittest)
+  find_package(LLVMGTest)
+  if (NOT TARGET llvm_gtest)

I don't see no `FindLLVMGTest.cmake` file anywhere. Is that suppose to exist 
yet or which Patch is suppose to create it?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D138472/new/

https://reviews.llvm.org/D138472

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D135273: [Clang][ObjC] Add optionality to property attribute strings.

2022-11-22 Thread Alastair Houghton via Phabricator via cfe-commits
al45tair added a comment.

In D135273#3942011 , @theraven wrote:

> In D135273#3936297 , @al45tair 
> wrote:
>
>> @theraven Any chance you could glance over this and reassure us that it 
>> isn't going to break the GNU runtime if we do this? (We're adding an extra 
>> attribute in the property attribute string so that we can detect `@optional` 
>> properties in ObjC protocols at runtime.)
>
> It shouldn't, we ignore any unknown property attributes.  I'd be more 
> concerned about code outside the runtime.  Lots of things parse encoding 
> strings badly, but the property APIs make it much easier to query known 
> attributes and so I think that's a lot lower risk than changing anything in 
> encoding strings.  It's a shame to use ?, since that is unknown type in type 
> encodings and that may confuse some parsers..

I don't think using `?` is really an issue here; anyone parsing types from 
these strings already has to stop for the `,` character, since the string is 
defined to be a `,`-separated list of attributes, the first of which is the 
type attribute `T`. If they were going to be confused by the 
`?`, then they'd already get confused by the other attribute characters, many 
of which are also valid in a type encoding.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D135273/new/

https://reviews.llvm.org/D135273

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D137939: [CGObjC] Open cleanup scope before SaveAndRestore CurrentFuncletPad and push CatchRetScope early

2022-11-22 Thread Stefan Gränitz via Phabricator via cfe-commits
This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rG9a9d636caeea: [CGObjC] Open cleanup scope before 
SaveAndRestore CurrentFuncletPad and push… (authored by sgraenitz).

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D137939/new/

https://reviews.llvm.org/D137939

Files:
  clang/lib/CodeGen/CGObjCRuntime.cpp
  clang/test/CodeGenObjCXX/arc-exceptions-seh.mm

Index: clang/test/CodeGenObjCXX/arc-exceptions-seh.mm
===
--- clang/test/CodeGenObjCXX/arc-exceptions-seh.mm
+++ clang/test/CodeGenObjCXX/arc-exceptions-seh.mm
@@ -1,29 +1,64 @@
-// RUN: %clang_cc1 -triple x86_64-pc-windows-msvc -emit-llvm -fobjc-arc -fexceptions -fobjc-exceptions -fobjc-runtime=gnustep-2.0 -o - %s | FileCheck %s
+// RUN: %clang_cc1 -triple x86_64-pc-windows-msvc -emit-llvm -fobjc-arc -fexceptions -fobjc-exceptions -fobjc-arc-exceptions -fobjc-runtime=gnustep-2.0 -o - %s | FileCheck %s
 
 // WinEH requires funclet tokens on nounwind intrinsics if they can lower to
 // regular function calls in the course of IR transformations.
 //
 // This is the case for ObjC ARC runtime intrinsics. Test that clang emits the
-// funclet tokens for llvm.objc.retain and llvm.objc.storeStrong and that they
-// refer to their catchpad's SSA value.
+// funclet tokens for llvm.objc.* calls inside catch- and cleanup-pads and that
+// they refer to their pad's SSA value.
 
-@class Ety;
-void opaque(void);
-void test_catch_with_objc_intrinsic(void) {
+void do_something();
+void may_throw(id);
+
+void try_catch_with_objc_intrinsic() {
+  id ex;
   @try {
-opaque();
-  } @catch (Ety *ex) {
-// Destroy ex when leaving catchpad. This emits calls to intrinsic functions
-// llvm.objc.retain and llvm.objc.storeStrong
+may_throw(ex);
+  } @catch (id ex_caught) {
+do_something();
+may_throw(ex_caught);
   }
 }
 
-// CHECK-LABEL: define{{.*}} void {{.*}}test_catch_with_objc_intrinsic
-//...
-// CHECK:   catch.dispatch:
-// CHECK-NEXT:[[CATCHSWITCH:%[0-9]+]] = catchswitch within none
-//...
-// CHECK:   catch:
-// CHECK-NEXT:[[CATCHPAD:%[0-9]+]] = catchpad within [[CATCHSWITCH]]
-// CHECK: {{%[0-9]+}} = call {{.*}} @llvm.objc.retain{{.*}} [ "funclet"(token [[CATCHPAD]]) ]
-// CHECK: call {{.*}} @llvm.objc.storeStrong{{.*}} [ "funclet"(token [[CATCHPAD]]) ]
+// CHECK-LABEL:   try_catch_with_objc_intrinsic
+//
+// CHECK: catch.dispatch:
+// CHECK-NEXT:  [[CATCHSWITCH:%[0-9]+]] = catchswitch within none [label %catch] unwind label %[[CLEANUP1:.*]]
+//
+// All calls within a catchpad must have funclet tokens that refer to it:
+// CHECK: catch:
+// CHECK-NEXT:  [[CATCHPAD:%[0-9]+]] = catchpad within [[CATCHSWITCH]]
+// CHECK:   call
+// CHECK: @llvm.objc.retain
+// CHECK: [ "funclet"(token [[CATCHPAD]]) ]
+// CHECK:   invoke
+// CHECK: do_something
+// CHECK: [ "funclet"(token [[CATCHPAD]]) ]
+// CHECK: unwind label %[[CLEANUP2:.*]]
+// CHECK:   invoke
+// CHECK: may_throw
+// CHECK: [ "funclet"(token [[CATCHPAD]]) ]
+// CHECK: unwind label %[[CLEANUP2]]
+// CHECK:   call
+// CHECK: @llvm.objc.storeStrong
+// CHECK: [ "funclet"(token [[CATCHPAD]]) ]
+// CHECK:   catchret from [[CATCHPAD]] to label %catchret.dest
+//
+// This block exists and it's empty:
+// CHECK: catchret.dest:
+// CHECK-NEXT:  br label %eh.cont
+//
+// CHECK: [[CLEANUP2]]:
+// CHECK-NEXT:  [[CLEANUPPAD2:%[0-9]+]] = cleanuppad within [[CATCHPAD]]
+// CHECK:   call
+// CHECK: @llvm.objc.storeStrong
+// CHECK: [ "funclet"(token [[CLEANUPPAD2]]) ]
+// CHECK:   cleanupret from [[CLEANUPPAD2]]
+// CHECK: unwind label %[[CLEANUP1]]
+//
+// CHECK: [[CLEANUP1]]:
+// CHECK-NEXT:  [[CLEANUPPAD1:%[0-9]+]] = cleanuppad within none
+// CHECK:   call
+// CHECK: @llvm.objc.storeStrong
+// CHECK: [ "funclet"(token [[CLEANUPPAD1]]) ]
+// CHECK:   cleanupret from [[CLEANUPPAD1]] unwind to caller
Index: clang/lib/CodeGen/CGObjCRuntime.cpp
===
--- clang/lib/CodeGen/CGObjCRuntime.cpp
+++ clang/lib/CodeGen/CGObjCRuntime.cpp
@@ -22,6 +22,7 @@
 #include "clang/AST/StmtObjC.h"
 #include "clang/CodeGen/CGFunctionInfo.h"
 #include "clang/CodeGen/CodeGenABITypes.h"
+#include "llvm/IR/Instruction.h"
 #include "llvm/Support/SaveAndRestore.h"
 
 using namespace clang;
@@ -227,13 +228,18 @@
 CatchHandler &Handler = Handlers[I];
 
 CGF.EmitBlock(Handler.Block);
-llvm::CatchPadInst *CPI = nullptr;
-SaveAndRestore RestoreCurrentFuncletPad(CGF.CurrentFuncletPad);
-if

[clang] 9a9d636 - [CGObjC] Open cleanup scope before SaveAndRestore CurrentFuncletPad and push CatchRetScope early

2022-11-22 Thread Stefan Gränitz via cfe-commits

Author: Stefan Gränitz
Date: 2022-11-22T12:02:53+01:00
New Revision: 9a9d636caeea9ca9364b906364ac1aaba0869858

URL: 
https://github.com/llvm/llvm-project/commit/9a9d636caeea9ca9364b906364ac1aaba0869858
DIFF: 
https://github.com/llvm/llvm-project/commit/9a9d636caeea9ca9364b906364ac1aaba0869858.diff

LOG: [CGObjC] Open cleanup scope before SaveAndRestore CurrentFuncletPad and 
push CatchRetScope early

Pushing the `CatchRetScope` early causes cleanups for catch parameters to be 
emitted in the basic block of the catch handler instead of the `catchret.dest` 
block. This is important because the latter is not part of the catchpad and 
this caused code truncations due to ARC PreISel intrinsics in WinEHPrepare.

Reviewed By: rnk

Differential Revision: https://reviews.llvm.org/D137939

Added: 


Modified: 
clang/lib/CodeGen/CGObjCRuntime.cpp
clang/test/CodeGenObjCXX/arc-exceptions-seh.mm

Removed: 




diff  --git a/clang/lib/CodeGen/CGObjCRuntime.cpp 
b/clang/lib/CodeGen/CGObjCRuntime.cpp
index 58078d68f7166..fbf6d21bd407d 100644
--- a/clang/lib/CodeGen/CGObjCRuntime.cpp
+++ b/clang/lib/CodeGen/CGObjCRuntime.cpp
@@ -22,6 +22,7 @@
 #include "clang/AST/StmtObjC.h"
 #include "clang/CodeGen/CGFunctionInfo.h"
 #include "clang/CodeGen/CodeGenABITypes.h"
+#include "llvm/IR/Instruction.h"
 #include "llvm/Support/SaveAndRestore.h"
 
 using namespace clang;
@@ -227,13 +228,18 @@ void CGObjCRuntime::EmitTryCatchStmt(CodeGenFunction &CGF,
 CatchHandler &Handler = Handlers[I];
 
 CGF.EmitBlock(Handler.Block);
-llvm::CatchPadInst *CPI = nullptr;
-SaveAndRestore 
RestoreCurrentFuncletPad(CGF.CurrentFuncletPad);
-if (useFunclets)
-  if ((CPI = 
dyn_cast_or_null(Handler.Block->getFirstNonPHI( {
+
+CodeGenFunction::LexicalScope Cleanups(CGF, 
Handler.Body->getSourceRange());
+SaveAndRestore 
RevertAfterScope(CGF.CurrentFuncletPad);
+if (useFunclets) {
+  llvm::Instruction *CPICandidate = Handler.Block->getFirstNonPHI();
+  if (auto *CPI = dyn_cast_or_null(CPICandidate)) {
 CGF.CurrentFuncletPad = CPI;
 CPI->setOperand(2, CGF.getExceptionSlot().getPointer());
+CGF.EHStack.pushCleanup(NormalCleanup, CPI);
   }
+}
+
 llvm::Value *RawExn = CGF.getExceptionFromSlot();
 
 // Enter the catch.
@@ -241,8 +247,6 @@ void CGObjCRuntime::EmitTryCatchStmt(CodeGenFunction &CGF,
 if (beginCatchFn)
   Exn = CGF.EmitNounwindRuntimeCall(beginCatchFn, RawExn, "exn.adjusted");
 
-CodeGenFunction::LexicalScope cleanups(CGF, 
Handler.Body->getSourceRange());
-
 if (endCatchFn) {
   // Add a cleanup to leave the catch.
   bool EndCatchMightThrow = (Handler.Variable == nullptr);
@@ -260,15 +264,13 @@ void CGObjCRuntime::EmitTryCatchStmt(CodeGenFunction &CGF,
   CGF.EmitAutoVarDecl(*CatchParam);
   EmitInitOfCatchParam(CGF, CastExn, CatchParam);
 }
-if (CPI)
-CGF.EHStack.pushCleanup(NormalCleanup, CPI);
 
 CGF.ObjCEHValueStack.push_back(Exn);
 CGF.EmitStmt(Handler.Body);
 CGF.ObjCEHValueStack.pop_back();
 
 // Leave any cleanups associated with the catch.
-cleanups.ForceCleanup();
+Cleanups.ForceCleanup();
 
 CGF.EmitBranchThroughCleanup(Cont);
   }

diff  --git a/clang/test/CodeGenObjCXX/arc-exceptions-seh.mm 
b/clang/test/CodeGenObjCXX/arc-exceptions-seh.mm
index 267fbd65cc510..b432abcda97d6 100644
--- a/clang/test/CodeGenObjCXX/arc-exceptions-seh.mm
+++ b/clang/test/CodeGenObjCXX/arc-exceptions-seh.mm
@@ -1,29 +1,64 @@
-// RUN: %clang_cc1 -triple x86_64-pc-windows-msvc -emit-llvm -fobjc-arc 
-fexceptions -fobjc-exceptions -fobjc-runtime=gnustep-2.0 -o - %s | FileCheck %s
+// RUN: %clang_cc1 -triple x86_64-pc-windows-msvc -emit-llvm -fobjc-arc 
-fexceptions -fobjc-exceptions -fobjc-arc-exceptions -fobjc-runtime=gnustep-2.0 
-o - %s | FileCheck %s
 
 // WinEH requires funclet tokens on nounwind intrinsics if they can lower to
 // regular function calls in the course of IR transformations.
 //
 // This is the case for ObjC ARC runtime intrinsics. Test that clang emits the
-// funclet tokens for llvm.objc.retain and llvm.objc.storeStrong and that they
-// refer to their catchpad's SSA value.
+// funclet tokens for llvm.objc.* calls inside catch- and cleanup-pads and that
+// they refer to their pad's SSA value.
 
-@class Ety;
-void opaque(void);
-void test_catch_with_objc_intrinsic(void) {
+void do_something();
+void may_throw(id);
+
+void try_catch_with_objc_intrinsic() {
+  id ex;
   @try {
-opaque();
-  } @catch (Ety *ex) {
-// Destroy ex when leaving catchpad. This emits calls to intrinsic 
functions
-// llvm.objc.retain and llvm.objc.storeStrong
+may_throw(ex);
+  } @catch (id ex_caught) {
+do_something();
+may_throw(ex_caught);
   }
 }
 
-// CHECK-LABEL: define{{.*}} void {{.*}}test_catch_with_objc_intrinsic
-//...
-// CHECK:   catch.dispatch:
-// CH

[PATCH] D138488: [AArch64][clang] implement 2022 General Data-Processing instructions

2022-11-22 Thread Ties Stuij via Phabricator via cfe-commits
stuij created this revision.
Herald added subscribers: hiraditya, kristof.beyls.
Herald added a project: All.
stuij requested review of this revision.
Herald added projects: clang, LLVM.
Herald added subscribers: llvm-commits, cfe-commits.

This patch implements the 2022 Architecture General Data-Processing Instructions

They include:

Common Short Sequence Compression (CSSC) instructions

- scalar comparison instructions SMAX, SMIN, UMAX, UMIN (32/64 bits) with or 
without immediate
- ABS (absolute), CNT (count non-zero bits), CTZ (count trailing zeroes)
- command-line options for CSSC

Associated with these instructions in the documentation is the Range Prefetch
Memory (RPRFM) instruction, which signals to the memory system that data memory
accesses from a specified range of addresses are likely to occur in the near
future. The instruction lies in hint space, and is made unconditional.

Specs for the individual instructions can be found here:
https://developer.arm.com/documentation/ddi0602/2022-09/Base-Instructions/

contributors to this patch:

- Cullen Rhodes
- Son Tuan Vu
- Mark Murray
- Tomas Matheson
- Sam Elliott
- Ties Stuij


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D138488

Files:
  clang/test/Driver/aarch64-cssc.c
  llvm/include/llvm/Support/AArch64TargetParser.def
  llvm/include/llvm/Support/AArch64TargetParser.h
  llvm/lib/Target/AArch64/AArch64.td
  llvm/lib/Target/AArch64/AArch64InstrFormats.td
  llvm/lib/Target/AArch64/AArch64InstrInfo.td
  llvm/lib/Target/AArch64/AArch64SystemOperands.td
  llvm/lib/Target/AArch64/AsmParser/AArch64AsmParser.cpp
  llvm/lib/Target/AArch64/Disassembler/AArch64Disassembler.cpp
  llvm/lib/Target/AArch64/MCTargetDesc/AArch64InstPrinter.cpp
  llvm/lib/Target/AArch64/MCTargetDesc/AArch64InstPrinter.h
  llvm/lib/Target/AArch64/SVEInstrFormats.td
  llvm/lib/Target/AArch64/Utils/AArch64BaseInfo.cpp
  llvm/lib/Target/AArch64/Utils/AArch64BaseInfo.h
  llvm/test/MC/AArch64/CSSC/abs_32.s
  llvm/test/MC/AArch64/CSSC/abs_64.s
  llvm/test/MC/AArch64/CSSC/cnt_32.s
  llvm/test/MC/AArch64/CSSC/cnt_64.s
  llvm/test/MC/AArch64/CSSC/ctz_32.s
  llvm/test/MC/AArch64/CSSC/ctz_64.s
  llvm/test/MC/AArch64/CSSC/smax_32_imm.s
  llvm/test/MC/AArch64/CSSC/smax_32_reg.s
  llvm/test/MC/AArch64/CSSC/smax_64_imm.s
  llvm/test/MC/AArch64/CSSC/smax_64_reg.s
  llvm/test/MC/AArch64/CSSC/smin_32_imm.s
  llvm/test/MC/AArch64/CSSC/smin_32_reg.s
  llvm/test/MC/AArch64/CSSC/smin_64_imm.s
  llvm/test/MC/AArch64/CSSC/smin_64_reg.s
  llvm/test/MC/AArch64/CSSC/umax_32_imm.s
  llvm/test/MC/AArch64/CSSC/umax_32_reg.s
  llvm/test/MC/AArch64/CSSC/umax_64_imm.s
  llvm/test/MC/AArch64/CSSC/umax_64_reg.s
  llvm/test/MC/AArch64/CSSC/umin_32_imm.s
  llvm/test/MC/AArch64/CSSC/umin_32_reg.s
  llvm/test/MC/AArch64/CSSC/umin_64_imm.s
  llvm/test/MC/AArch64/CSSC/umin_64_reg.s
  llvm/test/MC/AArch64/armv9.4a-v94-dp.s
  llvm/test/MC/AArch64/rprfm.s
  llvm/test/MC/Disassembler/AArch64/armv9.4a-v94-dp.txt
  llvm/unittests/Support/TargetParserTest.cpp

Index: llvm/unittests/Support/TargetParserTest.cpp
===
--- llvm/unittests/Support/TargetParserTest.cpp
+++ llvm/unittests/Support/TargetParserTest.cpp
@@ -1606,7 +1606,7 @@
   AArch64::AEK_SME, AArch64::AEK_SMEF64F64, AArch64::AEK_SMEI16I64,
   AArch64::AEK_SME2,AArch64::AEK_HBC,  AArch64::AEK_MOPS,
   AArch64::AEK_PERFMON, AArch64::AEK_SVE2p1,   AArch64::AEK_SME2p1,
-  AArch64::AEK_B16B16,  AArch64::AEK_SMEF16F16};
+  AArch64::AEK_B16B16,  AArch64::AEK_SMEF16F16, AArch64::AEK_CSSC};
 
   std::vector Features;
 
@@ -1671,6 +1671,7 @@
   EXPECT_TRUE(llvm::is_contained(Features, "+hbc"));
   EXPECT_TRUE(llvm::is_contained(Features, "+mops"));
   EXPECT_TRUE(llvm::is_contained(Features, "+perfmon"));
+  EXPECT_TRUE(llvm::is_contained(Features, "+cssc"));
 
   // Assuming we listed every extension above, this should produce the same
   // result. (note that AEK_NONE doesn't have a name so it won't be in the
Index: llvm/test/MC/Disassembler/AArch64/armv9.4a-v94-dp.txt
===
--- /dev/null
+++ llvm/test/MC/Disassembler/AArch64/armv9.4a-v94-dp.txt
@@ -0,0 +1,72 @@
+# RUN: llvm-mc -triple aarch64-none-linux-gnu -disassemble -mattr=+v9.4a < %s  | FileCheck %s
+# RUN: not llvm-mc -triple aarch64-none-linux-gnu -disassemble -mattr=+v8.8a < %s 2>&1 | FileCheck --check-prefix=NO-V94A-ERR %s
+# RUN: llvm-mc -triple aarch64-none-linux-gnu -disassemble -mattr=+v8.9a < %s  | FileCheck %s
+# RUN: not llvm-mc -triple aarch64-none-linux-gnu -disassemble -mattr=+v9.3a < %s 2>&1 | FileCheck --check-prefix=NO-V94A-ERR %s
+
+[0x20,0x20,0xc0,0xda]
+# CHECK:   abs x0, x1
+# NO-V94A-ERR: [[@LINE-2]]:2: warning: invalid instruction encoding
+[0x20,0x20,0xc0,0x5a]
+# CHECK:   abs w0, w1
+# NO-V94A-ERR: [[@LINE-2]]:2: warning: invalid instruction encoding
+[0x20,0x1c,0xc0,0xda]
+# CHECK:   cnt x0, x1

[PATCH] D138489: [tsan] Add tsan support for loongarch64

2022-11-22 Thread Youling Tang via Phabricator via cfe-commits
tangyouling created this revision.
tangyouling added reviewers: vitalybuka, dvyukov, melver, SixWeining, xen0n, 
xry111, MaskRay, lixing-star, MQ-mengqing, XiaodongLoong.
Herald added subscribers: Enna1, StephenFan, s.egerton, simoncook.
Herald added a project: All.
tangyouling requested review of this revision.
Herald added subscribers: Sanitizers, cfe-commits, pcwang-thead.
Herald added projects: clang, Sanitizers.

This patch enabled tsan for loongarch64 with 47-bit VMA layout. All
tests are passing.

Also adds assembly routines to enable setjmp/longjmp for loongarch64
on linux.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D138489

Files:
  clang/lib/Driver/ToolChains/Linux.cpp
  compiler-rt/cmake/Modules/AllSupportedArchDefs.cmake
  compiler-rt/lib/sanitizer_common/sanitizer_linux.cpp
  compiler-rt/lib/sanitizer_common/sanitizer_linux.h
  compiler-rt/lib/sanitizer_common/sanitizer_linux_libcdep.cpp
  compiler-rt/lib/sanitizer_common/sanitizer_stoptheworld_linux_libcdep.cpp
  compiler-rt/lib/tsan/rtl/CMakeLists.txt
  compiler-rt/lib/tsan/rtl/tsan_interceptors_posix.cpp
  compiler-rt/lib/tsan/rtl/tsan_platform.h
  compiler-rt/lib/tsan/rtl/tsan_platform_linux.cpp
  compiler-rt/lib/tsan/rtl/tsan_rtl.h
  compiler-rt/lib/tsan/rtl/tsan_rtl_loongarch64.S
  compiler-rt/test/sanitizer_common/print_address.h
  compiler-rt/test/tsan/map32bit.cpp
  compiler-rt/test/tsan/mmap_large.cpp

Index: compiler-rt/test/tsan/mmap_large.cpp
===
--- compiler-rt/test/tsan/mmap_large.cpp
+++ compiler-rt/test/tsan/mmap_large.cpp
@@ -17,7 +17,7 @@
 int main() {
 #ifdef __x86_64__
   const size_t kLog2Size = 39;
-#elif defined(__mips64) || defined(__aarch64__)
+#elif defined(__mips64) || defined(__aarch64__) || defined(__loongarch__)
   const size_t kLog2Size = 32;
 #elif defined(__powerpc64__)
   const size_t kLog2Size = 39;
Index: compiler-rt/test/tsan/map32bit.cpp
===
--- compiler-rt/test/tsan/map32bit.cpp
+++ compiler-rt/test/tsan/map32bit.cpp
@@ -12,6 +12,7 @@
 // XFAIL: aarch64
 // XFAIL: powerpc64
 // XFAIL: s390x
+// XFAIL: loongarch64
 
 // MAP_32BIT doesn't exist on OS X and NetBSD.
 // UNSUPPORTED: darwin,netbsd
Index: compiler-rt/test/sanitizer_common/print_address.h
===
--- compiler-rt/test/sanitizer_common/print_address.h
+++ compiler-rt/test/sanitizer_common/print_address.h
@@ -7,8 +7,9 @@
   va_start(ap, n);
   while (n--) {
 void *p = va_arg(ap, void *);
-#if defined(__x86_64__) || defined(__aarch64__) || defined(__powerpc64__) || \
-defined(__s390x__) || (defined(__riscv) && __riscv_xlen == 64)
+#if defined(__x86_64__) || defined(__aarch64__) || defined(__powerpc64__) ||   \
+defined(__s390x__) || (defined(__riscv) && __riscv_xlen == 64) ||  \
+defined(__loongarch__)
 // On FreeBSD, the %p conversion specifier works as 0x%x and thus does not
 // match to the format used in the diagnotic message.
 fprintf(stderr, "0x%012lx ", (unsigned long) p);
Index: compiler-rt/lib/tsan/rtl/tsan_rtl_loongarch64.S
===
--- /dev/null
+++ compiler-rt/lib/tsan/rtl/tsan_rtl_loongarch64.S
@@ -0,0 +1,196 @@
+#include "sanitizer_common/sanitizer_asm.h"
+
+.section .text
+
+ASM_HIDDEN(__tsan_setjmp)
+.comm _ZN14__interception11real_setjmpE,8,8
+.globl ASM_SYMBOL_INTERCEPTOR(setjmp)
+ASM_TYPE_FUNCTION(ASM_SYMBOL_INTERCEPTOR(setjmp))
+ASM_SYMBOL_INTERCEPTOR(setjmp):
+  CFI_STARTPROC
+
+  // Save frame pointer and return address register
+  addi.d $sp, $sp, -32
+  st.d $ra, $sp, 24
+  st.d $fp, $sp, 16
+  CFI_DEF_CFA_OFFSET (32)
+  CFI_OFFSET (1, -8)
+  CFI_OFFSET (22, -16)
+
+  // Adjust the SP for previous frame
+  addi.d $fp, $sp, 32
+  CFI_DEF_CFA_REGISTER (22)
+
+  // Save env parameter
+  st.d $a0, $sp, 8
+  CFI_OFFSET (4, -24)
+
+  // Obtain SP, first argument to `void __tsan_setjmp(uptr sp)`
+  addi.d  $a0, $fp, 0
+
+  // call tsan interceptor
+  bl  ASM_SYMBOL(__tsan_setjmp)
+
+  // Restore env parameter
+  ld.d $a0, $sp, 8
+  CFI_RESTORE (4)
+
+  // Restore frame/link register
+  ld.d $fp, $sp, 16
+  ld.d $ra, $sp, 24
+  addi.d $sp, $sp, 32
+  CFI_RESTORE (22)
+  CFI_RESTORE (1)
+  CFI_DEF_CFA (3, 0)
+
+  // tail jump to libc setjmp
+  la.local $a1, _ZN14__interception11real_setjmpE
+  ld.d $a1, $a1, 0
+  jr $a1
+
+  CFI_ENDPROC
+ASM_SIZE(ASM_SYMBOL_INTERCEPTOR(setjmp))
+
+.comm _ZN14__interception12real__setjmpE,8,8
+.globl ASM_SYMBOL_INTERCEPTOR(_setjmp)
+ASM_TYPE_FUNCTION(ASM_SYMBOL_INTERCEPTOR(_setjmp))
+ASM_SYMBOL_INTERCEPTOR(_setjmp):
+  CFI_STARTPROC
+
+  // Save frame pointer and return address register
+  addi.d $sp, $sp, -32
+  st.d $ra, $sp, 24
+  st.d $fp, $sp, 16
+  CFI_DEF_CFA_OFFSET (32)
+  CFI_OFFSET (1, -8)
+  CFI_OFFSET (22, -16)
+
+  // Adjust the SP for previous frame
+  addi.d $fp, $sp, 32
+  CFI_DEF_

[PATCH] D138489: [tsan] Add tsan support for loongarch64

2022-11-22 Thread Youling Tang via Phabricator via cfe-commits
tangyouling added a comment.

  $ make check-tsan -j4
  Testing Time: 78.34s
Unsupported  :  91
Passed   : 345
Expectedly Failed:   2


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D138489/new/

https://reviews.llvm.org/D138489

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D138488: [AArch64][clang] implement 2022 General Data-Processing instructions

2022-11-22 Thread Sam Elliott via Phabricator via cfe-commits
lenary accepted this revision.
lenary added a comment.
This revision is now accepted and ready to land.

LGTM!


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D138488/new/

https://reviews.llvm.org/D138488

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D137470: [Offloading] Initial support for registering offloading entries on COFF targets

2022-11-22 Thread Martin Storsjö via Phabricator via cfe-commits
mstorsjo added a comment.

In D137470#3928870 , @jhuber6 wrote:

> In D137470#3928828 , @mstorsjo 
> wrote:
>
>> Sorry, I'm not quite up to speed with exactly what is being done linker-wise 
>> here - can you give a more detailed overview? Keep in mind that there's two 
>> separate interfaces to lld for COFF; when used in mingw mode, it invokes the 
>> `ld.lld` frontend, but with a `-m` option which directs lld to the mingw 
>> frontend, which parses `ld.lld` style options and rewrites them to 
>> `lld-link` style options and invokes that interface. And when Clang is 
>> operating in msvc/clang-cl mode, `lld-link` is invoked (or called directly 
>> by the build system).
>
> Sure, there's a bit of documentation 
>  for what's going on here, 
> but I may need to update it a bit.
>
> Basically, for offloading languages (CUDA, HIP, OpenMP, etc) we compile the 
> source code twice, once for the host and once for the target device. We embed 
> the device relocatable object inside the host so we follow a standard 
> compilation pipeline. This `linker-wrapper` then fishes those relocatable 
> objects out and performs the device-linking phase. The linked output is then 
> put into a global along with some runtime calls to register the image and 
> kernels. That new file gets passed to the wrapped linker job and we get a 
> final executable.
>
> My concern is that the linker wrapper keys off of certain arguments to the 
> linker to do its job since it's invoked something like `clang-linker-wrapper 
> `. I understand these are fundamentally different for `lld-link` 
> so I was wondering if this approach in general would work there.

Right, yes, `lld-link` uses different arguments than `ld.lld`. (Also note that 
for mingw targets, the regular `ld.lld` interface is used on Windows too, while 
`link.exe` or `lld-link` is used for msvc targets.)

Anyway, I don't have much other comments on this - other than what I commented 
before, this seems mostly reasonable, but I'm not familiar enough with the 
whole OpenMP pipeline to give any authoritative review really. Feel free to ask 
specifically about other details relating to PE/COFF though!


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D137470/new/

https://reviews.llvm.org/D137470

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D138488: [AArch64][clang] implement 2022 General Data-Processing instructions

2022-11-22 Thread Sam Elliott via Phabricator via cfe-commits
lenary added a comment.

Oh, actually, I have a few nits. You can fix them on commit though.




Comment at: llvm/lib/Target/AArch64/AArch64.td:497
+def FeatureCSSC : SubtargetFeature<"cssc", "HasCSSC", "true",
+  "Enable Common Short Sequence Compression (CSSC) instructions">;
+

Please use the full name in parens: FEAT_CSSC (we've done this upstream for 
most other architectural extensions).





Comment at: llvm/test/MC/AArch64/armv9.4a-v94-dp.s:1
+// RUN: llvm-mc -triple aarch64-none-linux-gnu -show-encoding 
-mattr=+v9.4a < %s  | FileCheck %s
+// RUN: not llvm-mc -triple aarch64-none-linux-gnu
-mattr=+v8.8a < %s 2>&1 | FileCheck --check-prefix=NO-CSSC-ERR %s

CSSC is actually a v8.9a feature, can you update this filename?



Comment at: llvm/test/MC/Disassembler/AArch64/armv9.4a-v94-dp.txt:1
+# RUN: llvm-mc -triple aarch64-none-linux-gnu -disassemble -mattr=+v9.4a < 
%s  | FileCheck %s
+# RUN: not llvm-mc -triple aarch64-none-linux-gnu -disassemble -mattr=+v8.8a < 
%s 2>&1 | FileCheck --check-prefix=NO-V94A-ERR %s

And this filename too?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D138488/new/

https://reviews.llvm.org/D138488

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D138488: [AArch64][clang] implement 2022 General Data-Processing instructions

2022-11-22 Thread Dave Green via Phabricator via cfe-commits
dmgreen added inline comments.



Comment at: llvm/include/llvm/Support/AArch64TargetParser.h:79
+  AEK_SMEF16F16 =   1ULL << 47, // FEAT_SMEF16F16
+  AEK_CSSC =1ULL << 49, // FEAT_CSSC
 };

48!?



Comment at: llvm/lib/Target/AArch64/AArch64.td:497
+def FeatureCSSC : SubtargetFeature<"cssc", "HasCSSC", "true",
+  "Enable Common Short Sequence Compression (CSSC) instructions">;
+

lenary wrote:
> Please use the full name in parens: FEAT_CSSC (we've done this upstream for 
> most other architectural extensions).
> 
> 
Can you add (FEAT_SCCS) to this (if that is the correct name).



Comment at: llvm/lib/Target/AArch64/AArch64InstrFormats.td:11725
+: BaseTwoOperandRegReg,
+  Sched<[]> {
+  let Inst{11} = isMin;

Can we make this WriteI, maybe. I think that would probably be the closest 
sched class.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D138488/new/

https://reviews.llvm.org/D138488

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] 01023bf - [CGObjC] Add run line for release mode in test arc-exceptions-seh.mm (NFC)

2022-11-22 Thread Stefan Gränitz via cfe-commits

Author: Stefan Gränitz
Date: 2022-11-22T13:43:08+01:00
New Revision: 01023bfcd33f922ed8c934ce563e54abe8bfe246

URL: 
https://github.com/llvm/llvm-project/commit/01023bfcd33f922ed8c934ce563e54abe8bfe246
DIFF: 
https://github.com/llvm/llvm-project/commit/01023bfcd33f922ed8c934ce563e54abe8bfe246.diff

LOG: [CGObjC] Add run line for release mode in test arc-exceptions-seh.mm (NFC)

In release mode `arc-exceptions-seh.mm` fails. It needs 
`-enable-objc-arc-opts=false` to skip ObjC ARC optimizations.

Reviewed By: triplef

Differential Revision: https://reviews.llvm.org/D137942

Added: 


Modified: 
clang/test/CodeGenObjCXX/arc-exceptions-seh.mm

Removed: 




diff  --git a/clang/test/CodeGenObjCXX/arc-exceptions-seh.mm 
b/clang/test/CodeGenObjCXX/arc-exceptions-seh.mm
index b432abcda97d..d5daf55d 100644
--- a/clang/test/CodeGenObjCXX/arc-exceptions-seh.mm
+++ b/clang/test/CodeGenObjCXX/arc-exceptions-seh.mm
@@ -1,4 +1,5 @@
-// RUN: %clang_cc1 -triple x86_64-pc-windows-msvc -emit-llvm -fobjc-arc 
-fexceptions -fobjc-exceptions -fobjc-arc-exceptions -fobjc-runtime=gnustep-2.0 
-o - %s | FileCheck %s
+// RUN: %clang_cc1 -triple x86_64-pc-windows-msvc -emit-llvm -fobjc-arc 
-fexceptions -fobjc-exceptions -fobjc-arc-exceptions -fobjc-runtime=gnustep-2.0 
-o - %s | FileCheck %s --check-prefixes=CHECK,CHECK-O0
+// RUN: %clang_cc1 -O2 -triple x86_64-pc-windows-msvc -emit-llvm -fobjc-arc 
-fexceptions -fobjc-exceptions -fobjc-arc-exceptions -fobjc-runtime=gnustep-2.0 
-mllvm -enable-objc-arc-opts=false -o - %s | FileCheck %s 
--check-prefixes=CHECK,CHECK-O2
 
 // WinEH requires funclet tokens on nounwind intrinsics if they can lower to
 // regular function calls in the course of IR transformations.
@@ -40,18 +41,21 @@ void try_catch_with_objc_intrinsic() {
 // CHECK: [ "funclet"(token [[CATCHPAD]]) ]
 // CHECK: unwind label %[[CLEANUP2]]
 // CHECK:   call
-// CHECK: @llvm.objc.storeStrong
+// CHECK-O0:  @llvm.objc.storeStrong
+// CHECK-O2:  @llvm.objc.release
 // CHECK: [ "funclet"(token [[CATCHPAD]]) ]
-// CHECK:   catchret from [[CATCHPAD]] to label %catchret.dest
+// CHECK-O0:catchret from [[CATCHPAD]] to label %catchret.dest
+// CHECK-O2:catchret from [[CATCHPAD]] to label %eh.cont
 //
-// This block exists and it's empty:
-// CHECK: catchret.dest:
-// CHECK-NEXT:  br label %eh.cont
+// In debug mode, this block exists and it's empty:
+// CHECK-O0:  catchret.dest:
+// CHECK-O0-NEXT:   br label %eh.cont
 //
 // CHECK: [[CLEANUP2]]:
 // CHECK-NEXT:  [[CLEANUPPAD2:%[0-9]+]] = cleanuppad within [[CATCHPAD]]
 // CHECK:   call
-// CHECK: @llvm.objc.storeStrong
+// CHECK-O0:  @llvm.objc.storeStrong
+// CHECK-O2:  @llvm.objc.release
 // CHECK: [ "funclet"(token [[CLEANUPPAD2]]) ]
 // CHECK:   cleanupret from [[CLEANUPPAD2]]
 // CHECK: unwind label %[[CLEANUP1]]
@@ -59,6 +63,7 @@ void try_catch_with_objc_intrinsic() {
 // CHECK: [[CLEANUP1]]:
 // CHECK-NEXT:  [[CLEANUPPAD1:%[0-9]+]] = cleanuppad within none
 // CHECK:   call
-// CHECK: @llvm.objc.storeStrong
+// CHECK-O0:  @llvm.objc.storeStrong
+// CHECK-O2:  @llvm.objc.release
 // CHECK: [ "funclet"(token [[CLEANUPPAD1]]) ]
 // CHECK:   cleanupret from [[CLEANUPPAD1]] unwind to caller



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D137942: [CGObjC] Add run line for release mode in test arc-exceptions-seh.mm (NFC)

2022-11-22 Thread Stefan Gränitz via Phabricator via cfe-commits
This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rG01023bfcd33f: [CGObjC] Add run line for release mode in test 
arc-exceptions-seh.mm (NFC) (authored by sgraenitz).

Changed prior to commit:
  https://reviews.llvm.org/D137942?vs=475127&id=477140#toc

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D137942/new/

https://reviews.llvm.org/D137942

Files:
  clang/test/CodeGenObjCXX/arc-exceptions-seh.mm


Index: clang/test/CodeGenObjCXX/arc-exceptions-seh.mm
===
--- clang/test/CodeGenObjCXX/arc-exceptions-seh.mm
+++ clang/test/CodeGenObjCXX/arc-exceptions-seh.mm
@@ -1,4 +1,5 @@
-// RUN: %clang_cc1 -triple x86_64-pc-windows-msvc -emit-llvm -fobjc-arc 
-fexceptions -fobjc-exceptions -fobjc-arc-exceptions -fobjc-runtime=gnustep-2.0 
-o - %s | FileCheck %s
+// RUN: %clang_cc1 -triple x86_64-pc-windows-msvc -emit-llvm -fobjc-arc 
-fexceptions -fobjc-exceptions -fobjc-arc-exceptions -fobjc-runtime=gnustep-2.0 
-o - %s | FileCheck %s --check-prefixes=CHECK,CHECK-O0
+// RUN: %clang_cc1 -O2 -triple x86_64-pc-windows-msvc -emit-llvm -fobjc-arc 
-fexceptions -fobjc-exceptions -fobjc-arc-exceptions -fobjc-runtime=gnustep-2.0 
-mllvm -enable-objc-arc-opts=false -o - %s | FileCheck %s 
--check-prefixes=CHECK,CHECK-O2
 
 // WinEH requires funclet tokens on nounwind intrinsics if they can lower to
 // regular function calls in the course of IR transformations.
@@ -40,18 +41,21 @@
 // CHECK: [ "funclet"(token [[CATCHPAD]]) ]
 // CHECK: unwind label %[[CLEANUP2]]
 // CHECK:   call
-// CHECK: @llvm.objc.storeStrong
+// CHECK-O0:  @llvm.objc.storeStrong
+// CHECK-O2:  @llvm.objc.release
 // CHECK: [ "funclet"(token [[CATCHPAD]]) ]
-// CHECK:   catchret from [[CATCHPAD]] to label %catchret.dest
+// CHECK-O0:catchret from [[CATCHPAD]] to label %catchret.dest
+// CHECK-O2:catchret from [[CATCHPAD]] to label %eh.cont
 //
-// This block exists and it's empty:
-// CHECK: catchret.dest:
-// CHECK-NEXT:  br label %eh.cont
+// In debug mode, this block exists and it's empty:
+// CHECK-O0:  catchret.dest:
+// CHECK-O0-NEXT:   br label %eh.cont
 //
 // CHECK: [[CLEANUP2]]:
 // CHECK-NEXT:  [[CLEANUPPAD2:%[0-9]+]] = cleanuppad within [[CATCHPAD]]
 // CHECK:   call
-// CHECK: @llvm.objc.storeStrong
+// CHECK-O0:  @llvm.objc.storeStrong
+// CHECK-O2:  @llvm.objc.release
 // CHECK: [ "funclet"(token [[CLEANUPPAD2]]) ]
 // CHECK:   cleanupret from [[CLEANUPPAD2]]
 // CHECK: unwind label %[[CLEANUP1]]
@@ -59,6 +63,7 @@
 // CHECK: [[CLEANUP1]]:
 // CHECK-NEXT:  [[CLEANUPPAD1:%[0-9]+]] = cleanuppad within none
 // CHECK:   call
-// CHECK: @llvm.objc.storeStrong
+// CHECK-O0:  @llvm.objc.storeStrong
+// CHECK-O2:  @llvm.objc.release
 // CHECK: [ "funclet"(token [[CLEANUPPAD1]]) ]
 // CHECK:   cleanupret from [[CLEANUPPAD1]] unwind to caller


Index: clang/test/CodeGenObjCXX/arc-exceptions-seh.mm
===
--- clang/test/CodeGenObjCXX/arc-exceptions-seh.mm
+++ clang/test/CodeGenObjCXX/arc-exceptions-seh.mm
@@ -1,4 +1,5 @@
-// RUN: %clang_cc1 -triple x86_64-pc-windows-msvc -emit-llvm -fobjc-arc -fexceptions -fobjc-exceptions -fobjc-arc-exceptions -fobjc-runtime=gnustep-2.0 -o - %s | FileCheck %s
+// RUN: %clang_cc1 -triple x86_64-pc-windows-msvc -emit-llvm -fobjc-arc -fexceptions -fobjc-exceptions -fobjc-arc-exceptions -fobjc-runtime=gnustep-2.0 -o - %s | FileCheck %s --check-prefixes=CHECK,CHECK-O0
+// RUN: %clang_cc1 -O2 -triple x86_64-pc-windows-msvc -emit-llvm -fobjc-arc -fexceptions -fobjc-exceptions -fobjc-arc-exceptions -fobjc-runtime=gnustep-2.0 -mllvm -enable-objc-arc-opts=false -o - %s | FileCheck %s --check-prefixes=CHECK,CHECK-O2
 
 // WinEH requires funclet tokens on nounwind intrinsics if they can lower to
 // regular function calls in the course of IR transformations.
@@ -40,18 +41,21 @@
 // CHECK: [ "funclet"(token [[CATCHPAD]]) ]
 // CHECK: unwind label %[[CLEANUP2]]
 // CHECK:   call
-// CHECK: @llvm.objc.storeStrong
+// CHECK-O0:  @llvm.objc.storeStrong
+// CHECK-O2:  @llvm.objc.release
 // CHECK: [ "funclet"(token [[CATCHPAD]]) ]
-// CHECK:   catchret from [[CATCHPAD]] to label %catchret.dest
+// CHECK-O0:catchret from [[CATCHPAD]] to label %catchret.dest
+// CHECK-O2:catchret from [[CATCHPAD]] to label %eh.cont
 //
-// This block exists and it's empty:
-// CHECK: catchret.dest:
-// CHECK-NEXT:  br label %eh.cont
+// In debug mode, this block exists and it's empty:
+// CHECK-O0:  catchret.dest:
+// CHECK-O0

[PATCH] D138488: [AArch64][clang] implement 2022 General Data-Processing instructions

2022-11-22 Thread Thorsten via Phabricator via cfe-commits
tschuett added inline comments.



Comment at: llvm/lib/Target/AArch64/AArch64InstrFormats.td:11698
+//---
+// 2022 Architecture Extensions: General Data Processing (FEAT_V94_DP)
+//---

FEAT_CSSC or FEAT_V94_DP?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D138488/new/

https://reviews.llvm.org/D138488

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D138289: [clang][Parse] Remove constant expression from if condition

2022-11-22 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added a comment.

In D138289#3943090 , @tbaeder wrote:

> Yeah, just removing the `MaybeTypeCast` worked, but switching to `isTypeCast` 
> doens't.

I think for now we can remove the `MaybeTypeCast` entirely. We only set 
`isTypeCast` once we *know* we're dealing with a type cast, and this is about 
typo correction where we probably don't know what we're dealing with. Given 
that it's a no-op change to do that, removing it leaves us in no worse shape 
than we were before.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D138289/new/

https://reviews.llvm.org/D138289

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D138488: [AArch64][clang] implement 2022 General Data-Processing instructions

2022-11-22 Thread Ties Stuij via Phabricator via cfe-commits
stuij updated this revision to Diff 477143.
stuij marked 6 inline comments as done.
stuij added a comment.

addressed review comments


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D138488/new/

https://reviews.llvm.org/D138488

Files:
  clang/test/Driver/aarch64-cssc.c
  llvm/include/llvm/Support/AArch64TargetParser.def
  llvm/include/llvm/Support/AArch64TargetParser.h
  llvm/lib/Target/AArch64/AArch64.td
  llvm/lib/Target/AArch64/AArch64InstrFormats.td
  llvm/lib/Target/AArch64/AArch64InstrInfo.td
  llvm/lib/Target/AArch64/AArch64SystemOperands.td
  llvm/lib/Target/AArch64/AsmParser/AArch64AsmParser.cpp
  llvm/lib/Target/AArch64/Disassembler/AArch64Disassembler.cpp
  llvm/lib/Target/AArch64/MCTargetDesc/AArch64InstPrinter.cpp
  llvm/lib/Target/AArch64/MCTargetDesc/AArch64InstPrinter.h
  llvm/lib/Target/AArch64/SVEInstrFormats.td
  llvm/lib/Target/AArch64/Utils/AArch64BaseInfo.cpp
  llvm/lib/Target/AArch64/Utils/AArch64BaseInfo.h
  llvm/test/MC/AArch64/CSSC/abs_32.s
  llvm/test/MC/AArch64/CSSC/abs_64.s
  llvm/test/MC/AArch64/CSSC/cnt_32.s
  llvm/test/MC/AArch64/CSSC/cnt_64.s
  llvm/test/MC/AArch64/CSSC/ctz_32.s
  llvm/test/MC/AArch64/CSSC/ctz_64.s
  llvm/test/MC/AArch64/CSSC/smax_32_imm.s
  llvm/test/MC/AArch64/CSSC/smax_32_reg.s
  llvm/test/MC/AArch64/CSSC/smax_64_imm.s
  llvm/test/MC/AArch64/CSSC/smax_64_reg.s
  llvm/test/MC/AArch64/CSSC/smin_32_imm.s
  llvm/test/MC/AArch64/CSSC/smin_32_reg.s
  llvm/test/MC/AArch64/CSSC/smin_64_imm.s
  llvm/test/MC/AArch64/CSSC/smin_64_reg.s
  llvm/test/MC/AArch64/CSSC/umax_32_imm.s
  llvm/test/MC/AArch64/CSSC/umax_32_reg.s
  llvm/test/MC/AArch64/CSSC/umax_64_imm.s
  llvm/test/MC/AArch64/CSSC/umax_64_reg.s
  llvm/test/MC/AArch64/CSSC/umin_32_imm.s
  llvm/test/MC/AArch64/CSSC/umin_32_reg.s
  llvm/test/MC/AArch64/CSSC/umin_64_imm.s
  llvm/test/MC/AArch64/CSSC/umin_64_reg.s
  llvm/test/MC/AArch64/armv8.9a-v94-dp.s
  llvm/test/MC/AArch64/rprfm.s
  llvm/test/MC/Disassembler/AArch64/armv8.9a-v94-dp.txt
  llvm/unittests/Support/TargetParserTest.cpp

Index: llvm/unittests/Support/TargetParserTest.cpp
===
--- llvm/unittests/Support/TargetParserTest.cpp
+++ llvm/unittests/Support/TargetParserTest.cpp
@@ -1606,7 +1606,7 @@
   AArch64::AEK_SME, AArch64::AEK_SMEF64F64, AArch64::AEK_SMEI16I64,
   AArch64::AEK_SME2,AArch64::AEK_HBC,  AArch64::AEK_MOPS,
   AArch64::AEK_PERFMON, AArch64::AEK_SVE2p1,   AArch64::AEK_SME2p1,
-  AArch64::AEK_B16B16,  AArch64::AEK_SMEF16F16};
+  AArch64::AEK_B16B16,  AArch64::AEK_SMEF16F16, AArch64::AEK_CSSC};
 
   std::vector Features;
 
@@ -1671,6 +1671,7 @@
   EXPECT_TRUE(llvm::is_contained(Features, "+hbc"));
   EXPECT_TRUE(llvm::is_contained(Features, "+mops"));
   EXPECT_TRUE(llvm::is_contained(Features, "+perfmon"));
+  EXPECT_TRUE(llvm::is_contained(Features, "+cssc"));
 
   // Assuming we listed every extension above, this should produce the same
   // result. (note that AEK_NONE doesn't have a name so it won't be in the
Index: llvm/test/MC/Disassembler/AArch64/armv8.9a-v94-dp.txt
===
--- /dev/null
+++ llvm/test/MC/Disassembler/AArch64/armv8.9a-v94-dp.txt
@@ -0,0 +1,72 @@
+# RUN: llvm-mc -triple aarch64-none-linux-gnu -disassemble -mattr=+v9.4a < %s  | FileCheck %s
+# RUN: not llvm-mc -triple aarch64-none-linux-gnu -disassemble -mattr=+v8.8a < %s 2>&1 | FileCheck --check-prefix=NO-V94A-ERR %s
+# RUN: llvm-mc -triple aarch64-none-linux-gnu -disassemble -mattr=+v8.9a < %s  | FileCheck %s
+# RUN: not llvm-mc -triple aarch64-none-linux-gnu -disassemble -mattr=+v9.3a < %s 2>&1 | FileCheck --check-prefix=NO-V94A-ERR %s
+
+[0x20,0x20,0xc0,0xda]
+# CHECK:   abs x0, x1
+# NO-V94A-ERR: [[@LINE-2]]:2: warning: invalid instruction encoding
+[0x20,0x20,0xc0,0x5a]
+# CHECK:   abs w0, w1
+# NO-V94A-ERR: [[@LINE-2]]:2: warning: invalid instruction encoding
+[0x20,0x1c,0xc0,0xda]
+# CHECK:   cnt x0, x1
+# NO-V94A-ERR: [[@LINE-2]]:2: warning: invalid instruction encoding
+[0x20,0x1c,0xc0,0x5a]
+# CHECK:   cnt w0, w1
+# NO-V94A-ERR: [[@LINE-2]]:2: warning: invalid instruction encoding
+[0x20,0x18,0xc0,0xda]
+# CHECK:   ctz x0, x1
+# NO-V94A-ERR: [[@LINE-2]]:2: warning: invalid instruction encoding
+[0x20,0x18,0xc0,0x5a]
+# CHECK:   ctz w0, w1
+# NO-V94A-ERR: [[@LINE-2]]:2: warning: invalid instruction encoding
+
+[0x41,0x60,0xc3,0x9a]
+# CHECK:   smaxx1, x2, x3
+# NO-V94A-ERR: [[@LINE-2]]:2: warning: invalid instruction encoding
+[0x41,0x0c,0xc0,0x91]
+# CHECK:   smaxx1, x2, #3
+# NO-V94A-ERR: [[@LINE-2]]:2: warning: invalid instruction encoding
+[0x41,0x60,0xc3,0x1a]
+# CHECK:   smaxw1, w2, w3
+# NO-V94A-ERR: [[@LINE-2]]:2: warning: invalid instruction encoding
+[0x41,0x0c,0xc0,0x11]
+# CHECK:   smaxw1, w2, #3
+# NO-V94A-ERR: [[@LINE-2]]:2: warning: invalid instruction encoding
+[0x41,0x68,0xc3,0x9a]
+# CHECK

[PATCH] D138488: [AArch64][clang] implement 2022 General Data-Processing instructions

2022-11-22 Thread Ties Stuij via Phabricator via cfe-commits
stuij added inline comments.



Comment at: llvm/lib/Target/AArch64/AArch64InstrFormats.td:11725
+: BaseTwoOperandRegReg,
+  Sched<[]> {
+  let Inst{11} = isMin;

dmgreen wrote:
> Can we make this WriteI, maybe. I think that would probably be the closest 
> sched class.
I'm assuming you meant WriteLD.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D138488/new/

https://reviews.llvm.org/D138488

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D138488: [AArch64][clang] implement 2022 General Data-Processing instructions

2022-11-22 Thread Dave Green via Phabricator via cfe-commits
dmgreen added inline comments.



Comment at: llvm/lib/Target/AArch64/AArch64InstrFormats.td:11725
+: BaseTwoOperandRegReg,
+  Sched<[]> {
+  let Inst{11} = isMin;

stuij wrote:
> dmgreen wrote:
> > Can we make this WriteI, maybe. I think that would probably be the closest 
> > sched class.
> I'm assuming you meant WriteLD.
That would be a Load I believe. There are the min/max instructions?  I think 
"simple ALU instruction" should be the closest match, which would be WriteI


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D138488/new/

https://reviews.llvm.org/D138488

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D137232: [clang][Interp] Support inc/dec operators on pointers

2022-11-22 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman accepted this revision.
aaron.ballman added a comment.
This revision is now accepted and ready to land.

LGTM!


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D137232/new/

https://reviews.llvm.org/D137232

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] cdfb65e - [Clang][Sema] Added space after ',' in a warning

2022-11-22 Thread Egor Zhdan via cfe-commits

Author: Fahad Nayyar
Date: 2022-11-22T13:26:40Z
New Revision: cdfb65e5e7182a02005b3611aa28288890b9e296

URL: 
https://github.com/llvm/llvm-project/commit/cdfb65e5e7182a02005b3611aa28288890b9e296
DIFF: 
https://github.com/llvm/llvm-project/commit/cdfb65e5e7182a02005b3611aa28288890b9e296.diff

LOG: [Clang][Sema] Added space after ',' in a warning

This change fixes a typo in a warning message.

rdar://79707705

Added: 


Modified: 
clang/include/clang/Basic/DiagnosticSemaKinds.td
clang/test/SemaObjC/atomic-property-synthesis-rules.m

Removed: 




diff  --git a/clang/include/clang/Basic/DiagnosticSemaKinds.td 
b/clang/include/clang/Basic/DiagnosticSemaKinds.td
index ab06c1fea215..9678fd58b997 100644
--- a/clang/include/clang/Basic/DiagnosticSemaKinds.td
+++ b/clang/include/clang/Basic/DiagnosticSemaKinds.td
@@ -1326,7 +1326,7 @@ def warn_atomic_property_rule : Warning<
   "with a user defined %select{getter|setter}2">,
   InGroup>;
 def note_atomic_property_fixup_suggest : Note<"setter and getter must both be "
-  "synthesized, or both be user defined,or the property must be nonatomic">;
+  "synthesized, or both be user defined, or the property must be nonatomic">;
 def err_atomic_property_nontrivial_assign_op : Error<
   "atomic property of reference type %0 cannot have non-trivial assignment"
   " operator">;

diff  --git a/clang/test/SemaObjC/atomic-property-synthesis-rules.m 
b/clang/test/SemaObjC/atomic-property-synthesis-rules.m
index c7fac7b61811..c7f023e474f5 100644
--- a/clang/test/SemaObjC/atomic-property-synthesis-rules.m
+++ b/clang/test/SemaObjC/atomic-property-synthesis-rules.m
@@ -108,7 +108,7 @@ @interface Foo
 // read-write - might warn
 @property int GetSet;
 @property int Get; // expected-note {{property declared here}} \
-// expected-note {{setter and getter must both be 
synthesized}}
+// expected-note {{setter and getter must both be 
synthesized, or both be user defined, or the property must be nonatomic}}
 @property int Set; // expected-note {{property declared here}} \
 // expected-note {{setter and getter must both be 
synthesized}}
 @property int None;



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D138434: [Clang][Sema] Added space after ',' in a warning

2022-11-22 Thread Egor Zhdan via Phabricator via cfe-commits
egorzhdan closed this revision.
egorzhdan added a comment.

Merged: https://reviews.llvm.org/rGcdfb65e5e7182a02005b3611aa28288890b9e296


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D138434/new/

https://reviews.llvm.org/D138434

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D138488: [AArch64][clang] implement 2022 General Data-Processing instructions

2022-11-22 Thread Ties Stuij via Phabricator via cfe-commits
stuij updated this revision to Diff 477146.
stuij added a comment.

addressed review comment


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D138488/new/

https://reviews.llvm.org/D138488

Files:
  clang/test/Driver/aarch64-cssc.c
  llvm/include/llvm/Support/AArch64TargetParser.def
  llvm/include/llvm/Support/AArch64TargetParser.h
  llvm/lib/Target/AArch64/AArch64.td
  llvm/lib/Target/AArch64/AArch64InstrFormats.td
  llvm/lib/Target/AArch64/AArch64InstrInfo.td
  llvm/lib/Target/AArch64/AArch64SystemOperands.td
  llvm/lib/Target/AArch64/AsmParser/AArch64AsmParser.cpp
  llvm/lib/Target/AArch64/Disassembler/AArch64Disassembler.cpp
  llvm/lib/Target/AArch64/MCTargetDesc/AArch64InstPrinter.cpp
  llvm/lib/Target/AArch64/MCTargetDesc/AArch64InstPrinter.h
  llvm/lib/Target/AArch64/SVEInstrFormats.td
  llvm/lib/Target/AArch64/Utils/AArch64BaseInfo.cpp
  llvm/lib/Target/AArch64/Utils/AArch64BaseInfo.h
  llvm/test/MC/AArch64/CSSC/abs_32.s
  llvm/test/MC/AArch64/CSSC/abs_64.s
  llvm/test/MC/AArch64/CSSC/cnt_32.s
  llvm/test/MC/AArch64/CSSC/cnt_64.s
  llvm/test/MC/AArch64/CSSC/ctz_32.s
  llvm/test/MC/AArch64/CSSC/ctz_64.s
  llvm/test/MC/AArch64/CSSC/smax_32_imm.s
  llvm/test/MC/AArch64/CSSC/smax_32_reg.s
  llvm/test/MC/AArch64/CSSC/smax_64_imm.s
  llvm/test/MC/AArch64/CSSC/smax_64_reg.s
  llvm/test/MC/AArch64/CSSC/smin_32_imm.s
  llvm/test/MC/AArch64/CSSC/smin_32_reg.s
  llvm/test/MC/AArch64/CSSC/smin_64_imm.s
  llvm/test/MC/AArch64/CSSC/smin_64_reg.s
  llvm/test/MC/AArch64/CSSC/umax_32_imm.s
  llvm/test/MC/AArch64/CSSC/umax_32_reg.s
  llvm/test/MC/AArch64/CSSC/umax_64_imm.s
  llvm/test/MC/AArch64/CSSC/umax_64_reg.s
  llvm/test/MC/AArch64/CSSC/umin_32_imm.s
  llvm/test/MC/AArch64/CSSC/umin_32_reg.s
  llvm/test/MC/AArch64/CSSC/umin_64_imm.s
  llvm/test/MC/AArch64/CSSC/umin_64_reg.s
  llvm/test/MC/AArch64/armv8.9a-v94-dp.s
  llvm/test/MC/AArch64/rprfm.s
  llvm/test/MC/Disassembler/AArch64/armv8.9a-v94-dp.txt
  llvm/unittests/Support/TargetParserTest.cpp

Index: llvm/unittests/Support/TargetParserTest.cpp
===
--- llvm/unittests/Support/TargetParserTest.cpp
+++ llvm/unittests/Support/TargetParserTest.cpp
@@ -1606,7 +1606,7 @@
   AArch64::AEK_SME, AArch64::AEK_SMEF64F64, AArch64::AEK_SMEI16I64,
   AArch64::AEK_SME2,AArch64::AEK_HBC,  AArch64::AEK_MOPS,
   AArch64::AEK_PERFMON, AArch64::AEK_SVE2p1,   AArch64::AEK_SME2p1,
-  AArch64::AEK_B16B16,  AArch64::AEK_SMEF16F16};
+  AArch64::AEK_B16B16,  AArch64::AEK_SMEF16F16, AArch64::AEK_CSSC};
 
   std::vector Features;
 
@@ -1671,6 +1671,7 @@
   EXPECT_TRUE(llvm::is_contained(Features, "+hbc"));
   EXPECT_TRUE(llvm::is_contained(Features, "+mops"));
   EXPECT_TRUE(llvm::is_contained(Features, "+perfmon"));
+  EXPECT_TRUE(llvm::is_contained(Features, "+cssc"));
 
   // Assuming we listed every extension above, this should produce the same
   // result. (note that AEK_NONE doesn't have a name so it won't be in the
Index: llvm/test/MC/Disassembler/AArch64/armv8.9a-v94-dp.txt
===
--- /dev/null
+++ llvm/test/MC/Disassembler/AArch64/armv8.9a-v94-dp.txt
@@ -0,0 +1,72 @@
+# RUN: llvm-mc -triple aarch64-none-linux-gnu -disassemble -mattr=+v9.4a < %s  | FileCheck %s
+# RUN: not llvm-mc -triple aarch64-none-linux-gnu -disassemble -mattr=+v8.8a < %s 2>&1 | FileCheck --check-prefix=NO-V94A-ERR %s
+# RUN: llvm-mc -triple aarch64-none-linux-gnu -disassemble -mattr=+v8.9a < %s  | FileCheck %s
+# RUN: not llvm-mc -triple aarch64-none-linux-gnu -disassemble -mattr=+v9.3a < %s 2>&1 | FileCheck --check-prefix=NO-V94A-ERR %s
+
+[0x20,0x20,0xc0,0xda]
+# CHECK:   abs x0, x1
+# NO-V94A-ERR: [[@LINE-2]]:2: warning: invalid instruction encoding
+[0x20,0x20,0xc0,0x5a]
+# CHECK:   abs w0, w1
+# NO-V94A-ERR: [[@LINE-2]]:2: warning: invalid instruction encoding
+[0x20,0x1c,0xc0,0xda]
+# CHECK:   cnt x0, x1
+# NO-V94A-ERR: [[@LINE-2]]:2: warning: invalid instruction encoding
+[0x20,0x1c,0xc0,0x5a]
+# CHECK:   cnt w0, w1
+# NO-V94A-ERR: [[@LINE-2]]:2: warning: invalid instruction encoding
+[0x20,0x18,0xc0,0xda]
+# CHECK:   ctz x0, x1
+# NO-V94A-ERR: [[@LINE-2]]:2: warning: invalid instruction encoding
+[0x20,0x18,0xc0,0x5a]
+# CHECK:   ctz w0, w1
+# NO-V94A-ERR: [[@LINE-2]]:2: warning: invalid instruction encoding
+
+[0x41,0x60,0xc3,0x9a]
+# CHECK:   smaxx1, x2, x3
+# NO-V94A-ERR: [[@LINE-2]]:2: warning: invalid instruction encoding
+[0x41,0x0c,0xc0,0x91]
+# CHECK:   smaxx1, x2, #3
+# NO-V94A-ERR: [[@LINE-2]]:2: warning: invalid instruction encoding
+[0x41,0x60,0xc3,0x1a]
+# CHECK:   smaxw1, w2, w3
+# NO-V94A-ERR: [[@LINE-2]]:2: warning: invalid instruction encoding
+[0x41,0x0c,0xc0,0x11]
+# CHECK:   smaxw1, w2, #3
+# NO-V94A-ERR: [[@LINE-2]]:2: warning: invalid instruction encoding
+[0x41,0x68,0xc3,0x9a]
+# CHECK:   sminx1, x2, x3
+# NO-V94A-ERR: [[

[PATCH] D138488: [AArch64][clang] implement 2022 General Data-Processing instructions

2022-11-22 Thread Ties Stuij via Phabricator via cfe-commits
stuij marked an inline comment as done.
stuij added inline comments.



Comment at: llvm/lib/Target/AArch64/AArch64InstrFormats.td:11725
+: BaseTwoOperandRegReg,
+  Sched<[]> {
+  let Inst{11} = isMin;

dmgreen wrote:
> stuij wrote:
> > dmgreen wrote:
> > > Can we make this WriteI, maybe. I think that would probably be the 
> > > closest sched class.
> > I'm assuming you meant WriteLD.
> That would be a Load I believe. There are the min/max instructions?  I think 
> "simple ALU instruction" should be the closest match, which would be WriteI
ah right, sorry misread your comment.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D138488/new/

https://reviews.llvm.org/D138488

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D138489: [tsan] Add tsan support for loongarch64

2022-11-22 Thread Lu Weining via Phabricator via cfe-commits
SixWeining added a comment.

I haven't check the correctness of `tsan_rtl_loongarch64.S`.




Comment at: compiler-rt/lib/sanitizer_common/sanitizer_linux.cpp:1513
+
+  register int res __asm__("$a0");
+  register int __flags __asm__("$a0") = flags;

I'm not sure if this is necessary. Maybe `int res;` is enough?



Comment at: compiler-rt/lib/sanitizer_common/sanitizer_linux.cpp:1543
+"r"(__fn), "r"(__arg), "r"(nr_clone), "i"(__NR_exit)
+  : "memory");
+  return res;

Shall we list $t0-$t8 here? Ref D137396.



Comment at: compiler-rt/lib/sanitizer_common/sanitizer_linux.h:80
 void internal_sigdelset(__sanitizer_sigset_t *set, int signum);
-#if defined(__x86_64__) || defined(__mips__) || defined(__aarch64__) || \
-defined(__powerpc64__) || defined(__s390__) || defined(__i386__) || \
-defined(__arm__) || SANITIZER_RISCV64
+#if defined(__x86_64__) || defined(__mips__) || defined(__aarch64__) || \
+defined(__powerpc64__) || defined(__s390__) || defined(__i386__) || \

May be it's better to keep original indention. Otherwise the paired `#endif` 
doesn't look good.



Comment at: compiler-rt/test/sanitizer_common/print_address.h:12
+defined(__s390x__) || (defined(__riscv) && __riscv_xlen == 64) ||  
\
+defined(__loongarch__)
 // On FreeBSD, the %p conversion specifier works as 0x%x and thus does not

Should be __loongarch64?



Comment at: compiler-rt/test/tsan/mmap_large.cpp:20
   const size_t kLog2Size = 39;
-#elif defined(__mips64) || defined(__aarch64__)
+#elif defined(__mips64) || defined(__aarch64__) || defined(__loongarch__)
   const size_t kLog2Size = 32;

Should be __loongarch64?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D138489/new/

https://reviews.llvm.org/D138489

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D135750: [clang][Interp] Track initialization state of local variables

2022-11-22 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added inline comments.



Comment at: clang/lib/AST/Interp/ByteCodeExprGen.cpp:749-751
+  const Descriptor::MetadataSize MDSize{sizeof(InlineDescriptor)};
+  Descriptor *D =
+  P.createDescriptor(Src, Ty, MDSize, IsConst, Src.is());

tbaeder wrote:
> aaron.ballman wrote:
> > tbaeder wrote:
> > > erichkeane wrote:
> > > > aaron.ballman wrote:
> > > > > Double checking that `Src.is()` is correct here. That's 
> > > > > being passed as the `IsTemporary` argument. I presume the logic is 
> > > > > that if the decl type is an expression then it has to be a temporary, 
> > > > > but that's not entirely true. Consider C where a compound literal is 
> > > > > *not* a temporary but actually creates an lvalue: `(int){12}`. Will 
> > > > > that be an issue?
> > > > See suggested comment below in InterpBlock.
> > > That interpretation is correct and I don't know what to do about compound 
> > > literals yet.
> > My intuition is that `IsTemporary` should be set from 
> > `Expr::isTemporaryObject()` (or isa `MaterializeTemporaryExpr` maybe).
> > 
> > At the very least, you can add a .c test file with a compound literal in a 
> > _Static_assert and a FIXME comment (in the test and here in the code).
> > 
> The `Src.is<>` is not a change introduced by this patch though.
> 
> As for a test, it'll just be rejected because we don't implement visiting 
> `CompoundLiteral`s at all right now.
> The Src.is<> is not a change introduced by this patch though.

Then let's add a FIXME comment to remember to come back to look into this (I'm 
not convinced it was correct to begin with, but it is kind of orthogonal to 
this patch too).

> As for a test, it'll just be rejected because we don't implement visiting 
> CompoundLiterals at all right now.

Fair!



Comment at: clang/lib/AST/Interp/Descriptor.h:72
+  struct MetadataSize {
+size_t NumBytes;
+  };

I think this should use `InterpSize` rather than `size_t` given that it's used 
to assign into `MDSize`



Comment at: clang/lib/AST/Interp/Descriptor.h:141-145
   unsigned getAllocSize() const { return AllocSize; }
   /// returns the size of an element when the structure is viewed as an array.
   unsigned getElemSize()  const { return ElemSize; }
+  /// Returns the size of the metadata.
+  unsigned getMetadataSize() const { return MDSize; }

There's some interface awkwardness here where these values are of type 
`InterpSize` but the interface returns `unsigned`



Comment at: clang/lib/AST/Interp/Descriptor.h:74
+  };
+  static constexpr MetadataSize NoMetadata = MetadataSize{0};
+

aaron.ballman wrote:
> tbaeder wrote:
> > tbaeder wrote:
> > > shafik wrote:
> > > > erichkeane wrote:
> > > > > add a line: 
> > > > > `static constexpr MetadataSize InlineDescriptor = 
> > > > > MetadataSize{sizeof(InlineDescriptor)};` 
> > > > > and you can use this instead of depending on 'sizeof' all over the 
> > > > > place.
> > > > It feels weird to call this `NoMetadata` but we will pass this as an 
> > > > argument to a function with a parameter of `MetaDataSize`. So I am 
> > > > expecting a size but I am getting no meta data instead and it looks 
> > > > like a mistake. 
> > > > 
> > > > Maybe a better name would be `ZeroMetaDataSize`?
> > > I kinda get what your point is, but I don't think this is confusing.
> > I'm a bit concerned about the naming here; `InlineDescriptor` is already a 
> > type name, but calling it `MetadataSizeInlineDesc` is pretty long and 
> > callers already have to prepend a `Descriptor::` to that. :/
> Rather than using a sentinel value, should we be using `Optional`?
I'm still wondering if `Optional` is cleaner than `NoMetadata`...



Comment at: clang/lib/AST/Interp/InterpBlock.h:77-86
+  char *data() {
+// Data might contain metadata as well.
+size_t DataOffset = Desc->getMetadataSize();
+return reinterpret_cast(reinterpret_cast(this) +
+sizeof(Block) + DataOffset);
+  }
+

tbaeder wrote:
> aaron.ballman wrote:
> > tbaeder wrote:
> > > aaron.ballman wrote:
> > > > Should we have `const`-correct overloads to provide read-only access?
> > > IIRC I added that at least once in a different patch but I abandoned that 
> > > and haven't had a use for a const overload since.
> > My worry is that retrofitting const correctness will eventually become too 
> > much of a chore and so we'll be adding yet another const-incorrect 
> > interface to the compiler. Seeing as how this is being reworked from 
> > scratch, I think we should use the opportunity to get better 
> > const-correctness, but maybe that ship has sailed?
> I don't think the ship has sailed at all. Is your argument that the function 
> should be `const` because it can be? It's slightly problematic because they 
> end up returning `const char *` as well. I can add the two overloads without 

[PATCH] D136457: [clang][Interp] Fix discarding non-primitive function call return values

2022-11-22 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman accepted this revision.
aaron.ballman added a comment.
This revision is now accepted and ready to land.

LGTM!


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D136457/new/

https://reviews.llvm.org/D136457

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D137392: [clang][Interp] Explicitly handle RVO Pointer

2022-11-22 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman accepted this revision.
aaron.ballman added a comment.
This revision is now accepted and ready to land.

LGTM!


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D137392/new/

https://reviews.llvm.org/D137392

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D138491: [clangd] Add script to maintain list of fast clang-tidy checks

2022-11-22 Thread Sam McCall via Phabricator via cfe-commits
sammccall created this revision.
sammccall added a reviewer: kadircet.
Herald added subscribers: abrachet, phosek, arphaman.
Herald added a reviewer: njames93.
Herald added a project: All.
sammccall requested review of this revision.
Herald added subscribers: cfe-commits, sstefan1, MaskRay, ilya-biryukov.
Herald added a reviewer: jdoerfert.
Herald added a project: clang-tools-extra.

The plan is to intersect this list with the checks selected per config.
This is not yet done, but the initial list is checked in as a baseline.

https://github.com/clangd/clangd/issues/1337


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D138491

Files:
  clang-tools-extra/clangd/TidyFastChecks.inc
  clang-tools-extra/clangd/TidyFastChecks.py
  clang-tools-extra/clangd/tool/Check.cpp

Index: clang-tools-extra/clangd/tool/Check.cpp
===
--- clang-tools-extra/clangd/tool/Check.cpp
+++ clang-tools-extra/clangd/tool/Check.cpp
@@ -241,6 +241,9 @@
 elog("-{0} requires -DCLANGD_TIDY_CHECKS!", CheckTidyTime.ArgStr);
 return false;
   }
+  #ifndef NDEBUG
+  elog("Timing clang-tidy checks in asserts-mode is not representative!");
+  #endif
   checkTidyTimes();
 }
 
Index: clang-tools-extra/clangd/TidyFastChecks.py
===
--- /dev/null
+++ clang-tools-extra/clangd/TidyFastChecks.py
@@ -0,0 +1,88 @@
+#!/usr/bin/env python3
+#
+# Determines which clang-tidy checks are "fast enough" to run in clangd.
+# This runs clangd --check --check-tidy-time and parses the output.
+# This program outputs a header fragment specifying which checks are fast:
+#   FAST(bugprone-argument-comment, 5)
+#   SLOW(misc-const-correctness, 200)
+# If given the old header fragment as input, we lean to preserve its choices.
+#
+# This is not deterministic or hermetic, but should be run occasionally to
+# update the list of allowed checks. From llvm-project:
+#   clang-tools-extra/clangd/TidyFastChecks.py \
+# --clangd=build-opt/bin/clangd \
+# > clang-tools-extra/clangd/TidyFastChecks.inc
+# Be sure to use an optimized, no-asserts, tidy-enabled build of clangd!
+
+import argparse
+import re
+import subprocess
+import sys
+
+# Checks faster than FAST_THRESHOLD are fast, slower than SLOW_THRESHOLD slow.
+# If a check is in between, we stick with our previous decision. This avoids
+# enabling/disabling checks between releases due to random measurement jitter.
+FAST_THRESHOLD = 8 # percent
+SLOW_THRESHOLD = 15
+
+parser = argparse.ArgumentParser()
+parser.add_argument('--old', help='Existing TidyFastChecks.inc, for hysteresis',
+default='clang-tools-extra/clangd/TidyFastChecks.inc')
+parser.add_argument('--file', help='clangd binary to invoke',
+default='clang/lib/Sema/Sema.cpp')
+parser.add_argument('--clangd', help='clangd binary to invoke',
+default='build/bin/clangd')
+parser.add_argument('--checks', help='check glob to run', default='*')
+parser.add_argument('--verbose', help='log clangd output', action='store_true')
+args = parser.parse_args()
+
+# Use the preprocessor to extract the list of previously-fast checks.
+def read_old_fast(path):
+text = subprocess.check_output(["cpp", "-P", "-FAST(C,T)=C", path])
+for line in text.splitlines():
+if line.strip():
+yield line.strip().decode('utf-8')
+old_fast = list(read_old_fast(args.old)) if args.old else []
+print(f"Old fast checks: {old_fast}", file=sys.stderr)
+
+# Runs clangd --check --check-tidy-time.
+# Yields (check, percent-overhead) pairs.
+def measure():
+process = subprocess.Popen([args.clangd,
+"--check=" + args.file, "--check-locations=0", "--check-tidy-time=" + args.checks],
+stderr=subprocess.PIPE)
+recording = False
+for line in iter(process.stderr.readline, b""):
+if args.verbose:
+print("clangd> ", line, file=sys.stderr)
+if not recording:
+if b'Timing AST build with individual clang-tidy checks' in line:  
+   recording = True
+continue
+if b'Finished individual clang-tidy checks' in line:
+return
+match = re.search(rb'(\S+) = (\S+)%', line)
+if match:
+yield (match.group(1).decode('utf-8'), float(match.group(2)))
+
+# Produce an includable X-macros fragment with our decisions.
+print("""// This file is generated, do not edit it directly!
+// This describes 
+#ifndef FAST
+#define FAST(CHECK, DELTA)
+#endif
+#ifndef SLOW
+#define SLOW(CHECK, DELTA)
+#endif
+""")
+
+for check, time in measure():
+threshold = SLOW_THRESHOLD if check in old_fast else FAST_THRESHOLD
+decision = "FAST" if time <= threshold else "SLOW"
+print(f"{decision} {check} {time}% <= {threshold}%", file=sys.stderr)
+print(f"{decision}({check}, {time})")
+
+print("""
+#undef FAST
+#undef SLOW
+""")
Index: clang-tools-extra/clangd/TidyFastChecks.inc
===

[PATCH] D138418: [LoongArch] Add remaining intrinsics for CRC check instructions

2022-11-22 Thread Lu Weining via Phabricator via cfe-commits
SixWeining added inline comments.



Comment at: llvm/lib/Target/LoongArch/LoongArchISelLowering.cpp:925-933
+case Intrinsic::loongarch_crc_w_b_w: {
+  Results.push_back(DAG.getNode(
+  ISD::TRUNCATE, DL, VT,
+  DAG.getNode(LoongArchISD::CRC_W_B_W, DL, MVT::i64,
+  DAG.getNode(ISD::ANY_EXTEND, DL, MVT::i64, Op2),
+  DAG.getNode(ISD::ANY_EXTEND, DL, MVT::i64, Op3;
+  Results.push_back(N->getOperand(0));

Can we define a marco but not repeating similar codes?
For example:
```
#define CRC_CASE(NAME, ISD) \
case Intrinsic::loongarch_#NAME: { \
  Results.push_back(DAG.getNode( \
  ISD::TRUNCATE, DL, VT, \
  DAG.getNode(LoongArchISD::#ISD, DL, MVT::i64, \
  DAG.getNode(ISD::ANY_EXTEND, DL, MVT::i64, Op2), \
  DAG.getNode(ISD::ANY_EXTEND, DL, MVT::i64, Op3; \
  Results.push_back(N->getOperand(0)); \
  break; \
}
```

Then
```
CRC_CASE(crc_w_b_w, CRC_W_B_W)
```


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D138418/new/

https://reviews.llvm.org/D138418

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D138488: [AArch64][clang] implement 2022 General Data-Processing instructions

2022-11-22 Thread Ties Stuij via Phabricator via cfe-commits
stuij updated this revision to Diff 477156.
stuij marked an inline comment as done.
stuij added a comment.

renamed *v94-dp* to *cssc*


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D138488/new/

https://reviews.llvm.org/D138488

Files:
  clang/test/Driver/aarch64-cssc.c
  llvm/include/llvm/Support/AArch64TargetParser.def
  llvm/include/llvm/Support/AArch64TargetParser.h
  llvm/lib/Target/AArch64/AArch64.td
  llvm/lib/Target/AArch64/AArch64InstrFormats.td
  llvm/lib/Target/AArch64/AArch64InstrInfo.td
  llvm/lib/Target/AArch64/AArch64SystemOperands.td
  llvm/lib/Target/AArch64/AsmParser/AArch64AsmParser.cpp
  llvm/lib/Target/AArch64/Disassembler/AArch64Disassembler.cpp
  llvm/lib/Target/AArch64/MCTargetDesc/AArch64InstPrinter.cpp
  llvm/lib/Target/AArch64/MCTargetDesc/AArch64InstPrinter.h
  llvm/lib/Target/AArch64/SVEInstrFormats.td
  llvm/lib/Target/AArch64/Utils/AArch64BaseInfo.cpp
  llvm/lib/Target/AArch64/Utils/AArch64BaseInfo.h
  llvm/test/MC/AArch64/CSSC/abs_32.s
  llvm/test/MC/AArch64/CSSC/abs_64.s
  llvm/test/MC/AArch64/CSSC/cnt_32.s
  llvm/test/MC/AArch64/CSSC/cnt_64.s
  llvm/test/MC/AArch64/CSSC/ctz_32.s
  llvm/test/MC/AArch64/CSSC/ctz_64.s
  llvm/test/MC/AArch64/CSSC/smax_32_imm.s
  llvm/test/MC/AArch64/CSSC/smax_32_reg.s
  llvm/test/MC/AArch64/CSSC/smax_64_imm.s
  llvm/test/MC/AArch64/CSSC/smax_64_reg.s
  llvm/test/MC/AArch64/CSSC/smin_32_imm.s
  llvm/test/MC/AArch64/CSSC/smin_32_reg.s
  llvm/test/MC/AArch64/CSSC/smin_64_imm.s
  llvm/test/MC/AArch64/CSSC/smin_64_reg.s
  llvm/test/MC/AArch64/CSSC/umax_32_imm.s
  llvm/test/MC/AArch64/CSSC/umax_32_reg.s
  llvm/test/MC/AArch64/CSSC/umax_64_imm.s
  llvm/test/MC/AArch64/CSSC/umax_64_reg.s
  llvm/test/MC/AArch64/CSSC/umin_32_imm.s
  llvm/test/MC/AArch64/CSSC/umin_32_reg.s
  llvm/test/MC/AArch64/CSSC/umin_64_imm.s
  llvm/test/MC/AArch64/CSSC/umin_64_reg.s
  llvm/test/MC/AArch64/armv8.9a-cssc.s
  llvm/test/MC/AArch64/rprfm.s
  llvm/test/MC/Disassembler/AArch64/armv8.9a-cssc.txt
  llvm/unittests/Support/TargetParserTest.cpp

Index: llvm/unittests/Support/TargetParserTest.cpp
===
--- llvm/unittests/Support/TargetParserTest.cpp
+++ llvm/unittests/Support/TargetParserTest.cpp
@@ -1606,7 +1606,7 @@
   AArch64::AEK_SME, AArch64::AEK_SMEF64F64, AArch64::AEK_SMEI16I64,
   AArch64::AEK_SME2,AArch64::AEK_HBC,  AArch64::AEK_MOPS,
   AArch64::AEK_PERFMON, AArch64::AEK_SVE2p1,   AArch64::AEK_SME2p1,
-  AArch64::AEK_B16B16,  AArch64::AEK_SMEF16F16};
+  AArch64::AEK_B16B16,  AArch64::AEK_SMEF16F16, AArch64::AEK_CSSC};
 
   std::vector Features;
 
@@ -1671,6 +1671,7 @@
   EXPECT_TRUE(llvm::is_contained(Features, "+hbc"));
   EXPECT_TRUE(llvm::is_contained(Features, "+mops"));
   EXPECT_TRUE(llvm::is_contained(Features, "+perfmon"));
+  EXPECT_TRUE(llvm::is_contained(Features, "+cssc"));
 
   // Assuming we listed every extension above, this should produce the same
   // result. (note that AEK_NONE doesn't have a name so it won't be in the
Index: llvm/test/MC/Disassembler/AArch64/armv8.9a-cssc.txt
===
--- /dev/null
+++ llvm/test/MC/Disassembler/AArch64/armv8.9a-cssc.txt
@@ -0,0 +1,72 @@
+# RUN: llvm-mc -triple aarch64-none-linux-gnu -disassemble -mattr=+v9.4a < %s  | FileCheck %s
+# RUN: not llvm-mc -triple aarch64-none-linux-gnu -disassemble -mattr=+v8.8a < %s 2>&1 | FileCheck --check-prefix=NO-V94A-ERR %s
+# RUN: llvm-mc -triple aarch64-none-linux-gnu -disassemble -mattr=+v8.9a < %s  | FileCheck %s
+# RUN: not llvm-mc -triple aarch64-none-linux-gnu -disassemble -mattr=+v9.3a < %s 2>&1 | FileCheck --check-prefix=NO-V94A-ERR %s
+
+[0x20,0x20,0xc0,0xda]
+# CHECK:   abs x0, x1
+# NO-V94A-ERR: [[@LINE-2]]:2: warning: invalid instruction encoding
+[0x20,0x20,0xc0,0x5a]
+# CHECK:   abs w0, w1
+# NO-V94A-ERR: [[@LINE-2]]:2: warning: invalid instruction encoding
+[0x20,0x1c,0xc0,0xda]
+# CHECK:   cnt x0, x1
+# NO-V94A-ERR: [[@LINE-2]]:2: warning: invalid instruction encoding
+[0x20,0x1c,0xc0,0x5a]
+# CHECK:   cnt w0, w1
+# NO-V94A-ERR: [[@LINE-2]]:2: warning: invalid instruction encoding
+[0x20,0x18,0xc0,0xda]
+# CHECK:   ctz x0, x1
+# NO-V94A-ERR: [[@LINE-2]]:2: warning: invalid instruction encoding
+[0x20,0x18,0xc0,0x5a]
+# CHECK:   ctz w0, w1
+# NO-V94A-ERR: [[@LINE-2]]:2: warning: invalid instruction encoding
+
+[0x41,0x60,0xc3,0x9a]
+# CHECK:   smaxx1, x2, x3
+# NO-V94A-ERR: [[@LINE-2]]:2: warning: invalid instruction encoding
+[0x41,0x0c,0xc0,0x91]
+# CHECK:   smaxx1, x2, #3
+# NO-V94A-ERR: [[@LINE-2]]:2: warning: invalid instruction encoding
+[0x41,0x60,0xc3,0x1a]
+# CHECK:   smaxw1, w2, w3
+# NO-V94A-ERR: [[@LINE-2]]:2: warning: invalid instruction encoding
+[0x41,0x0c,0xc0,0x11]
+# CHECK:   smaxw1, w2, #3
+# NO-V94A-ERR: [[@LINE-2]]:2: warning: invalid instruction encoding
+[0x41,0x68,0xc3,0x9a]
+# CHECK:   smi

[PATCH] D138488: [AArch64][clang] implement 2022 General Data-Processing instructions

2022-11-22 Thread Ties Stuij via Phabricator via cfe-commits
stuij marked an inline comment as done.
stuij added inline comments.



Comment at: llvm/lib/Target/AArch64/AArch64InstrFormats.td:11698
+//---
+// 2022 Architecture Extensions: General Data Processing (FEAT_V94_DP)
+//---

tschuett wrote:
> FEAT_CSSC or FEAT_V94_DP?
Yes, should be FEAT_CSSC. Thanks!


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D138488/new/

https://reviews.llvm.org/D138488

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D138489: [tsan] Add tsan support for loongarch64

2022-11-22 Thread Xi Ruoyao via Phabricator via cfe-commits
xry111 added inline comments.



Comment at: compiler-rt/lib/sanitizer_common/sanitizer_linux.h:80
 void internal_sigdelset(__sanitizer_sigset_t *set, int signum);
-#if defined(__x86_64__) || defined(__mips__) || defined(__aarch64__) || \
-defined(__powerpc64__) || defined(__s390__) || defined(__i386__) || \
-defined(__arm__) || SANITIZER_RISCV64
+#if defined(__x86_64__) || defined(__mips__) || defined(__aarch64__) || \
+defined(__powerpc64__) || defined(__s390__) || defined(__i386__) || \

SixWeining wrote:
> May be it's better to keep original indention. Otherwise the paired `#endif` 
> doesn't look good.
The problem is `git clang-format` sometimes insist you to change the 
indentation...



Comment at: compiler-rt/test/sanitizer_common/print_address.h:12
+defined(__s390x__) || (defined(__riscv) && __riscv_xlen == 64) ||  
\
+defined(__loongarch__)
 // On FreeBSD, the %p conversion specifier works as 0x%x and thus does not

SixWeining wrote:
> Should be __loongarch64?
`__loongarch64` is deprecated, use `__loongarch_lp64` instead.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D138489/new/

https://reviews.llvm.org/D138489

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D138488: [AArch64][clang] implement 2022 General Data-Processing instructions

2022-11-22 Thread Dave Green via Phabricator via cfe-commits
dmgreen accepted this revision.
dmgreen added a comment.

Thanks. I haven't looked though all the details, but thanks for fixing the 
scheduling info.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D138488/new/

https://reviews.llvm.org/D138488

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D137706: [clang][Interp] Implement IntegralToPointer casts

2022-11-22 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added a comment.

I'd expect more test coverage for these changes. Like a C-style cast and a 
reinterpret_cast in C++ code


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D137706/new/

https://reviews.llvm.org/D137706

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D137044: [ClangFE] Add support for option -mno-pic-data-is-text-relative

2022-11-22 Thread Jonas Paulsson via Phabricator via cfe-commits
jonpa added a comment.

In D137044#3942990 , @pcwang-thead 
wrote:

> The test `clang/test/Driver/pic.c` failed when we compiled Clang/LLVM with 
> `-DCLANG_DEFAULT_PIE_ON_LINUX=False`.

Ah... I suppose that must be because -mno-pic-data-is-text-relative requires 
PIC (this is per GCC behavior). Does it help if you add -fpic to the RUN lines 
that were added by this patch? I was not aware of the cmake flag, sorry.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D137044/new/

https://reviews.llvm.org/D137044

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D137948: [clang][dataflow] Add widening API and implement it for built-in boolean model.

2022-11-22 Thread Yitzhak Mandelbaum via Phabricator via cfe-commits
ymandel added a comment.

Does anyone else on this review thread want to review? Gabor's accepted the 
revision so, if not, I'll go ahead and commit.
thx


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D137948/new/

https://reviews.llvm.org/D137948

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] ac84798 - [scudo] Add loongarch64 support for scudo

2022-11-22 Thread Weining Lu via cfe-commits

Author: Youling Tang
Date: 2022-11-22T22:02:31+08:00
New Revision: ac84798570cd480f431005b1ff943ca7070e541c

URL: 
https://github.com/llvm/llvm-project/commit/ac84798570cd480f431005b1ff943ca7070e541c
DIFF: 
https://github.com/llvm/llvm-project/commit/ac84798570cd480f431005b1ff943ca7070e541c.diff

LOG: [scudo] Add loongarch64 support for scudo

Enable scudo on LoongArch64 on both clang side and compiler-rt side.

Reviewed By: SixWeining

Differential Revision: https://reviews.llvm.org/D138350

Added: 


Modified: 
clang/lib/Driver/ToolChains/Linux.cpp
clang/test/Driver/fsanitize.c
compiler-rt/cmake/Modules/AllSupportedArchDefs.cmake

Removed: 




diff  --git a/clang/lib/Driver/ToolChains/Linux.cpp 
b/clang/lib/Driver/ToolChains/Linux.cpp
index 6fc3d7793ec63..66cafb3ceb50d 100644
--- a/clang/lib/Driver/ToolChains/Linux.cpp
+++ b/clang/lib/Driver/ToolChains/Linux.cpp
@@ -749,6 +749,7 @@ SanitizerMask Linux::getSupportedSanitizers() const {
  getTriple().getArch() == llvm::Triple::thumb ||
  getTriple().getArch() == llvm::Triple::armeb ||
  getTriple().getArch() == llvm::Triple::thumbeb;
+  const bool IsLoongArch64 = getTriple().getArch() == 
llvm::Triple::loongarch64;
   const bool IsRISCV64 = getTriple().getArch() == llvm::Triple::riscv64;
   const bool IsSystemZ = getTriple().getArch() == llvm::Triple::systemz;
   const bool IsHexagon = getTriple().getArch() == llvm::Triple::hexagon;
@@ -774,7 +775,7 @@ SanitizerMask Linux::getSupportedSanitizers() const {
   if (IsX86 || IsX86_64)
 Res |= SanitizerKind::Function;
   if (IsX86_64 || IsMIPS64 || IsAArch64 || IsX86 || IsMIPS || IsArmArch ||
-  IsPowerPC64 || IsHexagon)
+  IsPowerPC64 || IsHexagon || IsLoongArch64)
 Res |= SanitizerKind::Scudo;
   if (IsX86_64 || IsAArch64) {
 Res |= SanitizerKind::HWAddress;

diff  --git a/clang/test/Driver/fsanitize.c b/clang/test/Driver/fsanitize.c
index d1254a2e47029..6cf8bfa9be324 100644
--- a/clang/test/Driver/fsanitize.c
+++ b/clang/test/Driver/fsanitize.c
@@ -873,6 +873,7 @@
 // RUN: %clang --target=arm-linux-androideabi -fsanitize=scudo %s -### 2>&1 | 
FileCheck %s --check-prefix=CHECK-SCUDO
 // RUN: %clang --target=x86_64-linux-gnu -fsanitize=scudo %s -### 2>&1 | 
FileCheck %s --check-prefix=CHECK-SCUDO
 // RUN: %clang --target=i386-linux-gnu -fsanitize=scudo %s -### 2>&1 | 
FileCheck %s --check-prefix=CHECK-SCUDO
+// RUN: %clang --target=loongarch64-unknown-linux-gnu -fsanitize=scudo %s -### 
2>&1 | FileCheck %s --check-prefix=CHECK-SCUDO
 // RUN: %clang --target=mips64-unknown-linux-gnu -fsanitize=scudo %s -### 2>&1 
| FileCheck %s --check-prefix=CHECK-SCUDO
 // RUN: %clang --target=mips64el-unknown-linux-gnu -fsanitize=scudo %s -### 
2>&1 | FileCheck %s --check-prefix=CHECK-SCUDO
 // RUN: %clang --target=mips-unknown-linux-gnu -fsanitize=scudo %s -### 2>&1 | 
FileCheck %s --check-prefix=CHECK-SCUDO

diff  --git a/compiler-rt/cmake/Modules/AllSupportedArchDefs.cmake 
b/compiler-rt/cmake/Modules/AllSupportedArchDefs.cmake
index 56507c9576280..006bb8e3cd0f0 100644
--- a/compiler-rt/cmake/Modules/AllSupportedArchDefs.cmake
+++ b/compiler-rt/cmake/Modules/AllSupportedArchDefs.cmake
@@ -68,9 +68,9 @@ set(ALL_SAFESTACK_SUPPORTED_ARCH ${X86} ${X86_64} ${ARM64} 
${MIPS32} ${MIPS64}
 set(ALL_CFI_SUPPORTED_ARCH ${X86} ${X86_64} ${ARM32} ${ARM64} ${MIPS64}
 ${HEXAGON})
 set(ALL_SCUDO_SUPPORTED_ARCH ${X86} ${X86_64} ${ARM32} ${ARM64} ${MIPS32}
-${MIPS64} ${PPC64} ${HEXAGON})
+${MIPS64} ${PPC64} ${HEXAGON} ${LOONGARCH64})
 set(ALL_SCUDO_STANDALONE_SUPPORTED_ARCH ${X86} ${X86_64} ${ARM32} ${ARM64}
-${MIPS32} ${MIPS64} ${PPC64} ${HEXAGON})
+${MIPS32} ${MIPS64} ${PPC64} ${HEXAGON} ${LOONGARCH64})
 if(APPLE)
 set(ALL_XRAY_SUPPORTED_ARCH ${X86_64})
 else()



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D138350: [scudo] Add loongarch64 support for scudo

2022-11-22 Thread Lu Weining via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rGac84798570cd: [scudo] Add loongarch64 support for scudo 
(authored by tangyouling, committed by SixWeining).

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D138350/new/

https://reviews.llvm.org/D138350

Files:
  clang/lib/Driver/ToolChains/Linux.cpp
  clang/test/Driver/fsanitize.c
  compiler-rt/cmake/Modules/AllSupportedArchDefs.cmake


Index: compiler-rt/cmake/Modules/AllSupportedArchDefs.cmake
===
--- compiler-rt/cmake/Modules/AllSupportedArchDefs.cmake
+++ compiler-rt/cmake/Modules/AllSupportedArchDefs.cmake
@@ -68,9 +68,9 @@
 set(ALL_CFI_SUPPORTED_ARCH ${X86} ${X86_64} ${ARM32} ${ARM64} ${MIPS64}
 ${HEXAGON})
 set(ALL_SCUDO_SUPPORTED_ARCH ${X86} ${X86_64} ${ARM32} ${ARM64} ${MIPS32}
-${MIPS64} ${PPC64} ${HEXAGON})
+${MIPS64} ${PPC64} ${HEXAGON} ${LOONGARCH64})
 set(ALL_SCUDO_STANDALONE_SUPPORTED_ARCH ${X86} ${X86_64} ${ARM32} ${ARM64}
-${MIPS32} ${MIPS64} ${PPC64} ${HEXAGON})
+${MIPS32} ${MIPS64} ${PPC64} ${HEXAGON} ${LOONGARCH64})
 if(APPLE)
 set(ALL_XRAY_SUPPORTED_ARCH ${X86_64})
 else()
Index: clang/test/Driver/fsanitize.c
===
--- clang/test/Driver/fsanitize.c
+++ clang/test/Driver/fsanitize.c
@@ -873,6 +873,7 @@
 // RUN: %clang --target=arm-linux-androideabi -fsanitize=scudo %s -### 2>&1 | 
FileCheck %s --check-prefix=CHECK-SCUDO
 // RUN: %clang --target=x86_64-linux-gnu -fsanitize=scudo %s -### 2>&1 | 
FileCheck %s --check-prefix=CHECK-SCUDO
 // RUN: %clang --target=i386-linux-gnu -fsanitize=scudo %s -### 2>&1 | 
FileCheck %s --check-prefix=CHECK-SCUDO
+// RUN: %clang --target=loongarch64-unknown-linux-gnu -fsanitize=scudo %s -### 
2>&1 | FileCheck %s --check-prefix=CHECK-SCUDO
 // RUN: %clang --target=mips64-unknown-linux-gnu -fsanitize=scudo %s -### 2>&1 
| FileCheck %s --check-prefix=CHECK-SCUDO
 // RUN: %clang --target=mips64el-unknown-linux-gnu -fsanitize=scudo %s -### 
2>&1 | FileCheck %s --check-prefix=CHECK-SCUDO
 // RUN: %clang --target=mips-unknown-linux-gnu -fsanitize=scudo %s -### 2>&1 | 
FileCheck %s --check-prefix=CHECK-SCUDO
Index: clang/lib/Driver/ToolChains/Linux.cpp
===
--- clang/lib/Driver/ToolChains/Linux.cpp
+++ clang/lib/Driver/ToolChains/Linux.cpp
@@ -749,6 +749,7 @@
  getTriple().getArch() == llvm::Triple::thumb ||
  getTriple().getArch() == llvm::Triple::armeb ||
  getTriple().getArch() == llvm::Triple::thumbeb;
+  const bool IsLoongArch64 = getTriple().getArch() == 
llvm::Triple::loongarch64;
   const bool IsRISCV64 = getTriple().getArch() == llvm::Triple::riscv64;
   const bool IsSystemZ = getTriple().getArch() == llvm::Triple::systemz;
   const bool IsHexagon = getTriple().getArch() == llvm::Triple::hexagon;
@@ -774,7 +775,7 @@
   if (IsX86 || IsX86_64)
 Res |= SanitizerKind::Function;
   if (IsX86_64 || IsMIPS64 || IsAArch64 || IsX86 || IsMIPS || IsArmArch ||
-  IsPowerPC64 || IsHexagon)
+  IsPowerPC64 || IsHexagon || IsLoongArch64)
 Res |= SanitizerKind::Scudo;
   if (IsX86_64 || IsAArch64) {
 Res |= SanitizerKind::HWAddress;


Index: compiler-rt/cmake/Modules/AllSupportedArchDefs.cmake
===
--- compiler-rt/cmake/Modules/AllSupportedArchDefs.cmake
+++ compiler-rt/cmake/Modules/AllSupportedArchDefs.cmake
@@ -68,9 +68,9 @@
 set(ALL_CFI_SUPPORTED_ARCH ${X86} ${X86_64} ${ARM32} ${ARM64} ${MIPS64}
 ${HEXAGON})
 set(ALL_SCUDO_SUPPORTED_ARCH ${X86} ${X86_64} ${ARM32} ${ARM64} ${MIPS32}
-${MIPS64} ${PPC64} ${HEXAGON})
+${MIPS64} ${PPC64} ${HEXAGON} ${LOONGARCH64})
 set(ALL_SCUDO_STANDALONE_SUPPORTED_ARCH ${X86} ${X86_64} ${ARM32} ${ARM64}
-${MIPS32} ${MIPS64} ${PPC64} ${HEXAGON})
+${MIPS32} ${MIPS64} ${PPC64} ${HEXAGON} ${LOONGARCH64})
 if(APPLE)
 set(ALL_XRAY_SUPPORTED_ARCH ${X86_64})
 else()
Index: clang/test/Driver/fsanitize.c
===
--- clang/test/Driver/fsanitize.c
+++ clang/test/Driver/fsanitize.c
@@ -873,6 +873,7 @@
 // RUN: %clang --target=arm-linux-androideabi -fsanitize=scudo %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-SCUDO
 // RUN: %clang --target=x86_64-linux-gnu -fsanitize=scudo %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-SCUDO
 // RUN: %clang --target=i386-linux-gnu -fsanitize=scudo %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-SCUDO
+// RUN: %clang --target=loongarch64-unknown-linux-gnu -fsanitize=scudo %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-SCUDO
 // RUN: %clang --target=mips64-unknown-linux-gnu -fsanitize=scudo %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-SCUDO
 // RUN: %clang --target=mips64el-unknown-linux-gnu -fsanitize=scudo %s -### 2>&1 | FileCheck %

[PATCH] D138426: Fix #58958 on github

2022-11-22 Thread Alexey Kreshchuk via Phabricator via cfe-commits
krsch updated this revision to Diff 477166.
krsch added a comment.

Check any pointer, not just const. Test for volatile


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D138426/new/

https://reviews.llvm.org/D138426

Files:
  clang/lib/Sema/SemaFixItUtils.cpp
  clang/test/FixIt/fixit-function-call.cpp


Index: clang/test/FixIt/fixit-function-call.cpp
===
--- clang/test/FixIt/fixit-function-call.cpp
+++ clang/test/FixIt/fixit-function-call.cpp
@@ -115,4 +115,25 @@
   u(c);
 }
 
+void accept_void(void*);
+
+void issue58958(const char* a, volatile char * v, const volatile char * cv) {
+// CHECK: no matching function for call to 'accept_void'
+// CHECK-NOT: take the address of the argument with &
+accept_void(a);
+// CHECK: no matching function for call to 'accept_void'
+// CHECK-NOT: take the address of the argument with &
+accept_void(v);
+// CHECK: no matching function for call to 'accept_void'
+// CHECK-NOT: take the address of the argument with &
+accept_void(cv);
+char b;
+// CHECK: no matching function for call to 'accept_void'
+// CHECK: take the address of the argument with &
+accept_void(b);
+// CHECK-NOT: no matching function for call to 'accept_void'
+// CHECK-NOT: take the address of the argument with &
+accept_void(&b);
+}
+
 // CHECK: errors generated
Index: clang/lib/Sema/SemaFixItUtils.cpp
===
--- clang/lib/Sema/SemaFixItUtils.cpp
+++ clang/lib/Sema/SemaFixItUtils.cpp
@@ -124,7 +124,7 @@
 
   // Check if the pointer to the argument needs to be passed:
   //   (type -> type *) or (type & -> type *).
-  if (isa(ToQTy)) {
+  if (const auto *ToPtrTy = dyn_cast(ToQTy)) {
 bool CanConvert = false;
 OverloadFixItKind FixKind = OFIK_TakeAddress;
 
@@ -132,6 +132,10 @@
 if (!Expr->isLValue() || Expr->getObjectKind() != OK_Ordinary)
   return false;
 
+// Do no take address of const pointer to get void*
+if (isa(FromQTy) && ToPtrTy->isVoidPointerType())
+  return false;
+
 CanConvert = CompareTypes(S.Context.getPointerType(FromQTy), ToQTy, S,
   Begin, VK_PRValue);
 if (CanConvert) {


Index: clang/test/FixIt/fixit-function-call.cpp
===
--- clang/test/FixIt/fixit-function-call.cpp
+++ clang/test/FixIt/fixit-function-call.cpp
@@ -115,4 +115,25 @@
   u(c);
 }
 
+void accept_void(void*);
+
+void issue58958(const char* a, volatile char * v, const volatile char * cv) {
+// CHECK: no matching function for call to 'accept_void'
+// CHECK-NOT: take the address of the argument with &
+accept_void(a);
+// CHECK: no matching function for call to 'accept_void'
+// CHECK-NOT: take the address of the argument with &
+accept_void(v);
+// CHECK: no matching function for call to 'accept_void'
+// CHECK-NOT: take the address of the argument with &
+accept_void(cv);
+char b;
+// CHECK: no matching function for call to 'accept_void'
+// CHECK: take the address of the argument with &
+accept_void(b);
+// CHECK-NOT: no matching function for call to 'accept_void'
+// CHECK-NOT: take the address of the argument with &
+accept_void(&b);
+}
+
 // CHECK: errors generated
Index: clang/lib/Sema/SemaFixItUtils.cpp
===
--- clang/lib/Sema/SemaFixItUtils.cpp
+++ clang/lib/Sema/SemaFixItUtils.cpp
@@ -124,7 +124,7 @@
 
   // Check if the pointer to the argument needs to be passed:
   //   (type -> type *) or (type & -> type *).
-  if (isa(ToQTy)) {
+  if (const auto *ToPtrTy = dyn_cast(ToQTy)) {
 bool CanConvert = false;
 OverloadFixItKind FixKind = OFIK_TakeAddress;
 
@@ -132,6 +132,10 @@
 if (!Expr->isLValue() || Expr->getObjectKind() != OK_Ordinary)
   return false;
 
+// Do no take address of const pointer to get void*
+if (isa(FromQTy) && ToPtrTy->isVoidPointerType())
+  return false;
+
 CanConvert = CompareTypes(S.Context.getPointerType(FromQTy), ToQTy, S,
   Begin, VK_PRValue);
 if (CanConvert) {
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D138426: Fix #58958 on github

2022-11-22 Thread Alexey Kreshchuk via Phabricator via cfe-commits
krsch added inline comments.



Comment at: clang/lib/Sema/SemaFixItUtils.cpp:136-137
+// Do no take address of const pointer to get void*
+const PointerType *FromPtrTy = dyn_cast(FromQTy);
+const PointerType *ToPtrTy = dyn_cast(ToQTy);
+if (FromPtrTy && FromPtrTy->getPointeeType().isConstQualified() &&

xazax.hun wrote:
> xazax.hun wrote:
> > Nit: we usually try to avoid repeating types.
> Although the rest of the function clearly does not follow this guideline so 
> feel free to leave it as is.
The rest of the function was made this way in commit 1e95bc0f4063e, so I 
thought this is the style for this part of the codebase


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D138426/new/

https://reviews.llvm.org/D138426

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D127284: [clang-repl] Support statements on global scope in incremental mode.

2022-11-22 Thread Vassil Vassilev via Phabricator via cfe-commits
v.g.vassilev updated this revision to Diff 477168.
v.g.vassilev marked 2 inline comments as done.
v.g.vassilev edited the summary of this revision.
v.g.vassilev added a comment.

Address comments, support better C in clang-repl.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D127284/new/

https://reviews.llvm.org/D127284

Files:
  clang/include/clang/AST/ASTNodeTraverser.h
  clang/include/clang/AST/Decl.h
  clang/include/clang/AST/RecursiveASTVisitor.h
  clang/include/clang/Basic/DeclNodes.td
  clang/include/clang/Basic/LangOptions.def
  clang/include/clang/Driver/Options.td
  clang/include/clang/Lex/Preprocessor.h
  clang/include/clang/Parse/Parser.h
  clang/include/clang/Sema/Sema.h
  clang/include/clang/Sema/Template.h
  clang/include/clang/Serialization/ASTBitCodes.h
  clang/lib/AST/Decl.cpp
  clang/lib/AST/DeclBase.cpp
  clang/lib/AST/DeclPrinter.cpp
  clang/lib/CodeGen/CGDecl.cpp
  clang/lib/CodeGen/CodeGenModule.cpp
  clang/lib/CodeGen/CodeGenModule.h
  clang/lib/CodeGen/ModuleBuilder.cpp
  clang/lib/Interpreter/IncrementalParser.cpp
  clang/lib/Interpreter/Interpreter.cpp
  clang/lib/Parse/ParseDecl.cpp
  clang/lib/Parse/ParseTentative.cpp
  clang/lib/Parse/Parser.cpp
  clang/lib/Sema/SemaDecl.cpp
  clang/lib/Serialization/ASTCommon.cpp
  clang/lib/Serialization/ASTReaderDecl.cpp
  clang/lib/Serialization/ASTWriterDecl.cpp
  clang/test/Interpreter/disambiguate-decl-stmt.cpp
  clang/test/Interpreter/execute-stmts.cpp
  clang/test/Interpreter/stmt-serialization.cpp
  clang/unittests/Interpreter/InterpreterTest.cpp

Index: clang/unittests/Interpreter/InterpreterTest.cpp
===
--- clang/unittests/Interpreter/InterpreterTest.cpp
+++ clang/unittests/Interpreter/InterpreterTest.cpp
@@ -124,14 +124,8 @@
   auto *PTU1 = R1->TUPart;
   EXPECT_EQ(2U, DeclsSize(PTU1));
 
-  // FIXME: Add support for wrapping and running statements.
   auto R2 = Interp->Parse("var1++; printf(\"var1 value %d\\n\", var1);");
-  EXPECT_FALSE(!!R2);
-  using ::testing::HasSubstr;
-  EXPECT_THAT(DiagnosticsOS.str(),
-  HasSubstr("error: unknown type name 'var1'"));
-  auto Err = R2.takeError();
-  EXPECT_EQ("Parsing failed.", llvm::toString(std::move(Err)));
+  EXPECT_TRUE(!!R2);
 }
 
 TEST(InterpreterTest, UndoCommand) {
Index: clang/test/Interpreter/stmt-serialization.cpp
===
--- /dev/null
+++ clang/test/Interpreter/stmt-serialization.cpp
@@ -0,0 +1,19 @@
+// RUN: rm -rf %t
+// RUN: %clang_cc1 -std=c++20 -fincremental-extensions -fmodules-cache-path=%t \
+// RUN:-x c++ %s -verify
+// expected-no-diagnostics
+
+#pragma clang module build TopLevelStmt
+module TopLevelStmt { module Statements {} }
+#pragma clang module contents
+
+#pragma clang module begin TopLevelStmt.Statements
+extern "C" int printf(const char*,...);
+int i = 0;
+i++;
+#pragma clang module end /*TopLevelStmt.Statements*/
+#pragma clang module endbuild /*TopLevelStmt*/
+
+#pragma clang module import TopLevelStmt.Statements
+
+printf("Value of i is '%d'", i);
Index: clang/test/Interpreter/execute-stmts.cpp
===
--- /dev/null
+++ clang/test/Interpreter/execute-stmts.cpp
@@ -0,0 +1,33 @@
+// REQUIRES: host-supports-jit
+// UNSUPPORTED: system-aix
+// RUN: cat %s | clang-repl -Xcc -Xclang -Xcc  -verify | FileCheck %s
+// RUN: %clang_cc1 -fsyntax-only -verify -fincremental-extensions %s
+
+// expected-no-diagnostics
+
+extern "C" int printf(const char*,...);
+
+template  T call() { printf("called\n"); return T(); }
+call();
+// CHECK: called
+
+int i = 1;
+++i;
+printf("i = %d\n", i);
+// CHECK: i = 2
+
+namespace Ns { void f(){ i++; } }
+Ns::f();
+
+void g() { ++i; }
+g();
+::g();
+
+printf("i = %d\n", i);
+// CHECK-NEXT: i = 5
+
+for (; i > 4; --i) printf("i = %d\n", i);
+// CHECK-NEXT: i = 5
+
+int j = i; printf("j = %d\n", j);
+// CHECK-NEXT: j = 4
Index: clang/test/Interpreter/disambiguate-decl-stmt.cpp
===
--- /dev/null
+++ clang/test/Interpreter/disambiguate-decl-stmt.cpp
@@ -0,0 +1,51 @@
+// REQUIRES: host-supports-jit
+// UNSUPPORTED: system-aix
+// RUN: cat %s | clang-repl -Xcc -std=c++20 -Xcc -Xclang -Xcc -verify | FileCheck %s
+// RUN: %clang_cc1 -fsyntax-only -verify -fincremental-extensions -std=c++20 %s
+
+// expected-no-diagnostics
+
+extern "C" int printf(const char*,...);
+
+// Decls which are hard to disambiguate
+
+// Operators.
+struct S1 { operator int(); };
+S1::operator int() { return 0; }
+
+// Dtors
+using I = int;
+I x = 10;
+x.I::~I();
+x = 20;
+
+// Ctors
+
+// Deduction guide
+template struct A { A(); A(T); };
+A() -> A;
+
+struct S2 { S2(); };
+S2::S2() = default;
+
+namespace N { struct S { S(); }; }
+N::S::S() { printf("N::S::S()\n"); }
+N::S s;
+// CHECK: N::S::S()
+
+namespace Ns {namespace Ns { void Ns(); void Fs();}}
+void Ns::Ns::Ns() { printf("void Ns

[clang] cb261e3 - [AArch64][clang] implement 2022 General Data-Processing instructions

2022-11-22 Thread Ties Stuij via cfe-commits

Author: Ties Stuij
Date: 2022-11-22T14:23:12Z
New Revision: cb261e30fbb174085d2eea4f4afc3cef2838b7f7

URL: 
https://github.com/llvm/llvm-project/commit/cb261e30fbb174085d2eea4f4afc3cef2838b7f7
DIFF: 
https://github.com/llvm/llvm-project/commit/cb261e30fbb174085d2eea4f4afc3cef2838b7f7.diff

LOG: [AArch64][clang] implement 2022 General Data-Processing instructions

This patch implements the 2022 Architecture General Data-Processing Instructions

They include:

Common Short Sequence Compression (CSSC) instructions
- scalar comparison instructions
  SMAX, SMIN, UMAX, UMIN (32/64 bits) with or without immediate
- ABS (absolute), CNT (count non-zero bits), CTZ (count trailing zeroes)
- command-line options for CSSC

Associated with these instructions in the documentation is the Range Prefetch
Memory (RPRFM) instruction, which signals to the memory system that data memory
accesses from a specified range of addresses are likely to occur in the near
future. The instruction lies in hint space, and is made unconditional.

Specs for the individual instructions can be found here:
https://developer.arm.com/documentation/ddi0602/2022-09/Base-Instructions/

contributors to this patch:
- Cullen Rhodes
- Son Tuan Vu
- Mark Murray
- Tomas Matheson
- Sam Elliott
- Ties Stuij

Reviewed By: lenary

Differential Revision: https://reviews.llvm.org/D138488

Added: 
clang/test/Driver/aarch64-cssc.c
llvm/test/MC/AArch64/CSSC/abs_32.s
llvm/test/MC/AArch64/CSSC/abs_64.s
llvm/test/MC/AArch64/CSSC/cnt_32.s
llvm/test/MC/AArch64/CSSC/cnt_64.s
llvm/test/MC/AArch64/CSSC/ctz_32.s
llvm/test/MC/AArch64/CSSC/ctz_64.s
llvm/test/MC/AArch64/CSSC/smax_32_imm.s
llvm/test/MC/AArch64/CSSC/smax_32_reg.s
llvm/test/MC/AArch64/CSSC/smax_64_imm.s
llvm/test/MC/AArch64/CSSC/smax_64_reg.s
llvm/test/MC/AArch64/CSSC/smin_32_imm.s
llvm/test/MC/AArch64/CSSC/smin_32_reg.s
llvm/test/MC/AArch64/CSSC/smin_64_imm.s
llvm/test/MC/AArch64/CSSC/smin_64_reg.s
llvm/test/MC/AArch64/CSSC/umax_32_imm.s
llvm/test/MC/AArch64/CSSC/umax_32_reg.s
llvm/test/MC/AArch64/CSSC/umax_64_imm.s
llvm/test/MC/AArch64/CSSC/umax_64_reg.s
llvm/test/MC/AArch64/CSSC/umin_32_imm.s
llvm/test/MC/AArch64/CSSC/umin_32_reg.s
llvm/test/MC/AArch64/CSSC/umin_64_imm.s
llvm/test/MC/AArch64/CSSC/umin_64_reg.s
llvm/test/MC/AArch64/armv8.9a-cssc.s
llvm/test/MC/AArch64/rprfm.s
llvm/test/MC/Disassembler/AArch64/armv8.9a-cssc.txt

Modified: 
llvm/include/llvm/Support/AArch64TargetParser.def
llvm/include/llvm/Support/AArch64TargetParser.h
llvm/lib/Target/AArch64/AArch64.td
llvm/lib/Target/AArch64/AArch64InstrFormats.td
llvm/lib/Target/AArch64/AArch64InstrInfo.td
llvm/lib/Target/AArch64/AArch64SystemOperands.td
llvm/lib/Target/AArch64/AsmParser/AArch64AsmParser.cpp
llvm/lib/Target/AArch64/Disassembler/AArch64Disassembler.cpp
llvm/lib/Target/AArch64/MCTargetDesc/AArch64InstPrinter.cpp
llvm/lib/Target/AArch64/MCTargetDesc/AArch64InstPrinter.h
llvm/lib/Target/AArch64/SVEInstrFormats.td
llvm/lib/Target/AArch64/Utils/AArch64BaseInfo.cpp
llvm/lib/Target/AArch64/Utils/AArch64BaseInfo.h
llvm/unittests/Support/TargetParserTest.cpp

Removed: 




diff  --git a/clang/test/Driver/aarch64-cssc.c 
b/clang/test/Driver/aarch64-cssc.c
new file mode 100644
index 0..0ecda98d69504
--- /dev/null
+++ b/clang/test/Driver/aarch64-cssc.c
@@ -0,0 +1,15 @@
+// Test that target feature cssc is implemented and available correctly
+// RUN: %clang -### -target aarch64-none-none-eabi %s 
2>&1 | FileCheck %s --check-prefix=ABSENT_CSSC
+// RUN: %clang -### -target aarch64-none-none-eabi -march=armv8.8-a+cssc   %s 
2>&1 | FileCheck %s
+// RUN: %clang -### -target aarch64-none-none-eabi -march=armv8.9-a%s 
2>&1 | FileCheck %s --check-prefix=ABSENT_CSSC
+// RUN: %clang -### -target aarch64-none-none-eabi -march=armv8.8-a+cssc   %s 
2>&1 | FileCheck %s
+// RUN: %clang -### -target aarch64-none-none-eabi -march=armv8.9-a+nocssc %s 
2>&1 | FileCheck %s --check-prefix=NO_CSSC
+// RUN: %clang -### -target aarch64-none-none-eabi -march=armv9.3-a+cssc   %s 
2>&1 | FileCheck %s
+// RUN: %clang -### -target aarch64-none-none-eabi -march=armv9.4-a%s 
2>&1 | FileCheck %s --check-prefix=ABSENT_CSSC
+// RUN: %clang -### -target aarch64-none-none-eabi -march=armv9.3-a+cssc   %s 
2>&1 | FileCheck %s
+// RUN: %clang -### -target aarch64-none-none-eabi -march=armv9.4-a+nocssc %s 
2>&1 | FileCheck %s --check-prefix=NO_CSSC
+
+// CHECK: "-target-feature" "+cssc"
+// NO_CSSC: "-target-feature" "-cssc"
+// ABSENT_CSSC-NOT: "-target-feature" "+cssc"
+// ABSENT_CSSC-NOT: "-target-feature" "-cssc"

diff  --git a/llvm/include/llvm/Support/AArch64TargetParser.def 
b/llvm/include/llvm/Support/AArch64TargetParser.def
index 5f6ef92a14ed6..f016c9147a7bb 100644
--- a/llvm/include/llvm/Suppor

[PATCH] D137375: [AIX][pg] Add Correct Search Paths for Profiled Libraries

2022-11-22 Thread Chris Bowler via Phabricator via cfe-commits
cebowleratibm added a comment.

Looks good but I just want to confirm that the profiled -L paths are appended 
in the correct order with respect to the non-profiled paths.




Comment at: clang/test/Driver/aix-ld.c:192
 // CHECK-LD32-GPROF: "-lc"
+// CHECK-LD32-GPROF: "-L[[SYSROOT]]/lib/profiled"
+// CHECK-LD32-GPROF: "-L[[SYSROOT]]/usr/lib/profiled"

I don't currently see the test checking for the usual `/lib` and `/usr/lib` 
directories.  Should we check that the new profiled -L paths are correctly 
positioned relative to the non-profiled directories, or does it matter?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D137375/new/

https://reviews.llvm.org/D137375

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D138488: [AArch64][clang] implement 2022 General Data-Processing instructions

2022-11-22 Thread Ties Stuij via Phabricator via cfe-commits
This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
stuij marked an inline comment as done.
Closed by commit rGcb261e30fbb1: [AArch64][clang] implement 2022 General 
Data-Processing instructions (authored by stuij).

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D138488/new/

https://reviews.llvm.org/D138488

Files:
  clang/test/Driver/aarch64-cssc.c
  llvm/include/llvm/Support/AArch64TargetParser.def
  llvm/include/llvm/Support/AArch64TargetParser.h
  llvm/lib/Target/AArch64/AArch64.td
  llvm/lib/Target/AArch64/AArch64InstrFormats.td
  llvm/lib/Target/AArch64/AArch64InstrInfo.td
  llvm/lib/Target/AArch64/AArch64SystemOperands.td
  llvm/lib/Target/AArch64/AsmParser/AArch64AsmParser.cpp
  llvm/lib/Target/AArch64/Disassembler/AArch64Disassembler.cpp
  llvm/lib/Target/AArch64/MCTargetDesc/AArch64InstPrinter.cpp
  llvm/lib/Target/AArch64/MCTargetDesc/AArch64InstPrinter.h
  llvm/lib/Target/AArch64/SVEInstrFormats.td
  llvm/lib/Target/AArch64/Utils/AArch64BaseInfo.cpp
  llvm/lib/Target/AArch64/Utils/AArch64BaseInfo.h
  llvm/test/MC/AArch64/CSSC/abs_32.s
  llvm/test/MC/AArch64/CSSC/abs_64.s
  llvm/test/MC/AArch64/CSSC/cnt_32.s
  llvm/test/MC/AArch64/CSSC/cnt_64.s
  llvm/test/MC/AArch64/CSSC/ctz_32.s
  llvm/test/MC/AArch64/CSSC/ctz_64.s
  llvm/test/MC/AArch64/CSSC/smax_32_imm.s
  llvm/test/MC/AArch64/CSSC/smax_32_reg.s
  llvm/test/MC/AArch64/CSSC/smax_64_imm.s
  llvm/test/MC/AArch64/CSSC/smax_64_reg.s
  llvm/test/MC/AArch64/CSSC/smin_32_imm.s
  llvm/test/MC/AArch64/CSSC/smin_32_reg.s
  llvm/test/MC/AArch64/CSSC/smin_64_imm.s
  llvm/test/MC/AArch64/CSSC/smin_64_reg.s
  llvm/test/MC/AArch64/CSSC/umax_32_imm.s
  llvm/test/MC/AArch64/CSSC/umax_32_reg.s
  llvm/test/MC/AArch64/CSSC/umax_64_imm.s
  llvm/test/MC/AArch64/CSSC/umax_64_reg.s
  llvm/test/MC/AArch64/CSSC/umin_32_imm.s
  llvm/test/MC/AArch64/CSSC/umin_32_reg.s
  llvm/test/MC/AArch64/CSSC/umin_64_imm.s
  llvm/test/MC/AArch64/CSSC/umin_64_reg.s
  llvm/test/MC/AArch64/armv8.9a-cssc.s
  llvm/test/MC/AArch64/rprfm.s
  llvm/test/MC/Disassembler/AArch64/armv8.9a-cssc.txt
  llvm/unittests/Support/TargetParserTest.cpp

Index: llvm/unittests/Support/TargetParserTest.cpp
===
--- llvm/unittests/Support/TargetParserTest.cpp
+++ llvm/unittests/Support/TargetParserTest.cpp
@@ -1606,7 +1606,7 @@
   AArch64::AEK_SME, AArch64::AEK_SMEF64F64, AArch64::AEK_SMEI16I64,
   AArch64::AEK_SME2,AArch64::AEK_HBC,  AArch64::AEK_MOPS,
   AArch64::AEK_PERFMON, AArch64::AEK_SVE2p1,   AArch64::AEK_SME2p1,
-  AArch64::AEK_B16B16,  AArch64::AEK_SMEF16F16};
+  AArch64::AEK_B16B16,  AArch64::AEK_SMEF16F16, AArch64::AEK_CSSC};
 
   std::vector Features;
 
@@ -1671,6 +1671,7 @@
   EXPECT_TRUE(llvm::is_contained(Features, "+hbc"));
   EXPECT_TRUE(llvm::is_contained(Features, "+mops"));
   EXPECT_TRUE(llvm::is_contained(Features, "+perfmon"));
+  EXPECT_TRUE(llvm::is_contained(Features, "+cssc"));
 
   // Assuming we listed every extension above, this should produce the same
   // result. (note that AEK_NONE doesn't have a name so it won't be in the
Index: llvm/test/MC/Disassembler/AArch64/armv8.9a-cssc.txt
===
--- /dev/null
+++ llvm/test/MC/Disassembler/AArch64/armv8.9a-cssc.txt
@@ -0,0 +1,72 @@
+# RUN: llvm-mc -triple aarch64-none-linux-gnu -disassemble -mattr=+v9.4a < %s  | FileCheck %s
+# RUN: not llvm-mc -triple aarch64-none-linux-gnu -disassemble -mattr=+v8.8a < %s 2>&1 | FileCheck --check-prefix=NO-V94A-ERR %s
+# RUN: llvm-mc -triple aarch64-none-linux-gnu -disassemble -mattr=+v8.9a < %s  | FileCheck %s
+# RUN: not llvm-mc -triple aarch64-none-linux-gnu -disassemble -mattr=+v9.3a < %s 2>&1 | FileCheck --check-prefix=NO-V94A-ERR %s
+
+[0x20,0x20,0xc0,0xda]
+# CHECK:   abs x0, x1
+# NO-V94A-ERR: [[@LINE-2]]:2: warning: invalid instruction encoding
+[0x20,0x20,0xc0,0x5a]
+# CHECK:   abs w0, w1
+# NO-V94A-ERR: [[@LINE-2]]:2: warning: invalid instruction encoding
+[0x20,0x1c,0xc0,0xda]
+# CHECK:   cnt x0, x1
+# NO-V94A-ERR: [[@LINE-2]]:2: warning: invalid instruction encoding
+[0x20,0x1c,0xc0,0x5a]
+# CHECK:   cnt w0, w1
+# NO-V94A-ERR: [[@LINE-2]]:2: warning: invalid instruction encoding
+[0x20,0x18,0xc0,0xda]
+# CHECK:   ctz x0, x1
+# NO-V94A-ERR: [[@LINE-2]]:2: warning: invalid instruction encoding
+[0x20,0x18,0xc0,0x5a]
+# CHECK:   ctz w0, w1
+# NO-V94A-ERR: [[@LINE-2]]:2: warning: invalid instruction encoding
+
+[0x41,0x60,0xc3,0x9a]
+# CHECK:   smaxx1, x2, x3
+# NO-V94A-ERR: [[@LINE-2]]:2: warning: invalid instruction encoding
+[0x41,0x0c,0xc0,0x91]
+# CHECK:   smaxx1, x2, #3
+# NO-V94A-ERR: [[@LINE-2]]:2: warning: invalid instruction encoding
+[0x41,0x60,0xc3,0x1a]
+# CHECK:   smaxw1, w2, w3
+# NO-V94A-ERR: [[@LINE-2]]:2: warning: invalid instruction encoding
+[0

[clang] 969d787 - [OpenMP][OMPIRBuilder] Add a configuration class that captures flags that affect codegen

2022-11-22 Thread Jan Sjodin via cfe-commits

Author: Jan Sjodin
Date: 2022-11-22T09:25:04-05:00
New Revision: 969d787a470a801ad23be1fd53bcc166f75454a5

URL: 
https://github.com/llvm/llvm-project/commit/969d787a470a801ad23be1fd53bcc166f75454a5
DIFF: 
https://github.com/llvm/llvm-project/commit/969d787a470a801ad23be1fd53bcc166f75454a5.diff

LOG: [OpenMP][OMPIRBuilder] Add a configuration class that captures flags that 
affect codegen

This patch introudces the OpenMPIRBuilderConfig class which contains various
flags that are needed to lower OMP constructs to LLVM-IR. The purpose is to
keep the flags in one place so they do not have to be passed in every time.
The flags can be set optionally since some uses cases don't rely on functions
that depend on these flags.

Reviewed By: jdoerfert, tschuett

Differential Revision: https://reviews.llvm.org/D138220

Added: 


Modified: 
clang/lib/CodeGen/CGOpenMPRuntime.cpp
clang/lib/CodeGen/CGOpenMPRuntime.h
clang/lib/CodeGen/CGOpenMPRuntimeGPU.cpp
llvm/include/llvm/Frontend/OpenMP/OMPIRBuilder.h
llvm/lib/Frontend/OpenMP/OMPIRBuilder.cpp
llvm/unittests/Frontend/OpenMPIRBuilderTest.cpp

Removed: 




diff  --git a/clang/lib/CodeGen/CGOpenMPRuntime.cpp 
b/clang/lib/CodeGen/CGOpenMPRuntime.cpp
index 35eda4dca3210..0552fb31bff97 100644
--- a/clang/lib/CodeGen/CGOpenMPRuntime.cpp
+++ b/clang/lib/CodeGen/CGOpenMPRuntime.cpp
@@ -1062,9 +1062,13 @@ CGOpenMPRuntime::CGOpenMPRuntime(CodeGenModule &CGM, 
StringRef FirstSeparator,
 : CGM(CGM), FirstSeparator(FirstSeparator), Separator(Separator),
   OMPBuilder(CGM.getModule()), OffloadEntriesInfoManager() {
   KmpCriticalNameTy = llvm::ArrayType::get(CGM.Int32Ty, /*NumElements*/ 8);
+  llvm::OpenMPIRBuilderConfig Config(CGM.getLangOpts().OpenMPIsDevice, false,
+ hasRequiresUnifiedSharedMemory());
 
   // Initialize Types used in OpenMPIRBuilder from OMPKinds.def
   OMPBuilder.initialize();
+  OMPBuilder.setConfig(Config);
+  OffloadEntriesInfoManager.setConfig(Config);
   loadOffloadInfoMetadata();
 }
 
@@ -1910,8 +1914,7 @@ bool 
CGOpenMPRuntime::emitDeclareTargetVarDefinition(const VarDecl *VD,
 CtorEntryInfo.ParentName = Twine(Buffer, "_ctor").toStringRef(Out);
 OffloadEntriesInfoManager.registerTargetRegionEntryInfo(
 CtorEntryInfo, Ctor, ID,
-llvm::OffloadEntriesInfoManager::OMPTargetRegionEntryCtor,
-CGM.getLangOpts().OpenMPIsDevice);
+llvm::OffloadEntriesInfoManager::OMPTargetRegionEntryCtor);
   }
   if (VD->getType().isDestructedType() != QualType::DK_none) {
 llvm::Constant *Dtor;
@@ -1960,8 +1963,7 @@ bool 
CGOpenMPRuntime::emitDeclareTargetVarDefinition(const VarDecl *VD,
 DtorEntryInfo.ParentName = Twine(Buffer, "_dtor").toStringRef(Out);
 OffloadEntriesInfoManager.registerTargetRegionEntryInfo(
 DtorEntryInfo, Dtor, ID,
-llvm::OffloadEntriesInfoManager::OMPTargetRegionEntryDtor,
-CGM.getLangOpts().OpenMPIsDevice);
+llvm::OffloadEntriesInfoManager::OMPTargetRegionEntryDtor);
   }
   return CGM.getLangOpts().OpenMPIsDevice;
 }
@@ -2980,10 +2982,8 @@ void 
CGOpenMPRuntime::createOffloadEntriesAndInfoMetadata() {
 }
   };
 
-  OMPBuilder.createOffloadEntriesAndInfoMetadata(
-  OffloadEntriesInfoManager, isTargetCodegen(),
-  CGM.getLangOpts().OpenMPIsDevice,
-  CGM.getOpenMPRuntime().hasRequiresUnifiedSharedMemory(), ErrorReportFn);
+  OMPBuilder.createOffloadEntriesAndInfoMetadata(OffloadEntriesInfoManager,
+ ErrorReportFn);
 }
 
 /// Loads all the offload entries information from the host IR
@@ -6153,8 +6153,7 @@ void CGOpenMPRuntime::emitTargetOutlinedFunctionHelper(
   // Register the information for the entry associated with this target region.
   OffloadEntriesInfoManager.registerTargetRegionEntryInfo(
   EntryInfo, TargetRegionEntryAddr, OutlinedFnID,
-  llvm::OffloadEntriesInfoManager::OMPTargetRegionEntryTargetRegion,
-  CGM.getLangOpts().OpenMPIsDevice);
+  llvm::OffloadEntriesInfoManager::OMPTargetRegionEntryTargetRegion);
 
   // Add NumTeams and ThreadLimit attributes to the outlined GPU function
   int32_t DefaultValTeams = -1;
@@ -10419,7 +10418,7 @@ void 
CGOpenMPRuntime::registerTargetGlobalVariable(const VarDecl *VD,
   }
 
   OffloadEntriesInfoManager.registerDeviceGlobalVarEntryInfo(
-  VarName, Addr, VarSize, Flags, Linkage, 
CGM.getLangOpts().OpenMPIsDevice);
+  VarName, Addr, VarSize, Flags, Linkage);
 }
 
 bool CGOpenMPRuntime::emitTargetGlobal(GlobalDecl GD) {
@@ -10461,6 +10460,7 @@ void CGOpenMPRuntime::processRequiresDirective(const 
OMPRequiresDecl *D) {
   for (const OMPClause *Clause : D->clauselists()) {
 if (Clause->getClauseKind() == OMPC_unified_shared_memory) {
   HasRequiresUnifiedSharedMemory = true;
+  OMPBuilder.Config.setHasRequiresUnifiedSharedMemory(true);
 } else if (const auto *AC =

[PATCH] D138220: [OpenMP][OMPIRBuilder] Add a configuration class to captures flags/attributes that affect codegen

2022-11-22 Thread Jan Sjödin via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG969d787a470a: [OpenMP][OMPIRBuilder] Add a configuration 
class that captures flags that… (authored by jsjodin).
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D138220/new/

https://reviews.llvm.org/D138220

Files:
  clang/lib/CodeGen/CGOpenMPRuntime.cpp
  clang/lib/CodeGen/CGOpenMPRuntime.h
  clang/lib/CodeGen/CGOpenMPRuntimeGPU.cpp
  llvm/include/llvm/Frontend/OpenMP/OMPIRBuilder.h
  llvm/lib/Frontend/OpenMP/OMPIRBuilder.cpp
  llvm/unittests/Frontend/OpenMPIRBuilderTest.cpp

Index: llvm/unittests/Frontend/OpenMPIRBuilderTest.cpp
===
--- llvm/unittests/Frontend/OpenMPIRBuilderTest.cpp
+++ llvm/unittests/Frontend/OpenMPIRBuilderTest.cpp
@@ -5504,17 +5504,18 @@
 
 TEST_F(OpenMPIRBuilderTest, OffloadEntriesInfoManager) {
   OffloadEntriesInfoManager InfoManager;
+  InfoManager.setConfig(OpenMPIRBuilderConfig(true, false, false));
   TargetRegionEntryInfo EntryInfo("parent", 1, 2, 4, 0);
   InfoManager.initializeTargetRegionEntryInfo(EntryInfo, 0);
-  EXPECT_TRUE(InfoManager.hasTargetRegionEntryInfo(EntryInfo, true));
+  EXPECT_TRUE(InfoManager.hasTargetRegionEntryInfo(EntryInfo));
   InfoManager.initializeDeviceGlobalVarEntryInfo(
   "gvar", OffloadEntriesInfoManager::OMPTargetGlobalVarEntryTo, 0);
   InfoManager.registerTargetRegionEntryInfo(
   EntryInfo, nullptr, nullptr,
-  OffloadEntriesInfoManager::OMPTargetRegionEntryTargetRegion, true);
+  OffloadEntriesInfoManager::OMPTargetRegionEntryTargetRegion);
   InfoManager.registerDeviceGlobalVarEntryInfo(
   "gvar", 0x0, 8, OffloadEntriesInfoManager::OMPTargetGlobalVarEntryTo,
-  GlobalValue::WeakAnyLinkage, true);
+  GlobalValue::WeakAnyLinkage);
   EXPECT_TRUE(InfoManager.hasDeviceGlobalVarEntryInfo("gvar"));
 }
 } // namespace
Index: llvm/lib/Frontend/OpenMP/OMPIRBuilder.cpp
===
--- llvm/lib/Frontend/OpenMP/OMPIRBuilder.cpp
+++ llvm/lib/Frontend/OpenMP/OMPIRBuilder.cpp
@@ -4683,11 +4683,10 @@
   }
 }
 
-void OpenMPIRBuilder::createOffloadEntry(bool IsTargetCodegen, Constant *ID,
- Constant *Addr, uint64_t Size,
- int32_t Flags,
+void OpenMPIRBuilder::createOffloadEntry(Constant *ID, Constant *Addr,
+ uint64_t Size, int32_t Flags,
  GlobalValue::LinkageTypes) {
-  if (!IsTargetCodegen) {
+  if (!Config.isTargetCodegen()) {
 emitOffloadingEntry(ID, Addr->getName(), Size, Flags);
 return;
   }
@@ -4715,8 +4714,7 @@
 
 // We only generate metadata for function that contain target regions.
 void OpenMPIRBuilder::createOffloadEntriesAndInfoMetadata(
-OffloadEntriesInfoManager &OffloadEntriesInfoManager, bool IsTargetCodegen,
-bool IsEmbedded, bool HasRequiresUnifiedSharedMemory,
+OffloadEntriesInfoManager &OffloadEntriesInfoManager,
 EmitMetadataErrorReportFunctionTy &ErrorFn) {
 
   // If there are no entries, we don't need to do anything.
@@ -4809,7 +4807,7 @@
 ErrorFn(EMIT_MD_TARGET_REGION_ERROR, EntryInfo);
 continue;
   }
-  createOffloadEntry(IsTargetCodegen, CE->getID(), CE->getAddress(),
+  createOffloadEntry(CE->getID(), CE->getAddress(),
  /*Size=*/0, CE->getFlags(),
  GlobalValue::WeakAnyLinkage);
 } else if (const auto *CE = dyn_cast<
@@ -4820,7 +4818,7 @@
   CE->getFlags());
   switch (Flags) {
   case OffloadEntriesInfoManager::OMPTargetGlobalVarEntryTo: {
-if (IsEmbedded && HasRequiresUnifiedSharedMemory)
+if (Config.isEmbedded() && Config.hasRequiresUnifiedSharedMemory())
   continue;
 if (!CE->getAddress()) {
   ErrorFn(EMIT_MD_DECLARE_TARGET_ERROR, E.second);
@@ -4832,10 +4830,10 @@
 break;
   }
   case OffloadEntriesInfoManager::OMPTargetGlobalVarEntryLink:
-assert(((IsEmbedded && !CE->getAddress()) ||
-(!IsEmbedded && CE->getAddress())) &&
+assert(((Config.isEmbedded() && !CE->getAddress()) ||
+(!Config.isEmbedded() && CE->getAddress())) &&
"Declaret target link address is set.");
-if (IsEmbedded)
+if (Config.isEmbedded())
   continue;
 if (!CE->getAddress()) {
   ErrorFn(EMIT_MD_GLOBAL_VAR_LINK_ERROR, TargetRegionEntryInfo());
@@ -4851,8 +4849,8 @@
 if (GV->hasLocalLinkage() || GV->hasHiddenVisibility())
   continue;
 
-  createOffloadEntry(IsTargetCodegen, CE->getAddress(), CE->getAddress(),
- CE->getVarSize(), Flags, CE->getLinkage());
+  createOffloadEntry(CE->getAddress(), CE->getAddress(), CE-

[PATCH] D137044: [ClangFE] Add support for option -mno-pic-data-is-text-relative

2022-11-22 Thread Mariya Podchishchaeva via Phabricator via cfe-commits
Fznamznon added a comment.

In D137044#3943680 , @jonpa wrote:

> In D137044#3942990 , @pcwang-thead 
> wrote:
>
>> The test `clang/test/Driver/pic.c` failed when we compiled Clang/LLVM with 
>> `-DCLANG_DEFAULT_PIE_ON_LINUX=False`.
>
> Ah... I suppose that must be because -mno-pic-data-is-text-relative requires 
> PIC (this is per GCC behavior). Does it help if you add -fpic to the RUN 
> lines that were added by this patch? I was not aware of the cmake flag, sorry.

For me it does. Can we make this change?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D137044/new/

https://reviews.llvm.org/D137044

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D136594: [clangd] Add support for semantic token type "operator"

2022-11-22 Thread Christian Kandeler via Phabricator via cfe-commits
ckandeler updated this revision to Diff 477178.
ckandeler added a comment.

Make highlighting of built-in operators conditional


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D136594/new/

https://reviews.llvm.org/D136594

Files:
  clang-tools-extra/clangd/ClangdLSPServer.cpp
  clang-tools-extra/clangd/ClangdLSPServer.h
  clang-tools-extra/clangd/Protocol.cpp
  clang-tools-extra/clangd/Protocol.h
  clang-tools-extra/clangd/SemanticHighlighting.cpp
  clang-tools-extra/clangd/SemanticHighlighting.h
  clang-tools-extra/clangd/test/initialize-params.test
  clang-tools-extra/clangd/test/semantic-tokens.test
  clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp

Index: clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp
===
--- clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp
+++ clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp
@@ -113,9 +113,9 @@
   void $Function_def[[foo]](int $Parameter_def[[A]], $Class[[AS]] $Parameter_def[[As]]) {
 $Primitive_deduced_defaultLibrary[[auto]] $LocalVariable_def[[VeryLongVariableName]] = 12312;
 $Class[[AS]] $LocalVariable_def[[AA]];
-$Primitive_deduced_defaultLibrary[[auto]] $LocalVariable_def[[L]] = $LocalVariable[[AA]].$Field[[SomeMember]] + $Parameter[[A]];
+$Primitive_deduced_defaultLibrary[[auto]] $LocalVariable_def[[L]] = $LocalVariable[[AA]].$Field[[SomeMember]] $Operator[[+]] $Parameter[[A]];
 auto $LocalVariable_def[[FN]] = [ $LocalVariable[[AA]]](int $Parameter_def[[A]]) -> void {};
-$LocalVariable[[FN]](12312);
+$LocalVariable[[FN]]$Operator_userProvided[[(]]12312$Operator_userProvided[[)]];
   }
 )cpp",
   R"cpp(
@@ -144,7 +144,7 @@
   struct $Class_def[[B]] {
 $Class_decl_constrDestr[[B]]();
 ~$Class_decl_constrDestr[[B]]();
-void operator<<($Class[[B]]);
+void operator$Operator_decl[[<<]]($Class[[B]]);
 $Class[[AAA]] $Field_decl[[AA]];
   };
   $Class[[B]]::$Class_def_constrDestr[[B]]() {}
@@ -203,20 +203,20 @@
 static double $StaticField_decl_static[[S]];
 static void $StaticMethod_def_static[[bar]]() {}
 void $Method_def[[foo]]() {
-  $Field[[B]] = 123;
-  this->$Field[[B]] = 156;
+  $Field[[B]] $Operator[[=]] 123;
+  this->$Field[[B]] $Operator[[=]] 156;
   this->$Method[[foo]]();
   $Method[[foo]]();
   $StaticMethod_static[[bar]]();
-  $StaticField_static[[S]] = 90.1;
+  $StaticField_static[[S]] $Operator[[=]] 90.1;
 }
   };
   void $Function_def[[foo]]() {
 $Class[[A]] $LocalVariable_def[[AA]];
-$LocalVariable[[AA]].$Field[[B]] += 2;
+$LocalVariable[[AA]].$Field[[B]] $Operator[[+=]] 2;
 $LocalVariable[[AA]].$Method[[foo]]();
 $LocalVariable[[AA]].$Field[[E]].$Field[[C]];
-$Class[[A]]::$StaticField_static[[S]] = 90;
+$Class[[A]]::$StaticField_static[[S]] $Operator[[=]] 90;
   }
 )cpp",
   R"cpp(
@@ -295,10 +295,10 @@
   struct $Class_def[[B]] {};
   struct $Class_def[[A]] {
 $Class[[B]] $Field_decl[[BB]];
-$Class[[A]] &operator=($Class[[A]] &&$Parameter_def[[O]]);
+$Class[[A]] &operator$Operator_decl[[=]]($Class[[A]] &&$Parameter_def[[O]]);
   };
 
-  $Class[[A]] &$Class[[A]]::operator=($Class[[A]] &&$Parameter_def[[O]]) = default;
+  $Class[[A]] &$Class[[A]]::operator$Operator_def[[=]]($Class[[A]] &&$Parameter_def[[O]]) = default;
 )cpp",
   R"cpp(
   enum $Enum_decl[[En]] {
@@ -327,9 +327,9 @@
   $Enum_deduced[[auto]] $Variable_def[[AE]] = $Enum[[E]]::$EnumConstant_readonly[[E]];
   $Class_deduced[[auto]] $Variable_def[[AF]] = $Class[[Foo]]();
   $Class_deduced[[decltype]](auto) $Variable_def[[AF2]] = $Class[[Foo]]();
-  $Class_deduced[[auto]] *$Variable_def[[AFP]] = &$Variable[[AF]];
+  $Class_deduced[[auto]] *$Variable_def[[AFP]] = $Operator[[&]]$Variable[[AF]];
   $Enum_deduced[[auto]] &$Variable_def[[AER]] = $Variable[[AE]];
-  $Primitive_deduced_defaultLibrary[[auto]] $Variable_def[[Form]] = 10.2 + 2 * 4;
+  $Primitive_deduced_defaultLibrary[[auto]] $Variable_def[[Form]] = 10.2 $Operator[[+]] 2 $Operator[[*]] 4;
   $Primitive_deduced_defaultLibrary[[decltype]]($Variable[[Form]]) $Variable_def[[F]] = 10;
   auto $Variable_def[[Fun]] = []()->void{};
 )cpp",
@@ -342,21 +342,21 @@
   template
   class $Class_def[[IP]] {
 void $Method_def[[f]]() {
-  *$TemplateParameter_readonly[[U]] += 5;
+  $Operator[[*]]$TemplateParameter_readonly[[U]] $Operator[[+=]] 5;
 }
   };
   template
   class $Class_def[[Foo]] {
 void $Method_def[[f]]() {
   for(int $LocalVariable_def[[I]] = 0;
-$LocalVariable[[I]] < $TemplateParamet

[PATCH] D136594: [clangd] Add support for semantic token type "operator"

2022-11-22 Thread Christian Kandeler via Phabricator via cfe-commits
ckandeler added a comment.

> Should I perhaps add the augmentsSyntaxTokens option and rebase this patch to 
> make it its first user?

So I went ahead and did this. Opinions?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D136594/new/

https://reviews.llvm.org/D136594

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D136176: Implement support for option 'fexcess-precision'.

2022-11-22 Thread Zahira Ammarguellat via Phabricator via cfe-commits
zahiraam updated this revision to Diff 477179.

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D136176/new/

https://reviews.llvm.org/D136176

Files:
  clang/docs/UsersManual.rst
  clang/include/clang/Basic/FPOptions.def
  clang/include/clang/Basic/LangOptions.def
  clang/include/clang/Basic/LangOptions.h
  clang/include/clang/Driver/Options.td
  clang/lib/CodeGen/CGExprScalar.cpp
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/test/CodeGen/X86/fexcess-precision.c
  clang/test/Driver/clang_f_opts.c
  clang/test/Driver/fexcess-precision.c

Index: clang/test/Driver/fexcess-precision.c
===
--- /dev/null
+++ clang/test/Driver/fexcess-precision.c
@@ -0,0 +1,30 @@
+// RUN: %clang -### -target i386 -fexcess-precision=fast -c %s 2>&1  \
+// RUN:   | FileCheck --check-prefix=CHECK-FAST %s
+// RUN: %clang -### -target i386 -fexcess-precision=standard -c %s 2>&1  \
+// RUN:   | FileCheck --check-prefix=CHECK-STD %s
+
+// RUN: %clang -### -target x86_64 -fexcess-precision=fast -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-FAST %s
+// RUN: %clang -### -target x86_64 -fexcess-precision=standard -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-STD %s
+
+// RUN: %clang -### -target i386 -fexcess-precision=none -c %s 2>&1  \
+// RUN:   | FileCheck --check-prefix=CHECK-ERR-ARG %s
+
+// RUN: %clang -### -target x86_64 -fexcess-precision=none -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefixes=CHECK-ERR-ARG %s
+
+// RUN: %clang -### -target i386 -fexcess-precision=none -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefixes=CHECK-ERR-ARG %s
+
+// RUN: %clang -### -target i386 -fexcess-precision=16 -c %s 2>&1  \
+// RUN:   | FileCheck --check-prefix=CHECK-ERR-I386 %s
+
+// RUN: %clang -### -target x86_64 -fexcess-precision=16 -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-ERR-X64 %s
+
+// CHECK-FAST: "-ffloat16-excess-precision=fast"
+// CHECK-STD: "-ffloat16-excess-precision=standard"
+// CHECK-ERR-I386: error: unsupported option '-fexcess-precision=16' for target 'i386'
+// CHECK-ERR-X64: error: unsupported option '-fexcess-precision=16' for target 'x86_64'
+// CHECK-ERR-ARG: unsupported argument 'none' to option '-fexcess-precision='
Index: clang/test/Driver/clang_f_opts.c
===
--- clang/test/Driver/clang_f_opts.c
+++ clang/test/Driver/clang_f_opts.c
@@ -398,7 +398,7 @@
 // CHECK-WARNING-DAG: optimization flag '-falign-loops' is not supported
 // CHECK-WARNING-DAG: optimization flag '-falign-jumps' is not supported
 // CHECK-WARNING-DAG: optimization flag '-falign-jumps=100' is not supported
-// CHECK-WARNING-DAG: optimization flag '-fexcess-precision=100' is not supported
+// CHECK-WARNING-DAG: unsupported argument '100' to option '-fexcess-precision='
 // CHECK-WARNING-DAG: optimization flag '-fbranch-count-reg' is not supported
 // CHECK-WARNING-DAG: optimization flag '-fcaller-saves' is not supported
 // CHECK-WARNING-DAG: optimization flag '-fno-default-inline' is not supported
Index: clang/test/CodeGen/X86/fexcess-precision.c
===
--- /dev/null
+++ clang/test/CodeGen/X86/fexcess-precision.c
@@ -0,0 +1,286 @@
+// NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py
+// RUN: %clang_cc1 -triple x86_64-unknown-unknown -ffloat16-excess-precision=fast \
+// RUN: -emit-llvm -o - %s \
+// RUN: | FileCheck -check-prefixes=CHECK-EXT %s
+
+// RUN: %clang_cc1 -triple x86_64-unknown-unknown -ffloat16-excess-precision=standard \
+// RUN: -emit-llvm -o - %s \
+// RUN: | FileCheck -check-prefixes=CHECK-EXT %s
+
+// RUN: %clang_cc1 -triple x86_64-unknown-unknown -ffloat16-excess-precision=none \
+// RUN: -emit-llvm -o - %s \
+// RUN: | FileCheck -check-prefixes=CHECK-NO-EXT %s
+
+// RUN: %clang_cc1 -triple x86_64-unknown-unknown -ffloat16-excess-precision=fast \
+// RUN: -emit-llvm -ffp-eval-method=source -o - %s \
+// RUN: | FileCheck -check-prefixes=CHECK-EXT %s
+
+// RUN: %clang_cc1 -triple x86_64-unknown-unknown -ffloat16-excess-precision=standard \
+// RUN: -emit-llvm -ffp-eval-method=source -o - %s \
+// RUN: | FileCheck -check-prefixes=CHECK-EXT %s
+
+// RUN: %clang_cc1 -triple x86_64-unknown-unknown -ffloat16-excess-precision=none \
+// RUN: -emit-llvm -ffp-eval-method=source -o - %s \
+// RUN: | FileCheck -check-prefixes=CHECK-NO-EXT %s
+
+// RUN: %clang_cc1 -triple x86_64-unknown-unknown -ffloat16-excess-precision=fast \
+// RUN: -emit-llvm -ffp-eval-method=double -o - %s \
+// RUN: | FileCheck -check-prefixes=CHECK-EXT-DBL %s
+
+// RUN: %clang_cc1 -triple x86_64-unknown-unknown -ffloat16-excess-precision=standard \
+// RUN: -emit-llvm -ffp-eval-method=double -o - %s \
+// RUN: | FileCheck -check-prefixes=CHECK-EXT-DBL %s
+
+// RUN: %clang_cc1 -triple x86_64-unknown-unknown -ffloat16-excess-precision=none \
+// RUN: -emit-llvm -ffp-eval-method=double -o - %s \
+// RUN: | FileCheck -ch

[PATCH] D137348: [-Wunsafe-buffer-usage] Introduce an abstraction for fixable code patterns.

2022-11-22 Thread Balázs Benics via Phabricator via cfe-commits
steakhal added inline comments.



Comment at: clang/lib/Analysis/UnsafeBufferUsage.cpp:40
+
+  /// Determine if a kind is a safe kind. Slower than calling isSafe().
+  static bool isSafeKind(Kind K) {

We could have a `GADGET_RANGE(UnsafeGadgets, Increment, Decrement)`, which 
could expand to `BEGIN_##x = Increment, END_##x = Decrement,` when declaring 
the `Kind` enum, similarly how `SymExpr::Kind::Begin_BINARYSYMEXPRS` is defined.
That way this code could look like:
```lang=C++
return !(Kind::Begin_UnsafeGadgets <= K && K <= Kind::End_UnsafeGadgets);
```



Comment at: clang/lib/Analysis/UnsafeBufferUsage.cpp:43-45
+#define UNSAFE_GADGET(x)   
\
+case Kind::x:
+#include "clang/Analysis/Analyses/UnsafeBufferUsageGadgets.def"

I'd advocate for using the same macro variable name here as an XMACRO argument 
as it's present in the definition as parameter.
Same for the rest of the XMACRO expansions.



Comment at: clang/lib/Analysis/UnsafeBufferUsage.cpp:87
+  static bool classof(const Gadget *G) { return !isSafeKind(G->getKind()); }
+  bool isSafe() const override { return false; }
+};





Comment at: clang/lib/Analysis/UnsafeBufferUsage.cpp:102
+  static bool classof(const Gadget *G) { return isSafeKind(G->getKind()); }
+  bool isSafe() const override { return true; }
+};





Comment at: clang/lib/Analysis/UnsafeBufferUsage.cpp:123
+  hasUnaryOperand(ignoringParenImpCasts(hasPointerType()))
+).bind("op"));
+  }

I thought this matcher was already bound as `"Increment"` by `x ## 
Gadget::matcher().bind(#x)` inside `GadgetFinderCallback::run()`



Comment at: clang/lib/Analysis/UnsafeBufferUsage.cpp:150
+
+  const Stmt *getBaseStmt() const override { return Op; }
+};

I'd advocate for covariant return types for such cases.



Comment at: clang/lib/Analysis/UnsafeBufferUsage.cpp:163
 
 void run(const MatchFinder::MatchResult &Result) override {
+  // Figure out which matcher we've found, and call the appropriate

I wonder if we should assert that we only expect exactly one match (entry) 
inside `Result.Nodes`.



Comment at: clang/lib/Analysis/UnsafeBufferUsage.cpp:190-191
+#undef GADGET
+// FIXME: Is there a better way to avoid hanging comma?
+unless(stmt())
+  ))

I was thinking of constructing a `std::vector` of the matchers 
of the disjunction because the extra comma is allowed inside the initializer 
expression.
After that, you could probably use `constructVariadic(VO_AnyOf, ...)` as 
demonstrated by the `TEST(ConstructVariadic, MismatchedTypes_Regression)` 
unit-test. But TBH, I don't think it's more readable than this :D


Repository:
  rC Clang

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D137348/new/

https://reviews.llvm.org/D137348

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D134859: [clang][Interp] Implement basic support for floating point values

2022-11-22 Thread Timm Bäder via Phabricator via cfe-commits
tbaeder added a comment.

FYI, I noticed the way the floating values are serialized doesn't work if the 
`APFloat` heap-allocated anything; those values aren't preserved through 
(de)serialization of course.

Reproducer:

  constexpr double foo() {
return __LDBL_MIN__;
  }


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D134859/new/

https://reviews.llvm.org/D134859

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D138391: clang/HIP: Add new header test for math IR gen

2022-11-22 Thread Yaxun Liu via Phabricator via cfe-commits
yaxunl accepted this revision.
yaxunl added a comment.

LGTM. Thanks.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D138391/new/

https://reviews.llvm.org/D138391

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D137642: [X86][CodeGen] Fix crash in hotpatch

2022-11-22 Thread Sylvain Audi via Phabricator via cfe-commits
saudi updated this revision to Diff 477182.
saudi added a comment.

Small update: improve comments, remove empty line modification


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D137642/new/

https://reviews.llvm.org/D137642

Files:
  clang/lib/CodeGen/CodeGenFunction.cpp
  llvm/include/llvm/Support/TargetOpcodes.def
  llvm/lib/CodeGen/PatchableFunction.cpp
  llvm/lib/Target/X86/X86MCInstLower.cpp
  llvm/test/CodeGen/X86/patchable-prologue-debuginfo.ll
  llvm/test/CodeGen/X86/patchable-prologue.ll

Index: llvm/test/CodeGen/X86/patchable-prologue.ll
===
--- llvm/test/CodeGen/X86/patchable-prologue.ll
+++ llvm/test/CodeGen/X86/patchable-prologue.ll
@@ -5,10 +5,6 @@
 ; RUN: llc -verify-machineinstrs -show-mc-encoding -mtriple=i386-windows-msvc -mcpu=pentium3 < %s | FileCheck %s --check-prefixes=32,MOV
 ; RUN: llc -verify-machineinstrs -show-mc-encoding -mtriple=i386-windows-msvc -mcpu=pentium4 < %s | FileCheck %s --check-prefixes=32,XCHG
 ; RUN: llc -verify-machineinstrs -show-mc-encoding -mtriple=x86_64-windows-msvc < %s | FileCheck %s --check-prefix=64
-; RUN: llc -verify-machineinstrs -show-mc-encoding -mtriple=i386-unknown-linux-code16 < %s | FileCheck %s --check-prefix=16
-
-; 16-NOT: movl   %edi, %edi
-; 16-NOT: xchgw   %ax, %ax
 
 declare void @callee(ptr)
 
@@ -135,3 +131,63 @@
   %tmp22 = phi i32 [ %tmp12, %bb ], [ %arg3, %bb16 ]
   ret i32 %tmp22
 }
+
+; This testcase produces an empty function (not even a ret on some targets).
+; This scenario can happen with undefined behavior.
+; Ensure that the "patchable-function" pass supports this case.
+; CHECK-LABEL: _emptyfunc
+; CHECK-NEXT: 0f 0b 	ud2
+
+; CHECK-ALIGN: 	.p2align	4, 0x90
+; CHECK-ALIGN: _emptyfunc:
+
+; 32: emptyfunc:
+; 32CFI-NEXT: .cfi_startproc
+; 32-NEXT: # %bb.0:
+; XCHG-NEXT: xchgw   %ax, %ax
+; MOV-NEXT: movl   %edi, %edi
+
+; 64: emptyfunc:
+; 64-NEXT: # %bb.0:
+; 64-NEXT: xchgw   %ax, %ax
+
+; From code: int emptyfunc() {}
+define i32 @emptyfunc() "patchable-function"="prologue-short-redirect" {
+  unreachable
+}
+
+
+; Hotpatch feature must ensure no jump within the function goes to the first instruction.
+; From code:
+; void jmp_to_start(char *b) {
+;   do {
+;   } while ((++(*b++)));
+; }
+
+; CHECK-ALIGN: 	.p2align	4, 0x90
+; CHECK-ALIGN: _jmp_to_start:
+
+; 32: jmp_to_start:
+; 32CFI-NEXT: .cfi_startproc
+; 32-NEXT: # %bb.0:
+; XCHG-NEXT: xchgw   %ax, %ax
+; MOV-NEXT: movl   %edi, %edi
+
+; 64: jmp_to_start:
+; 64-NEXT: # %bb.0:
+; 64-NEXT: xchgw   %ax, %ax
+
+define dso_local void @jmp_to_start(ptr inreg nocapture noundef %b) "patchable-function"="prologue-short-redirect" {
+entry:
+  br label %do.body
+do.body:  ; preds = %do.body, %entry
+  %b.addr.0 = phi ptr [ %b, %entry ], [ %incdec.ptr, %do.body ]
+  %incdec.ptr = getelementptr inbounds i8, ptr %b.addr.0, i64 1
+  %0 = load i8, ptr %b.addr.0, align 1
+  %inc = add i8 %0, 1
+  store i8 %inc, ptr %b.addr.0, align 1
+  %tobool.not = icmp eq i8 %inc, 0
+  br i1 %tobool.not, label %do.end, label %do.body
+do.end:   ; preds = %do.body
+  ret void
+}
Index: llvm/test/CodeGen/X86/patchable-prologue-debuginfo.ll
===
--- /dev/null
+++ llvm/test/CodeGen/X86/patchable-prologue-debuginfo.ll
@@ -0,0 +1,56 @@
+; RUN: llc -verify-machineinstrs < %s | FileCheck %s --check-prefix=CHECK
+
+; Regression test for function patching asserting in some cases when debug info activated.
+; The code below reproduces this crash.
+
+; Compilation flag:  clang -target x86_64-none-linux-gnu -c -O2 -g -fms-hotpatch patchable-prologue-debuginfo.c
+; int func( int val ) {
+;   int neg = -val;
+;   return neg + 1;
+; }
+
+; CHECK: # -- Begin function func
+
+; ModuleID = 'patchable-prologue-debuginfo.c'
+source_filename = "patchable-prologue-debuginfo.c"
+target datalayout = "e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-f80:128-n8:16:32:64-S128"
+target triple = "x86_64-none-linux-gnu"
+
+; Function Attrs: mustprogress nofree norecurse nosync nounwind readnone willreturn uwtable
+define dso_local i32 @func(i32 noundef %val) local_unnamed_addr #0 !dbg !9 {
+entry:
+  call void @llvm.dbg.value(metadata i32 %val, metadata !14, metadata !DIExpression()), !dbg !16
+  call void @llvm.dbg.value(metadata !DIArgList(i32 0, i32 %val), metadata !15, metadata !DIExpression(DW_OP_LLVM_arg, 0, DW_OP_LLVM_arg, 1, DW_OP_minus, DW_OP_stack_value)), !dbg !16
+  %add = sub i32 1, %val, !dbg !17
+  ret i32 %add, !dbg !18
+}
+
+; Function Attrs: nocallback nofree nosync nounwind readnone speculatable willreturn
+declare void @llvm.dbg.value(metadata, metadata, metadata) #1
+
+attributes #0 = { mustprogress nofree norecurse nosync nounwind readnone willreturn uwtable "frame-pointer"="none" "min-legal-vector-width"="0" "no-trapping-math"="true" "patchable-function"="prologue

[PATCH] D137948: [clang][dataflow] Add widening API and implement it for built-in boolean model.

2022-11-22 Thread Stanislav Gatev via Phabricator via cfe-commits
sgatev accepted this revision.
sgatev added inline comments.



Comment at: clang/include/clang/Analysis/FlowSensitive/DataflowEnvironment.h:467
+
+  //`DeclContext` of the block being analysed if provided.
   std::vector CallStack;





Comment at: clang/lib/Analysis/FlowSensitive/DataflowEnvironment.cpp:418-419
+Effect = LatticeJoinEffect::Changed;
+
+
+  return Effect;




Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D137948/new/

https://reviews.llvm.org/D137948

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D137379: [-Wunsafe-buffer-usage] Add warnings for unsafe buffer accesses by array subscript operations

2022-11-22 Thread Balázs Benics via Phabricator via cfe-commits
steakhal added inline comments.



Comment at: clang/test/SemaCXX/warn-unsafe-buffer-usage.cpp:10-13
+void foo(...);
+
+void * bar(void);
+char * baz(void);

I would expect this test file to grow quite a bit.
As such, I think we should have more self-descriptive names for these functions.

I'm also curious what's the purpose of `foo()`in the examples.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D137379/new/

https://reviews.llvm.org/D137379

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D138499: [clangd] Extract Function: add hoisting support

2022-11-22 Thread Julian Schmidt via Phabricator via cfe-commits
5chmidti created this revision.
5chmidti added a reviewer: sammccall.
Herald added subscribers: kadircet, arphaman.
Herald added a project: All.
5chmidti requested review of this revision.
Herald added subscribers: cfe-commits, MaskRay, ilya-biryukov.
Herald added a project: clang-tools-extra.

Adds support to hoist variables declared inside the selected region
and used afterwards back out of the extraced function for later use.
Uses the explicit variable type if only one decl needs hoisting,
otherwise pair or tuple with auto return type deduction
(requires c++14) and a structured binding (requires c++17) or
explicitly unpacking the variables with get<>.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D138499

Files:
  clang-tools-extra/clangd/refactor/tweaks/ExtractFunction.cpp
  clang-tools-extra/clangd/unittests/tweaks/ExtractFunctionTests.cpp
  clang-tools-extra/docs/ReleaseNotes.rst

Index: clang-tools-extra/docs/ReleaseNotes.rst
===
--- clang-tools-extra/docs/ReleaseNotes.rst
+++ clang-tools-extra/docs/ReleaseNotes.rst
@@ -78,6 +78,9 @@
 Miscellaneous
 ^
 
+- The extract function tweak gained support for hoisting, i.e. returning decls declared
+  inside the selection that are used outside of the selection.
+
 Improvements to clang-doc
 -
 
Index: clang-tools-extra/clangd/unittests/tweaks/ExtractFunctionTests.cpp
===
--- clang-tools-extra/clangd/unittests/tweaks/ExtractFunctionTests.cpp
+++ clang-tools-extra/clangd/unittests/tweaks/ExtractFunctionTests.cpp
@@ -30,8 +30,9 @@
   EXPECT_EQ(apply("auto lam = [](){ [[int x;]] }; "), "unavailable");
   // Partial statements aren't extracted.
   EXPECT_THAT(apply("int [[x = 0]];"), "unavailable");
-  // FIXME: Support hoisting.
-  EXPECT_THAT(apply(" [[int a = 5;]] a++; "), "unavailable");
+
+  // Extract regions that require hoisting
+  EXPECT_THAT(apply(" [[int a = 5;]] a++; "), HasSubstr("extracted"));
 
   // Ensure that end of Zone and Beginning of PostZone being adjacent doesn't
   // lead to break being included in the extraction zone.
@@ -192,6 +193,202 @@
   EXPECT_EQ(apply(CompoundFailInput), "unavailable");
 }
 
+TEST_F(ExtractFunctionTest, Hoisting) {
+  std::string HoistingInput = R"cpp(
+int foo() {
+  int a = 3;
+  [[int x = 39 + a;
+  ++x;
+  int y = x * 2;
+  int z = 4;]]
+  return x + y + z;
+}
+  )cpp";
+  std::string HoistingOutput = R"cpp(
+auto extracted(int &a) {
+int x = 39 + a;
+  ++x;
+  int y = x * 2;
+  int z = 4;
+return std::tuple{x, y, z};
+}
+int foo() {
+  int a = 3;
+  auto [x, y, z] = extracted(a);
+  return x + y + z;
+}
+  )cpp";
+  EXPECT_EQ(apply(HoistingInput), HoistingOutput);
+
+  std::string HoistingInput2 = R"cpp(
+int foo() {
+  int a{};
+  [[int b = a + 1;]]
+  return b;
+}
+  )cpp";
+  std::string HoistingOutput2 = R"cpp(
+int extracted(int &a) {
+int b = a + 1;
+return b;
+}
+int foo() {
+  int a{};
+  auto b = extracted(a);
+  return b;
+}
+  )cpp";
+  EXPECT_EQ(apply(HoistingInput2), HoistingOutput2);
+
+  std::string HoistingInput3 = R"cpp(
+int foo(int b) {
+  int a{};
+  if (b == 42) {
+[[a = 123;
+return a + b;]]
+  }
+  a = 456;
+  return a;
+}
+  )cpp";
+  std::string HoistingOutput3 = R"cpp(
+int extracted(int &b, int &a) {
+a = 123;
+return a + b;
+}
+int foo(int b) {
+  int a{};
+  if (b == 42) {
+return extracted(b, a);
+  }
+  a = 456;
+  return a;
+}
+  )cpp";
+  EXPECT_EQ(apply(HoistingInput3), HoistingOutput3);
+
+  std::string HoistingInput4 = R"cpp(
+struct A {
+  bool flag;
+  int val;
+};
+A bar();
+int foo(int b) {
+  int a = 0;
+  [[auto [flag, val] = bar();
+  int c = 4;
+  val = c + a;]]
+  return a + b + c + val;
+}
+  )cpp";
+  std::string HoistingOutput4 = R"cpp(
+struct A {
+  bool flag;
+  int val;
+};
+A bar();
+auto extracted(int &a) {
+auto [flag, val] = bar();
+  int c = 4;
+  val = c + a;
+return std::pair{val, c};
+}
+int foo(int b) {
+  int a = 0;
+  auto [val, c] = extracted(a);
+  return a + b + c + val;
+}
+  )cpp";
+  EXPECT_EQ(apply(HoistingInput4), HoistingOutput4);
+}
+
+TEST_F(ExtractFunctionTest, HoistingCXX11) {
+  ExtraArgs.emplace_back("-std=c++11");
+  std::string HoistingInput = R"cpp(
+int foo() {
+  int a = 3;
+  [[int x = 39 + a;
+  ++x;
+  int y = x * 2;
+  int z = 4;]]
+  return x + y + z;
+}
+  )cpp";
+  EXPECT_THAT(apply(HoistingInput), HasSubstr("unavailable"));
+
+  std::string HoistingInput2 = R"cpp(
+int foo() {
+  int a;
+  [[int b = a + 1;]]
+  return b;
+}
+  )cpp";
+  std::string HoistingOutput2 = R"cpp(
+int extracted(int &a) {
+i

[PATCH] D137044: [ClangFE] Add support for option -mno-pic-data-is-text-relative

2022-11-22 Thread Jonas Paulsson via Phabricator via cfe-commits
jonpa added a comment.

In D137044#3943829 , @Fznamznon wrote:

> In D137044#3943680 , @jonpa wrote:
>
>> In D137044#3942990 , @pcwang-thead 
>> wrote:
>>
>>> The test `clang/test/Driver/pic.c` failed when we compiled Clang/LLVM with 
>>> `-DCLANG_DEFAULT_PIE_ON_LINUX=False`.
>>
>> Ah... I suppose that must be because -mno-pic-data-is-text-relative requires 
>> PIC (this is per GCC behavior). Does it help if you add -fpic to the RUN 
>> lines that were added by this patch? I was not aware of the cmake flag, 
>> sorry.
>
> For me it does. Can we make this change?

Yes, that should be fine as the test is assuming pic by default. Thanks.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D137044/new/

https://reviews.llvm.org/D137044

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D138499: [clangd] Extract Function: add hoisting support

2022-11-22 Thread Julian Schmidt via Phabricator via cfe-commits
5chmidti updated this revision to Diff 477184.
5chmidti added a comment.

Fixup: rm added includes


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D138499/new/

https://reviews.llvm.org/D138499

Files:
  clang-tools-extra/clangd/refactor/tweaks/ExtractFunction.cpp
  clang-tools-extra/clangd/unittests/tweaks/ExtractFunctionTests.cpp
  clang-tools-extra/docs/ReleaseNotes.rst

Index: clang-tools-extra/docs/ReleaseNotes.rst
===
--- clang-tools-extra/docs/ReleaseNotes.rst
+++ clang-tools-extra/docs/ReleaseNotes.rst
@@ -78,6 +78,9 @@
 Miscellaneous
 ^
 
+- The extract function tweak gained support for hoisting, i.e. returning decls declared
+  inside the selection that are used outside of the selection.
+
 Improvements to clang-doc
 -
 
Index: clang-tools-extra/clangd/unittests/tweaks/ExtractFunctionTests.cpp
===
--- clang-tools-extra/clangd/unittests/tweaks/ExtractFunctionTests.cpp
+++ clang-tools-extra/clangd/unittests/tweaks/ExtractFunctionTests.cpp
@@ -30,8 +30,9 @@
   EXPECT_EQ(apply("auto lam = [](){ [[int x;]] }; "), "unavailable");
   // Partial statements aren't extracted.
   EXPECT_THAT(apply("int [[x = 0]];"), "unavailable");
-  // FIXME: Support hoisting.
-  EXPECT_THAT(apply(" [[int a = 5;]] a++; "), "unavailable");
+
+  // Extract regions that require hoisting
+  EXPECT_THAT(apply(" [[int a = 5;]] a++; "), HasSubstr("extracted"));
 
   // Ensure that end of Zone and Beginning of PostZone being adjacent doesn't
   // lead to break being included in the extraction zone.
@@ -192,6 +193,202 @@
   EXPECT_EQ(apply(CompoundFailInput), "unavailable");
 }
 
+TEST_F(ExtractFunctionTest, Hoisting) {
+  std::string HoistingInput = R"cpp(
+int foo() {
+  int a = 3;
+  [[int x = 39 + a;
+  ++x;
+  int y = x * 2;
+  int z = 4;]]
+  return x + y + z;
+}
+  )cpp";
+  std::string HoistingOutput = R"cpp(
+auto extracted(int &a) {
+int x = 39 + a;
+  ++x;
+  int y = x * 2;
+  int z = 4;
+return std::tuple{x, y, z};
+}
+int foo() {
+  int a = 3;
+  auto [x, y, z] = extracted(a);
+  return x + y + z;
+}
+  )cpp";
+  EXPECT_EQ(apply(HoistingInput), HoistingOutput);
+
+  std::string HoistingInput2 = R"cpp(
+int foo() {
+  int a{};
+  [[int b = a + 1;]]
+  return b;
+}
+  )cpp";
+  std::string HoistingOutput2 = R"cpp(
+int extracted(int &a) {
+int b = a + 1;
+return b;
+}
+int foo() {
+  int a{};
+  auto b = extracted(a);
+  return b;
+}
+  )cpp";
+  EXPECT_EQ(apply(HoistingInput2), HoistingOutput2);
+
+  std::string HoistingInput3 = R"cpp(
+int foo(int b) {
+  int a{};
+  if (b == 42) {
+[[a = 123;
+return a + b;]]
+  }
+  a = 456;
+  return a;
+}
+  )cpp";
+  std::string HoistingOutput3 = R"cpp(
+int extracted(int &b, int &a) {
+a = 123;
+return a + b;
+}
+int foo(int b) {
+  int a{};
+  if (b == 42) {
+return extracted(b, a);
+  }
+  a = 456;
+  return a;
+}
+  )cpp";
+  EXPECT_EQ(apply(HoistingInput3), HoistingOutput3);
+
+  std::string HoistingInput4 = R"cpp(
+struct A {
+  bool flag;
+  int val;
+};
+A bar();
+int foo(int b) {
+  int a = 0;
+  [[auto [flag, val] = bar();
+  int c = 4;
+  val = c + a;]]
+  return a + b + c + val;
+}
+  )cpp";
+  std::string HoistingOutput4 = R"cpp(
+struct A {
+  bool flag;
+  int val;
+};
+A bar();
+auto extracted(int &a) {
+auto [flag, val] = bar();
+  int c = 4;
+  val = c + a;
+return std::pair{val, c};
+}
+int foo(int b) {
+  int a = 0;
+  auto [val, c] = extracted(a);
+  return a + b + c + val;
+}
+  )cpp";
+  EXPECT_EQ(apply(HoistingInput4), HoistingOutput4);
+}
+
+TEST_F(ExtractFunctionTest, HoistingCXX11) {
+  ExtraArgs.emplace_back("-std=c++11");
+  std::string HoistingInput = R"cpp(
+int foo() {
+  int a = 3;
+  [[int x = 39 + a;
+  ++x;
+  int y = x * 2;
+  int z = 4;]]
+  return x + y + z;
+}
+  )cpp";
+  EXPECT_THAT(apply(HoistingInput), HasSubstr("unavailable"));
+
+  std::string HoistingInput2 = R"cpp(
+int foo() {
+  int a;
+  [[int b = a + 1;]]
+  return b;
+}
+  )cpp";
+  std::string HoistingOutput2 = R"cpp(
+int extracted(int &a) {
+int b = a + 1;
+return b;
+}
+int foo() {
+  int a;
+  auto b = extracted(a);
+  return b;
+}
+  )cpp";
+  EXPECT_EQ(apply(HoistingInput2), HoistingOutput2);
+}
+
+TEST_F(ExtractFunctionTest, HoistingCXX14) {
+  ExtraArgs.emplace_back("-std=c++14");
+  std::string HoistingInput = R"cpp(
+int foo() {
+  int a = 3;
+  [[int x = 39 + a;
+  ++x;
+  int y = x * 2;
+  int z = 4;]]
+  return x + y + z;
+}
+  )cpp";
+  std::string HoistingOutput = R"cpp(

[clang] 056ebad - [HIP] Fix lld failure when devie object is empty

2022-11-22 Thread Yaxun Liu via cfe-commits

Author: Yaxun (Sam) Liu
Date: 2022-11-22T10:38:42-05:00
New Revision: 056ebadf5c75df6568ea3dda879518e1edc1f48f

URL: 
https://github.com/llvm/llvm-project/commit/056ebadf5c75df6568ea3dda879518e1edc1f48f
DIFF: 
https://github.com/llvm/llvm-project/commit/056ebadf5c75df6568ea3dda879518e1edc1f48f.diff

LOG: [HIP] Fix lld failure when devie object is empty

When -fgpu-rdc is used for linking relocatable objects, clang driver launches
clang-offload-bundler to extract a device relocatable object from each input
relocatable object file and passes the extracted files to lld. The input 
relocatable
object file could either come from HIP program or C++ program. The relocatable
object file from C++ program does not contain device relocatable objects, 
therefore
clang-offload-bundler extracts an empty file and passes it to lld. lld treates
empty file as linker script. When there is no object input file to lld, lld
will emit error:

target emulation unknown: -m or at least one .o file required

This patch adds "elf64_amdgpu" to lld so that lld always know the target
no matter whether there are object input files or not.

Reviewed by: Artem Belevich, Fangrui Song

Differential Revision: https://reviews.llvm.org/D138221

Added: 
lld/test/ELF/emulation-amdgpu.s

Modified: 
clang/lib/Driver/ToolChains/HIPAMD.cpp
clang/test/Driver/hip-toolchain-device-only.hip
clang/test/Driver/hip-toolchain-no-rdc.hip
lld/ELF/Driver.cpp

Removed: 




diff  --git a/clang/lib/Driver/ToolChains/HIPAMD.cpp 
b/clang/lib/Driver/ToolChains/HIPAMD.cpp
index 1951ac12515d8..c64421d259ce1 100644
--- a/clang/lib/Driver/ToolChains/HIPAMD.cpp
+++ b/clang/lib/Driver/ToolChains/HIPAMD.cpp
@@ -108,7 +108,12 @@ void AMDGCN::Linker::constructLldCommand(Compilation &C, 
const JobAction &JA,
  const llvm::opt::ArgList &Args) const 
{
   // Construct lld command.
   // The output from ld.lld is an HSA code object file.
-  ArgStringList LldArgs{"-flavor", "gnu", "--no-undefined", "-shared",
+  ArgStringList LldArgs{"-flavor",
+"gnu",
+"-m",
+"elf64_amdgpu",
+"--no-undefined",
+"-shared",
 "-plugin-opt=-amdgpu-internalize-symbols"};
 
   auto &TC = getToolChain();

diff  --git a/clang/test/Driver/hip-toolchain-device-only.hip 
b/clang/test/Driver/hip-toolchain-device-only.hip
index 9e4a36f9628b9..c6ff67bde738c 100644
--- a/clang/test/Driver/hip-toolchain-device-only.hip
+++ b/clang/test/Driver/hip-toolchain-device-only.hip
@@ -12,7 +12,7 @@
 // CHECK-SAME: "-target-cpu" "gfx803"
 // CHECK-SAME: {{.*}} "-o" [[OBJ_DEV_A_803:".*o"]] "-x" "hip"
 
-// CHECK: [[LLD: ".*lld.*"]] "-flavor" "gnu" "--no-undefined" "-shared"
+// CHECK: [[LLD: ".*lld.*"]] "-flavor" "gnu" "-m" "elf64_amdgpu" 
"--no-undefined" "-shared"
 // CHECK-SAME: "-o" "[[IMG_DEV_A_803:.*out]]" [[OBJ_DEV_A_803]]
 
 // CHECK: [[CLANG:".*clang.*"]] "-cc1"{{.*}} "-triple" "amdgcn-amd-amdhsa"
@@ -21,7 +21,7 @@
 // CHECK-SAME: "-target-cpu" "gfx900"
 // CHECK-SAME: {{.*}} "-o" [[OBJ_DEV_A_900:".*o"]] "-x" "hip"
 
-// CHECK: [[LLD]] "-flavor" "gnu" "--no-undefined" "-shared"
+// CHECK: [[LLD]] "-flavor" "gnu" "-m" "elf64_amdgpu" "--no-undefined" 
"-shared"
 // CHECK-SAME: "-o" "[[IMG_DEV_A_900:.*out]]" [[OBJ_DEV_A_900]]
 
 // CHECK: [[BUNDLER:".*clang-offload-bundler"]] "-type=o"

diff  --git a/clang/test/Driver/hip-toolchain-no-rdc.hip 
b/clang/test/Driver/hip-toolchain-no-rdc.hip
index 2cd44ca78eb8d..4ae054b62fb7f 100644
--- a/clang/test/Driver/hip-toolchain-no-rdc.hip
+++ b/clang/test/Driver/hip-toolchain-no-rdc.hip
@@ -59,7 +59,7 @@
 // CHECK-NOT: {{".*opt"}}
 // CHECK-NOT: {{".*llc"}}
 
-// CHECK: [[LLD: ".*lld.*"]] "-flavor" "gnu" "--no-undefined" "-shared"
+// CHECK: [[LLD: ".*lld.*"]] "-flavor" "gnu" "-m" "elf64_amdgpu" 
"--no-undefined" "-shared"
 // CHECK-SAME: "-o" "[[IMG_DEV_A_803:.*out]]" [[OBJ_DEV_A_803]]
 
 //
@@ -82,7 +82,7 @@
 // CHECK-NOT: {{".*opt"}}
 // CHECK-NOT: {{".*llc"}}
 
-// CHECK: [[LLD]] "-flavor" "gnu" "--no-undefined" "-shared"
+// CHECK: [[LLD]] "-flavor" "gnu" "-m" "elf64_amdgpu" "--no-undefined" 
"-shared"
 // CHECK-SAME: "-o" "[[IMG_DEV_A_900:.*out]]" [[OBJ_DEV_A_900]]
 
 //
@@ -122,7 +122,7 @@
 // CHECK-NOT: {{".*opt"}}
 // CHECK-NOT: {{".*llc"}}
 
-// CHECK: [[LLD]] "-flavor" "gnu" "--no-undefined" "-shared"
+// CHECK: [[LLD]] "-flavor" "gnu" "-m" "elf64_amdgpu" "--no-undefined" 
"-shared"
 // CHECK-SAME: "-o" "[[IMG_DEV_B_803:.*out]]" [[OBJ_DEV_B_803]]
 
 //
@@ -145,7 +145,7 @@
 // CHECK-NOT: {{".*opt"}}
 // CHECK-NOT: {{".*llc"}}
 
-// CHECK: [[LLD]] "-flavor" "gnu" "--no-undefined" "-shared"
+// CHECK: [[LLD]] "-flavor" "gnu" "-m" "elf64_amdgpu" "--no-undefined" 
"-shared"
 // CHECK-SAME: "-o" "[[IMG_DEV_B_900:.*out]]" [[OBJ_DEV_B_900]]
 
 //

diff  --git a/lld/ELF/Driver.cpp b/lld/ELF/D

[PATCH] D138221: [HIP] Fix lld failure when devie object is empty

2022-11-22 Thread Yaxun Liu via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG056ebadf5c75: [HIP] Fix lld failure when devie object is 
empty (authored by yaxunl).
Herald added a project: clang.

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D138221/new/

https://reviews.llvm.org/D138221

Files:
  clang/lib/Driver/ToolChains/HIPAMD.cpp
  clang/test/Driver/hip-toolchain-device-only.hip
  clang/test/Driver/hip-toolchain-no-rdc.hip
  lld/ELF/Driver.cpp
  lld/test/ELF/emulation-amdgpu.s

Index: lld/test/ELF/emulation-amdgpu.s
===
--- /dev/null
+++ lld/test/ELF/emulation-amdgpu.s
@@ -0,0 +1,36 @@
+# REQUIRES: amdgpu
+
+# RUN: llvm-mc -filetype=obj -triple=amdgcn-amd-amdhsa %s -o %t.o
+# RUN: ld.lld %t.o -o %t
+# RUN: llvm-readobj --file-headers %t | FileCheck %s
+# RUN: ld.lld -m elf64_amdgpu %t.o -o %t
+# RUN: llvm-readobj --file-headers %t | FileCheck %s
+
+# CHECK:  ElfHeader {
+# CHECK-NEXT:   Ident {
+# CHECK-NEXT: Magic: (7F 45 4C 46)
+# CHECK-NEXT: Class: 64-bit (0x2)
+# CHECK-NEXT: DataEncoding: LittleEndian (0x1)
+# CHECK-NEXT: FileVersion: 1
+# CHECK-NEXT: OS/ABI: AMDGPU_HSA (0x40)
+# CHECK-NEXT: ABIVersion: 2
+# CHECK-NEXT: Unused: (00 00 00 00 00 00 00)
+# CHECK-NEXT:   }
+# CHECK-NEXT:   Type: Executable (0x2)
+# CHECK-NEXT:   Machine: EM_AMDGPU (0xE0)
+# CHECK-NEXT:   Version: 1
+# CHECK-NEXT:   Entry:
+# CHECK-NEXT:   ProgramHeaderOffset: 0x40
+# CHECK-NEXT:   SectionHeaderOffset:
+# CHECK-NEXT:   Flags [ (0x0)
+# CHECK-NEXT:   ]
+# CHECK-NEXT:   HeaderSize: 64
+# CHECK-NEXT:   ProgramHeaderEntrySize: 56
+# CHECK-NEXT:   ProgramHeaderCount:
+# CHECK-NEXT:   SectionHeaderEntrySize: 64
+# CHECK-NEXT:   SectionHeaderCount:
+# CHECK-NEXT:   StringTableSectionIndex:
+# CHECK-NEXT: }
+
+.globl _start
+_start:
Index: lld/ELF/Driver.cpp
===
--- lld/ELF/Driver.cpp
+++ lld/ELF/Driver.cpp
@@ -176,12 +176,15 @@
   .Case("elf_iamcu", {ELF32LEKind, EM_IAMCU})
   .Case("elf64_sparc", {ELF64BEKind, EM_SPARCV9})
   .Case("msp430elf", {ELF32LEKind, EM_MSP430})
+  .Case("elf64_amdgpu", {ELF64LEKind, EM_AMDGPU})
   .Default({ELFNoneKind, EM_NONE});
 
   if (ret.first == ELFNoneKind)
 error("unknown emulation: " + emul);
   if (ret.second == EM_MSP430)
 osabi = ELFOSABI_STANDALONE;
+  else if (ret.second == EM_AMDGPU)
+osabi = ELFOSABI_AMDGPU_HSA;
   return std::make_tuple(ret.first, ret.second, osabi);
 }
 
Index: clang/test/Driver/hip-toolchain-no-rdc.hip
===
--- clang/test/Driver/hip-toolchain-no-rdc.hip
+++ clang/test/Driver/hip-toolchain-no-rdc.hip
@@ -59,7 +59,7 @@
 // CHECK-NOT: {{".*opt"}}
 // CHECK-NOT: {{".*llc"}}
 
-// CHECK: [[LLD: ".*lld.*"]] "-flavor" "gnu" "--no-undefined" "-shared"
+// CHECK: [[LLD: ".*lld.*"]] "-flavor" "gnu" "-m" "elf64_amdgpu" "--no-undefined" "-shared"
 // CHECK-SAME: "-o" "[[IMG_DEV_A_803:.*out]]" [[OBJ_DEV_A_803]]
 
 //
@@ -82,7 +82,7 @@
 // CHECK-NOT: {{".*opt"}}
 // CHECK-NOT: {{".*llc"}}
 
-// CHECK: [[LLD]] "-flavor" "gnu" "--no-undefined" "-shared"
+// CHECK: [[LLD]] "-flavor" "gnu" "-m" "elf64_amdgpu" "--no-undefined" "-shared"
 // CHECK-SAME: "-o" "[[IMG_DEV_A_900:.*out]]" [[OBJ_DEV_A_900]]
 
 //
@@ -122,7 +122,7 @@
 // CHECK-NOT: {{".*opt"}}
 // CHECK-NOT: {{".*llc"}}
 
-// CHECK: [[LLD]] "-flavor" "gnu" "--no-undefined" "-shared"
+// CHECK: [[LLD]] "-flavor" "gnu" "-m" "elf64_amdgpu" "--no-undefined" "-shared"
 // CHECK-SAME: "-o" "[[IMG_DEV_B_803:.*out]]" [[OBJ_DEV_B_803]]
 
 //
@@ -145,7 +145,7 @@
 // CHECK-NOT: {{".*opt"}}
 // CHECK-NOT: {{".*llc"}}
 
-// CHECK: [[LLD]] "-flavor" "gnu" "--no-undefined" "-shared"
+// CHECK: [[LLD]] "-flavor" "gnu" "-m" "elf64_amdgpu" "--no-undefined" "-shared"
 // CHECK-SAME: "-o" "[[IMG_DEV_B_900:.*out]]" [[OBJ_DEV_B_900]]
 
 //
Index: clang/test/Driver/hip-toolchain-device-only.hip
===
--- clang/test/Driver/hip-toolchain-device-only.hip
+++ clang/test/Driver/hip-toolchain-device-only.hip
@@ -12,7 +12,7 @@
 // CHECK-SAME: "-target-cpu" "gfx803"
 // CHECK-SAME: {{.*}} "-o" [[OBJ_DEV_A_803:".*o"]] "-x" "hip"
 
-// CHECK: [[LLD: ".*lld.*"]] "-flavor" "gnu" "--no-undefined" "-shared"
+// CHECK: [[LLD: ".*lld.*"]] "-flavor" "gnu" "-m" "elf64_amdgpu" "--no-undefined" "-shared"
 // CHECK-SAME: "-o" "[[IMG_DEV_A_803:.*out]]" [[OBJ_DEV_A_803]]
 
 // CHECK: [[CLANG:".*clang.*"]] "-cc1"{{.*}} "-triple" "amdgcn-amd-amdhsa"
@@ -21,7 +21,7 @@
 // CHECK-SAME: "-target-cpu" "gfx900"
 // CHECK-SAME: {{.*}} "-o" [[OBJ_DEV_A_900:".*o"]] "-x" "hip"
 
-// CHECK: [[LLD]] "-flavor" "gnu" "--no-undefined" "-shared"
+// CHECK: [[LLD]] "-flavor" "gnu" "-m" "elf64_amdgpu" "--no-undefined" "-shared"
 // CHECK-SAME: "-o" "[[IMG_DEV_A_900:.*out]]" [[OBJ_DEV_A_900]]
 
 /

[PATCH] D137948: [clang][dataflow] Add widening API and implement it for built-in boolean model.

2022-11-22 Thread Yitzhak Mandelbaum via Phabricator via cfe-commits
ymandel updated this revision to Diff 477200.
ymandel added a comment.

address comments


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D137948/new/

https://reviews.llvm.org/D137948

Files:
  clang/include/clang/Analysis/FlowSensitive/DataflowAnalysis.h
  clang/include/clang/Analysis/FlowSensitive/DataflowEnvironment.h
  clang/include/clang/Analysis/FlowSensitive/DataflowLattice.h
  clang/include/clang/Analysis/FlowSensitive/TypeErasedDataflowAnalysis.h
  clang/include/clang/Analysis/FlowSensitive/Value.h
  clang/lib/Analysis/FlowSensitive/DataflowEnvironment.cpp
  clang/lib/Analysis/FlowSensitive/TypeErasedDataflowAnalysis.cpp
  clang/unittests/Analysis/FlowSensitive/TransferTest.cpp

Index: clang/unittests/Analysis/FlowSensitive/TransferTest.cpp
===
--- clang/unittests/Analysis/FlowSensitive/TransferTest.cpp
+++ clang/unittests/Analysis/FlowSensitive/TransferTest.cpp
@@ -9,7 +9,6 @@
 #include "TestingSupport.h"
 #include "clang/AST/ASTContext.h"
 #include "clang/AST/Decl.h"
-#include "clang/ASTMatchers/ASTMatchFinder.h"
 #include "clang/ASTMatchers/ASTMatchers.h"
 #include "clang/Analysis/FlowSensitive/DataflowEnvironment.h"
 #include "clang/Analysis/FlowSensitive/NoopAnalysis.h"
@@ -63,7 +62,7 @@
  LangStandard::Kind Std = LangStandard::lang_cxx17,
  bool ApplyBuiltinTransfer = true,
  llvm::StringRef TargetFun = "target") {
-  runDataflow(Code, Match,
+  runDataflow(Code, std::move(Match),
   {ApplyBuiltinTransfer ? TransferOptions{}
 : llvm::Optional()},
   Std, TargetFun);
@@ -3255,8 +3254,7 @@
 
 TEST(TransferTest, LoopWithAssignmentConverges) {
   std::string Code = R"(
-
-bool &foo();
+bool foo();
 
 void target() {
do {
@@ -3285,9 +3283,45 @@
   });
 }
 
-TEST(TransferTest, LoopWithReferenceAssignmentConverges) {
+TEST(TransferTest, LoopWithStagedAssignments) {
   std::string Code = R"(
+bool foo();
+
+void target() {
+  bool Bar = false;
+  bool Err = false;
+  while (foo()) {
+if (Bar)
+  Err = true;
+Bar = true;
+/*[[p]]*/
+  }
+}
+  )";
+  runDataflow(
+  Code,
+  [](const llvm::StringMap> &Results,
+ ASTContext &ASTCtx) {
+ASSERT_THAT(Results.keys(), UnorderedElementsAre("p"));
+const Environment &Env = getEnvironmentAtAnnotation(Results, "p");
+
+const ValueDecl *BarDecl = findValueDecl(ASTCtx, "Bar");
+ASSERT_THAT(BarDecl, NotNull());
+const ValueDecl *ErrDecl = findValueDecl(ASTCtx, "Err");
+ASSERT_THAT(ErrDecl, NotNull());
+
+auto &BarVal = *cast(Env.getValue(*BarDecl, SkipPast::None));
+auto &ErrVal = *cast(Env.getValue(*ErrDecl, SkipPast::None));
+EXPECT_TRUE(Env.flowConditionImplies(BarVal));
+// An unsound analysis, for example only evaluating the loop once, can
+// conclude that `Err` is false. So, we test that this conclusion is not
+// reached.
+EXPECT_FALSE(Env.flowConditionImplies(Env.makeNot(ErrVal)));
+  });
+}
 
+TEST(TransferTest, LoopWithReferenceAssignmentConverges) {
+  std::string Code = R"(
 bool &foo();
 
 void target() {
@@ -3299,9 +,8 @@
   } while (true);
 }
   )";
-  // The key property that we are verifying is implicit in `runDataflow` --
-  // namely, that the analysis succeeds, rather than hitting the maximum number
-  // of iterations.
+  // The key property that we are verifying is that the analysis succeeds,
+  // rather than hitting the maximum number of iterations.
   runDataflow(
   Code,
   [](const llvm::StringMap> &Results,
Index: clang/lib/Analysis/FlowSensitive/TypeErasedDataflowAnalysis.cpp
===
--- clang/lib/Analysis/FlowSensitive/TypeErasedDataflowAnalysis.cpp
+++ clang/lib/Analysis/FlowSensitive/TypeErasedDataflowAnalysis.cpp
@@ -23,6 +23,7 @@
 #include "clang/Analysis/Analyses/PostOrderCFGView.h"
 #include "clang/Analysis/CFG.h"
 #include "clang/Analysis/FlowSensitive/DataflowEnvironment.h"
+#include "clang/Analysis/FlowSensitive/DataflowLattice.h"
 #include "clang/Analysis/FlowSensitive/DataflowWorklist.h"
 #include "clang/Analysis/FlowSensitive/Transfer.h"
 #include "clang/Analysis/FlowSensitive/TypeErasedDataflowAnalysis.h"
@@ -69,6 +70,20 @@
   return BlockPos - Pred.succ_begin();
 }
 
+static bool isLoopHead(const CFGBlock &B) {
+  if (const auto *T = B.getTerminatorStmt())
+switch (T->getStmtClass()) {
+  case Stmt::WhileStmtClass:
+  case Stmt::DoStmtClass:
+  case Stmt::ForStmtClass:
+return true;
+  default:
+return false;
+}
+
+  return false;
+}
+
 // The return type of the visit functions in TerminatorVisitor. The first
 // element represents the terminator expression (that is the condi

[PATCH] D138472: clang/cmake: Use installed gtest libraries for stand-alone builds

2022-11-22 Thread Tom Stellard via Phabricator via cfe-commits
tstellar added inline comments.



Comment at: clang/CMakeLists.txt:103
 if (LLVM_LIT AND LLVM_UTILS_PROVIDED)
-  set(UNITTEST_DIR ${LLVM_THIRD_PARTY_DIR}/utils/unittest)
-  if(EXISTS ${UNITTEST_DIR}/googletest/include/gtest/gtest.h
- AND NOT EXISTS 
${LLVM_LIBRARY_DIR}/${CMAKE_STATIC_LIBRARY_PREFIX}gtest${CMAKE_STATIC_LIBRARY_SUFFIX}
- AND EXISTS ${UNITTEST_DIR}/CMakeLists.txt)
-add_subdirectory(${UNITTEST_DIR} third-part/unittest)
+  find_package(LLVMGTest)
+  if (NOT TARGET llvm_gtest)

kwk wrote:
> I don't see no `FindLLVMGTest.cmake` file anywhere. Is that suppose to exist 
> yet or which Patch is suppose to create it?
It's added in  D137890.  And it's called LLVMGTestConfig.cmake.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D138472/new/

https://reviews.llvm.org/D138472

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D138122: Lift EHPersonalities from Analysis to IR (NFC)

2022-11-22 Thread Saleem Abdulrasool via Phabricator via cfe-commits
compnerd accepted this revision.
compnerd added a comment.

Additional validation is never a bad thing :).  Please do sort the headers 
before committing.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D138122/new/

https://reviews.llvm.org/D138122

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D138463: [windows-itanium] Propagate DLL storage class to Initialisation Guard Variables

2022-11-22 Thread Paul Robinson via Phabricator via cfe-commits
probinson added a subscriber: cfe-commits.
probinson added a comment.

+cfe-commits


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D138463/new/

https://reviews.llvm.org/D138463

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D137995: [Flang][Driver] Handle target CPU and features

2022-11-22 Thread Andrzej Warzynski via Phabricator via cfe-commits
awarzynski added a comment.

Thanks for implementing this!

> Processes target cpu and features in the flang driver. Right now features are 
> only added for AArch64 because I only did basic testing on AArch64 but it 
> should generally work for others as well.

X86 is a very popular target and we have pre-commit CI as well. And X86 
buildbots :) Please include X86.

Question: are the option semantics identical that what you get in `clang -cc1`? 
If yes, could you add a comment in the summary?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D137995/new/

https://reviews.llvm.org/D137995

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D137437: [lit][AIX] Convert clang tests to use 'target={{.*}}aix{{.*}}'

2022-11-22 Thread Louis Dionne via Phabricator via cfe-commits
ldionne accepted this revision.
ldionne added a comment.
This revision is now accepted and ready to land.

LGTM w/ normalization.

I suggest trying to land these changes sooner rather than later since this is 
bound to merge conflict and become stale.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D137437/new/

https://reviews.llvm.org/D137437

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D138499: [clangd] Extract Function: add hoisting support

2022-11-22 Thread Julian Schmidt via Phabricator via cfe-commits
5chmidti updated this revision to Diff 477204.
5chmidti added a comment.

Fix windows build by setting the c++ standard for the hoisting tests explicitly 
to c++17.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D138499/new/

https://reviews.llvm.org/D138499

Files:
  clang-tools-extra/clangd/refactor/tweaks/ExtractFunction.cpp
  clang-tools-extra/clangd/unittests/tweaks/ExtractFunctionTests.cpp
  clang-tools-extra/docs/ReleaseNotes.rst

Index: clang-tools-extra/docs/ReleaseNotes.rst
===
--- clang-tools-extra/docs/ReleaseNotes.rst
+++ clang-tools-extra/docs/ReleaseNotes.rst
@@ -78,6 +78,9 @@
 Miscellaneous
 ^
 
+- The extract function tweak gained support for hoisting, i.e. returning decls declared
+  inside the selection that are used outside of the selection.
+
 Improvements to clang-doc
 -
 
Index: clang-tools-extra/clangd/unittests/tweaks/ExtractFunctionTests.cpp
===
--- clang-tools-extra/clangd/unittests/tweaks/ExtractFunctionTests.cpp
+++ clang-tools-extra/clangd/unittests/tweaks/ExtractFunctionTests.cpp
@@ -30,8 +30,9 @@
   EXPECT_EQ(apply("auto lam = [](){ [[int x;]] }; "), "unavailable");
   // Partial statements aren't extracted.
   EXPECT_THAT(apply("int [[x = 0]];"), "unavailable");
-  // FIXME: Support hoisting.
-  EXPECT_THAT(apply(" [[int a = 5;]] a++; "), "unavailable");
+
+  // Extract regions that require hoisting
+  EXPECT_THAT(apply(" [[int a = 5;]] a++; "), HasSubstr("extracted"));
 
   // Ensure that end of Zone and Beginning of PostZone being adjacent doesn't
   // lead to break being included in the extraction zone.
@@ -192,6 +193,203 @@
   EXPECT_EQ(apply(CompoundFailInput), "unavailable");
 }
 
+TEST_F(ExtractFunctionTest, Hoisting) {
+  ExtraArgs.emplace_back("-std=c++17");
+  std::string HoistingInput = R"cpp(
+int foo() {
+  int a = 3;
+  [[int x = 39 + a;
+  ++x;
+  int y = x * 2;
+  int z = 4;]]
+  return x + y + z;
+}
+  )cpp";
+  std::string HoistingOutput = R"cpp(
+auto extracted(int &a) {
+int x = 39 + a;
+  ++x;
+  int y = x * 2;
+  int z = 4;
+return std::tuple{x, y, z};
+}
+int foo() {
+  int a = 3;
+  auto [x, y, z] = extracted(a);
+  return x + y + z;
+}
+  )cpp";
+  EXPECT_EQ(apply(HoistingInput), HoistingOutput);
+
+  std::string HoistingInput2 = R"cpp(
+int foo() {
+  int a{};
+  [[int b = a + 1;]]
+  return b;
+}
+  )cpp";
+  std::string HoistingOutput2 = R"cpp(
+int extracted(int &a) {
+int b = a + 1;
+return b;
+}
+int foo() {
+  int a{};
+  auto b = extracted(a);
+  return b;
+}
+  )cpp";
+  EXPECT_EQ(apply(HoistingInput2), HoistingOutput2);
+
+  std::string HoistingInput3 = R"cpp(
+int foo(int b) {
+  int a{};
+  if (b == 42) {
+[[a = 123;
+return a + b;]]
+  }
+  a = 456;
+  return a;
+}
+  )cpp";
+  std::string HoistingOutput3 = R"cpp(
+int extracted(int &b, int &a) {
+a = 123;
+return a + b;
+}
+int foo(int b) {
+  int a{};
+  if (b == 42) {
+return extracted(b, a);
+  }
+  a = 456;
+  return a;
+}
+  )cpp";
+  EXPECT_EQ(apply(HoistingInput3), HoistingOutput3);
+
+  std::string HoistingInput4 = R"cpp(
+struct A {
+  bool flag;
+  int val;
+};
+A bar();
+int foo(int b) {
+  int a = 0;
+  [[auto [flag, val] = bar();
+  int c = 4;
+  val = c + a;]]
+  return a + b + c + val;
+}
+  )cpp";
+  std::string HoistingOutput4 = R"cpp(
+struct A {
+  bool flag;
+  int val;
+};
+A bar();
+auto extracted(int &a) {
+auto [flag, val] = bar();
+  int c = 4;
+  val = c + a;
+return std::pair{val, c};
+}
+int foo(int b) {
+  int a = 0;
+  auto [val, c] = extracted(a);
+  return a + b + c + val;
+}
+  )cpp";
+  EXPECT_EQ(apply(HoistingInput4), HoistingOutput4);
+}
+
+TEST_F(ExtractFunctionTest, HoistingCXX11) {
+  ExtraArgs.emplace_back("-std=c++11");
+  std::string HoistingInput = R"cpp(
+int foo() {
+  int a = 3;
+  [[int x = 39 + a;
+  ++x;
+  int y = x * 2;
+  int z = 4;]]
+  return x + y + z;
+}
+  )cpp";
+  EXPECT_THAT(apply(HoistingInput), HasSubstr("unavailable"));
+
+  std::string HoistingInput2 = R"cpp(
+int foo() {
+  int a;
+  [[int b = a + 1;]]
+  return b;
+}
+  )cpp";
+  std::string HoistingOutput2 = R"cpp(
+int extracted(int &a) {
+int b = a + 1;
+return b;
+}
+int foo() {
+  int a;
+  auto b = extracted(a);
+  return b;
+}
+  )cpp";
+  EXPECT_EQ(apply(HoistingInput2), HoistingOutput2);
+}
+
+TEST_F(ExtractFunctionTest, HoistingCXX14) {
+  ExtraArgs.emplace_back("-std=c++14");
+  std::string HoistingInput = R"cpp(
+int foo() {
+  int a = 3;
+  [[int x = 39 + a;
+  ++x;
+  int y = 

[clang] 84dd12b - [clang][dataflow] Add widening API and implement it for built-in boolean model.

2022-11-22 Thread Yitzhak Mandelbaum via cfe-commits

Author: Yitzhak Mandelbaum
Date: 2022-11-22T16:09:28Z
New Revision: 84dd12b29064095cdef3949e8fd5c91b93f36004

URL: 
https://github.com/llvm/llvm-project/commit/84dd12b29064095cdef3949e8fd5c91b93f36004
DIFF: 
https://github.com/llvm/llvm-project/commit/84dd12b29064095cdef3949e8fd5c91b93f36004.diff

LOG: [clang][dataflow] Add widening API and implement it for built-in boolean 
model.

* Adds API support for widening of lattice elements and environments,
* Updates the algorithm to apply widening where appropriate,
* Implements widening for boolean values. In the process, moves the unsoundness
  of comparison from the default implementation of
  `Environment::ValueModel::compare` to model-specific handling inside
  `DataflowEnvironment::equivalentTo`. This change is intended to clarify
  the source and location of unsoundess.

This patch is a replacement for, and was based substantially on, 
https://reviews.llvm.org/D131645.

Differential Revision: https://reviews.llvm.org/D137948

Added: 


Modified: 
clang/include/clang/Analysis/FlowSensitive/DataflowAnalysis.h
clang/include/clang/Analysis/FlowSensitive/DataflowEnvironment.h
clang/include/clang/Analysis/FlowSensitive/DataflowLattice.h
clang/include/clang/Analysis/FlowSensitive/TypeErasedDataflowAnalysis.h
clang/include/clang/Analysis/FlowSensitive/Value.h
clang/lib/Analysis/FlowSensitive/DataflowEnvironment.cpp
clang/lib/Analysis/FlowSensitive/TypeErasedDataflowAnalysis.cpp
clang/unittests/Analysis/FlowSensitive/TransferTest.cpp

Removed: 




diff  --git a/clang/include/clang/Analysis/FlowSensitive/DataflowAnalysis.h 
b/clang/include/clang/Analysis/FlowSensitive/DataflowAnalysis.h
index 52844302b8532..ad5ba1d2468ab 100644
--- a/clang/include/clang/Analysis/FlowSensitive/DataflowAnalysis.h
+++ b/clang/include/clang/Analysis/FlowSensitive/DataflowAnalysis.h
@@ -23,6 +23,7 @@
 #include "clang/Analysis/CFG.h"
 #include "clang/Analysis/FlowSensitive/ControlFlowContext.h"
 #include "clang/Analysis/FlowSensitive/DataflowEnvironment.h"
+#include "clang/Analysis/FlowSensitive/DataflowLattice.h"
 #include "clang/Analysis/FlowSensitive/TypeErasedDataflowAnalysis.h"
 #include "llvm/ADT/Any.h"
 #include "llvm/ADT/Optional.h"
@@ -32,16 +33,6 @@
 namespace clang {
 namespace dataflow {
 
-template >
-struct HasTransferBranchFor : std::false_type {};
-
-template 
-struct HasTransferBranchFor<
-AnalysisT, LatticeT,
-std::void_t().transferBranch(
-std::declval(), std::declval(),
-std::declval(), std::declval()))>>
-: std::true_type {};
 /// Base class template for dataflow analyses built on a single lattice type.
 ///
 /// Requirements:
@@ -54,6 +45,11 @@ struct HasTransferBranchFor<
 /// the analysis transfer function for a given CFG element and lattice
 /// element.
 ///
+///  `Derived` can optionally provide the following members:
+///  * `void transferBranch(bool Branch, const Stmt *Stmt, TypeErasedLattice 
&E,
+/// Environment &Env)` - applies the analysis transfer
+///function for a given edge from a CFG block of a conditional statement.
+///
 ///  `Derived` can optionally override the following members:
 ///   * `bool merge(QualType, const Value &, const Value &, Value &,
 /// Environment &)` -  joins distinct values. This could be a strict
@@ -67,6 +63,15 @@ struct HasTransferBranchFor<
 /// made to it;
 ///   * `bool operator==(const LatticeT &) const` - returns true if and only if
 /// the object is equal to the argument.
+///
+/// `LatticeT` can optionally provide the following members:
+///  * `LatticeJoinEffect widen(const LatticeT &Previous)` - replaces the
+///lattice element with an  approximation that can reach a fixed point more
+///quickly than iterated application of the transfer function alone. The
+///previous value is provided to inform the choice of widened value. The
+///function must also serve as a comparison operation, by indicating 
whether
+///the widened value is equivalent to the previous value with the returned
+///`LatticeJoinEffect`.
 template 
 class DataflowAnalysis : public TypeErasedDataflowAnalysis {
 public:
@@ -98,6 +103,13 @@ class DataflowAnalysis : public TypeErasedDataflowAnalysis {
 return L1.join(L2);
   }
 
+  LatticeJoinEffect widenTypeErased(TypeErasedLattice &Current,
+const TypeErasedLattice &Previous) final {
+Lattice &C = llvm::any_cast(Current.Value);
+const Lattice &P = llvm::any_cast(Previous.Value);
+return widenInternal(Rank0{}, C, P);
+  }
+
   bool isEqualTypeErased(const TypeErasedLattice &E1,
  const TypeErasedLattice &E2) final {
 const Lattice &L1 = llvm::any_cast(E1.Value);
@@ -113,16 +125,47 @@ class DataflowAnalysis : public 
TypeErasedDataflowAnalysis {
 
   void transferBranchTypeErased(bool Branch, const Stmt

[PATCH] D137948: [clang][dataflow] Add widening API and implement it for built-in boolean model.

2022-11-22 Thread Yitzhak Mandelbaum via Phabricator via cfe-commits
This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
ymandel marked 2 inline comments as done.
Closed by commit rG84dd12b29064: [clang][dataflow] Add widening API and 
implement it for built-in boolean model. (authored by ymandel).

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D137948/new/

https://reviews.llvm.org/D137948

Files:
  clang/include/clang/Analysis/FlowSensitive/DataflowAnalysis.h
  clang/include/clang/Analysis/FlowSensitive/DataflowEnvironment.h
  clang/include/clang/Analysis/FlowSensitive/DataflowLattice.h
  clang/include/clang/Analysis/FlowSensitive/TypeErasedDataflowAnalysis.h
  clang/include/clang/Analysis/FlowSensitive/Value.h
  clang/lib/Analysis/FlowSensitive/DataflowEnvironment.cpp
  clang/lib/Analysis/FlowSensitive/TypeErasedDataflowAnalysis.cpp
  clang/unittests/Analysis/FlowSensitive/TransferTest.cpp

Index: clang/unittests/Analysis/FlowSensitive/TransferTest.cpp
===
--- clang/unittests/Analysis/FlowSensitive/TransferTest.cpp
+++ clang/unittests/Analysis/FlowSensitive/TransferTest.cpp
@@ -9,7 +9,6 @@
 #include "TestingSupport.h"
 #include "clang/AST/ASTContext.h"
 #include "clang/AST/Decl.h"
-#include "clang/ASTMatchers/ASTMatchFinder.h"
 #include "clang/ASTMatchers/ASTMatchers.h"
 #include "clang/Analysis/FlowSensitive/DataflowEnvironment.h"
 #include "clang/Analysis/FlowSensitive/NoopAnalysis.h"
@@ -63,7 +62,7 @@
  LangStandard::Kind Std = LangStandard::lang_cxx17,
  bool ApplyBuiltinTransfer = true,
  llvm::StringRef TargetFun = "target") {
-  runDataflow(Code, Match,
+  runDataflow(Code, std::move(Match),
   {ApplyBuiltinTransfer ? TransferOptions{}
 : llvm::Optional()},
   Std, TargetFun);
@@ -3255,8 +3254,7 @@
 
 TEST(TransferTest, LoopWithAssignmentConverges) {
   std::string Code = R"(
-
-bool &foo();
+bool foo();
 
 void target() {
do {
@@ -3285,9 +3283,45 @@
   });
 }
 
-TEST(TransferTest, LoopWithReferenceAssignmentConverges) {
+TEST(TransferTest, LoopWithStagedAssignments) {
   std::string Code = R"(
+bool foo();
+
+void target() {
+  bool Bar = false;
+  bool Err = false;
+  while (foo()) {
+if (Bar)
+  Err = true;
+Bar = true;
+/*[[p]]*/
+  }
+}
+  )";
+  runDataflow(
+  Code,
+  [](const llvm::StringMap> &Results,
+ ASTContext &ASTCtx) {
+ASSERT_THAT(Results.keys(), UnorderedElementsAre("p"));
+const Environment &Env = getEnvironmentAtAnnotation(Results, "p");
+
+const ValueDecl *BarDecl = findValueDecl(ASTCtx, "Bar");
+ASSERT_THAT(BarDecl, NotNull());
+const ValueDecl *ErrDecl = findValueDecl(ASTCtx, "Err");
+ASSERT_THAT(ErrDecl, NotNull());
+
+auto &BarVal = *cast(Env.getValue(*BarDecl, SkipPast::None));
+auto &ErrVal = *cast(Env.getValue(*ErrDecl, SkipPast::None));
+EXPECT_TRUE(Env.flowConditionImplies(BarVal));
+// An unsound analysis, for example only evaluating the loop once, can
+// conclude that `Err` is false. So, we test that this conclusion is not
+// reached.
+EXPECT_FALSE(Env.flowConditionImplies(Env.makeNot(ErrVal)));
+  });
+}
 
+TEST(TransferTest, LoopWithReferenceAssignmentConverges) {
+  std::string Code = R"(
 bool &foo();
 
 void target() {
@@ -3299,9 +,8 @@
   } while (true);
 }
   )";
-  // The key property that we are verifying is implicit in `runDataflow` --
-  // namely, that the analysis succeeds, rather than hitting the maximum number
-  // of iterations.
+  // The key property that we are verifying is that the analysis succeeds,
+  // rather than hitting the maximum number of iterations.
   runDataflow(
   Code,
   [](const llvm::StringMap> &Results,
Index: clang/lib/Analysis/FlowSensitive/TypeErasedDataflowAnalysis.cpp
===
--- clang/lib/Analysis/FlowSensitive/TypeErasedDataflowAnalysis.cpp
+++ clang/lib/Analysis/FlowSensitive/TypeErasedDataflowAnalysis.cpp
@@ -23,6 +23,7 @@
 #include "clang/Analysis/Analyses/PostOrderCFGView.h"
 #include "clang/Analysis/CFG.h"
 #include "clang/Analysis/FlowSensitive/DataflowEnvironment.h"
+#include "clang/Analysis/FlowSensitive/DataflowLattice.h"
 #include "clang/Analysis/FlowSensitive/DataflowWorklist.h"
 #include "clang/Analysis/FlowSensitive/Transfer.h"
 #include "clang/Analysis/FlowSensitive/TypeErasedDataflowAnalysis.h"
@@ -69,6 +70,20 @@
   return BlockPos - Pred.succ_begin();
 }
 
+static bool isLoopHead(const CFGBlock &B) {
+  if (const auto *T = B.getTerminatorStmt())
+switch (T->getStmtClass()) {
+  case Stmt::WhileStmtClass:
+  case Stmt::DoStmtClass:
+  case Stmt::ForStmtClass:
+return

[PATCH] D138391: clang/HIP: Add new header test for math IR gen

2022-11-22 Thread Matt Arsenault via Phabricator via cfe-commits
arsenm closed this revision.
arsenm added a comment.

2edafe8393fa7c9ad2e95d691191469adb7bf4b0 



CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D138391/new/

https://reviews.llvm.org/D138391

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D130327: [ODRHash] Detect duplicate `ObjCProtocolDecl` ODR mismatches during parsing.

2022-11-22 Thread Nancy Wang via Phabricator via cfe-commits
NancyWang added a comment.

@vsapsai  hi Volodymyr Sapsai , test case 
clang/test/Modules/hidden-duplicates.m is failing on our llvm community AIX box 
https://lab.llvm.org/buildbot/#/builders/214/builds/4442/steps/6/logs/FAIL__Clang__hidden-duplicates_m
 , it gives exit code 70 without detail error message, can you help fix it as 
soon as possible. Thanks


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D130327/new/

https://reviews.llvm.org/D130327

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D127762: [Clang][AArch64] Add ACLE attributes for SME.

2022-11-22 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added inline comments.



Comment at: clang/include/clang/AST/Type.h:4008
 bool HasTrailingReturn : 1;
+unsigned AArch64SMEAttributes : 8;
 Qualifiers TypeQuals;

sdesmalen wrote:
> aaron.ballman wrote:
> > erichkeane wrote:
> > > sdesmalen wrote:
> > > > aaron.ballman wrote:
> > > > > So functions without prototypes cannot have any of these attributes?
> > > > Yes, the ACLE explicitly states that 
> > > > [[https://github.com/ARM-software/acle/pull/188/commits/59751df91d9630400531a64108f179e3951c3b89#diff-516526d4a18101dc85300bc2033d0f86dc46c505b7510a7694baabea851aedfaR503|here]]:
> > > > > The function type attributes cannot be used with K&R-style 
> > > > > “unprototyped” C function types
> > > Are they aware that includes; `void Baz();` ?
> > FWIW, the linked docs say:
> > ```
> > > Functions like `some_func` and `another_func` are referred to as
> > > (K&R-style) “unprototyped” functions. The first C standard categorized
> > > them as an obsolescent feature and C18 removed all remaining support
> > > for them.
> > ```
> > That's not quite accurate. They've always been obsolete in standard C (both 
> > ANSI and ISO C), so that's correct. But it's C2x that removes all remaining 
> > support for them. (Also, there's no such release as C18, there's C11, C17, 
> > and expected to be C23).
> > 
> > > Are they aware that includes; void Baz(); ?
> > 
> > Just to expound on this question: this means `void baz();` in C17 mode 
> > cannot have the attribute but `void baz();` in C2x mode can. Folks coming 
> > from C++ tend to expect the C2x behavior to be the default and so it's 
> > plausible to see such signatures in older language modes. Will that cause 
> > any pain or confusion for you?
> @rsandifo-arm explained to me that it is indeed a deliberate choice not to 
> support the attribute on unprototyped functions, as these are an obsolescent 
> feature that will be removed in C2x. The mitigation should be trivial for new 
> code that is written and it makes new code compliant with the next version of 
> the standard.
Perfect, thank you for double-checking!



Comment at: clang/include/clang/Basic/AttrDocs.td:6322
+
+Only when Clang defines __ARM_FEATURE_SME, the support for this feature is
+considered to be stable and complete.

Double-checking: that macro is missing the trailing double underscore, is that 
expected?



Comment at: clang/include/clang/Basic/DiagnosticSemaKinds.td:2000
   "overridden virtual function is here">;
+def err_conflicting_overriding_attributes : Error<
+  "virtual function %0 has different attributes "

rsandifo-arm wrote:
> aaron.ballman wrote:
> > rsandifo-arm wrote:
> > > rsandifo-arm wrote:
> > > > aaron.ballman wrote:
> > > > > aaron.ballman wrote:
> > > > > > rsandifo-arm wrote:
> > > > > > > sdesmalen wrote:
> > > > > > > > aaron.ballman wrote:
> > > > > > > > > sdesmalen wrote:
> > > > > > > > > > aaron.ballman wrote:
> > > > > > > > > > > This error and the one below make me wonder whether an 
> > > > > > > > > > > attribute spelling is the appropriate way to surface this 
> > > > > > > > > > > functionality as opposed to a keyword. Attributes don't 
> > > > > > > > > > > typically don't cause errors in these situations, but 
> > > > > > > > > > > because these attributes are strongly coupled to their 
> > > > > > > > > > > type system effects I can see why you want these to be 
> > > > > > > > > > > errors.
> > > > > > > > > > > This error and the one below make me wonder whether an 
> > > > > > > > > > > attribute spelling is the appropriate way to surface this 
> > > > > > > > > > > functionality as opposed to a keyword. 
> > > > > > > > > > I'm not sure I understand what you mean, do you have an 
> > > > > > > > > > example?
> > > > > > > > > `override` and `final` could have been surfaced via 
> > > > > > > > > attributes, and in Clang we semantically express them as such 
> > > > > > > > > (see `Final` and `Override` in Attr.td), but instead they are 
> > > > > > > > > surfaced to the user as keywords in the language standard. 
> > > > > > > > > You're not under the same constraints as the standard (you're 
> > > > > > > > > making a vendor-specific attribute). We're not super 
> > > > > > > > > consistent with whether we use the same approach as the 
> > > > > > > > > standard (we have some type attributes that are spelled as 
> > > > > > > > > attributes like `vector_size` and others that are spelled via 
> > > > > > > > > keywords like `_Nullable`.
> > > > > > > > > 
> > > > > > > > > So you could spell your type attributes the way you have been 
> > > > > > > > > with `__attribute__`, or you could come up with keywords for 
> > > > > > > > > them (so instead of using `GNU<"whatever">` for the 
> > > > > > > > > attribute, you could use `Keyword<_Whatever>` or 
> > > > > > > > > `Keyword<__whatever>` (you'd also need to add them as 
> > > > > > 

[PATCH] D138387: [Clang] Implement static operator[]

2022-11-22 Thread Corentin Jabot via Phabricator via cfe-commits
cor3ntin accepted this revision.
cor3ntin added a comment.
This revision is now accepted and ready to land.

Beside the formatting nitpick this looks good




Comment at: clang/test/CodeGenCXX/cxx2b-static-subscript-operator.cpp:14
+  f.operator[](201, 202);
+  Functor{}[301, 302];
+}

I think this is missing a test like
`Functor::operator[](42, 42)` for completeness


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D138387/new/

https://reviews.llvm.org/D138387

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D138253: [-Wunsafe-buffer-usage] NFC: Implement fix-strategies and variable-use-claiming.

2022-11-22 Thread Balázs Benics via Phabricator via cfe-commits
steakhal added inline comments.



Comment at: clang/include/clang/Analysis/Analyses/UnsafeBufferUsage.h:30
+  /// of primitive fixits (individual insertions/removals/replacements).
+  using FixItList = llvm::SmallVector;
+

Unless we have a well-formed idea of how many elements we are going to have, we 
should probably omit it.



Comment at: clang/lib/Analysis/UnsafeBufferUsage.cpp:83
+  /// Returns the list of pointer-type variables on which this gadget performs
+  /// its operation. Typically there's only one variable. This isn't a list
+  /// of all DeclRefExprs in the gadget's AST!





Comment at: clang/lib/Analysis/UnsafeBufferUsage.cpp:90
+  /// returns an empty list if no fixes are necessary.
+  virtual Optional getFixits(const Strategy &) const {
+return None;

I wonder if we should prefer `std::optional` as we are c++17.
IDK if it was ever covered on the community forum.
I'm just leaving this here without expecting any action.



Comment at: clang/lib/Analysis/UnsafeBufferUsage.cpp:231-233
+// An auxiliary tracking facility for the fixit analysis. It helps connect
+// declarations to its and make sure we've covered all uses with our analysis
+// before we try to fix the declaration.





Comment at: clang/lib/Analysis/UnsafeBufferUsage.cpp:259-262
+// FIXME: Can this be less linear? Maybe maintain a map from VDs to DREs?
+return any_of(*Uses, [VD](const DeclRefExpr *DRE) {
+  return DRE->getDecl()->getCanonicalDecl() == VD->getCanonicalDecl();
+});

Maybe `Uses` should refer to the canonical decls. If that would be the case we 
could just call `.contains(VD)` here.



Comment at: clang/lib/Analysis/UnsafeBufferUsage.cpp:408
   for (const auto &G : Gadgets) {
-Handler.handleUnsafeOperation(G->getBaseStmt());
+DeclUseList DREs = G->getClaimedVarUseSites();
+





Comment at: clang/lib/Analysis/UnsafeBufferUsage.cpp:428-430
+  for (const auto &Item : Map) {
+const VarDecl *VD = Item.first;
+const std::vector &VDGadgets = Item.second;




Repository:
  rC Clang

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D138253/new/

https://reviews.llvm.org/D138253

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D138504: clang/HIP: Remove __llvm_amdgcn_* wrapper hacks

2022-11-22 Thread Matt Arsenault via Phabricator via cfe-commits
arsenm created this revision.
arsenm added reviewers: yaxunl, JonChesterfield, b-sumner.
Herald added a subscriber: kosarev.
Herald added a project: All.
arsenm requested review of this revision.
Herald added a subscriber: wdng.

These are leftover hacks from using asm declaratios to access
intrinsics.


https://reviews.llvm.org/D138504

Files:
  clang/lib/Headers/__clang_hip_libdevice_declares.h
  clang/lib/Headers/__clang_hip_math.h


Index: clang/lib/Headers/__clang_hip_math.h
===
--- clang/lib/Headers/__clang_hip_math.h
+++ clang/lib/Headers/__clang_hip_math.h
@@ -659,7 +659,7 @@
 #endif
 
 __DEVICE__
-float __frsqrt_rn(float __x) { return __llvm_amdgcn_rsq_f32(__x); }
+float __frsqrt_rn(float __x) { return __builtin_amdgcn_rsqf(__x); }
 
 #if defined OCML_BASIC_ROUNDED_OPERATIONS
 __DEVICE__
Index: clang/lib/Headers/__clang_hip_libdevice_declares.h
===
--- clang/lib/Headers/__clang_hip_libdevice_declares.h
+++ clang/lib/Headers/__clang_hip_libdevice_declares.h
@@ -137,23 +137,6 @@
 __device__ __attribute__((const)) float __ocml_fma_rtn_f32(float, float, 
float);
 __device__ __attribute__((const)) float __ocml_fma_rtp_f32(float, float, 
float);
 __device__ __attribute__((const)) float __ocml_fma_rtz_f32(float, float, 
float);
-
-__device__ inline __attribute__((const)) float
-__llvm_amdgcn_cos_f32(float __x) {
-  return __builtin_amdgcn_cosf(__x);
-}
-__device__ inline __attribute__((const)) float
-__llvm_amdgcn_rcp_f32(float __x) {
-  return __builtin_amdgcn_rcpf(__x);
-}
-__device__ inline __attribute__((const)) float
-__llvm_amdgcn_rsq_f32(float __x) {
-  return __builtin_amdgcn_rsqf(__x);
-}
-__device__ inline __attribute__((const)) float
-__llvm_amdgcn_sin_f32(float __x) {
-  return __builtin_amdgcn_sinf(__x);
-}
 // END INTRINSICS
 // END FLOAT
 
@@ -277,15 +260,6 @@
 __device__ __attribute__((const)) double __ocml_fma_rtz_f64(double, double,
 double);
 
-__device__ inline __attribute__((const)) double
-__llvm_amdgcn_rcp_f64(double __x) {
-  return __builtin_amdgcn_rcp(__x);
-}
-__device__ inline __attribute__((const)) double
-__llvm_amdgcn_rsq_f64(double __x) {
-  return __builtin_amdgcn_rsq(__x);
-}
-
 __device__ __attribute__((const)) _Float16 __ocml_ceil_f16(_Float16);
 __device__ _Float16 __ocml_cos_f16(_Float16);
 __device__ __attribute__((const)) _Float16 __ocml_cvtrtn_f16_f32(float);


Index: clang/lib/Headers/__clang_hip_math.h
===
--- clang/lib/Headers/__clang_hip_math.h
+++ clang/lib/Headers/__clang_hip_math.h
@@ -659,7 +659,7 @@
 #endif
 
 __DEVICE__
-float __frsqrt_rn(float __x) { return __llvm_amdgcn_rsq_f32(__x); }
+float __frsqrt_rn(float __x) { return __builtin_amdgcn_rsqf(__x); }
 
 #if defined OCML_BASIC_ROUNDED_OPERATIONS
 __DEVICE__
Index: clang/lib/Headers/__clang_hip_libdevice_declares.h
===
--- clang/lib/Headers/__clang_hip_libdevice_declares.h
+++ clang/lib/Headers/__clang_hip_libdevice_declares.h
@@ -137,23 +137,6 @@
 __device__ __attribute__((const)) float __ocml_fma_rtn_f32(float, float, float);
 __device__ __attribute__((const)) float __ocml_fma_rtp_f32(float, float, float);
 __device__ __attribute__((const)) float __ocml_fma_rtz_f32(float, float, float);
-
-__device__ inline __attribute__((const)) float
-__llvm_amdgcn_cos_f32(float __x) {
-  return __builtin_amdgcn_cosf(__x);
-}
-__device__ inline __attribute__((const)) float
-__llvm_amdgcn_rcp_f32(float __x) {
-  return __builtin_amdgcn_rcpf(__x);
-}
-__device__ inline __attribute__((const)) float
-__llvm_amdgcn_rsq_f32(float __x) {
-  return __builtin_amdgcn_rsqf(__x);
-}
-__device__ inline __attribute__((const)) float
-__llvm_amdgcn_sin_f32(float __x) {
-  return __builtin_amdgcn_sinf(__x);
-}
 // END INTRINSICS
 // END FLOAT
 
@@ -277,15 +260,6 @@
 __device__ __attribute__((const)) double __ocml_fma_rtz_f64(double, double,
 double);
 
-__device__ inline __attribute__((const)) double
-__llvm_amdgcn_rcp_f64(double __x) {
-  return __builtin_amdgcn_rcp(__x);
-}
-__device__ inline __attribute__((const)) double
-__llvm_amdgcn_rsq_f64(double __x) {
-  return __builtin_amdgcn_rsq(__x);
-}
-
 __device__ __attribute__((const)) _Float16 __ocml_ceil_f16(_Float16);
 __device__ _Float16 __ocml_cos_f16(_Float16);
 __device__ __attribute__((const)) _Float16 __ocml_cvtrtn_f16_f32(float);
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] 2a1c192 - [clang][Parse] Remove constant expression from if condition

2022-11-22 Thread Timm Bäder via cfe-commits

Author: Timm Bäder
Date: 2022-11-22T17:31:21+01:00
New Revision: 2a1c192bd6bf639bc3f14cfb19c5d7aff5e7794b

URL: 
https://github.com/llvm/llvm-project/commit/2a1c192bd6bf639bc3f14cfb19c5d7aff5e7794b
DIFF: 
https://github.com/llvm/llvm-project/commit/2a1c192bd6bf639bc3f14cfb19c5d7aff5e7794b.diff

LOG: [clang][Parse] Remove constant expression from if condition

MaybeTypeCast here is not a variable, it's an enum member with value 1.

Differential Revision: https://reviews.llvm.org/D138289

Added: 


Modified: 
clang/lib/Parse/ParseExpr.cpp

Removed: 




diff  --git a/clang/lib/Parse/ParseExpr.cpp b/clang/lib/Parse/ParseExpr.cpp
index 20ce560514e94..9ac8706191d3a 100644
--- a/clang/lib/Parse/ParseExpr.cpp
+++ b/clang/lib/Parse/ParseExpr.cpp
@@ -3168,7 +3168,7 @@ Parser::ParseParenExpression(ParenParseOption &ExprType, 
bool stopIfCastExpr,
 InMessageExpressionRAIIObject InMessage(*this, false);
 
 Result = ParseExpression(MaybeTypeCast);
-if (!getLangOpts().CPlusPlus && MaybeTypeCast && Result.isUsable()) {
+if (!getLangOpts().CPlusPlus && Result.isUsable()) {
   // Correct typos in non-C++ code earlier so that implicit-cast-like
   // expressions are parsed correctly.
   Result = Actions.CorrectDelayedTyposInExpr(Result);



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D138289: [clang][Parse] Remove constant expression from if condition

2022-11-22 Thread Timm Bäder via Phabricator via cfe-commits
This revision was not accepted when it landed; it landed in state "Needs 
Review".
This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rG2a1c192bd6bf: [clang][Parse] Remove constant expression from 
if condition (authored by tbaeder).

Changed prior to commit:
  https://reviews.llvm.org/D138289?vs=476452&id=477210#toc

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D138289/new/

https://reviews.llvm.org/D138289

Files:
  clang/lib/Parse/ParseExpr.cpp


Index: clang/lib/Parse/ParseExpr.cpp
===
--- clang/lib/Parse/ParseExpr.cpp
+++ clang/lib/Parse/ParseExpr.cpp
@@ -3168,7 +3168,7 @@
 InMessageExpressionRAIIObject InMessage(*this, false);
 
 Result = ParseExpression(MaybeTypeCast);
-if (!getLangOpts().CPlusPlus && MaybeTypeCast && Result.isUsable()) {
+if (!getLangOpts().CPlusPlus && Result.isUsable()) {
   // Correct typos in non-C++ code earlier so that implicit-cast-like
   // expressions are parsed correctly.
   Result = Actions.CorrectDelayedTyposInExpr(Result);


Index: clang/lib/Parse/ParseExpr.cpp
===
--- clang/lib/Parse/ParseExpr.cpp
+++ clang/lib/Parse/ParseExpr.cpp
@@ -3168,7 +3168,7 @@
 InMessageExpressionRAIIObject InMessage(*this, false);
 
 Result = ParseExpression(MaybeTypeCast);
-if (!getLangOpts().CPlusPlus && MaybeTypeCast && Result.isUsable()) {
+if (!getLangOpts().CPlusPlus && Result.isUsable()) {
   // Correct typos in non-C++ code earlier so that implicit-cast-like
   // expressions are parsed correctly.
   Result = Actions.CorrectDelayedTyposInExpr(Result);
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D138505: [clangd] Don't run slow clang-tidy checks

2022-11-22 Thread Sam McCall via Phabricator via cfe-commits
sammccall created this revision.
sammccall added a reviewer: kadircet.
Herald added a subscriber: arphaman.
Herald added a reviewer: njames93.
Herald added a project: All.
sammccall requested review of this revision.
Herald added subscribers: cfe-commits, MaskRay, ilya-biryukov.
Herald added a project: clang-tools-extra.

This uses the fast-check allowlist added in the previous commit.
This is behind a config option to allow users/developers to enable checks
we haven't timed yet, and to allow the --check-tidy-time flag to work.

https://github.com/clangd/clangd/issues/1337


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D138505

Files:
  clang-tools-extra/clangd/Config.h
  clang-tools-extra/clangd/ConfigCompile.cpp
  clang-tools-extra/clangd/ConfigFragment.h
  clang-tools-extra/clangd/ConfigYAML.cpp
  clang-tools-extra/clangd/ParsedAST.cpp
  clang-tools-extra/clangd/TidyProvider.cpp
  clang-tools-extra/clangd/TidyProvider.h
  clang-tools-extra/clangd/tool/Check.cpp

Index: clang-tools-extra/clangd/tool/Check.cpp
===
--- clang-tools-extra/clangd/tool/Check.cpp
+++ clang-tools-extra/clangd/tool/Check.cpp
@@ -30,6 +30,8 @@
 #include "CodeComplete.h"
 #include "CompileCommands.h"
 #include "Config.h"
+#include "ConfigFragment.h"
+#include "ConfigProvider.h"
 #include "Feature.h"
 #include "GlobalCompilationDatabase.h"
 #include "Hover.h"
@@ -82,15 +84,19 @@
 "check-completion",
 llvm::cl::desc("Run code-completion at each point (slow)"),
 llvm::cl::init(false)};
+llvm::cl::opt CheckWarnings{
+"check-warnings",
+llvm::cl::desc("Print warnings as well as errors"),
+llvm::cl::init(false)};
 
 // Print (and count) the error-level diagnostics (warnings are ignored).
 unsigned showErrors(llvm::ArrayRef Diags) {
   unsigned ErrCount = 0;
   for (const auto &D : Diags) {
-if (D.Severity >= DiagnosticsEngine::Error) {
+if (D.Severity >= DiagnosticsEngine::Error || CheckWarnings)
   elog("[{0}] Line {1}: {2}", D.Name, D.Range.start.line + 1, D.Message);
+if (D.Severity >= DiagnosticsEngine::Error)
   ++ErrCount;
-}
   }
   return ErrCount;
 }
@@ -452,8 +458,23 @@
   }
   log("Testing on source file {0}", File);
 
+  class OverrideConfigProvider : public config::Provider {
+std::vector
+getFragments(const config::Params &,
+ config::DiagnosticCallback Diag) const override {
+  config::Fragment F;
+  // If we're timing clang-tidy checks, implicitly disabling the slow ones
+  // is counterproductive! 
+  if (CheckTidyTime.getNumOccurrences())
+F.Diagnostics.ClangTidy.SlowChecks = true;
+  return {std::move(F).compile(Diag)};
+}
+  } OverrideConfig;
+  auto ConfigProvider =
+  config::Provider::combine({Opts.ConfigProvider, &OverrideConfig});
+
   auto ContextProvider = ClangdServer::createConfiguredContextProvider(
-  Opts.ConfigProvider, nullptr);
+  ConfigProvider.get(), nullptr);
   WithContext Ctx(ContextProvider(
   FakeFile.empty()
   ? File
Index: clang-tools-extra/clangd/TidyProvider.h
===
--- clang-tools-extra/clangd/TidyProvider.h
+++ clang-tools-extra/clangd/TidyProvider.h
@@ -60,6 +60,10 @@
 /// \pre \p must not be empty, must not contain '*' or ',' or start with '-'.
 bool isRegisteredTidyCheck(llvm::StringRef Check);
 
+/// Returns if \p Check is a known-fast clang-tidy check.
+/// By default, only such checks will run in clangd.
+bool isFastTidyCheck(llvm::StringRef Check);
+
 } // namespace clangd
 } // namespace clang
 
Index: clang-tools-extra/clangd/TidyProvider.cpp
===
--- clang-tools-extra/clangd/TidyProvider.cpp
+++ clang-tools-extra/clangd/TidyProvider.cpp
@@ -213,13 +213,7 @@
// tries to build an AST.
"-bugprone-use-after-move",
// Alias for bugprone-use-after-move.
-   "-hicpp-invalid-access-moved",
-
-   // - Performance problems -
-
-   // This check runs expensive analysis for each variable.
-   // It has been observed to increase reparse time by 10x.
-   "-misc-const-correctness");
+   "-hicpp-invalid-access-moved");
 
   size_t Size = BadChecks.size();
   for (const std::string &Str : ExtraBadChecks) {
@@ -308,5 +302,14 @@
 
   return AllChecks.contains(Check);
 }
+
+bool isFastTidyCheck(llvm::StringRef Check) {
+  static auto &Fast = *new llvm::StringSet<>{
+#define FAST(CHECK, TIME) #CHECK,
+#include "TidyFastChecks.inc"
+  };
+  return Fast.contains(Check);
+}
+
 } // namespace clangd
 } // namespace clang
Index: clang-tools-extra/clangd/ParsedAST.cpp
===
--- clang-tools-extra/clangd/ParsedAST.cpp
++

[PATCH] D138505: [clangd] Don't run slow clang-tidy checks

2022-11-22 Thread Sam McCall via Phabricator via cfe-commits
sammccall added a comment.

Ideas on testing welcome. Does it make sense to rely on the fact that 
`misc-const-correctness` is always slow? :-D


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D138505/new/

https://reviews.llvm.org/D138505

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D137375: [AIX][pg] Add Correct Search Paths for Profiled Libraries

2022-11-22 Thread Michael Francis via Phabricator via cfe-commits
francii added a comment.

In D137375#3943751 , @cebowleratibm 
wrote:

> Looks good but I just want to confirm that the profiled -L paths are appended 
> in the correct order with respect to the non-profiled paths.

The linker gives priority to the libraries that are linked last, in the sense 
that if I link 2 directories with the same library, the library that gets 
linked against is chosen from the second directory, not the first. This patch 
makes the profiled libraries the last to be linked against, so that their 
linking overwrites the linking of their non-profiled counterparts.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D137375/new/

https://reviews.llvm.org/D137375

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D138394: HIP: Directly call fma builtins

2022-11-22 Thread Matt Arsenault via Phabricator via cfe-commits
arsenm updated this revision to Diff 477213.
arsenm added a comment.

Missed one


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D138394/new/

https://reviews.llvm.org/D138394

Files:
  clang/lib/Headers/__clang_hip_math.h
  clang/test/Headers/__clang_hip_math.hip

Index: clang/test/Headers/__clang_hip_math.hip
===
--- clang/test/Headers/__clang_hip_math.hip
+++ clang/test/Headers/__clang_hip_math.hip
@@ -943,13 +943,13 @@
 
 // DEFAULT-LABEL: @test_fmaf(
 // DEFAULT-NEXT:  entry:
-// DEFAULT-NEXT:[[CALL_I:%.*]] = tail call contract float @__ocml_fma_f32(float noundef [[X:%.*]], float noundef [[Y:%.*]], float noundef [[Z:%.*]]) #[[ATTR15]]
-// DEFAULT-NEXT:ret float [[CALL_I]]
+// DEFAULT-NEXT:[[TMP0:%.*]] = tail call contract float @llvm.fma.f32(float [[X:%.*]], float [[Y:%.*]], float [[Z:%.*]])
+// DEFAULT-NEXT:ret float [[TMP0]]
 //
 // FINITEONLY-LABEL: @test_fmaf(
 // FINITEONLY-NEXT:  entry:
-// FINITEONLY-NEXT:[[CALL_I:%.*]] = tail call nnan ninf contract float @__ocml_fma_f32(float noundef [[X:%.*]], float noundef [[Y:%.*]], float noundef [[Z:%.*]]) #[[ATTR15]]
-// FINITEONLY-NEXT:ret float [[CALL_I]]
+// FINITEONLY-NEXT:[[TMP0:%.*]] = tail call nnan ninf contract float @llvm.fma.f32(float [[X:%.*]], float [[Y:%.*]], float [[Z:%.*]])
+// FINITEONLY-NEXT:ret float [[TMP0]]
 //
 extern "C" __device__ float test_fmaf(float x, float y, float z) {
   return fmaf(x, y, z);
@@ -957,13 +957,13 @@
 
 // DEFAULT-LABEL: @test_fma(
 // DEFAULT-NEXT:  entry:
-// DEFAULT-NEXT:[[CALL_I:%.*]] = tail call contract double @__ocml_fma_f64(double noundef [[X:%.*]], double noundef [[Y:%.*]], double noundef [[Z:%.*]]) #[[ATTR15]]
-// DEFAULT-NEXT:ret double [[CALL_I]]
+// DEFAULT-NEXT:[[TMP0:%.*]] = tail call contract double @llvm.fma.f64(double [[X:%.*]], double [[Y:%.*]], double [[Z:%.*]])
+// DEFAULT-NEXT:ret double [[TMP0]]
 //
 // FINITEONLY-LABEL: @test_fma(
 // FINITEONLY-NEXT:  entry:
-// FINITEONLY-NEXT:[[CALL_I:%.*]] = tail call nnan ninf contract double @__ocml_fma_f64(double noundef [[X:%.*]], double noundef [[Y:%.*]], double noundef [[Z:%.*]]) #[[ATTR15]]
-// FINITEONLY-NEXT:ret double [[CALL_I]]
+// FINITEONLY-NEXT:[[TMP0:%.*]] = tail call nnan ninf contract double @llvm.fma.f64(double [[X:%.*]], double [[Y:%.*]], double [[Z:%.*]])
+// FINITEONLY-NEXT:ret double [[TMP0]]
 //
 extern "C" __device__ double test_fma(double x, double y, double z) {
   return fma(x, y, z);
@@ -971,13 +971,13 @@
 
 // DEFAULT-LABEL: @test_fma_rn(
 // DEFAULT-NEXT:  entry:
-// DEFAULT-NEXT:[[CALL_I:%.*]] = tail call contract double @__ocml_fma_f64(double noundef [[X:%.*]], double noundef [[Y:%.*]], double noundef [[Z:%.*]]) #[[ATTR15]]
-// DEFAULT-NEXT:ret double [[CALL_I]]
+// DEFAULT-NEXT:[[TMP0:%.*]] = tail call contract double @llvm.fma.f64(double [[X:%.*]], double [[Y:%.*]], double [[Z:%.*]])
+// DEFAULT-NEXT:ret double [[TMP0]]
 //
 // FINITEONLY-LABEL: @test_fma_rn(
 // FINITEONLY-NEXT:  entry:
-// FINITEONLY-NEXT:[[CALL_I:%.*]] = tail call nnan ninf contract double @__ocml_fma_f64(double noundef [[X:%.*]], double noundef [[Y:%.*]], double noundef [[Z:%.*]]) #[[ATTR15]]
-// FINITEONLY-NEXT:ret double [[CALL_I]]
+// FINITEONLY-NEXT:[[TMP0:%.*]] = tail call nnan ninf contract double @llvm.fma.f64(double [[X:%.*]], double [[Y:%.*]], double [[Z:%.*]])
+// FINITEONLY-NEXT:ret double [[TMP0]]
 //
 extern "C" __device__ double test_fma_rn(double x, double y, double z) {
   return __fma_rn(x, y, z);
@@ -3360,13 +3360,13 @@
 
 // DEFAULT-LABEL: @test__fmaf_rn(
 // DEFAULT-NEXT:  entry:
-// DEFAULT-NEXT:[[CALL_I:%.*]] = tail call contract float @__ocml_fma_f32(float noundef [[X:%.*]], float noundef [[Y:%.*]], float noundef [[Z:%.*]]) #[[ATTR15]]
-// DEFAULT-NEXT:ret float [[CALL_I]]
+// DEFAULT-NEXT:[[TMP0:%.*]] = tail call contract float @llvm.fma.f32(float [[X:%.*]], float [[Y:%.*]], float [[Z:%.*]])
+// DEFAULT-NEXT:ret float [[TMP0]]
 //
 // FINITEONLY-LABEL: @test__fmaf_rn(
 // FINITEONLY-NEXT:  entry:
-// FINITEONLY-NEXT:[[CALL_I:%.*]] = tail call nnan ninf contract float @__ocml_fma_f32(float noundef [[X:%.*]], float noundef [[Y:%.*]], float noundef [[Z:%.*]]) #[[ATTR15]]
-// FINITEONLY-NEXT:ret float [[CALL_I]]
+// FINITEONLY-NEXT:[[TMP0:%.*]] = tail call nnan ninf contract float @llvm.fma.f32(float [[X:%.*]], float [[Y:%.*]], float [[Z:%.*]])
+// FINITEONLY-NEXT:ret float [[TMP0]]
 //
 extern "C" __device__ float test__fmaf_rn(float x, float y, float z) {
   return __fmaf_rn(x, y, z);
@@ -3624,13 +3624,13 @@
 
 // DEFAULT-LABEL: @test__fma_rn(
 // DEFAULT-NEXT:  entry:
-// DEFAULT-NEXT:[[CALL_I:%.*]] = tail call contract double @__ocml_fma_f64(double noundef [[X:%.*]], double noundef [[Y:%.*]], double noundef [[Z:%.*]]) #[[ATTR15]]
-// DEFAULT-NEXT:ret double [[CALL_I]]
+// DEFAULT-NEXT:[[TMP0:%.*]] = tail call contr

[PATCH] D138504: clang/HIP: Remove __llvm_amdgcn_* wrapper hacks

2022-11-22 Thread Matt Arsenault via Phabricator via cfe-commits
arsenm updated this revision to Diff 477219.
arsenm added a comment.

Remove some of the externally defined ones


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D138504/new/

https://reviews.llvm.org/D138504

Files:
  clang/lib/Headers/__clang_hip_libdevice_declares.h
  clang/lib/Headers/__clang_hip_math.h


Index: clang/lib/Headers/__clang_hip_math.h
===
--- clang/lib/Headers/__clang_hip_math.h
+++ clang/lib/Headers/__clang_hip_math.h
@@ -659,7 +659,7 @@
 #endif
 
 __DEVICE__
-float __frsqrt_rn(float __x) { return __llvm_amdgcn_rsq_f32(__x); }
+float __frsqrt_rn(float __x) { return __builtin_amdgcn_rsqf(__x); }
 
 #if defined OCML_BASIC_ROUNDED_OPERATIONS
 __DEVICE__
Index: clang/lib/Headers/__clang_hip_libdevice_declares.h
===
--- clang/lib/Headers/__clang_hip_libdevice_declares.h
+++ clang/lib/Headers/__clang_hip_libdevice_declares.h
@@ -137,23 +137,6 @@
 __device__ __attribute__((const)) float __ocml_fma_rtn_f32(float, float, 
float);
 __device__ __attribute__((const)) float __ocml_fma_rtp_f32(float, float, 
float);
 __device__ __attribute__((const)) float __ocml_fma_rtz_f32(float, float, 
float);
-
-__device__ inline __attribute__((const)) float
-__llvm_amdgcn_cos_f32(float __x) {
-  return __builtin_amdgcn_cosf(__x);
-}
-__device__ inline __attribute__((const)) float
-__llvm_amdgcn_rcp_f32(float __x) {
-  return __builtin_amdgcn_rcpf(__x);
-}
-__device__ inline __attribute__((const)) float
-__llvm_amdgcn_rsq_f32(float __x) {
-  return __builtin_amdgcn_rsqf(__x);
-}
-__device__ inline __attribute__((const)) float
-__llvm_amdgcn_sin_f32(float __x) {
-  return __builtin_amdgcn_sinf(__x);
-}
 // END INTRINSICS
 // END FLOAT
 
@@ -277,15 +260,6 @@
 __device__ __attribute__((const)) double __ocml_fma_rtz_f64(double, double,
 double);
 
-__device__ inline __attribute__((const)) double
-__llvm_amdgcn_rcp_f64(double __x) {
-  return __builtin_amdgcn_rcp(__x);
-}
-__device__ inline __attribute__((const)) double
-__llvm_amdgcn_rsq_f64(double __x) {
-  return __builtin_amdgcn_rsq(__x);
-}
-
 __device__ __attribute__((const)) _Float16 __ocml_ceil_f16(_Float16);
 __device__ _Float16 __ocml_cos_f16(_Float16);
 __device__ __attribute__((const)) _Float16 __ocml_cvtrtn_f16_f32(float);
@@ -305,7 +279,6 @@
 __device__ __attribute__((pure)) _Float16 __ocml_log_f16(_Float16);
 __device__ __attribute__((pure)) _Float16 __ocml_log10_f16(_Float16);
 __device__ __attribute__((pure)) _Float16 __ocml_log2_f16(_Float16);
-__device__ __attribute__((const)) _Float16 __llvm_amdgcn_rcp_f16(_Float16);
 __device__ __attribute__((const)) _Float16 __ocml_rint_f16(_Float16);
 __device__ __attribute__((const)) _Float16 __ocml_rsqrt_f16(_Float16);
 __device__ _Float16 __ocml_sin_f16(_Float16);
@@ -332,11 +305,6 @@
 __device__ __attribute__((pure)) __2f16 __ocml_log_2f16(__2f16);
 __device__ __attribute__((pure)) __2f16 __ocml_log10_2f16(__2f16);
 __device__ __attribute__((pure)) __2f16 __ocml_log2_2f16(__2f16);
-__device__ inline __2f16
-__llvm_amdgcn_rcp_2f16(__2f16 __x) // Not currently exposed by ROCDL.
-{
-  return (__2f16)(__llvm_amdgcn_rcp_f16(__x.x), __llvm_amdgcn_rcp_f16(__x.y));
-}
 __device__ __attribute__((const)) __2f16 __ocml_rint_2f16(__2f16);
 __device__ __attribute__((const)) __2f16 __ocml_rsqrt_2f16(__2f16);
 __device__ __2f16 __ocml_sin_2f16(__2f16);


Index: clang/lib/Headers/__clang_hip_math.h
===
--- clang/lib/Headers/__clang_hip_math.h
+++ clang/lib/Headers/__clang_hip_math.h
@@ -659,7 +659,7 @@
 #endif
 
 __DEVICE__
-float __frsqrt_rn(float __x) { return __llvm_amdgcn_rsq_f32(__x); }
+float __frsqrt_rn(float __x) { return __builtin_amdgcn_rsqf(__x); }
 
 #if defined OCML_BASIC_ROUNDED_OPERATIONS
 __DEVICE__
Index: clang/lib/Headers/__clang_hip_libdevice_declares.h
===
--- clang/lib/Headers/__clang_hip_libdevice_declares.h
+++ clang/lib/Headers/__clang_hip_libdevice_declares.h
@@ -137,23 +137,6 @@
 __device__ __attribute__((const)) float __ocml_fma_rtn_f32(float, float, float);
 __device__ __attribute__((const)) float __ocml_fma_rtp_f32(float, float, float);
 __device__ __attribute__((const)) float __ocml_fma_rtz_f32(float, float, float);
-
-__device__ inline __attribute__((const)) float
-__llvm_amdgcn_cos_f32(float __x) {
-  return __builtin_amdgcn_cosf(__x);
-}
-__device__ inline __attribute__((const)) float
-__llvm_amdgcn_rcp_f32(float __x) {
-  return __builtin_amdgcn_rcpf(__x);
-}
-__device__ inline __attribute__((const)) float
-__llvm_amdgcn_rsq_f32(float __x) {
-  return __builtin_amdgcn_rsqf(__x);
-}
-__device__ inline __attribute__((const)) float
-__llvm_amdgcn_sin_f32(float __x) {
-  return __builtin_amdgcn_sinf(__x);
-}
 // END INTRINSICS
 // END FLOAT
 
@@ -277,15 +260,6 @@
 __device__ __a

  1   2   3   >