[PATCH] D105457: [clang] Refactor AST printing tests to share more infrastructure

[Douglas Yung via Phabricator via cfe-commits]

dyung added a comment.

In D105457#2875672 , @dblaikie wrote:

> In D105457#2874783 , @nridge wrote:
>
>> To be honest, I don't really understand this error. It seems to come from a 
>> compile step (not a link step), and it comes from the assembler and says 
>> "symbol ... is already defined"? I don't think I've seen an error like that 
>> before. (Typically, errors about duplicate definitions would come from the 
>> linker.)
>>
>> Any suggestions for what it might indicate or how to investigate are welcome.
>
> Yeah, I'm with you there.
>
> @dyung @glaubitz - perhaps you two could help with a reduced example of what 
> causes this, it does look like a bug in the compiler (yeah, I'd at first 
> assumed a bug in the standard library that caused a link error, but as 
> @nridge pointed out it's not a link error but an assembly error - which 
> really looks like a compiler bug to me) - but likely there's some room for a 
> workaround if we knew what we were dealing with and how to workaround it 
> reliably.

@nridge, from the commit message of your revert, it sounds like you are able to 
locally reproduce the failure?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105457

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

[PATCH] D105726: Added fsanitize-address-instrument-via-callback, which controls if address sanitizer will always use a callback.

[Vitaly Buka via Phabricator via cfe-commits]

vitalybuka added a comment.

In D105726#2875482 , @kstoimenov 
wrote:

> Modified UsersManual.rst and added a test. Couldn't find a relevant section in
> AddressSanitizer.rst and adding a new one is outside of the scope of this 
> change.

something like:
Limitations

AddressSanitizer increases binary size. Use -fsanitize-address-instrument... to 
 reduce the overhead.




Comment at: clang/docs/UsersManual.rst:1652
 
+**-f[no-]sanitize-address-instrument-via-callback**
+

Here "Callback" here does not match common meaning of this term and it's just 
out internal detail.

**-f[no-]sanitize-address-inline-instrumentation**
or even
**-f[no-]sanitize-address-inline**
or 
**-f[no-]sanitize-address-outline-instrumentation**



Comment at: clang/include/clang/Driver/Options.td:1564
+HelpText<"Always use callback 
for the address sanitizer">;
+def fnosanitize_address_instrument_via_callback : Flag<["-"], 
"fnosanitize-address-instrument-via-callback">,
+  Group,

no-



Comment at: clang/test/Driver/fsanitize.c:254
+// CHECK-ASAN-CALLBACK-OK: "-mllvm" 
"-asan-instrumentation-with-call-threshold=0"
+// RUN: %clang -target x86_64-linux-gnu -fsanitize=address 
-fnosanitize-address-instrument-via-callback %s -### 2>&1 | FileCheck %s 
--check-prefix=CHECK-ASAN-NOCALLBACK
+// CHECK-ASAN-NOCALLBACK-NOT: "-mllvm" 
"-asan-instrumentation-with-call-threshold=0"

Maybe test pairs to make sure the last one is selected
"-fno-sanitize- -fsanitize-"
"-fsanitize- -no-fsanitize-"


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105726

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

[PATCH] D105091: [RISCV] Pass -u to linker correctly.

[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 rG5635d2a56dab: [RISCV] Pass -u to linker correctly. (authored 
by Kito Cheng ).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105091

Files:
  clang/lib/Driver/ToolChains/RISCVToolchain.cpp
  clang/test/Driver/riscv-args.c


Index: clang/test/Driver/riscv-args.c
===
--- clang/test/Driver/riscv-args.c
+++ clang/test/Driver/riscv-args.c
@@ -1,7 +1,6 @@
 // Check the arguments are correctly passed
 
 // Make sure -T is the last with gcc-toolchain option
-// RUN: %clang -### -target riscv32 \
-// RUN:   --gcc-toolchain= -Xlinker --defsym=FOO=10 -T a.lds %s 2>&1 \
+// RUN: %clang -### -target riscv32 --gcc-toolchain= -Xlinker --defsym=FOO=10 
-T a.lds -u foo %s 2>&1 \
 // RUN:   | FileCheck -check-prefix=CHECK-LD %s
-// CHECK-LD: {{.*}} "--defsym=FOO=10" {{.*}} "-T" "a.lds"
+// CHECK-LD: {{.*}} "--defsym=FOO=10" {{.*}} "-u" "foo" {{.*}} "-T" "a.lds"
Index: clang/lib/Driver/ToolChains/RISCVToolchain.cpp
===
--- clang/lib/Driver/ToolChains/RISCVToolchain.cpp
+++ clang/lib/Driver/ToolChains/RISCVToolchain.cpp
@@ -184,6 +184,7 @@
   AddLinkerInputs(ToolChain, Inputs, Args, CmdArgs, JA);
 
   Args.AddAllArgs(CmdArgs, options::OPT_L);
+  Args.AddAllArgs(CmdArgs, options::OPT_u);
   ToolChain.AddFilePathLibArgs(Args, CmdArgs);
   Args.AddAllArgs(CmdArgs,
   {options::OPT_T_Group, options::OPT_e, options::OPT_s,


Index: clang/test/Driver/riscv-args.c
===
--- clang/test/Driver/riscv-args.c
+++ clang/test/Driver/riscv-args.c
@@ -1,7 +1,6 @@
 // Check the arguments are correctly passed
 
 // Make sure -T is the last with gcc-toolchain option
-// RUN: %clang -### -target riscv32 \
-// RUN:   --gcc-toolchain= -Xlinker --defsym=FOO=10 -T a.lds %s 2>&1 \
+// RUN: %clang -### -target riscv32 --gcc-toolchain= -Xlinker --defsym=FOO=10 -T a.lds -u foo %s 2>&1 \
 // RUN:   | FileCheck -check-prefix=CHECK-LD %s
-// CHECK-LD: {{.*}} "--defsym=FOO=10" {{.*}} "-T" "a.lds"
+// CHECK-LD: {{.*}} "--defsym=FOO=10" {{.*}} "-u" "foo" {{.*}} "-T" "a.lds"
Index: clang/lib/Driver/ToolChains/RISCVToolchain.cpp
===
--- clang/lib/Driver/ToolChains/RISCVToolchain.cpp
+++ clang/lib/Driver/ToolChains/RISCVToolchain.cpp
@@ -184,6 +184,7 @@
   AddLinkerInputs(ToolChain, Inputs, Args, CmdArgs, JA);
 
   Args.AddAllArgs(CmdArgs, options::OPT_L);
+  Args.AddAllArgs(CmdArgs, options::OPT_u);
   ToolChain.AddFilePathLibArgs(Args, CmdArgs);
   Args.AddAllArgs(CmdArgs,
   {options::OPT_T_Group, options::OPT_e, options::OPT_s,
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] 5635d2a - [RISCV] Pass -u to linker correctly.

[Kito Cheng via cfe-commits]

Author: Kito Cheng
Date: 2021-07-14T14:25:02+08:00
New Revision: 5635d2a56dab6dc64d3a3f185d68f676b81dc736

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

LOG: [RISCV] Pass -u to linker correctly.

`-u` is a linker option used to pretend a symbol is undefined,
this option are common used for forcing archive member extraction.

This option should pass to `ld`, and many other toolchain in Clang
like `tools::gnutools` has pass that too.

Reviewed By: MaskRay

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

Added: 


Modified: 
clang/lib/Driver/ToolChains/RISCVToolchain.cpp
clang/test/Driver/riscv-args.c

Removed: 




diff  --git a/clang/lib/Driver/ToolChains/RISCVToolchain.cpp 
b/clang/lib/Driver/ToolChains/RISCVToolchain.cpp
index 0b8c52096933d..075c1dc11b210 100644
--- a/clang/lib/Driver/ToolChains/RISCVToolchain.cpp
+++ b/clang/lib/Driver/ToolChains/RISCVToolchain.cpp
@@ -184,6 +184,7 @@ void RISCV::Linker::ConstructJob(Compilation &C, const 
JobAction &JA,
   AddLinkerInputs(ToolChain, Inputs, Args, CmdArgs, JA);
 
   Args.AddAllArgs(CmdArgs, options::OPT_L);
+  Args.AddAllArgs(CmdArgs, options::OPT_u);
   ToolChain.AddFilePathLibArgs(Args, CmdArgs);
   Args.AddAllArgs(CmdArgs,
   {options::OPT_T_Group, options::OPT_e, options::OPT_s,

diff  --git a/clang/test/Driver/riscv-args.c b/clang/test/Driver/riscv-args.c
index 7b68df977f7c3..305a50885eade 100644
--- a/clang/test/Driver/riscv-args.c
+++ b/clang/test/Driver/riscv-args.c
@@ -1,7 +1,6 @@
 // Check the arguments are correctly passed
 
 // Make sure -T is the last with gcc-toolchain option
-// RUN: %clang -### -target riscv32 \
-// RUN:   --gcc-toolchain= -Xlinker --defsym=FOO=10 -T a.lds %s 2>&1 \
+// RUN: %clang -### -target riscv32 --gcc-toolchain= -Xlinker --defsym=FOO=10 
-T a.lds -u foo %s 2>&1 \
 // RUN:   | FileCheck -check-prefix=CHECK-LD %s
-// CHECK-LD: {{.*}} "--defsym=FOO=10" {{.*}} "-T" "a.lds"
+// CHECK-LD: {{.*}} "--defsym=FOO=10" {{.*}} "-u" "foo" {{.*}} "-T" "a.lds"



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

[PATCH] D105564: Fix for DWARF parsing to better handle auto return type for member functions

[Jonas Devlieghere via Phabricator via cfe-commits]

JDevlieghere added inline comments.



Comment at: lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp:402-403
 case DW_AT_type:
-  type = form_value;
+  if (!type.IsValid())
+type = form_value;
   break;

What's the purpose of this? Do we expect to see the type attribute more than 
once? 



Comment at: lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp:900-901
+  const auto *ft = qt->getAs();
+  TypeSystemClang *ts =
+  llvm::dyn_cast_or_null(function_type.GetTypeSystem());
+  ast.adjustDeducedFunctionResultType(

You're doing `dyn_cast_or_null` but then below you're dereferencing `ts` 
unconditionally? 



Comment at: 
lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp:1337-1339
+TypeSP ret_type = dwarf->FindTypeForAutoReturnForDIE(
+die, ConstString(attrs.mangled_name));
+if (ret_type) {

LLVM likes to put these variables in the if-clause, which I personally really 
like because it conveys the scope without hurting readability. 



Comment at: 
lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp:1341-1344
+  auto *function_decl = llvm::dyn_cast_or_null(
+  GetCachedClangDeclContextForDIE(die));
+
+  if (function_decl)





Comment at: lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp:2672-2675
+  TypeSP type_sp;
+
+  if (!name)
+return type_sp;

I know this pattern is common in LLDB, but I really dislike it because you have 
to backtrack all the way to the beginning of the function to know if `type_sp` 
has been modified in any way. When I write code like, this I tend to use 
`return {};` to make it clear I'm returning a default constructed instance of 
the return type. That also makes it clear where we're actually returning a 
non-default instance by just looking at the `return`s. 



Comment at: lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp:2718
+
+  type_sp = func_type->shared_from_this();
+}




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

https://reviews.llvm.org/D105564

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

[PATCH] D104420: thread_local support for AIX

[Hubert Tong via Phabricator via cfe-commits]

hubert.reinterpretcast added inline comments.



Comment at: clang/lib/CodeGen/ItaniumCXXABI.cpp:2966
+// other TUs will not know whether the initialization routine exists
+// so create a weak, empty, init function to satisfy the linker.
+// This is needed whenever a thread wrapper function is not used, and

The linkage of the init function here should not be hard-coded as weak: If the 
strong definition of the variable has no dynamic initialization/finalization, 
then the init function the wrapper functions call should resolve to the empty 
version created here.


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

https://reviews.llvm.org/D104420

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

[PATCH] D105960: [clang][driver][darwin] Add driver support for Mac Catalyst

[Alex Lorenz via Phabricator via cfe-commits]

arphaman created this revision.
arphaman added reviewers: dexonsmith, Bigcheese.
Herald added a subscriber: ributzka.
arphaman requested review of this revision.
Herald added a project: clang.

This patch is the last patch in the series of patches for the Mac Catalyst 
support in clang. It adds driver support for the Mac Catalyst target, as 
supported by the Apple clang compiler. It depends on 
https://reviews.llvm.org/D105257


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D105960

Files:
  clang/include/clang/Basic/DarwinSDKInfo.h
  clang/include/clang/Basic/DiagnosticDriverKinds.td
  clang/lib/Basic/DarwinSDKInfo.cpp
  clang/lib/Driver/ToolChains/Darwin.cpp
  clang/lib/Driver/ToolChains/Darwin.h
  clang/test/Driver/Inputs/MacOSX10.15.versioned.sdk/SDKSettings.json
  clang/test/Driver/darwin-ld-platform-version-maccatalyst.c
  clang/test/Driver/darwin-ld.c
  clang/test/Driver/darwin-mac-catalyst-32bit-not-supported.c
  clang/test/Driver/darwin-maccatalyst.c
  clang/test/Driver/darwin-objc-defaults.m
  clang/test/Driver/darwin-objc-runtime-maccatalyst.m
  clang/test/Driver/darwin-sanitizer-ld.c
  clang/test/Driver/darwin-sdk-version-maccatalyst.c

Index: clang/test/Driver/darwin-sdk-version-maccatalyst.c
===
--- /dev/null
+++ clang/test/Driver/darwin-sdk-version-maccatalyst.c
@@ -0,0 +1,6 @@
+// RUN: %clang -target x86_64-apple-ios13.1-macabi -isysroot %S/Inputs/MacOSX10.15.versioned.sdk -c -### %s 2>&1 \
+// RUN:   | FileCheck %s
+// RUN: %clang -target x86_64-apple-ios13.99-macabi -isysroot %S/Inputs/MacOSX10.15.versioned.sdk -c -### %s 2>&1 \
+// RUN:   | FileCheck %s
+
+// CHECK: "-target-sdk-version=13.1"
Index: clang/test/Driver/darwin-sanitizer-ld.c
===
--- clang/test/Driver/darwin-sanitizer-ld.c
+++ clang/test/Driver/darwin-sanitizer-ld.c
@@ -93,6 +93,18 @@
 // CHECK-ASAN-WATCHOSSIM: "-rpath" "@executable_path"
 // CHECK-ASAN-WATCHOSSIM: "-rpath" "{{.*}}lib{{.*}}darwin"
 
+// RUN: %clang -no-canonical-prefixes -### -target x86_64-apple-ios13.1-macabi \
+// RUN:   -stdlib=platform -fsanitize=address \
+// RUN:   -resource-dir %S/Inputs/resource_dir \
+// RUN:   %s -o %t.o 2>&1 | FileCheck --check-prefix=CHECK-ASAN-MACCATALYST %s
+
+// CHECK-ASAN-MACCATALYST: "{{.*}}ld{{(.exe)?}}"
+// CHECK-ASAN-MACCATALYST-NOT: "-lstdc++"
+// CHECK-ASAN-MACCATALYST-NOT: "-lc++"
+// CHECK-ASAN-MACCATALYST: libclang_rt.asan_osx_dynamic.dylib"
+// CHECK-ASAN-MACCATALYST: "-rpath" "@executable_path"
+// CHECK-ASAN-MACCATALYST: "-rpath" "{{.*}}lib{{.*}}darwin"
+
 // RUN: %clang -no-canonical-prefixes -### -target armv7-apple-ios  \
 // RUN:   -stdlib=platform -fsanitize=address -miphoneos-version-min=7 \
 // RUN:   %s -o %t.o 2>&1 | FileCheck --check-prefix=CHECK-ASAN-IOS %s
Index: clang/test/Driver/darwin-objc-runtime-maccatalyst.m
===
--- /dev/null
+++ clang/test/Driver/darwin-objc-runtime-maccatalyst.m
@@ -0,0 +1,13 @@
+// RUN: %clang -target x86_64-apple-ios13.2-macabi -isysroot %S/Inputs/MacOSX10.15.versioned.sdk -c %s -### 2>&1 \
+// RUN:   | FileCheck %s
+// RUN: %clang -target x86_64-apple-ios13.2.0-macabi -isysroot %S/Inputs/MacOSX10.15.versioned.sdk -c %s -### 2>&1 \
+// RUN:   | FileCheck %s
+// RUN: %clang -target x86_64-apple-ios13.2-macabi -isysroot %S/Inputs/MacOSX10.14.sdk -c %s -### 2>&1 \
+// RUN:   | FileCheck --check-prefix=FALLBACK-DEFAULT %s
+// RUN: %clang -target x86_64-apple-ios12.99.99-macabi -isysroot %S/Inputs/MacOSX10.15.versioned.sdk -c %s -### 2>&1 \
+// RUN:   | FileCheck --check-prefix=FALLBACK-DEFAULT %s
+// RUN: %clang -target x86_64-apple-ios-macabi -isysroot %S/Inputs/MacOSX10.15.versioned.sdk -c %s -### 2>&1 \
+// RUN:   | FileCheck --check-prefix=FALLBACK-DEFAULT %s
+
+// CHECK: -fobjc-runtime=macosx-10.15.1
+// FALLBACK-DEFAULT: -fobjc-runtime=macosx-10.15
Index: clang/test/Driver/darwin-objc-defaults.m
===
--- clang/test/Driver/darwin-objc-defaults.m
+++ clang/test/Driver/darwin-objc-defaults.m
@@ -92,3 +92,11 @@
 // CHECK-CHECK-ARMV7_IPHONE3_0: -fobjc-runtime=ios-3.0
 // CHECK-CHECK-ARMV7_IPHONE3_0-NOT: -fobjc-dispatch-method
 // CHECK-CHECK-ARMV7_IPHONE3_0: darwin-objc-defaults
+
+// RUN: %clang -target x86_64-apple-ios13.1-macabi -S -### %s 2> %t
+// RUN: FileCheck --check-prefix CHECK-CHECK-MACCATALYST < %t %s
+
+// CHECK-CHECK-MACCATALYST: "-cc1"
+// CHECK-CHECK-MACCATALYST: -fobjc-runtime=macosx-10.15
+// CHECK-CHECK-MACCATALYST-NOT: -fobjc-dispatch-method
+// CHECK-CHECK-MACCATALYST: darwin-objc-defaults
Index: clang/test/Driver/darwin-maccatalyst.c
===
--- /dev/null
+++ clang/test/Driver/darwin-maccatalyst.c
@@ -0,0 +1,9 @@
+// RUN: %clang -target x86_64-apple-ios13.1-macabi -c %s -### 2>&1 | \
+// RUN:   FileCheck --check-prefix=CHECK-VERS

[PATCH] D105958: [clang][darwin] add support for version remapping to the Darwin SDK Info class

[Alex Lorenz via Phabricator via cfe-commits]

arphaman added a comment.

This patch depends on a small NFC commit that moves DarwinSDKInfo over to 
lib/Basic from lib/Driver, which isn't up on phabricator.


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

https://reviews.llvm.org/D105958

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

[PATCH] D105257: [clang][darwin] add support for remapping macOS availability to Mac Catalyst availability

[Alex Lorenz via Phabricator via cfe-commits]

arphaman added a comment.

In D105257#2853438 , @dexonsmith 
wrote:

> Could the DarwinSDKInfo changes be tested directly with C++ unit tests? Since 
> this stuff is in Basic it'd be nice to test it separately from the driver. If 
> so, maybe they could also mostly land in a separate prep commit (except the 
> update to `clang::parseDarwinSDKInfo` which is what changes the Driver 
> behaviour).

I split the patch to also https://reviews.llvm.org/D105958 like you suggested.


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

https://reviews.llvm.org/D105257

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

[PATCH] D105257: [clang][darwin] add support for remapping macOS availability to Mac Catalyst availability

[Alex Lorenz via Phabricator via cfe-commits]

arphaman added inline comments.



Comment at: clang/include/clang/Basic/DarwinSDKInfo.h:129
+  static Optional
+  parseDarwinSDKSettingsJSON(StringRef FilePath, const llvm::json::Object 
*Obj);
+

dexonsmith wrote:
> Should this take the VFS?
No, the Filepath is not actually used here. I removed it.



Comment at: clang/lib/Basic/DarwinSDKInfo.cpp:28
+  // If no exact entry found, try just the major key version.
+  if (Key.getMinor())
+return map(VersionTuple(Key.getMajor()), MinimumValue, MaximumValue);

aaron.ballman wrote:
> Why are you looking for a minor key here?
To avoid recursing infinitely in the next iteration, when minor is 0.



Comment at: clang/lib/Sema/Sema.cpp:72-75
+// Ignore the error and pretend the SDK info
+// is missing.
+// FIXME: should we care about missing SDK info
+// for some darwin targets?

aaron.ballman wrote:
> Does this scenario happen often (like, is warning the user about this 
> situation a bad idea without a default-off warning flag)?
It shouldn't ever happen unless the SDKs are damaged. It would still probably 
be good to warn about it, so I added an extra warning.



Comment at: clang/lib/Sema/SemaDeclAttr.cpp:2565-2567
 if (II->getName() == "ios")
   NewII = &S.Context.Idents.get("maccatalyst");
 else if (II->getName() == "ios_app_extension")

aaron.ballman wrote:
> This matches the surrounding code, but at some point, we may want to switch 
> these to `isStr()` calls instead -- slightly more declarative as to what's 
> going on.
I can do this in a followup NFC patch.


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

https://reviews.llvm.org/D105257

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

[PATCH] D105257: [clang][darwin] add support for remapping macOS availability to Mac Catalyst availability

[Alex Lorenz via Phabricator via cfe-commits]

arphaman updated this revision to Diff 358511.
arphaman marked 11 inline comments as done.
arphaman added a comment.

Split patch and address review comments


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

https://reviews.llvm.org/D105257

Files:
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Sema/Sema.h
  clang/lib/Basic/DarwinSDKInfo.cpp
  clang/lib/Sema/Sema.cpp
  clang/lib/Sema/SemaDeclAttr.cpp
  clang/test/Driver/Inputs/MacOSX10.14.sdk/SDKSettings.json
  clang/test/Driver/Inputs/WatchOS6.0.sdk/SDKSettings.json
  clang/test/Driver/Inputs/iPhoneOS13.0.sdk/SDKSettings.json
  clang/test/Sema/Inputs/MacOSX11.0.sdk/SDKSettings.json
  clang/test/Sema/attr-availability-iosmac-infer-from-macos-no-sdk-settings.c
  clang/test/Sema/attr-availability-iosmac-infer-from-macos.c
  clang/test/Sema/attr-availability-maccatalyst.c

Index: clang/test/Sema/attr-availability-maccatalyst.c
===
--- clang/test/Sema/attr-availability-maccatalyst.c
+++ clang/test/Sema/attr-availability-maccatalyst.c
@@ -12,8 +12,8 @@
 void f0(int) __attribute__((availability(maccatalyst,introduced=2.0,deprecated=9.1))); // expected-note {{'f0' has been explicitly marked deprecated here}}
 void f1(int) __attribute__((availability(maccatalyst,introduced=2.1)));
 void f2(int) __attribute__((availability(macCatalyst,introduced=2.0,deprecated=9.0))); // expected-note {{'f2' has been explicitly marked deprecated here}}
-void f3(int) __attribute__((availability(macosx,introduced=10.1),  availability(maccatalyst,introduced=3.0, obsoleted=9.0))); // expected-note {{'f3' has been explicitly marked unavailable here}}
-void f32(int) __attribute__((availability(macosx,introduced=10.1,deprecated=10.3,obsoleted=10.5),  availability(maccatalyst,introduced=3.0, obsoleted=9.0))); // expected-note {{'f32' has been explicitly marked unavailable here}}
+void f3(int) __attribute__((availability(maccatalyst,introduced=3.0, obsoleted=9.0))); // expected-note {{'f3' has been explicitly marked unavailable here}}
+void f32(int) __attribute__((availability(maccatalyst,introduced=3.0, obsoleted=9.0))); // expected-note {{'f32' has been explicitly marked unavailable here}}
 
 
 void f5(int) __attribute__((availability(maccatalyst,introduced=2.0))) __attribute__((availability(maccatalyst,deprecated=9.0))); // expected-note {{'f5' has been explicitly marked deprecated here}}
Index: clang/test/Sema/attr-availability-iosmac-infer-from-macos.c
===
--- /dev/null
+++ clang/test/Sema/attr-availability-iosmac-infer-from-macos.c
@@ -0,0 +1,58 @@
+// RUN: %clang_cc1 "-triple" "x86_64-apple-ios13.1-macabi" -isysroot %S/Inputs/MacOSX11.0.sdk -fsyntax-only -verify %s
+// RUN: %clang_cc1 "-triple" "x86_64-apple-ios14-macabi" -isysroot %S/Inputs/MacOSX11.0.sdk -DIOS14 -fsyntax-only -verify %s
+
+void f0(void) __attribute__((availability(macOS, introduced = 10.11)));
+void f1(void) __attribute__((availability(macOS, introduced = 10.15)));
+void f2(void) __attribute__(( // expected-note {{'f2' has been explicitly marked deprecated here}}
+availability(macOS, introduced = 10.11,
+ deprecated = 10.12)));
+void f3(void)
+__attribute__((availability(macOS, introduced = 10.11, deprecated = 10.14)))
+__attribute__((availability(iOS, introduced = 11.0)));
+
+void f4(void)
+__attribute__((availability(macOS, introduced = 10, deprecated = 10)));
+
+void fAvail() __attribute__((availability(macOS, unavailable)));
+
+void f16() __attribute__((availability(macOS, introduced = 11.0)));
+#ifndef IOS14
+// expected-note@-2 {{here}}
+#endif
+
+void fObs() __attribute__((availability(macOS, introduced = 10.11, obsoleted = 10.15))); // expected-note {{'fObs' has been explicitly marked unavailable here}}
+
+void fAPItoDepr() __attribute__((availability(macOS, introduced = 10.11, deprecated = 10)));
+
+void dontRemapFutureVers() __attribute__((availability(macOS, introduced = 20)));
+
+void usage() {
+  f0();
+  f1();
+  f2(); // expected-warning {{'f2' is deprecated: first deprecated in macCatalyst 13.1}}
+  f3();
+  f4();
+  fAvail();
+  f16();
+#ifndef IOS14
+  // expected-warning@-2 {{'f16' is only available on macCatalyst 14.0 or newer}} expected-note@-2 {{enclose}}
+#endif
+  fObs(); // expected-error {{'fObs' is unavailable: obsoleted in macCatalyst 13.1}}
+  fAPItoDepr();
+  dontRemapFutureVers();
+}
+
+#ifdef IOS14
+
+void f15_4(void) __attribute__((availability(macOS, introduced = 10.15, deprecated = 10.15.4))); // expected-note {{here}}
+void f15_3(void) __attribute__((availability(macOS, introduced = 10.15, deprecated = 10.15.3))); // expected-note {{here}}
+void f15_2(void) __attribute__((availability(macOS, introduced = 10.15, deprecated = 10.15.2))); // expected-note {{here}}
+
+void usage16() {
+  f15_2(); // expected-warning {{'f15_2' is deprecated: first deprecated in macCatalyst 13.3}}

[PATCH] D105958: [clang][darwin] add support for version remapping to the Darwin SDK Info class

[Alex Lorenz via Phabricator via cfe-commits]

arphaman updated this revision to Diff 358510.
arphaman added a comment.

fix typo


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

https://reviews.llvm.org/D105958

Files:
  clang/include/clang/Basic/DarwinSDKInfo.h
  clang/lib/Basic/DarwinSDKInfo.cpp
  clang/lib/Driver/ToolChains/Darwin.cpp
  clang/unittests/Basic/CMakeLists.txt
  clang/unittests/Basic/DarwinSDKinfoTest.cpp
  llvm/include/llvm/Support/VersionTuple.h

Index: llvm/include/llvm/Support/VersionTuple.h
===
--- llvm/include/llvm/Support/VersionTuple.h
+++ llvm/include/llvm/Support/VersionTuple.h
@@ -14,6 +14,7 @@
 #ifndef LLVM_SUPPORT_VERSIONTUPLE_H
 #define LLVM_SUPPORT_VERSIONTUPLE_H
 
+#include "llvm/ADT/DenseMapInfo.h"
 #include "llvm/ADT/Hashing.h"
 #include "llvm/ADT/Optional.h"
 #include 
@@ -95,6 +96,20 @@
 return *this;
   }
 
+  /// Return a version tuple that contains only components that are non-zero.
+  VersionTuple normalize() const {
+VersionTuple Result = *this;
+if (Result.Build == 0) {
+  Result.HasBuild = false;
+  if (Result.Subminor == 0) {
+Result.HasSubminor = false;
+if (Result.Minor == 0)
+  Result.HasMinor = false;
+  }
+}
+return Result;
+  }
+
   /// Determine if two version numbers are equivalent. If not
   /// provided, minor and subminor version numbers are considered to be zero.
   friend bool operator==(const VersionTuple &X, const VersionTuple &Y) {
@@ -161,5 +176,28 @@
 /// Print a version number.
 raw_ostream &operator<<(raw_ostream &Out, const VersionTuple &V);
 
+// Provide DenseMapInfo for version tuples.
+template <> struct DenseMapInfo {
+  static inline VersionTuple getEmptyKey() { return VersionTuple(0x7FFF); }
+  static inline VersionTuple getTombstoneKey() {
+return VersionTuple(0x7FFE);
+  }
+  static unsigned getHashValue(const VersionTuple &Value) {
+unsigned Result = Value.getMajor();
+if (auto Minor = Value.getMinor())
+  Result = detail::combineHashValue(Result, *Minor);
+if (auto Subminor = Value.getSubminor())
+  Result = detail::combineHashValue(Result, *Subminor);
+if (auto Build = Value.getBuild())
+  Result = detail::combineHashValue(Result, *Build);
+
+return Result;
+  }
+
+  static bool isEqual(const VersionTuple &LHS, const VersionTuple &RHS) {
+return LHS == RHS;
+  }
+};
+
 } // end namespace llvm
 #endif // LLVM_SUPPORT_VERSIONTUPLE_H
Index: clang/unittests/Basic/DarwinSDKinfoTest.cpp
===
--- /dev/null
+++ clang/unittests/Basic/DarwinSDKinfoTest.cpp
@@ -0,0 +1,57 @@
+//===- unittests/Basic/DarwinSDKInfoTest.cpp -- SDKSettings.json test -===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include "clang/Basic/DarwinSDKInfo.h"
+#include "llvm/Support/JSON.h"
+#include "gtest/gtest.h"
+
+using namespace llvm;
+using namespace clang;
+
+TEST(DarwinSDKInfoTest, ParseAndTestMapping) {
+  llvm::json::Object Obj;
+  Obj["Version"] = "11.0";
+  Obj["MaximumDeploymentTarget"] = "11.99";
+  llvm::json::Object VersionMap;
+  VersionMap["10.15"] = "13.1";
+  VersionMap["11.0"] = "14.0";
+  VersionMap["11.2"] = "14.2";
+  llvm::json::Object MacOS2iOSMac;
+  MacOS2iOSMac["macOS_iOSMac"] = std::move(VersionMap);
+  Obj["VersionMap"] = std::move(MacOS2iOSMac);
+
+  auto SDKInfo = DarwinSDKInfo::parseDarwinSDKSettingsJSON(&Obj);
+  ASSERT_TRUE(SDKInfo);
+  EXPECT_EQ(SDKInfo->getVersion(), VersionTuple(11, 0));
+
+  auto Mapping = SDKInfo->getVersionMapping(
+  DarwinSDKInfo::OSEnvPair::macOStoMacCatalystPair());
+  ASSERT_TRUE(Mapping);
+  EXPECT_EQ(*Mapping->map(VersionTuple(10, 15), VersionTuple(), None),
+VersionTuple(13, 1));
+  EXPECT_EQ(*Mapping->map(VersionTuple(11, 0), VersionTuple(), None),
+VersionTuple(14, 0));
+  EXPECT_EQ(*Mapping->map(VersionTuple(11, 2), VersionTuple(), None),
+VersionTuple(14, 2));
+
+  EXPECT_EQ(*Mapping->map(VersionTuple(11, 1), VersionTuple(), None),
+VersionTuple(14, 0));
+
+  EXPECT_EQ(*Mapping->map(VersionTuple(10, 14), VersionTuple(99, 99), None),
+VersionTuple(99, 99));
+  EXPECT_EQ(
+  *Mapping->map(VersionTuple(11, 5), VersionTuple(), VersionTuple(99, 99)),
+  VersionTuple(99, 99));
+}
+
+TEST(DarwinSDKInfoTest, MissingKeys) {
+  llvm::json::Object Obj;
+  ASSERT_FALSE(DarwinSDKInfo::parseDarwinSDKSettingsJSON(&Obj));
+  Obj["Version"] = "11.0";
+  ASSERT_FALSE(DarwinSDKInfo::parseDarwinSDKSettingsJSON(&Obj));
+}
Index: clang/unittests/Basic/CMakeLists.txt
===
--- clang/unittests/Basic/CMakeLists.txt
+++ clang/unittests/Basi

[PATCH] D105958: [clang][darwin] add support for version remapping to the Darwin SDK Info class

[Alex Lorenz via Phabricator via cfe-commits]

arphaman created this revision.
arphaman added reviewers: dexonsmith, Bigcheese.
Herald added subscribers: ributzka, mgorny.
arphaman requested review of this revision.
Herald added projects: clang, LLVM.
Herald added a subscriber: llvm-commits.

This patch is a pre-commit for https://reviews.llvm.org/D105257. It adds 
support for the macOS -> Mac Catalyst version mapping to the Darwin SDK Info 
class, alongside appropriate unit tests.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D105958

Files:
  clang/include/clang/Basic/DarwinSDKInfo.h
  clang/lib/Basic/DarwinSDKInfo.cpp
  clang/lib/Driver/ToolChains/Darwin.cpp
  clang/unittests/Basic/CMakeLists.txt
  clang/unittests/Basic/DarwinSDKinfoTest.cpp
  llvm/include/llvm/Support/VersionTuple.h

Index: llvm/include/llvm/Support/VersionTuple.h
===
--- llvm/include/llvm/Support/VersionTuple.h
+++ llvm/include/llvm/Support/VersionTuple.h
@@ -14,6 +14,7 @@
 #ifndef LLVM_SUPPORT_VERSIONTUPLE_H
 #define LLVM_SUPPORT_VERSIONTUPLE_H
 
+#include "llvm/ADT/DenseMapInfo.h"
 #include "llvm/ADT/Hashing.h"
 #include "llvm/ADT/Optional.h"
 #include 
@@ -95,6 +96,20 @@
 return *this;
   }
 
+  /// Return a version tuple that contains only components that are non-zero.
+  VersionTuple normalize() const {
+VersionTuple Result = *this;
+if (Result.Build == 0) {
+  Result.HasBuild = false;
+  if (Result.Subminor == 0) {
+Result.HasSubminor = false;
+if (Result.Minor == 0)
+  Result.HasMinor = false;
+  }
+}
+return Result;
+  }
+
   /// Determine if two version numbers are equivalent. If not
   /// provided, minor and subminor version numbers are considered to be zero.
   friend bool operator==(const VersionTuple &X, const VersionTuple &Y) {
@@ -161,5 +176,28 @@
 /// Print a version number.
 raw_ostream &operator<<(raw_ostream &Out, const VersionTuple &V);
 
+// Provide DenseMapInfo for version tuples.
+template <> struct DenseMapInfo {
+  static inline VersionTuple getEmptyKey() { return VersionTuple(0x7FFF); }
+  static inline VersionTuple getTombstoneKey() {
+return VersionTuple(0x7FFE);
+  }
+  static unsigned getHashValue(const VersionTuple &Value) {
+unsigned Result = Value.getMajor();
+if (auto Minor = Value.getMinor())
+  Result = detail::combineHashValue(Result, *Minor);
+if (auto Subminor = Value.getSubminor())
+  Result = detail::combineHashValue(Result, *Subminor);
+if (auto Build = Value.getBuild())
+  Result = detail::combineHashValue(Result, *Build);
+
+return Result;
+  }
+
+  static bool isEqual(const VersionTuple &LHS, const VersionTuple &RHS) {
+return LHS == RHS;
+  }
+};
+
 } // end namespace llvm
 #endif // LLVM_SUPPORT_VERSIONTUPLE_H
Index: clang/unittests/Basic/DarwinSDKinfoTest.cpp
===
--- /dev/null
+++ clang/unittests/Basic/DarwinSDKinfoTest.cpp
@@ -0,0 +1,57 @@
+//===- unittests/Basic/DarwinSDKInfoTest.cpp -- SDKSettings.json test -===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include "clang/Basic/DarwinSDKInfo.h"
+#include "llvm/Support/JSON.h"
+#include "gtest/gtest.h"
+
+using namespace llvm;
+using namespace clang;
+
+TEST(DarwinSDKInfoTest, ParseAndTestMapping) {
+  llvm::json::Object Obj;
+  Obj["Version"] = "11.0";
+  Obj["MaximumDeploymentTarget"] = "11.99";
+  llvm::json::Object VersionMap;
+  VersionMap["10.15"] = "13.1";
+  VersionMap["11.0"] = "14.0";
+  VersionMap["11.2"] = "14.2";
+  llvm::json::Object MacOS2iOSMac;
+  MacOS2iOSMac["macOS_iOSMac"] = std::move(VersionMap);
+  Obj["VersionMap"] = std::move(MacOS2iOSMac);
+
+  auto SDKInfo = DarwinSDKInfo::parseDarwinSDKSettingsJSON(&Obj);
+  ASSERT_TRUE(SDKInfo);
+  EXPECT_EQ(SDKInfo->getVersion(), VersionTuple(11, 0));
+
+  auto Mapping = SDKInfo->getVersionMapping(
+  DarwinSDKInfo::OSEnvPair::macOStoMacCatalystPair());
+  ASSERT_TRUE(Mapping);
+  EXPECT_EQ(*Mapping->map(VersionTuple(10, 15), VersionTuple(), None),
+VersionTuple(13, 1));
+  EXPECT_EQ(*Mapping->map(VersionTuple(11, 0), VersionTuple(), None),
+VersionTuple(14, 0));
+  EXPECT_EQ(*Mapping->map(VersionTuple(11, 2), VersionTuple(), None),
+VersionTuple(14, 2));
+
+  EXPECT_EQ(*Mapping->map(VersionTuple(11, 1), VersionTuple(), None),
+VersionTuple(14, 0));
+
+  EXPECT_EQ(*Mapping->map(VersionTuple(10, 14), VersionTuple(99, 99), None),
+VersionTuple(99, 99));
+  EXPECT_EQ(
+  *Mapping->map(VersionTuple(11, 5), VersionTuple(), VersionTuple(99, 99)),
+  VersionTuple(99, 99));
+}
+
+TEST(DarwinSDKInfoTest, MissingKeys) {
+  llvm::json::Object Obj;
+  ASSERT_F

[PATCH] D105637: [clang][Analyzer] Add symbol uninterestingness to bug report.

[Artem Dergachev via Phabricator via cfe-commits]

NoQ added inline comments.



Comment at: clang/lib/StaticAnalyzer/Core/BugReporter.cpp:2260-2261
+  InterestingSymbols.erase(sym);
+  if (const auto *meta = dyn_cast(sym))
+markNotInteresting(meta->getRegion());
+}

balazske wrote:
> balazske wrote:
> > NoQ wrote:
> > > You're saying, e.g., "If string length is not interesting then neither is 
> > > the string itself". Or, dunno, "If the raw pointer value is not 
> > > interesting then neither is a smart pointer that was holding it".
> > > 
> > > I'm not sure about that. I'm pretty sure that no checkers are currently 
> > > affected by this code but I still don't understand your point.
> > > 
> > > I don't understand the original code in `markInteresting()` either; do we 
> > > have even one test to cover it?
> > > 
> > > Also note that what you've written is not a correct negation of the 
> > > original code. The correct negation (that would keep the region-metadata 
> > > relationship in sync as originally intended) would be "if the region 
> > > loses interestingness, so does the metadata". Or it has to go both ways. 
> > > I'm still not sure if any of this matters though.
> > > 
> > > Maybe we should eliminate these extra clauses entirely. If you're not 
> > > willing to investigate whether this is all dead code or it actually does 
> > > something, I'd like to suggest a "FIXME: Is this necessary?" (or 
> > > something like that) both here and in the original code.
> > The metadata interestingness was added in rG735724fb1e78 long ago, there is 
> > not more information. All test pass if the code is removed (but it may have 
> > impacts on bug paths). Is it not the job of the checker to mark the 
> > interestingness of objects? I assume that the meaning of 
> > `meta->getRegion()` is checker dependent (the string or smart pointer or 
> > something totally different?) and the checker should know what to make 
> > interesting (or not). The `markInteresting()` has no test (what I could 
> > extend here), it may be implicitly tested by the other checker tests.
> The mark of associated region as interesting may not work correct if there 
> are multiple metadata symbols for the same region, which should be a possible 
> case. Specially the remove of interestingness is not correct in this way. So 
> I would remove the `if (const auto *meta = dyn_cast(sym))` 
> part.
> A better approach can be to make the interestingness depend totally on the 
> associated region for metadata symbol. If a symbol is metadata, its 
> interestingness is that of the region. And only the region is inserted into 
> the map. `isInteresting` can be updated for this purpose.
> I assume that the meaning of `meta->getRegion()` is checker dependent

I completely agree with your reasoning. One way or another, that old commit 
didn't come with a test, or any explanation whatsoever. I think we have all the 
rights to question it.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105637

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

[PATCH] D105939: [OpenMP] Add IDs to OpenMP remarks

[Johannes Doerfert via Phabricator via cfe-commits]

jdoerfert accepted this revision.
jdoerfert added a comment.
This revision is now accepted and ready to land.

LG


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105939

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

[PATCH] D105909: [clang][CallGraphSection] Add type id metadata to indirect call and targets

[Necip Fazil Yildiran via Phabricator via cfe-commits]

necipfazil updated this revision to Diff 358505.
necipfazil added a comment.

Several review comments are addressed

- Don't emit type metadata for Objective-C
- Don't emit metadata for function definitions, which leads to duplicates
- Improve the test case
  - Add C struct parameter test
  - Fix variable capturing
  - Make function and callsite metadata checking distinct
  - Some formatting

TODO: a C++ test will be added with class functions, templates, etc.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105909

Files:
  clang/lib/CodeGen/CGClass.cpp
  clang/lib/CodeGen/CGExpr.cpp
  clang/lib/CodeGen/CGExprCXX.cpp
  clang/lib/CodeGen/CodeGenModule.cpp
  clang/lib/CodeGen/CodeGenModule.h
  clang/test/CodeGen/call-graph-section.c

Index: clang/test/CodeGen/call-graph-section.c
===
--- /dev/null
+++ clang/test/CodeGen/call-graph-section.c
@@ -0,0 +1,75 @@
+// Tests that we assign appropriate identifiers to indirect calls and targets.
+
+// RUN: %clang_cc1 -triple x86_64-unknown-linux -fcall-graph-section -S \
+// RUN: -emit-llvm -o - %s | FileCheck --check-prefixes=CHECK,ITANIUM %s
+
+// RUN: %clang_cc1 -triple x86_64-pc-windows-msvc -fcall-graph-section -S \
+// RUN: -emit-llvm -o - %s | FileCheck --check-prefixes=CHECK,MS %s
+
+// CHECK-DAG: define {{(dso_local)?}} void @foo({{.*}} !type [[F_TVOID:![0-9]+]]
+void foo() {
+}
+
+// CHECK-DAG: define {{(dso_local)?}} void @bar({{.*}} !type [[F_TVOID]]
+void bar() {
+  void (*fp)() = foo;
+  // CHECK: call {{.*}} !type [[CS_TVOID:![0-9]+]]
+  fp();
+}
+
+// CHECK-DAG: define {{(dso_local)?}} i32 @baz({{.*}} !type [[F_TPRIMITIVE:![0-9]+]]
+int baz(char a, float b, double c) {
+  return 1;
+}
+
+// CHECK-DAG: define {{(dso_local)?}} i32* @qux({{.*}} !type [[F_TPTR:![0-9]+]]
+int *qux(char *a, float *b, double *c) {
+  return 0;
+}
+
+// CHECK-DAG: define {{(dso_local)?}} void @corge({{.*}} !type [[F_TVOID]]
+void corge() {
+  int (*fp_baz)(char, float, double) = baz;
+  // CHECK: call i32 {{.*}}, !type [[CS_TPRIMITIVE:![0-9]+]]
+  fp_baz('a', .0f, .0);
+
+  int *(*fp_qux)(char *, float *, double *) = qux;
+  // CHECK: call i32* {{.*}}, !type [[CS_TPTR:![0-9]+]]
+  fp_qux(0, 0, 0);
+}
+
+struct st1 {
+  int *(*fp)(char *, float *, double *);
+};
+
+struct st2 {
+  struct st1 m;
+};
+
+// CHECK-DAG: define {{(dso_local)?}} void @stf({{.*}} !type [[F_TVOID]]
+void stf() {
+  struct st1 St1;
+  St1.fp = qux;
+  // CHECK: call i32* {{.*}}, !type [[CS_TPTR]]
+  St1.fp(0, 0, 0);
+
+  struct st2 St2;
+  St2.m.fp = qux;
+  // CHECK: call i32* {{.*}}, !type [[CS_TPTR]]
+  St2.m.fp(0, 0, 0);
+}
+
+// ITANIUM-DAG: [[F_TVOID]] = !{i64 0, !"_ZTSFvE.generalized"}
+// ITANIUM-DAG: [[CS_TVOID]] = !{!"_ZTSFvE.generalized"}
+// MS-DAG: [[F_TVOID]] = !{i64 0, !"?6AX@Z.generalized"}
+// MS-DAG: [[CS_TVOID]] = !{!"?6AX@Z.generalized"}
+
+// ITANIUM-DAG: [[F_TPRIMITIVE]] = !{i64 0, !"_ZTSFicfdE.generalized"}
+// ITANIUM-DAG: [[CS_TPRIMITIVE]] = !{!"_ZTSFicfdE.generalized"}
+// MS-DAG: [[F_TPRIMITIVE]] = !{i64 0, !"?6AHDMN@Z.generalized"}
+// MS-DAG: [[CS_TPRIMITIVE]] = !{!"?6AHDMN@Z.generalized"}
+
+// ITANIUM-DAG: [[F_TPTR]] = !{i64 0, !"_ZTSFPvS_S_S_E.generalized"}
+// ITANIUM-DAG: [[CS_TPTR]] = !{!"_ZTSFPvS_S_S_E.generalized"}
+// MS-DAG: [[F_TPTR]] = !{i64 0, !"?6APEAXPEAX00@Z.generalized"}
+// MS-DAG: [[CS_TPTR]] = !{!"?6APEAXPEAX00@Z.generalized"}
Index: clang/lib/CodeGen/CodeGenModule.h
===
--- clang/lib/CodeGen/CodeGenModule.h
+++ clang/lib/CodeGen/CodeGenModule.h
@@ -1406,6 +1406,10 @@
   void CreateFunctionTypeMetadataForIcall(const FunctionDecl *FD,
   llvm::Function *F);
 
+  /// Create and attach type metadata to the given call.
+  void CreateFunctionTypeMetadataForIcall(const QualType &QT,
+  llvm::CallBase *CB);
+
   /// Whether this function's return type has no side effects, and thus may
   /// be trivially discarded if it is unused.
   bool MayDropFunctionReturn(const ASTContext &Context, QualType ReturnType);
Index: clang/lib/CodeGen/CodeGenModule.cpp
===
--- clang/lib/CodeGen/CodeGenModule.cpp
+++ clang/lib/CodeGen/CodeGenModule.cpp
@@ -2057,7 +2057,17 @@
 
 void CodeGenModule::CreateFunctionTypeMetadataForIcall(const FunctionDecl *FD,
llvm::Function *F) {
-  // Only if we are checking indirect calls.
+  bool EmittedMDIdGeneralized = false;
+  if (CodeGenOpts.CallGraphSection &&
+  (!F->hasLocalLinkage() ||
+   F->getFunction().hasAddressTaken(nullptr, /* IgnoreCallbackUses */ true,
+/* IgnoreAssumeLikeCalls */ true,
+/* IgnoreLLVMUsed */ false))) {
+F->addTypeMetada

[PATCH] D105909: [clang][CallGraphSection] Add type id metadata to indirect call and targets

[Necip Fazil Yildiran via Phabricator via cfe-commits]

necipfazil added inline comments.



Comment at: clang/lib/CodeGen/CGObjCMac.cpp:2288
+}
+  }
 

morehouse wrote:
> This is for Objective C?  I don't think we care about Objective C.
I will remove this.



Comment at: clang/lib/CodeGen/CodeGenModule.cpp:1878
+   CodeGenOpts.SanitizeCfiCanonicalJumpTables) ||
+  CodeGenOpts.CallGraphSection) {
 if (auto *FD = dyn_cast(D)) {

morehouse wrote:
> Why do we need the type metadata on function definitions?
Actually, we don’t.  It seems like having this may lead to duplicate metadata 
as well.

I will remove this.



Comment at: clang/test/CodeGen/call-graph-section.c:39
+  fp_qux(0, 0, 0);
+}
+

morehouse wrote:
> Should we also add a test with a C struct parameter?
I will add one.



Comment at: clang/test/CodeGen/call-graph-section.c:41
+
+// ITANIUM-DAG: [[TVOID_GENERALIZED]] = !{{{.*}}!"_ZTSFvE.generalized"}
+// ITANIUM-DAG: [[TPRIMITIVE_GENERALIZED]] = !{{{.*}}!"_ZTSFicfdE.generalized"}

morehouse wrote:
> What is the `{{.*}}` consuming here?
Internally, for functions, this metadata is added using 
`llvm::GlobalObject::addTypeMetadata()`, which takes an offset parameter. This 
is always 0 for our case. `{{.*}}` is consuming `i64 0,` if the metadata 
belongs to a function. Otherwise, for callsites, it consumes nothing.

I will make the distinction in the test case.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105909

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

[PATCH] D105937: [OpenMP] Encode `omp [...] assume[...]` assumptions with `omp[x]` prefix

[Johannes Doerfert via Phabricator via cfe-commits]

jdoerfert updated this revision to Diff 358502.
jdoerfert added a comment.

Fix lifetime problem, update one more test


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105937

Files:
  clang/include/clang/Sema/Sema.h
  clang/lib/Parse/ParseOpenMP.cpp
  clang/lib/Sema/SemaOpenMP.cpp
  clang/test/OpenMP/assumes_codegen.cpp
  clang/test/OpenMP/assumes_include_nvptx.cpp
  clang/test/OpenMP/assumes_print.cpp
  clang/test/OpenMP/assumes_template_print.cpp

Index: clang/test/OpenMP/assumes_template_print.cpp
===
--- clang/test/OpenMP/assumes_template_print.cpp
+++ clang/test/OpenMP/assumes_template_print.cpp
@@ -17,7 +17,7 @@
 struct S {
   int a;
 // CHECK: template  struct S {
-// CHECK: void foo() __attribute__((assume("global_assumption"))) {
+// CHECK: void foo() __attribute__((assume("ompx_global_assumption"))) {
   void foo() {
 #pragma omp parallel
 {}
@@ -25,15 +25,15 @@
 };
 
 // CHECK: template<> struct S {
-// CHECK: void foo() __attribute__((assume("global_assumption"))) {
+// CHECK: void foo() __attribute__((assume("ompx_global_assumption"))) {
 
 #pragma omp begin assumes no_openmp
-// CHECK: void S_with_assumes_no_call() __attribute__((assume("no_openmp"))) __attribute__((assume("global_assumption"))) {
+// CHECK: void S_with_assumes_no_call() __attribute__((assume("omp_no_openmp"))) __attribute__((assume("ompx_global_assumption"))) {
 void S_with_assumes_no_call() {
   S s;
   s.a = 0;
 }
-// CHECK: void S_with_assumes_call() __attribute__((assume("no_openmp"))) __attribute__((assume("global_assumption"))) {
+// CHECK: void S_with_assumes_call() __attribute__((assume("omp_no_openmp"))) __attribute__((assume("ompx_global_assumption"))) {
 void S_with_assumes_call() {
   S s;
   s.a = 0;
@@ -42,7 +42,7 @@
 }
 #pragma omp end assumes
 
-// CHECK: void S_without_assumes() __attribute__((assume("global_assumption"))) {
+// CHECK: void S_without_assumes() __attribute__((assume("ompx_global_assumption"))) {
 void S_without_assumes() {
   S s;
   s.foo();
@@ -54,7 +54,7 @@
 template 
 struct P {
 // CHECK: template  struct P {
-// CHECK: void foo() __attribute__((assume("global_assumption"))) {
+// CHECK: void foo() __attribute__((assume("ompx_global_assumption"))) {
   int a;
   void foo() {
 #pragma omp parallel
@@ -65,21 +65,21 @@
 // TODO: Avoid the duplication here:
 
 // CHECK: template<> struct P {
-// CHECK: void foo() __attribute__((assume("global_assumption"))) __attribute__((assume("global_assumption"))) {
+// CHECK: void foo() __attribute__((assume("ompx_global_assumption"))) __attribute__((assume("ompx_global_assumption"))) {
 
-// CHECK: void P_without_assumes() __attribute__((assume("global_assumption"))) {
+// CHECK: void P_without_assumes() __attribute__((assume("ompx_global_assumption"))) {
 void P_without_assumes() {
   P p;
   p.foo();
 }
 
 #pragma omp begin assumes no_openmp
-// CHECK: void P_with_assumes_no_call() __attribute__((assume("no_openmp"))) __attribute__((assume("global_assumption"))) {
+// CHECK: void P_with_assumes_no_call() __attribute__((assume("omp_no_openmp"))) __attribute__((assume("ompx_global_assumption"))) {
 void P_with_assumes_no_call() {
   P p;
   p.a = 0;
 }
-// CHECK: void P_with_assumes_call() __attribute__((assume("no_openmp"))) __attribute__((assume("global_assumption"))) {
+// CHECK: void P_with_assumes_call() __attribute__((assume("omp_no_openmp"))) __attribute__((assume("ompx_global_assumption"))) {
 void P_with_assumes_call() {
   P p;
   p.a = 0;
Index: clang/test/OpenMP/assumes_print.cpp
===
--- clang/test/OpenMP/assumes_print.cpp
+++ clang/test/OpenMP/assumes_print.cpp
@@ -37,8 +37,8 @@
 }
 #pragma omp end assumes
 
-// CHECK: void foo() __attribute__((assume("no_openmp_routines"))) __attribute__((assume("no_openmp")))
-// CHECK: void bar() __attribute__((assume("range_bar_only"))) __attribute__((assume("range_bar_only_2"))) __attribute__((assume("no_openmp_routines"))) __attribute__((assume("no_openmp")))
-// CHECK: void baz() __attribute__((assume("1234"))) __attribute__((assume("no_openmp_routines"))) __attribute__((assume("no_openmp")))
+// CHECK: void foo() __attribute__((assume("omp_no_openmp_routines"))) __attribute__((assume("omp_no_openmp")))
+// CHECK: void bar() __attribute__((assume("ompx_range_bar_only"))) __attribute__((assume("ompx_range_bar_only_2"))) __attribute__((assume("omp_no_openmp_routines"))) __attribute__((assume("omp_no_openmp")))
+// CHECK: void baz() __attribute__((assume("ompx_1234"))) __attribute__((assume("omp_no_openmp_routines"))) __attribute__((assume("omp_no_openmp")))
 
 #endif
Index: clang/test/OpenMP/assumes_include_nvptx.cpp
===
--- clang/test/OpenMP/assumes_inc

[clang] 40ce58d - Revert "[clang] Refactor AST printing tests to share more infrastructure"

[David Green via cfe-commits]

Author: David Green
Date: 2021-07-14T04:40:47+01:00
New Revision: 40ce58d0ca10a1195da82895749b67f30f000243

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

LOG: Revert "[clang] Refactor AST printing tests to share more infrastructure"

This reverts commit 20176bc7dd3f431db4c3d59b51a9f53d52190c82 as some
versions of GCC do not seem to handle the new code very well. They
complain about:

/tmp/ccqUQZyw.s: Assembler messages:
/tmp/ccqUQZyw.s:1151: Error: symbol 
`_ZNSt14_Function_base13_Base_managerIN5clangUlPKNS1_4StmtEE2_EE10_M_managerERSt9_Any_dataRKS7_St18_Manager_operation'
 is already defined
/tmp/ccqUQZyw.s:11963: Error: symbol 
`_ZNSt17_Function_handlerIFbPKN5clang4StmtEENS0_UlS3_E2_EE9_M_invokeERKSt9_Any_dataOS3_'
 is already defined

This seems like it is some GCC issue, but multiple buildbots (and my
local machine) are all failing because of it.

Added: 


Modified: 
clang/unittests/AST/ASTPrint.h
clang/unittests/AST/DeclPrinterTest.cpp
clang/unittests/AST/NamedDeclPrinterTest.cpp
clang/unittests/AST/StmtPrinterTest.cpp

Removed: 




diff  --git a/clang/unittests/AST/ASTPrint.h b/clang/unittests/AST/ASTPrint.h
index 0e35846c86f47..c3b6b842316d9 100644
--- a/clang/unittests/AST/ASTPrint.h
+++ b/clang/unittests/AST/ASTPrint.h
@@ -19,88 +19,72 @@
 
 namespace clang {
 
-using PrintingPolicyAdjuster = llvm::function_ref;
-
-template 
-using NodePrinter =
-std::function;
-
-template 
-using NodeFilter = std::function;
+using PolicyAdjusterType =
+Optional>;
+
+static void PrintStmt(raw_ostream &Out, const ASTContext *Context,
+  const Stmt *S, PolicyAdjusterType PolicyAdjuster) {
+  assert(S != nullptr && "Expected non-null Stmt");
+  PrintingPolicy Policy = Context->getPrintingPolicy();
+  if (PolicyAdjuster)
+(*PolicyAdjuster)(Policy);
+  S->printPretty(Out, /*Helper*/ nullptr, Policy);
+}
 
-template 
 class PrintMatch : public ast_matchers::MatchFinder::MatchCallback {
-  using PrinterT = NodePrinter;
-  using FilterT = NodeFilter;
-
   SmallString<1024> Printed;
-  unsigned NumFoundNodes;
-  PrinterT Printer;
-  FilterT Filter;
-  PrintingPolicyAdjuster PolicyAdjuster;
+  unsigned NumFoundStmts;
+  PolicyAdjusterType PolicyAdjuster;
 
 public:
-  PrintMatch(PrinterT Printer, PrintingPolicyAdjuster PolicyAdjuster,
- FilterT Filter)
-  : NumFoundNodes(0), Printer(std::move(Printer)),
-Filter(std::move(Filter)), PolicyAdjuster(PolicyAdjuster) {}
+  PrintMatch(PolicyAdjusterType PolicyAdjuster)
+  : NumFoundStmts(0), PolicyAdjuster(PolicyAdjuster) {}
 
   void run(const ast_matchers::MatchFinder::MatchResult &Result) override {
-const NodeType *N = Result.Nodes.getNodeAs("id");
-if (!N || !Filter(N))
+const Stmt *S = Result.Nodes.getNodeAs("id");
+if (!S)
   return;
-NumFoundNodes++;
-if (NumFoundNodes > 1)
+NumFoundStmts++;
+if (NumFoundStmts > 1)
   return;
 
 llvm::raw_svector_ostream Out(Printed);
-Printer(Out, Result.Context, N, PolicyAdjuster);
+PrintStmt(Out, Result.Context, S, PolicyAdjuster);
   }
 
   StringRef getPrinted() const { return Printed; }
 
-  unsigned getNumFoundNodes() const { return NumFoundNodes; }
+  unsigned getNumFoundStmts() const { return NumFoundStmts; }
 };
 
-template 
-::testing::AssertionResult PrintedNodeMatches(
-StringRef Code, const std::vector &Args,
-const Matcher &NodeMatch, StringRef ExpectedPrinted, StringRef FileName,
-NodePrinter Printer,
-PrintingPolicyAdjuster PolicyAdjuster = nullptr, bool AllowError = false,
-NodeFilter Filter = [](const NodeType *) { return true; }) {
+template 
+::testing::AssertionResult
+PrintedStmtMatches(StringRef Code, const std::vector &Args,
+   const T &NodeMatch, StringRef ExpectedPrinted,
+   PolicyAdjusterType PolicyAdjuster = None) {
 
-  PrintMatch Callback(Printer, PolicyAdjuster, Filter);
+  PrintMatch Printer(PolicyAdjuster);
   ast_matchers::MatchFinder Finder;
-  Finder.addMatcher(NodeMatch, &Callback);
+  Finder.addMatcher(NodeMatch, &Printer);
   std::unique_ptr Factory(
   tooling::newFrontendActionFactory(&Finder));
 
-  bool ToolResult;
-  if (FileName.empty()) {
-ToolResult = tooling::runToolOnCodeWithArgs(Factory->create(), Code, Args);
-  } else {
-ToolResult =
-tooling::runToolOnCodeWithArgs(Factory->create(), Code, Args, 
FileName);
-  }
-  if (!ToolResult && !AllowError)
+  if (!tooling::runToolOnCodeWithArgs(Factory->create(), Code, Args))
 return testing::AssertionFailure()
<< "Parsing error in \"" << Code.str() << "\"";
 
-  if (Callback.getNumFoundNodes() == 0)
-return testing::AssertionFailure() << "Matcher didn't find any nodes";
+  if (Printer.getNumFoundStm

[PATCH] D105091: [RISCV] Pass -u to linker correctly.

[Kito Cheng via Phabricator via cfe-commits]

kito-cheng updated this revision to Diff 358494.
kito-cheng added a comment.

Changes:

- Update testcase again.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105091

Files:
  clang/lib/Driver/ToolChains/RISCVToolchain.cpp
  clang/test/Driver/riscv-args.c


Index: clang/test/Driver/riscv-args.c
===
--- clang/test/Driver/riscv-args.c
+++ clang/test/Driver/riscv-args.c
@@ -1,7 +1,6 @@
 // Check the arguments are correctly passed
 
 // Make sure -T is the last with gcc-toolchain option
-// RUN: %clang -### -target riscv32 \
-// RUN:   --gcc-toolchain= -Xlinker --defsym=FOO=10 -T a.lds %s 2>&1 \
+// RUN: %clang -### -target riscv32 --gcc-toolchain= -Xlinker --defsym=FOO=10 
-T a.lds -u foo %s 2>&1 \
 // RUN:   | FileCheck -check-prefix=CHECK-LD %s
-// CHECK-LD: {{.*}} "--defsym=FOO=10" {{.*}} "-T" "a.lds"
+// CHECK-LD: {{.*}} "--defsym=FOO=10" {{.*}} "-u" "foo" {{.*}} "-T" "a.lds"
Index: clang/lib/Driver/ToolChains/RISCVToolchain.cpp
===
--- clang/lib/Driver/ToolChains/RISCVToolchain.cpp
+++ clang/lib/Driver/ToolChains/RISCVToolchain.cpp
@@ -184,6 +184,7 @@
   AddLinkerInputs(ToolChain, Inputs, Args, CmdArgs, JA);
 
   Args.AddAllArgs(CmdArgs, options::OPT_L);
+  Args.AddAllArgs(CmdArgs, options::OPT_u);
   ToolChain.AddFilePathLibArgs(Args, CmdArgs);
   Args.AddAllArgs(CmdArgs,
   {options::OPT_T_Group, options::OPT_e, options::OPT_s,


Index: clang/test/Driver/riscv-args.c
===
--- clang/test/Driver/riscv-args.c
+++ clang/test/Driver/riscv-args.c
@@ -1,7 +1,6 @@
 // Check the arguments are correctly passed
 
 // Make sure -T is the last with gcc-toolchain option
-// RUN: %clang -### -target riscv32 \
-// RUN:   --gcc-toolchain= -Xlinker --defsym=FOO=10 -T a.lds %s 2>&1 \
+// RUN: %clang -### -target riscv32 --gcc-toolchain= -Xlinker --defsym=FOO=10 -T a.lds -u foo %s 2>&1 \
 // RUN:   | FileCheck -check-prefix=CHECK-LD %s
-// CHECK-LD: {{.*}} "--defsym=FOO=10" {{.*}} "-T" "a.lds"
+// CHECK-LD: {{.*}} "--defsym=FOO=10" {{.*}} "-u" "foo" {{.*}} "-T" "a.lds"
Index: clang/lib/Driver/ToolChains/RISCVToolchain.cpp
===
--- clang/lib/Driver/ToolChains/RISCVToolchain.cpp
+++ clang/lib/Driver/ToolChains/RISCVToolchain.cpp
@@ -184,6 +184,7 @@
   AddLinkerInputs(ToolChain, Inputs, Args, CmdArgs, JA);
 
   Args.AddAllArgs(CmdArgs, options::OPT_L);
+  Args.AddAllArgs(CmdArgs, options::OPT_u);
   ToolChain.AddFilePathLibArgs(Args, CmdArgs);
   Args.AddAllArgs(CmdArgs,
   {options::OPT_T_Group, options::OPT_e, options::OPT_s,
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D105926: [PowerPC] Extra test case for LDARX

[Nemanja Ivanovic via Phabricator via cfe-commits]

nemanjai added inline comments.



Comment at: clang/test/CodeGen/builtins-ppc-xlcompat-check-ldarx-opt.ll:149
+
+attributes #0 = { noinline nounwind optnone uwtable "frame-pointer"="all" 
"min-legal-vector-width"="0" "no-trapping-math"="true" 
"stack-protector-buffer-size"="8" "target-cpu"="ppc64le" 
"target-features"="+altivec,+bpermd,+crypto,+direct-move,+extdiv,+htm,+isa-v207-instructions,+power8-vector,+vsx,-isa-v30-instructions,-power9-vector,-privileged,-rop-protect,-spe"
 }
+attributes #1 = { nounwind writeonly }

Get rid of all the metadata please.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105926

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

[PATCH] D105926: [PowerPC] Extra test case for LDARX

[Nemanja Ivanovic via Phabricator via cfe-commits]

nemanjai requested changes to this revision.
nemanjai added inline comments.
This revision now requires changes to proceed.



Comment at: clang/test/CodeGen/builtins-ppc-xlcompat-check-ldarx-opt.ll:1
+; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
+; RUN: llc -verify-machineinstrs -mtriple=powerpc64le-unknown-linux-gnu \

Please pre-optimize this test case by running `opt -O3` on it (or produce it 
with `clang -O3 -S -emit-llvm`).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105926

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

[PATCH] D99487: [CodeGen] Port basic block sections from ELF to COFF

[TaoPan via Phabricator via cfe-commits]

TaoPan added inline comments.



Comment at: llvm/lib/CodeGen/TargetLoweringObjectFileImpl.cpp:1712
+  COFF::IMAGE_SCN_MEM_READ | COFF::IMAGE_SCN_LNK_COMDAT,
+  SectionKind::getText(), COMDATSymName,
+  COFF::IMAGE_COMDAT_SELECT_NODUPLICATES, UniqueID);

TaoPan wrote:
> TaoPan wrote:
> > mstorsjo wrote:
> > > rnk wrote:
> > > > mstorsjo wrote:
> > > > > TaoPan wrote:
> > > > > > rnk wrote:
> > > > > > > tmsriram wrote:
> > > > > > > > MaskRay wrote:
> > > > > > > > > TaoPan wrote:
> > > > > > > > > > tmsriram wrote:
> > > > > > > > > > > COMDATSymName can be folded to be equal to 
> > > > > > > > > > > MBB.getSymbol()->getName() here?  Plus, you are not 
> > > > > > > > > > > preserving the .text.hot prefix that the original 
> > > > > > > > > > > function might get here.  Is this future work?  If the 
> > > > > > > > > > > original function is named .text.hot.foo, the basic block 
> > > > > > > > > > > will still be named .text.foo.__part.1 which is not right.
> > > > > > > > > > > 
> > > > > > > > > > > Plus, what about exception handling sections like ".eh.*"?
> > > > > > > > > > Thanks! I'll redesign section name and comdat symbol name.
> > > > > > > > > > The text section with prefix "hot" and "unlikely" won't be 
> > > > > > > > > > constructed here, I added COFF text section prefix "hot" 
> > > > > > > > > > and "unlikely" in D92073. In ELF override function, also 
> > > > > > > > > > not handling text section with prefix "hot" and "unlikely".
> > > > > > > > > > The text section with prefix "split" will be constructed 
> > > > > > > > > > here, I plan to add related code in MFS COFF patch.
> > > > > > > > > > Also, exception handling section is future work that 
> > > > > > > > > > support basic block sections Windows COFF exception 
> > > > > > > > > > handling.
> > > > > > > > > This is complex. PE-COFF has multiple COMDAT seletion kinds. 
> > > > > > > > > I want to see a holistic plan how every component is going to 
> > > > > > > > > be implemented.
> > > > > > > > The basic block should just mimic the COMDAT type of its 
> > > > > > > > containing function, is there a reason to do anything more with 
> > > > > > > > it here?
> > > > > > > After thinking about it a bit, I think the entry block should use 
> > > > > > > the regular selection kind, and all of the auxilliary MBB 
> > > > > > > sections should use IMAGE_COMDAT_SELECT_ASSOCIATIVE. They should 
> > > > > > > be associated with the main function symbol, unless the function 
> > > > > > > itself is associated with something else, in which case the BBs 
> > > > > > > use that symbol.
> > > > > > > 
> > > > > > > This will ensure that if the main function section prevails, they 
> > > > > > > are included, and if it does not prevail, they are discarded. 
> > > > > > > Does that make sense?
> > > > > > Thanks! I think set entry block sections as regular 
> > > > > > IMAGE_COMDAT_SELECT_NODUPLICATES and set the auxilliary MBB 
> > > > > > sections as IMAGE_COMDAT_SELECT_ASSOCIATIVE is fine. I changed.
> > > > > @rnk - I'm not quite familiar with the concrete implications of this 
> > > > > work here, but would this need to be mapped to the GNU style comdats, 
> > > > > for compatibility with ld.bfd for mingw targets? (LLD itself works 
> > > > > fine with proper associative comdats though.)
> > > > I think basic block sections are kind of in the same category as LTO: 
> > > > it's a very sophisticated optimization feature, and it's probably OK if 
> > > > it's LLD-only. I think it also requires special linker support that 
> > > > might make it LLD-only, but I've forgotten the details.
> > > > 
> > > > It also has potentially very high object file size overhead, and it 
> > > > will be important to do everything possible to minimize that object 
> > > > file size overhead. Long gnu-style section names for every basic block 
> > > > section are likely to make the feature unusably slow, so maybe it's 
> > > > worth removing these "if mingw" conditionals. We can leave behind a 
> > > > comment by the use of IMAGE_COMDAT_SELECT_ASSOCIATIVE indicating that 
> > > > gnu-style section names are not needed because the feature is only 
> > > > designed to work with LLD.
> > > Thanks for the clarification! Leaving the feature as LLD-only (or in 
> > > other terms, requiring a conforming COMDAT implementation) sounds good to 
> > > me.
> > Thanks for discussion between @mstorsjo and @rnk !
> > I removed "if mingw" conditionals.
> @rnk about the issue 4.a of https://reviews.llvm.org/D99487#2821343, I tried 
> to use clang-cl.exe with bbs option and lld to build helloworld c program, 
> meet IMAGE_COMDAT_SELECT_XXX related problem.
> helloworld c program is general c demo program as below
> $ cat helloworld.c
> #include 
> 
> int main() {
>printf("hello world!\n");
>return 0;
> }
> $ clang-cl.exe helloworld.c -Xclang -fbasic-block-sections=all -Xclang 
> -funique-basic-block-section-names -fuse-l

[PATCH] D105957: [PowerPC] Implement intrinsics for mtfsf[i]

[Nemanja Ivanovic via Phabricator via cfe-commits]

nemanjai added inline comments.



Comment at: llvm/lib/Target/PowerPC/PPCInstrInfo.td:4484
+// as an implicit def for all of them.
+let Predicates = [HasFPU] in {
+let Defs = [RM] in {

@ZhangKang You modified this code most recently. Please provide your opinion 
here.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105957

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

[PATCH] D105930: [PowerPC] Implement XL compact math builtins

[Nemanja Ivanovic via Phabricator via cfe-commits]

nemanjai added a subscriber: ZhangKang.
nemanjai added inline comments.



Comment at: llvm/lib/Target/PowerPC/PPCInstrInfo.td:3087
 // RM should be set.
+let hasSideEffects = 1 in {
 def MTFSB0 : XForm_43<63, 70, (outs), (ins u5imm:$FM),

I think we should conservatively set RM as an implicit def here. @ZhangKang you 
modified this code most recently, please provide your opinion here.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105930

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

[PATCH] D105957: [PowerPC] Implement intrinsics for mtfsf[i]

[Nemanja Ivanovic via Phabricator via cfe-commits]

nemanjai created this revision.
nemanjai added reviewers: PowerPC, ZhangKang.
Herald added subscribers: shchenz, kbarton, hiraditya.
nemanjai requested review of this revision.
Herald added projects: clang, LLVM.
Herald added a subscriber: cfe-commits.

This provides intrinsics for emitting instructions that set the FPSCR 
(`mtfsf/mtfsfi`).

The patch also conservatively marks the rounding mode as an implicit def for 
both since they both may set the rounding mode depending on the operands.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D105957

Files:
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/test/CodeGen/builtins-ppc-xlcompat-math.c
  llvm/include/llvm/IR/IntrinsicsPowerPC.td
  llvm/lib/Target/PowerPC/P9InstrResources.td
  llvm/lib/Target/PowerPC/PPCInstrInfo.td
  llvm/test/CodeGen/PowerPC/builtins-ppc-xlcompat-math.ll
  llvm/test/CodeGen/PowerPC/fpscr-intrinsics.ll

Index: llvm/test/CodeGen/PowerPC/fpscr-intrinsics.ll
===
--- /dev/null
+++ llvm/test/CodeGen/PowerPC/fpscr-intrinsics.ll
@@ -0,0 +1,121 @@
+; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
+; RUN: llc -verify-machineinstrs -mtriple=powerpc64le-unknown-linux-gnu < %s | \
+; RUN:   FileCheck %s
+; RUN: llc -verify-machineinstrs -mtriple=powerpc64-unknown-aix -mcpu=pwr7 \
+; RUN:   < %s | FileCheck %s --check-prefix=CHECK-AIX64
+; RUN: llc -verify-machineinstrs -mtriple=powerpc-unknown-aix -mcpu=pwr8 < %s | \
+; RUN:   FileCheck %s --check-prefix=CHECK-AIX32
+
+define dso_local void @mtfsb0() local_unnamed_addr #0 {
+; CHECK-PWR8-LABEL: mtfsb0:
+; CHECK-PWR8:   # %bb.0: # %entry
+; CHECK-PWR8-NEXT:mtfsb0 10
+; CHECK-PWR8-NEXT:blr
+;
+; CHECK-PWR7-LABEL: mtfsb0:
+; CHECK-PWR7:   # %bb.0: # %entry
+; CHECK-PWR7-NEXT:mtfsb0 10
+; CHECK-PWR7-NEXT:blr
+; CHECK-LABEL: mtfsb0:
+; CHECK:   # %bb.0: # %entry
+; CHECK-NEXT:mtfsb0 10
+; CHECK-NEXT:blr
+;
+; CHECK-AIX64-LABEL: mtfsb0:
+; CHECK-AIX64:   # %bb.0: # %entry
+; CHECK-AIX64-NEXT:mtfsb0 10
+; CHECK-AIX64-NEXT:blr
+;
+; CHECK-AIX32-LABEL: mtfsb0:
+; CHECK-AIX32:   # %bb.0: # %entry
+; CHECK-AIX32-NEXT:mtfsb0 10
+; CHECK-AIX32-NEXT:blr
+entry:
+  tail call void @llvm.ppc.mtfsb0(i32 10)
+  ret void
+}
+
+define dso_local void @mtfsb1() local_unnamed_addr #0 {
+; CHECK-PWR8-LABEL: mtfsb1:
+; CHECK-PWR8:   # %bb.0: # %entry
+; CHECK-PWR8-NEXT:mtfsb1 0
+; CHECK-PWR8-NEXT:blr
+;
+; CHECK-PWR7-LABEL: mtfsb1:
+; CHECK-PWR7:   # %bb.0: # %entry
+; CHECK-PWR7-NEXT:mtfsb1 0
+; CHECK-PWR7-NEXT:blr
+; CHECK-LABEL: mtfsb1:
+; CHECK:   # %bb.0: # %entry
+; CHECK-NEXT:mtfsb1 0
+; CHECK-NEXT:blr
+;
+; CHECK-AIX64-LABEL: mtfsb1:
+; CHECK-AIX64:   # %bb.0: # %entry
+; CHECK-AIX64-NEXT:mtfsb1 0
+; CHECK-AIX64-NEXT:blr
+;
+; CHECK-AIX32-LABEL: mtfsb1:
+; CHECK-AIX32:   # %bb.0: # %entry
+; CHECK-AIX32-NEXT:mtfsb1 0
+; CHECK-AIX32-NEXT:blr
+entry:
+  tail call void @llvm.ppc.mtfsb1(i32 0)
+  ret void
+}
+
+define dso_local void @callmtfsf(i32 zeroext %a) local_unnamed_addr {
+; CHECK-LABEL: callmtfsf:
+; CHECK:   # %bb.0: # %entry
+; CHECK-NEXT:mtfprwz 0, 3
+; CHECK-NEXT:xscvuxddp 0, 0
+; CHECK-NEXT:mtfsf 7, 0
+; CHECK-NEXT:blr
+;
+; CHECK-AIX64-LABEL: callmtfsf:
+; CHECK-AIX64:   # %bb.0: # %entry
+; CHECK-AIX64-NEXT:addi 4, 1, -4
+; CHECK-AIX64-NEXT:stw 3, -4(1)
+; CHECK-AIX64-NEXT:lfiwzx 0, 0, 4
+; CHECK-AIX64-NEXT:xscvuxddp 0, 0
+; CHECK-AIX64-NEXT:mtfsf 7, 0
+; CHECK-AIX64-NEXT:blr
+;
+; CHECK-AIX32-LABEL: callmtfsf:
+; CHECK-AIX32:   # %bb.0: # %entry
+; CHECK-AIX32-NEXT:addi 4, 1, -4
+; CHECK-AIX32-NEXT:stw 3, -4(1)
+; CHECK-AIX32-NEXT:lfiwzx 0, 0, 4
+; CHECK-AIX32-NEXT:xscvuxddp 0, 0
+; CHECK-AIX32-NEXT:mtfsf 7, 0
+; CHECK-AIX32-NEXT:blr
+entry:
+  %0 = uitofp i32 %a to double
+  tail call void @llvm.ppc.mtfsf(i32 7, double %0)
+  ret void
+}
+
+define dso_local void @callmtfsfi(i32 zeroext %a) local_unnamed_addr {
+; CHECK-LABEL: callmtfsfi:
+; CHECK:   # %bb.0: # %entry
+; CHECK-NEXT:mtfsfi 1, 3
+; CHECK-NEXT:blr
+;
+; CHECK-AIX64-LABEL: callmtfsfi:
+; CHECK-AIX64:   # %bb.0: # %entry
+; CHECK-AIX64-NEXT:mtfsfi 1, 3
+; CHECK-AIX64-NEXT:blr
+;
+; CHECK-AIX32-LABEL: callmtfsfi:
+; CHECK-AIX32:   # %bb.0: # %entry
+; CHECK-AIX32-NEXT:mtfsfi 1, 3
+; CHECK-AIX32-NEXT:blr
+entry:
+  tail call void @llvm.ppc.mtfsfi(i32 1, i32 3)
+  ret void
+}
+
+declare void @llvm.ppc.mtfsb0(i32)
+declare void @llvm.ppc.mtfsb1(i32)
+declare void @llvm.ppc.mtfsfi(i32, i32)
+declare void @llvm.ppc.mtfsf(i32, double)
Index: llvm/test/CodeGen/PowerPC/builtins-ppc-xlcompat-math.ll
===
--- llvm/test/CodeGen/PowerPC/builtins-ppc-xlcompat-math.ll
+++ llvm/test/CodeGen/PowerPC/builtins-ppc-xlcompat-math.ll
@@ -8,44 +8,6 @@
 ; RUN: llc -veri

[clang] 8a0f116 - Fix test trying to write a spurious output file into the source

[Richard Smith via cfe-commits]

Author: Richard Smith
Date: 2021-07-13T18:58:24-07:00
New Revision: 8a0f1163d02c77c6e764929b66c26ba196cfc549

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

LOG: Fix test trying to write a spurious output file into the source
directory.

This causes test failures if the source directory is read-only.

Added: 


Modified: 
clang/test/CodeGen/builtins-ppc-xlcompat-pwr9-64bit.c
clang/test/CodeGen/builtins-ppc-xlcompat-pwr9.c

Removed: 




diff  --git a/clang/test/CodeGen/builtins-ppc-xlcompat-pwr9-64bit.c 
b/clang/test/CodeGen/builtins-ppc-xlcompat-pwr9-64bit.c
index bee48b022559..6dd96f4e2f88 100644
--- a/clang/test/CodeGen/builtins-ppc-xlcompat-pwr9-64bit.c
+++ b/clang/test/CodeGen/builtins-ppc-xlcompat-pwr9-64bit.c
@@ -4,9 +4,9 @@
 // RUN:   -target-cpu pwr9 -o - | FileCheck %s
 // RUN: %clang_cc1 -triple powerpc64-unknown-aix -emit-llvm %s \
 // RUN:   -target-cpu pwr9 -o - | FileCheck %s
-// RUN: not %clang_cc1 -triple powerpc-unknown-aix %s -emit-llvm %s \
+// RUN: not %clang_cc1 -triple powerpc-unknown-aix -emit-llvm-only %s \
 // RUN:   -target-cpu pwr9 2>&1 | FileCheck %s --check-prefix=CHECK-32-ERROR
-// RUN: not %clang_cc1 -triple powerpc64-unknown-aix -emit-llvm %s \
+// RUN: not %clang_cc1 -triple powerpc64-unknown-aix -emit-llvm-only %s \
 // RUN:   -target-cpu pwr8 2>&1 | FileCheck %s --check-prefix=CHECK-NONPWR9-ERR
 
 extern signed long long sll;

diff  --git a/clang/test/CodeGen/builtins-ppc-xlcompat-pwr9.c 
b/clang/test/CodeGen/builtins-ppc-xlcompat-pwr9.c
index e49bbaf5234c..bdce26a82dd2 100644
--- a/clang/test/CodeGen/builtins-ppc-xlcompat-pwr9.c
+++ b/clang/test/CodeGen/builtins-ppc-xlcompat-pwr9.c
@@ -6,7 +6,7 @@
 // RUN:   -target-cpu pwr9 -o - | FileCheck %s
 // RUN: %clang_cc1 -triple powerpc-unknown-aix %s -emit-llvm %s \
 // RUN:   -target-cpu pwr9 -o - | FileCheck %s
-// RUN: not %clang_cc1 -triple powerpc64-unknown-aix -emit-llvm %s \
+// RUN: not %clang_cc1 -triple powerpc64-unknown-aix -emit-llvm-only %s \
 // RUN:   -target-cpu pwr8 2>&1 | FileCheck %s --check-prefix=CHECK-NONPWR9-ERR
 
 extern unsigned int ui;



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

[PATCH] D105951: [clang] P2266 implicit moves STL workaround

[Matheus Izvekov via Phabricator via cfe-commits]

mizvekov updated this revision to Diff 358488.
mizvekov added a comment.

.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105951

Files:
  clang/lib/Frontend/InitPreprocessor.cpp
  clang/lib/Sema/SemaStmt.cpp
  clang/test/SemaCXX/Inputs/sys/cxx2b-p2266-disable-with-msvc-compat-sys.hpp
  clang/test/SemaCXX/Inputs/usr/cxx2b-p2266-disable-with-msvc-compat-usr.hpp
  clang/test/SemaCXX/cxx2b-p2266-disable-with-msvc-compat.cpp

Index: clang/test/SemaCXX/cxx2b-p2266-disable-with-msvc-compat.cpp
===
--- clang/test/SemaCXX/cxx2b-p2266-disable-with-msvc-compat.cpp
+++ clang/test/SemaCXX/cxx2b-p2266-disable-with-msvc-compat.cpp
@@ -1,50 +1,48 @@
-// RUN: %clang_cc1 -std=c++2b -fsyntax-only -fcxx-exceptions-verify=new %s
-// RUN: %clang_cc1 -std=c++2b -fsyntax-only -fcxx-exceptions -fms-compatibility -verify=old %s
-// RUN: %clang_cc1 -std=c++20 -fsyntax-only -fcxx-exceptions-verify=old %s
+// RUN: %clang_cc1 -std=c++2b -fsyntax-only -I %S/Inputs/usr -isystem %S/Inputs/sys-verify=cxx2b,new %s
+// RUN: %clang_cc1 -std=c++2b -fsyntax-only -I %S/Inputs/usr -isystem %S/Inputs/sys -fms-compatibility -verify=cxx2b,old %s
+// RUN: %clang_cc1 -std=c++20 -fsyntax-only -I %S/Inputs/usr -isystem %S/Inputs/sys-verify=cxx20,old %s
 
 // FIXME: This is a test for a temporary workaround where we disable simpler implicit moves
-//when compiling with -fms-compatibility, because the MSVC STL does not compile.
-//A better workaround is under discussion.
-//The test cases here are just a copy from `CXX/class/class.init/class.copy.elision/p3.cpp`,
-//so feel free to delete this file when the workaround is not needed anymore.
-
-struct CopyOnly {
-  CopyOnly(); // new-note {{candidate constructor not viable: requires 0 arguments, but 1 was provided}}
-  // new-note@-1 {{candidate constructor not viable: requires 0 arguments, but 1 was provided}}
-  CopyOnly(CopyOnly &); // new-note {{candidate constructor not viable: expects an lvalue for 1st argument}}
-  // new-note@-1 {{candidate constructor not viable: expects an lvalue for 1st argument}}
-};
-struct MoveOnly {
-  MoveOnly();
-  MoveOnly(MoveOnly &&);
-};
-MoveOnly &&rref();
-
-MoveOnly &&test1(MoveOnly &&w) {
-  return w; // old-error {{cannot bind to lvalue of type}}
-}
-
-CopyOnly test2(bool b) {
-  static CopyOnly w1;
-  CopyOnly w2;
-  if (b) {
-return w1;
-  } else {
-return w2; // new-error {{no matching constructor for initialization}}
-  }
-}
-
-template  T &&test3(T &&x) { return x; } // old-error {{cannot bind to lvalue of type}}
-template MoveOnly &test3(MoveOnly &);
-template MoveOnly &&test3(MoveOnly &&); // old-note {{in instantiation of function template specialization}}
-
-MoveOnly &&test4() {
-  MoveOnly &&x = rref();
-  return x; // old-error {{cannot bind to lvalue of type}}
-}
-
-void test5() try {
-  CopyOnly x;
-  throw x; // new-error {{no matching constructor for initialization}}
-} catch (...) {
-}
+//in the STL when compiling with -fms-compatibility, because of issues with the
+//implementation there.
+//Feel free to delete this file when the workaround is not needed anymore.
+
+#if __cpluscplus > 202002L && __cpp_implicit_move < 202011L
+#error "__cpp_implicit_move not defined correctly"
+#endif
+
+int &&mt1(int &&x) { return x; } // cxx20-error {{cannot bind to lvalue}}
+int &mt2(int &&x) { return x; }  // cxx2b-error {{cannot bind to a temporary}}
+
+namespace {
+int &&mt1(int &&x) { return x; } // cxx20-error {{cannot bind to lvalue}}
+int &mt2(int &&x) { return x; }  // cxx2b-error {{cannot bind to a temporary}}
+} // namespace
+
+namespace foo {
+int &&mt1(int &&x) { return x; } // cxx20-error {{cannot bind to lvalue}}
+int &mt2(int &&x) { return x; }  // cxx2b-error {{cannot bind to a temporary}}
+namespace std {
+int &&mt1(int &&x) { return x; } // cxx20-error {{cannot bind to lvalue}}
+int &mt2(int &&x) { return x; }  // cxx2b-error {{cannot bind to a temporary}}
+} // namespace std
+} // namespace foo
+
+namespace std {
+
+int &&mt1(int &&x) { return x; } // cxx20-error {{cannot bind to lvalue}}
+int &mt2(int &&x) { return x; }  // cxx2b-error {{cannot bind to a temporary}}
+
+namespace {
+int &&mt1(int &&x) { return x; } // cxx20-error {{cannot bind to lvalue}}
+int &mt2(int &&x) { return x; }  // cxx2b-error {{cannot bind to a temporary}}
+} // namespace
+
+namespace foo {
+int &&mt1(int &&x) { return x; } // cxx20-error {{cannot bind to lvalue}}
+int &mt2(int &&x) { return x; }  // cxx2b-error {{cannot bind to a temporary}}
+} // namespace foo
+
+} // namespace std
+#include 
+#include 
Index: clang/test/SemaCXX/Inputs/usr/cxx2b-p2266-disable-with-msvc-compat-usr.hpp
===
--- /dev/null
+++ clan

[PATCH] D105951: [clang] P2266 implicit moves STL workaround

[Matheus Izvekov via Phabricator via cfe-commits]

mizvekov created this revision.
mizvekov updated this revision to Diff 358468.
mizvekov added a comment.
mizvekov updated this revision to Diff 358483.
mizvekov published this revision for review.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

.


mizvekov added a comment.

format.


This patch replaces the workaround for simpler implicit moves
implemented in D105518 .

The Microsoft STL currently has some issues with P2266 
.

Where before, with -fms-compatibility, we would disable simpler
implicit moves globally, with this change, we disable it only
when the returned expression is in a context contained by
std namespace and is located within a system header.

Signed-off-by: Matheus Izvekov 


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D105951

Files:
  clang/lib/Frontend/InitPreprocessor.cpp
  clang/lib/Sema/SemaStmt.cpp
  clang/test/SemaCXX/Inputs/sys/cxx2b-p2266-disable-with-msvc-compat-sys.hpp
  clang/test/SemaCXX/Inputs/usr/cxx2b-p2266-disable-with-msvc-compat-usr.hpp
  clang/test/SemaCXX/cxx2b-p2266-disable-with-msvc-compat.cpp

Index: clang/test/SemaCXX/cxx2b-p2266-disable-with-msvc-compat.cpp
===
--- clang/test/SemaCXX/cxx2b-p2266-disable-with-msvc-compat.cpp
+++ clang/test/SemaCXX/cxx2b-p2266-disable-with-msvc-compat.cpp
@@ -1,50 +1,48 @@
-// RUN: %clang_cc1 -std=c++2b -fsyntax-only -fcxx-exceptions-verify=new %s
-// RUN: %clang_cc1 -std=c++2b -fsyntax-only -fcxx-exceptions -fms-compatibility -verify=old %s
-// RUN: %clang_cc1 -std=c++20 -fsyntax-only -fcxx-exceptions-verify=old %s
+// RUN: %clang_cc1 -std=c++2b -fsyntax-only -I %S/Inputs/usr -isystem %S/Inputs/sys-verify=cxx2b,new %s
+// RUN: %clang_cc1 -std=c++2b -fsyntax-only -I %S/Inputs/usr -isystem %S/Inputs/sys -fms-compatibility -verify=cxx2b,old %s
+// RUN: %clang_cc1 -std=c++20 -fsyntax-only -I %S/Inputs/usr -isystem %S/Inputs/sys-verify=cxx20,old %s
 
 // FIXME: This is a test for a temporary workaround where we disable simpler implicit moves
-//when compiling with -fms-compatibility, because the MSVC STL does not compile.
-//A better workaround is under discussion.
-//The test cases here are just a copy from `CXX/class/class.init/class.copy.elision/p3.cpp`,
-//so feel free to delete this file when the workaround is not needed anymore.
-
-struct CopyOnly {
-  CopyOnly(); // new-note {{candidate constructor not viable: requires 0 arguments, but 1 was provided}}
-  // new-note@-1 {{candidate constructor not viable: requires 0 arguments, but 1 was provided}}
-  CopyOnly(CopyOnly &); // new-note {{candidate constructor not viable: expects an lvalue for 1st argument}}
-  // new-note@-1 {{candidate constructor not viable: expects an lvalue for 1st argument}}
-};
-struct MoveOnly {
-  MoveOnly();
-  MoveOnly(MoveOnly &&);
-};
-MoveOnly &&rref();
-
-MoveOnly &&test1(MoveOnly &&w) {
-  return w; // old-error {{cannot bind to lvalue of type}}
-}
-
-CopyOnly test2(bool b) {
-  static CopyOnly w1;
-  CopyOnly w2;
-  if (b) {
-return w1;
-  } else {
-return w2; // new-error {{no matching constructor for initialization}}
-  }
-}
-
-template  T &&test3(T &&x) { return x; } // old-error {{cannot bind to lvalue of type}}
-template MoveOnly &test3(MoveOnly &);
-template MoveOnly &&test3(MoveOnly &&); // old-note {{in instantiation of function template specialization}}
-
-MoveOnly &&test4() {
-  MoveOnly &&x = rref();
-  return x; // old-error {{cannot bind to lvalue of type}}
-}
-
-void test5() try {
-  CopyOnly x;
-  throw x; // new-error {{no matching constructor for initialization}}
-} catch (...) {
-}
+//in the STL when compiling with -fms-compatibility, because of issues with the
+//implementation there.
+//Feel free to delete this file when the workaround is not needed anymore.
+
+#if __cpluscplus > 202002L && __cpp_implicit_move < 202011L
+#error "__cpp_implicit_move not defined correctly"
+#endif
+
+int &&mt1(int &&x) { return x; } // cxx20-error {{cannot bind to lvalue}}
+int &mt2(int &&x) { return x; }  // cxx2b-error {{cannot bind to a temporary}}
+
+namespace {
+int &&mt1(int &&x) { return x; } // cxx20-error {{cannot bind to lvalue}}
+int &mt2(int &&x) { return x; }  // cxx2b-error {{cannot bind to a temporary}}
+} // namespace
+
+namespace foo {
+int &&mt1(int &&x) { return x; } // cxx20-error {{cannot bind to lvalue}}
+int &mt2(int &&x) { return x; }  // cxx2b-error {{cannot bind to a temporary}}
+namespace std {
+int &&mt1(int &&x) { return x; } // cxx20-error {{cannot bind to lvalue}}
+int &mt2(int &&x) { return x; }  // cxx2b-error {{cannot bind to a temporary}}
+} // namespace std
+} // namespace foo
+
+namespace std {
+
+int &&mt1(int &&x) { return x; } // cxx20-error {{cannot bind to lvalue}}
+int &mt2(int &&x) { retur

[PATCH] D99487: [CodeGen] Port basic block sections from ELF to COFF

[TaoPan via Phabricator via cfe-commits]

TaoPan updated this revision to Diff 358481.
TaoPan added a comment.

Change select of BB sections to IMAGE_COMDAT_SELECT_NODUPLICATES


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99487

Files:
  clang/include/clang/Driver/Options.td
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/test/Driver/fbasic-block-sections.c
  llvm/include/llvm/CodeGen/TargetLoweringObjectFileImpl.h
  llvm/lib/CodeGen/TargetLoweringObjectFileImpl.cpp
  llvm/test/CodeGen/X86/basic-block-sections.ll

Index: llvm/test/CodeGen/X86/basic-block-sections.ll
===
--- llvm/test/CodeGen/X86/basic-block-sections.ll
+++ llvm/test/CodeGen/X86/basic-block-sections.ll
@@ -3,6 +3,10 @@
 ; RUN: llc < %s -mtriple=x86_64-pc-linux -function-sections -basic-block-sections=all -unique-basic-block-section-names -split-machine-functions | FileCheck %s -check-prefix=LINUX-SECTIONS
 ; RUN: llc < %s -mtriple=i386-unknown-linux-gnu  -function-sections -basic-block-sections=all -unique-basic-block-section-names | FileCheck %s -check-prefix=LINUX-SECTIONS
 ; RUN: llc < %s -mtriple=i386-unknown-linux-gnu  -basic-block-sections=all -unique-basic-block-section-names | FileCheck %s -check-prefix=LINUX-SECTIONS
+; RUN: llc < %s -mtriple=x86_64-windows-msvc -function-sections -basic-block-sections=all -unique-basic-block-section-names | FileCheck %s -check-prefix=WINDOWS-MSVC-SECTIONS
+; RUN: llc < %s -mtriple=x86_64-windows-msvc -basic-block-sections=all -unique-basic-block-section-names | FileCheck %s -check-prefix=WINDOWS-MSVC-SECTIONS
+; RUN: llc < %s -mtriple=x86_64-windows-gnu -function-sections -basic-block-sections=all -unique-basic-block-section-names | FileCheck %s -check-prefix=WINDOWS-GNU-FUNCTION-SECTIONS
+; RUN: llc < %s -mtriple=x86_64-windows-gnu -basic-block-sections=all -unique-basic-block-section-names | FileCheck %s -check-prefix=WINDOWS-GNU-SECTIONS
 
 define void @_Z3bazb(i1 zeroext) nounwind {
   %2 = alloca i8, align 1
@@ -39,3 +43,27 @@
 ; LINUX-SECTIONS: [[SECTION_LABEL_2]]:
 ; LINUX-SECTIONS: .LBB_END0_2:
 ; LINUX-SECTIONS-NEXT: .size   [[SECTION_LABEL_2]], .LBB_END0_2-[[SECTION_LABEL_2]]
+; WINDOWS-MSVC-FUNCTION-SECTIONS: .section.text,"xr",discard,_Z3bazb
+; WINDOWS-MSVC-FUNCTION-SECTIONS: _Z3bazb:
+; WINDOWS-MSVC-FUNCTION-SECTIONS: .section.text,"xr",one_only,[[SECTION_LABEL_1:_Z3bazb.__part.[0-9]+]]
+; WINDOWS-MSVC-FUNCTION-SECTIONS: [[SECTION_LABEL_1]]:
+; WINDOWS-MSVC-FUNCTION-SECTIONS: .section.text,"xr",one_only,[[SECTION_LABEL_2:_Z3bazb.__part.[0-9]+]]
+; WINDOWS-MSVC-FUNCTION-SECTIONS: [[SECTION_LABEL_2]]:
+; WINDOWS-MSVC-SECTIONS: .section.text,"xr"
+; WINDOWS-MSVC-SECTIONS: _Z3bazb:
+; WINDOWS-MSVC-SECTIONS: je  [[SECTION_LABEL_2:_Z3bazb.__part.[0-9]+]]
+; WINDOWS-MSVC-SECTIONS: jmp [[SECTION_LABEL_1:_Z3bazb.__part.[0-9]+]]
+; WINDOWS-MSVC-SECTIONS: [[SECTION_LABEL_1]]:
+; WINDOWS-MSVC-SECTIONS: [[SECTION_LABEL_2]]:
+; WINDOWS-GNU-FUNCTION-SECTIONS: .section.text$_Z3bazb,"xr",discard,_Z3bazb
+; WINDOWS-GNU-FUNCTION-SECTIONS: _Z3bazb:
+; WINDOWS-GNU-FUNCTION-SECTIONS: .section.text,"xr",one_only,[[SECTION_LABEL_1:_Z3bazb.__part.[0-9]+]]
+; WINDOWS-GNU-FUNCTION-SECTIONS: [[SECTION_LABEL_1]]:
+; WINDOWS-GNU-FUNCTION-SECTIONS: .section.text,"xr",one_only,[[SECTION_LABEL_2:_Z3bazb.__part.[0-9]+]]
+; WINDOWS-GNU-FUNCTION-SECTIONS: [[SECTION_LABEL_2]]:
+; WINDOWS-GNU-SECTIONS: .section.text$_Z3bazb,"xr"
+; WINDOWS-GNU-SECTIONS: _Z3bazb:
+; WINDOWS-GNU-SECTIONS: .section.text,"xr"
+; WINDOWS-GNU-SECTIONS: _Z3bazb.__part.1:
+; WINDOWS-GNU-SECTIONS: .section.text,"xr"
+; WINDOWS-GNU-SECTIONS: _Z3bazb.__part.2:
Index: llvm/lib/CodeGen/TargetLoweringObjectFileImpl.cpp
===
--- llvm/lib/CodeGen/TargetLoweringObjectFileImpl.cpp
+++ llvm/lib/CodeGen/TargetLoweringObjectFileImpl.cpp
@@ -1733,6 +1733,61 @@
   COFF::IMAGE_COMDAT_SELECT_ASSOCIATIVE, UniqueID);
 }
 
+/// Returns a unique section for the given machine basic block.
+MCSection *TargetLoweringObjectFileCOFF::getSectionForMachineBasicBlock(
+const Function &F, const MachineBasicBlock &MBB,
+const TargetMachine &TM) const {
+  assert(MBB.isBeginSection() && "Basic block does not start a section!");
+  SectionKind Kind = SectionKind::getText();
+  unsigned Characteristics = getCOFFSectionFlags(Kind, TM);
+  // If we have -ffunction-sections then we should emit the global value to a
+  // uniqued section specifically for it.
+  if (TM.getFunctionSections() || F.hasComdat())
+Characteristics |= COFF::IMAGE_SCN_LNK_COMDAT;
+  unsigned UniqueID = MCContext::GenericSectionID;
+  StringRef COMDATSymName;
+  if (TM.getUniqueBasicBlockSectionNames())
+COMDATSymName = MBB.getSymbol()->getName();
+  else {
+UniqueID = NextUniqueID++;
+COMDATSymName = MBB.getP

[PATCH] D105328: [Frontend] Only compile modules if not already finalized

[Ben Barham via Phabricator via cfe-commits]

bnbarham updated this revision to Diff 358465.
bnbarham edited the summary of this revision.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105328

Files:
  clang/include/clang/Basic/DiagnosticCommonKinds.td
  clang/include/clang/Basic/DiagnosticSerializationKinds.td
  clang/include/clang/Serialization/ASTReader.h
  clang/lib/Frontend/CompilerInstance.cpp
  clang/lib/Serialization/ASTReader.cpp
  clang/unittests/Serialization/CMakeLists.txt
  clang/unittests/Serialization/ModuleCacheTest.cpp

Index: clang/unittests/Serialization/ModuleCacheTest.cpp
===
--- /dev/null
+++ clang/unittests/Serialization/ModuleCacheTest.cpp
@@ -0,0 +1,179 @@
+//===- unittests/Serialization/ModuleCacheTest.cpp - CI tests -===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include "clang/Basic/FileManager.h"
+#include "clang/Frontend/CompilerInstance.h"
+#include "clang/Frontend/CompilerInvocation.h"
+#include "clang/Frontend/FrontendActions.h"
+#include "clang/Lex/HeaderSearch.h"
+#include "llvm/ADT/SmallString.h"
+#include "llvm/Support/FileSystem.h"
+#include "llvm/Support/raw_ostream.h"
+
+#include "gtest/gtest.h"
+
+using namespace llvm;
+using namespace clang;
+
+namespace {
+
+class ModuleCacheTest : public ::testing::Test {
+  void SetUp() override {
+ASSERT_FALSE(sys::fs::createUniqueDirectory("modulecache-test", TestDir));
+
+ModuleCachePath = SmallString<256>(TestDir);
+sys::path::append(ModuleCachePath, "mcp");
+ASSERT_FALSE(sys::fs::create_directories(ModuleCachePath));
+  }
+
+  void TearDown() override { sys::fs::remove_directories(TestDir); }
+
+public:
+  SmallString<256> TestDir;
+  SmallString<256> ModuleCachePath;
+
+  void addFile(StringRef Path, StringRef Contents) {
+ASSERT_FALSE(sys::path::is_absolute(Path));
+
+SmallString<256> AbsPath(TestDir);
+sys::path::append(AbsPath, Path);
+
+std::error_code EC;
+ASSERT_FALSE(
+sys::fs::create_directories(llvm::sys::path::parent_path(AbsPath)));
+llvm::raw_fd_ostream OS(AbsPath, EC);
+ASSERT_FALSE(EC);
+OS << Contents;
+  }
+
+  void addDuplicateFrameworks() {
+addFile("test.m", R"cpp(
+@import Top;
+)cpp");
+
+addFile("frameworks/Top.framework/Headers/top.h", R"cpp(
+@import M;
+)cpp");
+addFile("frameworks/Top.framework/Modules/module.modulemap", R"cpp(
+framework module Top [system] {
+  header "top.h"
+  export *
+}
+)cpp");
+
+addFile("frameworks/M.framework/Headers/m.h", R"cpp(
+void foo();
+)cpp");
+addFile("frameworks/M.framework/Modules/module.modulemap", R"cpp(
+framework module M [system] {
+  header "m.h"
+  export *
+}
+)cpp");
+
+addFile("frameworks2/M.framework/Headers/m.h", R"cpp(
+void foo();
+)cpp");
+addFile("frameworks2/M.framework/Modules/module.modulemap", R"cpp(
+framework module M [system] {
+  header "m.h"
+  export *
+}
+)cpp");
+  }
+};
+
+TEST_F(ModuleCacheTest, CachedModuleNewPath) {
+  addDuplicateFrameworks();
+
+  SmallString<256> MCPArg("-fmodules-cache-path=");
+  MCPArg.append(ModuleCachePath);
+  IntrusiveRefCntPtr Diags =
+  CompilerInstance::createDiagnostics(new DiagnosticOptions());
+
+  // First run should pass with no errors
+  const char *Args[] = {"clang","-fmodules",  "-Fframeworks",
+MCPArg.c_str(), "-working-directory", TestDir.c_str(),
+"test.m"};
+  std::shared_ptr Invocation =
+  createInvocationFromCommandLine(Args, Diags);
+  ASSERT_TRUE(Invocation);
+  CompilerInstance Instance;
+  Instance.setDiagnostics(Diags.get());
+  Instance.setInvocation(Invocation);
+  SyntaxOnlyAction Action;
+  ASSERT_TRUE(Instance.ExecuteAction(Action));
+  ASSERT_FALSE(Diags->hasErrorOccurred());
+
+  // Now add `frameworks2` to the search path. `Top.pcm` will have a reference
+  // to the `M` from `frameworks`, but a search will find the `M` from
+  // `frameworks2` - causing a mismatch and it to be considered out of date.
+  //
+  // Normally this would be fine - `M` and the modules it depends on would be
+  // rebuilt. However, since we have a shared module cache and thus an already
+  // finalized `Top`, recompiling `Top` will cause the existing module to be
+  // removed from the cache, causing possible crashed if it is ever used.
+  //
+  // Make sure that an error occurs instead.
+  const char *Args2[] = {"clang", "-fmodules","-Fframeworks2",
+ "-Fframeworks",  MCPArg.c_str(), "-

[PATCH] D105328: [Frontend] Only compile modules if not already finalized

[Ben Barham via Phabricator via cfe-commits]

bnbarham marked 5 inline comments as done.
bnbarham added inline comments.



Comment at: clang/lib/Frontend/CompilerInstance.cpp:1063
+<< ModuleName;
+return ImportingInstance.getFrontendOpts().AllowPCMWithCompilerErrors;
+  }

bnbarham wrote:
> vsapsai wrote:
> > Can we get in infinite loop with `AllowPCMWithCompilerErrors = true`? 
> > Specifically, I'm thinking about the scenario
> > 
> > 1. `compileModuleAndReadAST` obtains a file lock and calls `compileModule`
> > 2. `compileModule` calls `compileModuleImpl`
> > 3. Module is finalized but `AllowPCMWithCompilerErrors` is true, so 
> > `compileModuleImpl` returns true
> > 4. `compileModule` returns true
> > 5. `compileModuleAndReadAST` tries to read AST because compilation was 
> > successful
> > 6. AST is out of date, so `compileModuleAndReadAST` decides to try again, 
> > goto 1
> > 
> > Haven't tried to reproduce it locally but even if this scenario is 
> > impossible, a corresponding test case can be useful.
> Nice catch, that does seem likely - I'll see if I can add a test for this.
It doesn't end up causing an infinite recursion as `false` will end up being 
returned from `compileModuleAndReadAST`, but in that case there's no point 
returning `true` from `compileModuleImpl` in the first place so I've changed it 
anyway. Have also added that as a test case, just to make sure.



Comment at: clang/lib/Serialization/ASTReader.cpp:2923
   if (!BuildDir || *BuildDir != M->Directory) {
-if ((ClientLoadCapabilities & ARR_OutOfDate) == 0)
+if (diagnoseOutOfDate(F.FileName, ClientLoadCapabilities))
   Diag(diag::err_imported_module_relocated)

bnbarham wrote:
> vsapsai wrote:
> > I'm thinking if in case of finalized modules diagnostic messages are good 
> > enough. One concern is it won't be clear why a module wasn't rebuilt. It 
> > can be already confusing for precompiled headers and I'm afraid we won't be 
> > able to detect `isPCMFinal` code path without a debugger. Though I don't 
> > know how bad that would be in practice.
> > 
> > Another concern is that retrying a compilation should succeed as for a new 
> > process we have a new InMemoryModuleCache and `isPCMFinal` should return 
> > false. So we might have non-deterministic behavior and some of the valid 
> > error messages can seem to be non-deterministic and not reliable. I was 
> > thinking about adding a note in case we are dealing with `isPCMFinal` to 
> > distinguish these cases but not sure it is a good idea.
> > I'm thinking if in case of finalized modules diagnostic messages are good 
> > enough. One concern is it won't be clear why a module wasn't rebuilt. It 
> > can be already confusing for precompiled headers and I'm afraid we won't be 
> > able to detect `isPCMFinal` code path without a debugger. Though I don't 
> > know how bad that would be in practice.
> 
> The error messages will mention a module in the module cache, which would be 
> the main way to tell. We could add a note here as you suggest below, but I'm 
> not quite sure what it would say... something about there being two modules 
> with the same name?
> 
> > Another concern is that retrying a compilation should succeed as for a new 
> > process we have a new InMemoryModuleCache and `isPCMFinal` should return 
> > false. So we might have non-deterministic behavior and some of the valid 
> > error messages can seem to be non-deterministic and not reliable. I was 
> > thinking about adding a note in case we are dealing with `isPCMFinal` to 
> > distinguish these cases but not sure it is a good idea.
> 
> The errors should be deterministic I believe. If one process has the issue 
> then a new one will have the issue as well. For what it's worth, I don't 
> think these crashes are possible from the clang frontend. They require 
> messing around with search paths such that between two compilations in the 
> same process, different modules are found.
I've added an extra note "this is generally caused by modules with the same 
name found in multiple paths". So the diagnostics would now be:
```
/.../test.m:2:10: fatal error: module 'M' was built in directory 
'/.../frameworks/M.framework' but now resides in directory 
'frameworks2/M.framework'
@import Top;
 ^
/.../test.m:2:10: note: imported by module 'Top' in 
'/path/to/module/cache/LGSY9KSYAKN1/Top-1MZE9QJ1AHENQ.pcm
/.../test.m:2:10: note: this is generally caused by modules with the same name 
found in multiple paths
```

I was thinking of mentioning the finalized module, but that's really just a 
side effect of the error that should have already been output (ie. `module 'M' 
was built in...` in this case). So the existence of this note should help point 
users to the problem + make which path caused the error obvious when looking at 
the code.



Comment at: clang/lib/Serialization/ASTReader.cpp:5929
 
+bool ASTReader::diagn

[PATCH] D105950: [WebAssembly] Codegen for v128.loadX_lane instructions

[Thomas Lively via Phabricator via cfe-commits]

tlively created this revision.
tlively added reviewers: aheejin, dschuff.
Herald added subscribers: wingo, ecnelises, sunfish, hiraditya, 
jgravelle-google, sbc100.
tlively requested review of this revision.
Herald added projects: clang, LLVM.
Herald added subscribers: llvm-commits, cfe-commits.

Replace the experimental clang builtin and LLVM intrinsics for these
instructions with normal codegen patterns. Resolves PR50433.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D105950

Files:
  clang/include/clang/Basic/BuiltinsWebAssembly.def
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/lib/Headers/wasm_simd128.h
  clang/test/CodeGen/builtins-wasm.c
  clang/test/Headers/wasm.c
  llvm/include/llvm/IR/IntrinsicsWebAssembly.td
  llvm/lib/Target/WebAssembly/WebAssemblyISelLowering.cpp
  llvm/lib/Target/WebAssembly/WebAssemblyInstrSIMD.td
  llvm/test/CodeGen/WebAssembly/simd-build-vector.ll
  llvm/test/CodeGen/WebAssembly/simd-load-lane-offset.ll
  llvm/test/CodeGen/WebAssembly/simd-load-store-alignment.ll

Index: llvm/test/CodeGen/WebAssembly/simd-load-store-alignment.ll
===
--- llvm/test/CodeGen/WebAssembly/simd-load-store-alignment.ll
+++ llvm/test/CodeGen/WebAssembly/simd-load-store-alignment.ll
@@ -134,6 +134,34 @@
   ret <16 x i8> %v2
 }
 
+; 1 is the default alignment for v128.load8_lane so no attribute is needed.
+define <16 x i8> @load_lane_i8_a1(i8* %p, <16 x i8> %v) {
+; CHECK-LABEL: load_lane_i8_a1:
+; CHECK: .functype load_lane_i8_a1 (i32, v128) -> (v128)
+; CHECK-NEXT:  # %bb.0:
+; CHECK-NEXT:local.get 0
+; CHECK-NEXT:local.get 1
+; CHECK-NEXT:v128.load8_lane 0, 0
+; CHECK-NEXT:# fallthrough-return
+  %e = load i8, i8* %p, align 1
+  %v1 = insertelement <16 x i8> %v, i8 %e, i32 0
+  ret <16 x i8> %v1
+}
+
+; 2 is greater than the default alignment so it is ignored.
+define <16 x i8> @load_lane_i8_a2(i8* %p, <16 x i8> %v) {
+; CHECK-LABEL: load_lane_i8_a2:
+; CHECK: .functype load_lane_i8_a2 (i32, v128) -> (v128)
+; CHECK-NEXT:  # %bb.0:
+; CHECK-NEXT:local.get 0
+; CHECK-NEXT:local.get 1
+; CHECK-NEXT:v128.load8_lane 0, 0
+; CHECK-NEXT:# fallthrough-return
+  %e = load i8, i8* %p, align 2
+  %v1 = insertelement <16 x i8> %v, i8 %e, i32 0
+  ret <16 x i8> %v1
+}
+
 ; ==
 ; 8 x i16
 ; ==
@@ -394,6 +422,47 @@
   ret <8 x i16> %v2
 }
 
+define <8 x i16> @load_lane_i16_a1(i16* %p, <8 x i16> %v) {
+; CHECK-LABEL: load_lane_i16_a1:
+; CHECK: .functype load_lane_i16_a1 (i32, v128) -> (v128)
+; CHECK-NEXT:  # %bb.0:
+; CHECK-NEXT:local.get 0
+; CHECK-NEXT:local.get 1
+; CHECK-NEXT:v128.load16_lane 0:p2align=0, 0
+; CHECK-NEXT:# fallthrough-return
+  %e = load i16, i16* %p, align 1
+  %v1 = insertelement <8 x i16> %v, i16 %e, i32 0
+  ret <8 x i16> %v1
+}
+
+; 2 is the default alignment for v128.load16_lane so no attribute is needed.
+define <8 x i16> @load_lane_i16_a2(i16* %p, <8 x i16> %v) {
+; CHECK-LABEL: load_lane_i16_a2:
+; CHECK: .functype load_lane_i16_a2 (i32, v128) -> (v128)
+; CHECK-NEXT:  # %bb.0:
+; CHECK-NEXT:local.get 0
+; CHECK-NEXT:local.get 1
+; CHECK-NEXT:v128.load16_lane 0, 0
+; CHECK-NEXT:# fallthrough-return
+  %e = load i16, i16* %p, align 2
+  %v1 = insertelement <8 x i16> %v, i16 %e, i32 0
+  ret <8 x i16> %v1
+}
+
+; 4 is greater than the default alignment so it is ignored.
+define <8 x i16> @load_lane_i16_a4(i16* %p, <8 x i16> %v) {
+; CHECK-LABEL: load_lane_i16_a4:
+; CHECK: .functype load_lane_i16_a4 (i32, v128) -> (v128)
+; CHECK-NEXT:  # %bb.0:
+; CHECK-NEXT:local.get 0
+; CHECK-NEXT:local.get 1
+; CHECK-NEXT:v128.load16_lane 0, 0
+; CHECK-NEXT:# fallthrough-return
+  %e = load i16, i16* %p, align 4
+  %v1 = insertelement <8 x i16> %v, i16 %e, i32 0
+  ret <8 x i16> %v1
+}
+
 ; ==
 ; 4 x i32
 ; ==
@@ -667,6 +736,60 @@
   ret <4 x i32> %v2
 }
 
+define <4 x i32> @load_lane_i32_a1(i32* %p, <4 x i32> %v) {
+; CHECK-LABEL: load_lane_i32_a1:
+; CHECK: .functype load_lane_i32_a1 (i32, v128) -> (v128)
+; CHECK-NEXT:  # %bb.0:
+; CHECK-NEXT:local.get 0
+; CHECK-NEXT:local.get 1
+; CHECK-NEXT:v128.load32_lane 0:p2align=0, 0
+; CHECK-NEXT:# fallthrough-return
+  %e = load i32, i32* %p, align 1
+  %v1 = insertelement <4 x i32> %v, i32 %e, i32 0
+  ret <4 x i32> %v1
+}
+
+define <4 x i32> @load_lane_i32_a2(i32* %p, <4 x i32> %v) {
+; CHECK-LABEL: load_lane_i32_a2:
+; CHECK: .functype load_lane_i32_a2 (i32, v128) -> (v128)
+; CHECK-NEXT:  # %bb.0:
+; CHECK-NEXT:local.get 0
+; CHECK-NEXT:local.get 1
+; CHECK-NEXT:v128.load32_lane 0:p2align=1, 0
+; CHECK-NEXT:

[PATCH] D105907: [CallGraphSection] Add call graph section options and documentation

[Necip Fazil Yildiran via Phabricator via cfe-commits]

necipfazil updated this revision to Diff 358463.
necipfazil added a comment.

rebase, fix nits in docs


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105907

Files:
  clang/docs/CallGraphSection.rst
  clang/include/clang/Basic/CodeGenOptions.def
  clang/include/clang/Driver/Options.td
  clang/lib/CodeGen/BackendUtil.cpp
  clang/lib/Driver/ToolChains/Clang.cpp
  llvm/include/llvm/CodeGen/CommandFlags.h
  llvm/include/llvm/Target/TargetOptions.h
  llvm/lib/CodeGen/CommandFlags.cpp

Index: llvm/lib/CodeGen/CommandFlags.cpp
===
--- llvm/lib/CodeGen/CommandFlags.cpp
+++ llvm/lib/CodeGen/CommandFlags.cpp
@@ -86,6 +86,7 @@
 CGOPT(DebuggerKind, DebuggerTuningOpt)
 CGOPT(bool, EnableStackSizeSection)
 CGOPT(bool, EnableAddrsig)
+CGOPT(bool, EnableCallGraphSection)
 CGOPT(bool, EmitCallSiteInfo)
 CGOPT(bool, EnableMachineFunctionSplitter)
 CGOPT(bool, EnableDebugEntryValues)
@@ -407,6 +408,11 @@
   cl::init(false));
   CGBINDOPT(EnableAddrsig);
 
+  static cl::opt EnableCallGraphSection(
+  "call-graph-section", cl::desc("Emit a call graph section"),
+  cl::init(false));
+  CGBINDOPT(EnableCallGraphSection);
+
   static cl::opt EmitCallSiteInfo(
   "emit-call-site-info",
   cl::desc(
@@ -520,6 +526,7 @@
   Options.EmitStackSizeSection = getEnableStackSizeSection();
   Options.EnableMachineFunctionSplitter = getEnableMachineFunctionSplitter();
   Options.EmitAddrsig = getEnableAddrsig();
+  Options.EmitCallGraphSection = getEnableCallGraphSection();
   Options.EmitCallSiteInfo = getEmitCallSiteInfo();
   Options.EnableDebugEntryValues = getEnableDebugEntryValues();
   Options.PseudoProbeForProfiling = getPseudoProbeForProfiling();
Index: llvm/include/llvm/Target/TargetOptions.h
===
--- llvm/include/llvm/Target/TargetOptions.h
+++ llvm/include/llvm/Target/TargetOptions.h
@@ -127,11 +127,11 @@
   EmulatedTLS(false), ExplicitEmulatedTLS(false), EnableIPRA(false),
   EmitStackSizeSection(false), EnableMachineOutliner(false),
   EnableMachineFunctionSplitter(false), SupportsDefaultOutlining(false),
-  EmitAddrsig(false), EmitCallSiteInfo(false),
-  SupportsDebugEntryValues(false), EnableDebugEntryValues(false),
-  PseudoProbeForProfiling(false), ValueTrackingVariableLocations(false),
-  ForceDwarfFrameSection(false), XRayOmitFunctionIndex(false),
-  DebugStrictDwarf(false),
+  EmitAddrsig(false), EmitCallGraphSection(false),
+  EmitCallSiteInfo(false), SupportsDebugEntryValues(false),
+  EnableDebugEntryValues(false), PseudoProbeForProfiling(false),
+  ValueTrackingVariableLocations(false), ForceDwarfFrameSection(false),
+  XRayOmitFunctionIndex(false), DebugStrictDwarf(false),
   FPDenormalMode(DenormalMode::IEEE, DenormalMode::IEEE) {}
 
 /// DisableFramePointerElim - This returns true if frame pointer elimination
@@ -290,6 +290,9 @@
 /// to selectively generate basic block sections.
 std::shared_ptr BBSectionsFuncListBuf;
 
+/// Emit section containing call graph metadata.
+unsigned EmitCallGraphSection : 1;
+
 /// The flag enables call site info production. It is used only for debug
 /// info, and it is restricted only to optimized code. This can be used for
 /// something else, so that should be controlled in the frontend.
Index: llvm/include/llvm/CodeGen/CommandFlags.h
===
--- llvm/include/llvm/CodeGen/CommandFlags.h
+++ llvm/include/llvm/CodeGen/CommandFlags.h
@@ -122,6 +122,8 @@
 
 bool getEnableAddrsig();
 
+bool getEnableCallGraphSection();
+
 bool getEmitCallSiteInfo();
 
 bool getEnableMachineFunctionSplitter();
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -6413,6 +6413,10 @@
options::OPT_fno_apple_pragma_pack, false))
 CmdArgs.push_back("-fapple-pragma-pack");
 
+  if (Args.hasFlag(options::OPT_fcall_graph_section,
+   options::OPT_fno_call_graph_section, false))
+CmdArgs.push_back("-fcall-graph-section");
+
   if (Args.hasFlag(options::OPT_fxl_pragma_pack,
options::OPT_fno_xl_pragma_pack, RawTriple.isOSAIX()))
 CmdArgs.push_back("-fxl-pragma-pack");
Index: clang/lib/CodeGen/BackendUtil.cpp
===
--- clang/lib/CodeGen/BackendUtil.cpp
+++ clang/lib/CodeGen/BackendUtil.cpp
@@ -568,6 +568,7 @@
   Options.EmitStackSizeSection = CodeGenOpts.StackSizeSection;
   Options.StackUsageOutput = CodeGenOpts.StackUsageOutput;
   Options.EmitAddrsig = CodeGenOpts.Addrsig;
+  Options.EmitCallGraphSection = Code

[PATCH] D105939: [OpenMP] Add IDs to OpenMP remarks

[Joseph Huber via Phabricator via cfe-commits]

jhuber6 updated this revision to Diff 358461.
jhuber6 added a comment.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Adding test case for IDs.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105939

Files:
  clang/test/OpenMP/remarks_parallel_in_multiple_target_state_machines.c
  clang/test/OpenMP/remarks_parallel_in_target_state_machine.c
  llvm/include/llvm/Transforms/IPO/Attributor.h
  llvm/lib/Transforms/IPO/AttributorAttributes.cpp
  llvm/lib/Transforms/IPO/OpenMPOpt.cpp

Index: llvm/lib/Transforms/IPO/OpenMPOpt.cpp
===
--- llvm/lib/Transforms/IPO/OpenMPOpt.cpp
+++ llvm/lib/Transforms/IPO/OpenMPOpt.cpp
@@ -943,8 +943,7 @@
 return OR << ".";
   };
 
-  emitRemark(MergableCIs.front(),
- "OpenMPParallelRegionMerging", Remark);
+  emitRemark(MergableCIs.front(), "OMP150", Remark);
 
   Function *OriginalFn = BB->getParent();
   LLVM_DEBUG(dbgs() << TAG << "Merge " << MergableCIs.size()
@@ -1040,8 +1039,7 @@
 << ".";
 };
 if (CI != MergableCIs.front())
-  emitRemark(CI, "OpenMPParallelRegionMerging",
- Remark);
+  emitRemark(CI, "OMP150", Remark);
 
 CI->eraseFromParent();
   }
@@ -1210,8 +1208,7 @@
   auto Remark = [&](OptimizationRemark OR) {
 return OR << "Removing parallel region with no side-effects.";
   };
-  emitRemark(CI, "OpenMPParallelRegionDeletion",
- Remark);
+  emitRemark(CI, "OMP160", Remark);
 
   CGUpdater.removeCallSite(*CI);
   CI->eraseFromParent();
@@ -1317,7 +1314,7 @@
  << "Found thread data sharing on the GPU. "
  << "Expect degraded performance due to data globalization.";
 };
-emitRemark(CI, "OpenMPGlobalization", Remark);
+emitRemark(CI, "OMP112", Remark);
   }
 
   return false;
@@ -1598,7 +1595,7 @@
 return OR << "OpenMP runtime call "
   << ore::NV("OpenMPOptRuntime", RFI.Name) << " deduplicated.";
   };
-  emitRemark(&F, "OpenMPRuntimeDeduplicated", Remark);
+  emitRemark(&F, "OMP170", Remark);
 
   CGUpdater.removeCallSite(*CI);
   CI->replaceAllUsesWith(ReplVal);
@@ -1705,7 +1702,14 @@
 Function *F = I->getParent()->getParent();
 auto &ORE = OREGetter(F);
 
-ORE.emit([&]() { return RemarkCB(RemarkKind(DEBUG_TYPE, RemarkName, I)); });
+if (RemarkName.startswith("OMP"))
+  ORE.emit([&]() {
+return RemarkCB(RemarkKind(DEBUG_TYPE, RemarkName, I))
+   << " [" << RemarkName << "]";
+  });
+else
+  ORE.emit(
+  [&]() { return RemarkCB(RemarkKind(DEBUG_TYPE, RemarkName, I)); });
   }
 
   /// Emit a remark on a function.
@@ -1714,7 +1718,14 @@
   RemarkCallBack &&RemarkCB) const {
 auto &ORE = OREGetter(F);
 
-ORE.emit([&]() { return RemarkCB(RemarkKind(DEBUG_TYPE, RemarkName, F)); });
+if (RemarkName.startswith("OMP"))
+  ORE.emit([&]() {
+return RemarkCB(RemarkKind(DEBUG_TYPE, RemarkName, F))
+   << " [" << RemarkName << "]";
+  });
+else
+  ORE.emit(
+  [&]() { return RemarkCB(RemarkKind(DEBUG_TYPE, RemarkName, F)); });
   }
 
   /// The underlying module.
@@ -1883,8 +1894,7 @@
<< (UnknownUse ? "unknown" : "unexpected")
<< " ways. Will not attempt to rewrite the state machine.";
   };
-  emitRemark(F, "OpenMPParallelRegionInNonSPMD",
- Remark);
+  emitRemark(F, "OMP101", Remark);
   continue;
 }
 
@@ -1896,8 +1906,7 @@
 return ORA << "Parallel region is not called from a unique kernel. "
   "Will not attempt to rewrite the state machine.";
   };
-  emitRemark(
-  F, "OpenMPParallelRegionInMultipleKernesl", Remark);
+  emitRemark(F, "OMP102", Remark);
   continue;
 }
 
@@ -2584,8 +2593,7 @@
   << ((AllocSize->getZExtValue() != 1) ? " bytes " : " byte ")
   << "of shared memory";
   };
-  A.emitRemark(CB, "OpenMPReplaceGlobalization",
-   Remark);
+  A.emitRemark(CB, "OMP111", Remark);
 
   SharedMem->setAlignment(MaybeAlign(32));
 
@@ -2816,14 +2824,14 @@
 auto Remark = [&](OptimizationRemarkAnalysis ORA) {
   ORA << "Value has potential side effects preventing SPMD-mode "
  "execution";
-  if (auto *CI = dyn_cast(NonCompatibleI)) {
+  if (isa(NonCompatibleI)) {
 ORA << ". Add `__attribute__((assume(\"ompx_spmd_amenable\")))` to "
"the called function to override";
   }
   return ORA << ".";
 };
- 

[PATCH] D105909: [clang][CallGraphSection] Add type id metadata to indirect call and targets

[Matt Morehouse via Phabricator via cfe-commits]

morehouse added a comment.

I think we want a C++ test as well, with class functions, templates, etc.

Also, please rebase the patch onto any parent commits, so that it builds 
properly and the clang-tidy warnings go away.




Comment at: clang/lib/CodeGen/CGObjCMac.cpp:2288
+}
+  }
 

This is for Objective C?  I don't think we care about Objective C.



Comment at: clang/lib/CodeGen/CodeGenModule.cpp:1878
+   CodeGenOpts.SanitizeCfiCanonicalJumpTables) ||
+  CodeGenOpts.CallGraphSection) {
 if (auto *FD = dyn_cast(D)) {

Why do we need the type metadata on function definitions?



Comment at: clang/test/CodeGen/call-graph-section.c:4-7
+// RUN: -emit-llvm -o - %s | FileCheck --check-prefix=CHECK 
--check-prefix=ITANIUM %s
+
+// RUN: %clang_cc1 -triple x86_64-pc-windows-msvc -fcall-graph-section -S \
+// RUN: -emit-llvm -o - %s | FileCheck --check-prefix=CHECK --check-prefix=MS 
%s





Comment at: clang/test/CodeGen/call-graph-section.c:9
+
+// CHECK: define {{(dso_local )?}}void @foo({{.*}} !type 
[[TVOID_GENERALIZED:![0-9]+]]
+void foo() {

Nit:  I find this spacing more readable



Comment at: clang/test/CodeGen/call-graph-section.c:13
+
+// CHECK: define {{(dso_local )?}}void @bar({{.*}} !type 
[[TVOID_GENERALIZED:![0-9]+]]
+void bar() {

This recaptures the `TVOID_GENERALIZED` variable.  We should reuse the previous 
one instead: `[[TVOID_GENERALIZED]]`.

Same for other variables below.



Comment at: clang/test/CodeGen/call-graph-section.c:39
+  fp_qux(0, 0, 0);
+}
+

Should we also add a test with a C struct parameter?



Comment at: clang/test/CodeGen/call-graph-section.c:41
+
+// ITANIUM-DAG: [[TVOID_GENERALIZED]] = !{{{.*}}!"_ZTSFvE.generalized"}
+// ITANIUM-DAG: [[TPRIMITIVE_GENERALIZED]] = !{{{.*}}!"_ZTSFicfdE.generalized"}

What is the `{{.*}}` consuming here?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105909

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

[PATCH] D105869: [Driver] fix PowerPC SPE musl dynamic linker name

[Patrick Oppenlander via Phabricator via cfe-commits]

pattop added a comment.

Here is the corresponding gcc patch:

https://github.com/richfelker/musl-cross-make/commit/5b405688ee23df621e5b33911e2aa7b046ef632e


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105869

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

[PATCH] D105052: [clang][darwin] add support for Mac Catalyst availability

[Alex Lorenz via Phabricator via cfe-commits]

arphaman updated this revision to Diff 358457.
arphaman added a comment.

Sorry, took a bit longer than anticipated. I updated the patch to address 
reviewer's comments


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

https://reviews.llvm.org/D105052

Files:
  clang/include/clang/Basic/Attr.td
  clang/lib/Basic/Targets/OSTargets.cpp
  clang/lib/Sema/SemaDeclAttr.cpp
  clang/lib/Sema/SemaExpr.cpp
  clang/test/CodeGenObjC/availability-check-maccatalyst.m
  clang/test/FixIt/fixit-availability-maccatalyst.m
  clang/test/Sema/attr-availability-maccatalyst.c
  clang/test/SemaObjC/unguarded-availability-maccatalyst.m

Index: clang/test/SemaObjC/unguarded-availability-maccatalyst.m
===
--- /dev/null
+++ clang/test/SemaObjC/unguarded-availability-maccatalyst.m
@@ -0,0 +1,91 @@
+// RUN: %clang_cc1 -triple x86_64-apple-ios14-macabi -fblocks -fsyntax-only -verify %s
+// RUN: %clang_cc1 -xobjective-c++ -triple x86_64-apple-ios14-macabi -fblocks -fsyntax-only -verify %s
+
+// RUN: %clang_cc1 -triple x86_64-apple-ios14.1-macabi -DNO_WARNING -fblocks -fsyntax-only -verify %s
+
+#ifdef NO_WARNING
+  // expected-no-diagnostics
+#endif
+
+#define AVAILABLE_PREV __attribute__((availability(macCatalyst, introduced = 13.1)))
+#define AVAILABLE_CURRENT __attribute__((availability(macCatalyst, introduced = 14)))
+#define AVAILABLE_NEXT __attribute__((availability(macCatalyst, introduced = 14.1)))
+
+void previouslyAvailable() AVAILABLE_PREV;
+void currentlyAvailable() AVAILABLE_CURRENT;
+void willBeAvailabile() AVAILABLE_NEXT;
+#ifndef NO_WARNING
+// expected-note@-2 {{'willBeAvailabile' has been marked as being introduced in macCatalyst 14.1 here, but the deployment target is macCatalyst 14.0.0}}
+#endif
+
+
+typedef struct {
+
+} Record AVAILABLE_NEXT;
+#ifndef NO_WARNING
+// expected-note@-2 {{'Record' has been marked as being introduced in macCatalyst 14.1 here, but the deployment target is macCatalyst 14.0.0}}
+#endif
+
+AVAILABLE_PREV
+Record var;
+#ifndef NO_WARNING
+// expected-warning@-2 {{'Record' is only available on macCatalyst 14.1 or newer}}
+// expected-note@-3 {{annotate 'var' with an availability attribute to silence this warnin}}
+#endif
+
+AVAILABLE_NEXT
+Record var2;
+
+void test() {
+  previouslyAvailable();
+  currentlyAvailable();
+  willBeAvailabile();
+#ifndef NO_WARNING
+  // expected-warning@-2 {{'willBeAvailabile' is only available on macCatalyst 14.1 or newer}}
+  // expected-note@-3 {{enclose 'willBeAvailabile' in an @available check to silence this warning}}
+#endif
+  if (@available(maccatalyst 14.1, *))
+willBeAvailabile(); // OK
+  if (@available(ios 14.1, *))
+willBeAvailabile(); // Also OK
+  if (@available(macCatalyst 14.1, *))
+willBeAvailabile(); // OK
+}
+
+void previouslyAvailableIOS() __attribute__((availability(ios, introduced = 10)));
+void currentlyAvailableIOS() __attribute__((availability(ios, introduced = 14)));
+void willBeAvailabileIOS() __attribute__((availability(ios, introduced = 14.1)));
+#ifndef NO_WARNING
+// expected-note@-2 {{'willBeAvailabileIOS' has been marked as being introduced in macCatalyst 14.1 here, but the deployment target is macCatalyst 14.0.0}}
+#endif
+
+void testIOSAvailabilityAlsoWorks() {
+  previouslyAvailableIOS();
+  currentlyAvailableIOS();
+  willBeAvailabileIOS();
+#ifndef NO_WARNING
+  // expected-warning@-2 {{'willBeAvailabileIOS' is only available on macCatalyst 14.1 or newer}}
+  // expected-note@-3 {{enclose 'willBeAvailabileIOS' in an @available check to silence this warning}}
+#endif
+  if (@available(macCatalyst 14.1, *))
+willBeAvailabileIOS(); // OK
+  if (@available(ios 14.1, *))
+willBeAvailabile(); // Also OK
+}
+
+typedef struct {
+
+} Record2 __attribute__((availability(ios, introduced = 14.1)));
+#ifndef NO_WARNING
+// expected-note@-2 {{'Record2' has been marked as being introduced in macCatalyst 14.1 here, but the deployment target is macCatalyst 14.0.0}}
+#endif
+
+__attribute__((availability(ios, introduced = 10)))
+Record2 var11;
+#ifndef NO_WARNING
+// expected-warning@-2 {{'Record2' is only available on macCatalyst 14.1 or newer}}
+// expected-note@-3 {{annotate 'var11' with an availability attribute to silence this warnin}}
+#endif
+
+__attribute__((availability(ios, introduced = 14.1)))
+Record2 var12;
Index: clang/test/Sema/attr-availability-maccatalyst.c
===
--- /dev/null
+++ clang/test/Sema/attr-availability-maccatalyst.c
@@ -0,0 +1,131 @@
+// RUN: %clang_cc1 "-triple" "x86_64-apple-ios13.1-macabi" -fsyntax-only -verify %s
+// RUN: %clang_cc1 "-triple" "x86_64-apple-ios13.1-macabi" -fapplication-extension -D APPEXT -fsyntax-only -verify %s
+
+#ifdef APPEXT
+
+#define maccatalyst maccatalyst_app_extension
+#define macCatalyst maccatalyst_app_extension
+#define ios ios_app_extension
+
+#endif
+
+void f0(int) __attribute__((availability(maccatalyst,introduced=2

[PATCH] D105328: [Frontend] Only compile modules if not already finalized

[Ben Barham via Phabricator via cfe-commits]

bnbarham added inline comments.



Comment at: clang/lib/Frontend/CompilerInstance.cpp:1063
+<< ModuleName;
+return ImportingInstance.getFrontendOpts().AllowPCMWithCompilerErrors;
+  }

vsapsai wrote:
> Can we get in infinite loop with `AllowPCMWithCompilerErrors = true`? 
> Specifically, I'm thinking about the scenario
> 
> 1. `compileModuleAndReadAST` obtains a file lock and calls `compileModule`
> 2. `compileModule` calls `compileModuleImpl`
> 3. Module is finalized but `AllowPCMWithCompilerErrors` is true, so 
> `compileModuleImpl` returns true
> 4. `compileModule` returns true
> 5. `compileModuleAndReadAST` tries to read AST because compilation was 
> successful
> 6. AST is out of date, so `compileModuleAndReadAST` decides to try again, 
> goto 1
> 
> Haven't tried to reproduce it locally but even if this scenario is 
> impossible, a corresponding test case can be useful.
Nice catch, that does seem likely - I'll see if I can add a test for this.



Comment at: clang/lib/Serialization/ASTReader.cpp:2923
   if (!BuildDir || *BuildDir != M->Directory) {
-if ((ClientLoadCapabilities & ARR_OutOfDate) == 0)
+if (diagnoseOutOfDate(F.FileName, ClientLoadCapabilities))
   Diag(diag::err_imported_module_relocated)

vsapsai wrote:
> I'm thinking if in case of finalized modules diagnostic messages are good 
> enough. One concern is it won't be clear why a module wasn't rebuilt. It can 
> be already confusing for precompiled headers and I'm afraid we won't be able 
> to detect `isPCMFinal` code path without a debugger. Though I don't know how 
> bad that would be in practice.
> 
> Another concern is that retrying a compilation should succeed as for a new 
> process we have a new InMemoryModuleCache and `isPCMFinal` should return 
> false. So we might have non-deterministic behavior and some of the valid 
> error messages can seem to be non-deterministic and not reliable. I was 
> thinking about adding a note in case we are dealing with `isPCMFinal` to 
> distinguish these cases but not sure it is a good idea.
> I'm thinking if in case of finalized modules diagnostic messages are good 
> enough. One concern is it won't be clear why a module wasn't rebuilt. It can 
> be already confusing for precompiled headers and I'm afraid we won't be able 
> to detect `isPCMFinal` code path without a debugger. Though I don't know how 
> bad that would be in practice.

The error messages will mention a module in the module cache, which would be 
the main way to tell. We could add a note here as you suggest below, but I'm 
not quite sure what it would say... something about there being two modules 
with the same name?

> Another concern is that retrying a compilation should succeed as for a new 
> process we have a new InMemoryModuleCache and `isPCMFinal` should return 
> false. So we might have non-deterministic behavior and some of the valid 
> error messages can seem to be non-deterministic and not reliable. I was 
> thinking about adding a note in case we are dealing with `isPCMFinal` to 
> distinguish these cases but not sure it is a good idea.

The errors should be deterministic I believe. If one process has the issue then 
a new one will have the issue as well. For what it's worth, I don't think these 
crashes are possible from the clang frontend. They require messing around with 
search paths such that between two compilations in the same process, different 
modules are found.



Comment at: clang/lib/Serialization/ASTReader.cpp:5929
 
+bool ASTReader::diagnoseOutOfDate(StringRef ModuleFileName,
+  unsigned int ClientLoadCapabilities) {

vsapsai wrote:
> Based on the rest of the code in clang, the expectation for `diagnose...` 
> methods is to emit diagnostic in some cases. Personally, I'm often confused 
> what true/false means for these methods, so I'm thinking about renaming the 
> method to something like isRecoverableOutOfDateModule, 
> canRecoverOutOfDateModule or some such. Feel free to pick a name you believe 
> is appropriate, mine are just examples.
Fair enough, `canRecoverOutOfDateModule` sounds reasonable to me. Or maybe 
`canRecoverFromOutOfDate`?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105328

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

[PATCH] D105946: [PowerPC] Store, load, move from and to registers related builtins

[Albion Fung via Phabricator via cfe-commits]

Conanap created this revision.
Herald added subscribers: shchenz, kbarton, hiraditya, nemanjai.
Conanap requested review of this revision.
Herald added projects: clang, LLVM.
Herald added subscribers: llvm-commits, cfe-commits.

  This patch implements store, load, move from and to registers related

builtins. The patch aims to provide feature parady with xlC on AIX.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D105946

Files:
  clang/include/clang/Basic/BuiltinsPPC.def
  clang/lib/Basic/Targets/PPC.cpp
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/test/CodeGen/builtins-ppc-xlcompat-LoadReseve-StoreCond.c
  clang/test/CodeGen/builtins-ppc-xlcompat-move-tofrom-regs.c
  clang/test/CodeGen/builtins-ppc-xlcompat-prefetch.c
  llvm/include/llvm/IR/IntrinsicsPowerPC.td
  llvm/lib/Target/PowerPC/PPC.td
  llvm/lib/Target/PowerPC/PPCInstrInfo.td
  llvm/test/CodeGen/PowerPC/builtins-ppc-xlcompat-LoadReserve-StoreCond.ll
  llvm/test/CodeGen/builtins-ppc-xlcompat-move-tofrom-regs.ll
  llvm/test/CodeGen/builtins-ppc-xlcompat-prefetch.ll

Index: llvm/test/CodeGen/builtins-ppc-xlcompat-prefetch.ll
===
--- /dev/null
+++ llvm/test/CodeGen/builtins-ppc-xlcompat-prefetch.ll
@@ -0,0 +1,71 @@
+; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
+; RUN: llc -verify-machineinstrs -mtriple=powerpc64le-unknown-linux-gnu \
+; RUN:   -mcpu=pwr8 < %s | FileCheck %s
+; RUN: llc -verify-machineinstrs -mtriple=powerpc64-unknown-linux-gnu \
+; RUN:   -mcpu=pwr7 < %s | FileCheck %s
+; RUN: llc -verify-machineinstrs -mtriple=powerpc-unknown-aix \
+; RUN:   -mcpu=pwr7 < %s | FileCheck %s --check-prefix=CHECK-AIX
+; RUN: llc -verify-machineinstrs -mtriple=powerpc64-unknown-aix \
+; RUN:   -mcpu=pwr7 < %s | FileCheck %s --check-prefix=CHECK-AIX64
+
+declare void @llvm.ppc.dcbtstt(i8*)
+declare void @llvm.ppc.dcbtt(i8*)
+
+@vpa = external local_unnamed_addr global i8*, align 8
+
+define dso_local void @test_dcbtstt() {
+; CHECK-LABEL: test_dcbtstt:
+; CHECK:   # %bb.0: # %entry
+; CHECK-NEXT:addis 3, 2, .LC0@toc@ha
+; CHECK-NEXT:ld 3, .LC0@toc@l(3)
+; CHECK-NEXT:ld 3, 0(3)
+; CHECK-NEXT:dcbtstt 0, 3
+; CHECK-NEXT:blr
+;
+; CHECK-AIX-LABEL: test_dcbtstt:
+; CHECK-AIX:   # %bb.0: # %entry
+; CHECK-AIX-NEXT:lwz 3, L..C0(2) # @vpa
+; CHECK-AIX-NEXT:lwz 3, 0(3)
+; CHECK-AIX-NEXT:dcbtstt 0, 3
+; CHECK-AIX-NEXT:blr
+;
+; CHECK-AIX64-LABEL: test_dcbtstt:
+; CHECK-AIX64:   # %bb.0: # %entry
+; CHECK-AIX64-NEXT:ld 3, L..C0(2) # @vpa
+; CHECK-AIX64-NEXT:ld 3, 0(3)
+; CHECK-AIX64-NEXT:dcbtstt 0, 3
+; CHECK-AIX64-NEXT:blr
+entry:
+  %0 = load i8*, i8** @vpa, align 8
+  tail call void @llvm.ppc.dcbtstt(i8* %0)
+  ret void
+}
+
+
+define dso_local void @test_dcbtt() {
+; CHECK-LABEL: test_dcbtt:
+; CHECK:   # %bb.0: # %entry
+; CHECK-NEXT:addis 3, 2, .LC0@toc@ha
+; CHECK-NEXT:ld 3, .LC0@toc@l(3)
+; CHECK-NEXT:ld 3, 0(3)
+; CHECK-NEXT:dcbtt 0, 3
+; CHECK-NEXT:blr
+;
+; CHECK-AIX-LABEL: test_dcbtt:
+; CHECK-AIX:   # %bb.0: # %entry
+; CHECK-AIX-NEXT:lwz 3, L..C0(2) # @vpa
+; CHECK-AIX-NEXT:lwz 3, 0(3)
+; CHECK-AIX-NEXT:dcbtt 0, 3
+; CHECK-AIX-NEXT:blr
+;
+; CHECK-AIX64-LABEL: test_dcbtt:
+; CHECK-AIX64:   # %bb.0: # %entry
+; CHECK-AIX64-NEXT:ld 3, L..C0(2) # @vpa
+; CHECK-AIX64-NEXT:ld 3, 0(3)
+; CHECK-AIX64-NEXT:dcbtt 0, 3
+; CHECK-AIX64-NEXT:blr
+entry:
+  %0 = load i8*, i8** @vpa, align 8
+  tail call void @llvm.ppc.dcbtt(i8* %0)
+  ret void
+}
Index: llvm/test/CodeGen/builtins-ppc-xlcompat-move-tofrom-regs.ll
===
--- /dev/null
+++ llvm/test/CodeGen/builtins-ppc-xlcompat-move-tofrom-regs.ll
@@ -0,0 +1,46 @@
+; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
+; RUN: llc -verify-machineinstrs -mtriple=powerpc64le-unknown-linux-gnu \
+; RUN:   -mcpu=pwr8 < %s | FileCheck %s
+; RUN: llc -verify-machineinstrs -mtriple=powerpc64-unknown-linux-gnu \
+; RUN:   -mcpu=pwr7 < %s | FileCheck %s
+; RUN: llc -verify-machineinstrs -mtriple=powerpc-unknown-aix \
+; RUN:   -mcpu=pwr7 < %s | FileCheck %s --check-prefix=CHECK-AIX
+; RUN: llc -verify-machineinstrs -mtriple=powerpc64-unknown-aix \
+; RUN:   -mcpu=pwr7 < %s | FileCheck %s
+
+declare i32 @llvm.ppc.mftbu()
+declare i32 @llvm.ppc.mfmsr()
+
+define dso_local zeroext i32 @test_mftbu() {
+; CHECK-LABEL: test_mftbu:
+; CHECK:   # %bb.0: # %entry
+; CHECK-NEXT:mftbu 3
+; CHECK-NEXT:clrldi 3, 3, 32
+; CHECK-NEXT:blr
+;
+; CHECK-AIX-LABEL: test_mftbu:
+; CHECK-AIX:   # %bb.0: # %entry
+; CHECK-AIX-NEXT:mftbu 3
+; CHECK-AIX-NEXT:blr
+entry:
+  %0 = tail call i32 @llvm.ppc.mftbu()
+  ret i32 %0
+}
+
+define dso_local i64 @test_mfmsr() {
+; CHECK-LABEL: test_mfmsr:
+; CHECK:   # %bb.0: # %entry
+; CHECK-NEXT:mfmsr 3
+; CHECK-NEXT:clrldi 3, 3, 32
+; CHECK-NEXT:b

[PATCH] D105457: [clang] Refactor AST printing tests to share more infrastructure

[David Blaikie via Phabricator via cfe-commits]

dblaikie added a comment.

In D105457#2874783 , @nridge wrote:

> To be honest, I don't really understand this error. It seems to come from a 
> compile step (not a link step), and it comes from the assembler and says 
> "symbol ... is already defined"? I don't think I've seen an error like that 
> before. (Typically, errors about duplicate definitions would come from the 
> linker.)
>
> Any suggestions for what it might indicate or how to investigate are welcome.

Yeah, I'm with you there.

@dyung @glaubitz - perhaps you two could help with a reduced example of what 
causes this, it does look like a bug in the compiler (yeah, I'd at first 
assumed a bug in the standard library that caused a link error, but as @nridge 
pointed out it's not a link error but an assembly error - which really looks 
like a compiler bug to me) - but likely there's some room for a workaround if 
we knew what we were dealing with and how to workaround it reliably.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105457

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

[PATCH] D69764: [clang-format] Add East/West Const fixer capability

[MyDeveloperDay via Phabricator via cfe-commits]

MyDeveloperDay added a comment.

Because I don't want to move this review on other than to maintain it for 
future rebasing, I've created a new review for the concept of the new tool  
D105943: [clang-format++] Create a new variant of the clang-format tool to 
allow additional  code mutating behaviour such as East/West Const Fixer 


This is not what I wanted to do, but lets start here and see if people dislike 
the thought of a new tool more than they dislike the concept of putting it into 
clang-format in the first place.


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

https://reviews.llvm.org/D69764

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

[PATCH] D105943: [clang-format++] Create a new variant of the clang-format tool to allow additional code mutating behaviour such as East/West Const Fixer

[MyDeveloperDay via Phabricator via cfe-commits]

MyDeveloperDay created this revision.
MyDeveloperDay added reviewers: curdeius, HazardyKnusperkeks, aaron.ballman.
MyDeveloperDay added projects: clang-format, clang.
Herald added a subscriber: mgorny.
MyDeveloperDay requested review of this revision.

There has been much discussion about the relative merits of including East/West 
in the existing clang-format over in D69764: [clang-format] Add East/West Const 
fixer capability  on and off over the last 18 
months

It seem we could not get to a concencus if this functionality should/shouldn't 
exist in clang-format mainly on the grounds that it broke the fundamental 
belief that clang-format should not modify the code (a precedent that had 
already been broken with SortIncludes)

As a compromise I'm suggesting a new tool which allows the introduction of such 
rules that can alter the code as well as format it.  This allows those users 
who want to use this check to do so by switching to this binary.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D105943

Files:
  clang/docs/ClangFormatStyleOptions.rst
  clang/docs/ReleaseNotes.rst
  clang/include/clang/Format/Format.h
  clang/lib/Format/CMakeLists.txt
  clang/lib/Format/ContinuationIndenter.cpp
  clang/lib/Format/EastWestConstFixer.cpp
  clang/lib/Format/EastWestConstFixer.h
  clang/lib/Format/Format.cpp
  clang/lib/Format/FormatInternal.h
  clang/tools/CMakeLists.txt
  clang/tools/clang-format++/CMakeLists.txt
  clang/tools/clang-format++/ClangFormatPlusPlus.cpp
  clang/unittests/Format/FormatTest.cpp

Index: clang/unittests/Format/FormatTest.cpp
===
--- clang/unittests/Format/FormatTest.cpp
+++ clang/unittests/Format/FormatTest.cpp
@@ -39,7 +39,7 @@
 std::vector Ranges(1, tooling::Range(0, Code.size()));
 FormattingAttemptStatus Status;
 tooling::Replacements Replaces =
-reformat(Style, Code, Ranges, "", &Status);
+reformat(Style, Code, Ranges, "", &Status, true);
 if (CheckComplete != SC_DoNotCheck) {
   bool ExpectedCompleteFormat = CheckComplete == SC_ExpectComplete;
   EXPECT_EQ(ExpectedCompleteFormat, Status.FormatComplete)
@@ -18202,6 +18202,13 @@
   CHECK_PARSE("ContinuationIndentWidth: 11", ContinuationIndentWidth, 11u);
   CHECK_PARSE("CommentPragmas: '// abc$'", CommentPragmas, "// abc$");
 
+  Style.ConstPlacement = FormatStyle::CS_West;
+  CHECK_PARSE("ConstPlacement: Leave", ConstPlacement, FormatStyle::CS_Leave);
+  CHECK_PARSE("ConstPlacement: East", ConstPlacement, FormatStyle::CS_East);
+  CHECK_PARSE("ConstPlacement: West", ConstPlacement, FormatStyle::CS_West);
+  CHECK_PARSE("ConstPlacement: Right", ConstPlacement, FormatStyle::CS_East);
+  CHECK_PARSE("ConstPlacement: Left", ConstPlacement, FormatStyle::CS_West);
+
   Style.AlignConsecutiveAssignments = FormatStyle::ACS_Consecutive;
   CHECK_PARSE("AlignConsecutiveAssignments: None", AlignConsecutiveAssignments,
   FormatStyle::ACS_None);
@@ -22146,6 +22153,330 @@
   "}";
   EXPECT_EQ(Code, format(Code, Style));
 }
+
+TEST_F(FormatTest, EastWestConst) {
+  FormatStyle Style = getLLVMStyle();
+
+  // keep the const style unaltered
+  verifyFormat("const int a;", Style);
+  verifyFormat("const int *a;", Style);
+  verifyFormat("const int &a;", Style);
+  verifyFormat("const int &&a;", Style);
+  verifyFormat("int const b;", Style);
+  verifyFormat("int const *b;", Style);
+  verifyFormat("int const &b;", Style);
+  verifyFormat("int const &&b;", Style);
+  verifyFormat("int const *b const;", Style);
+  verifyFormat("int *const c;", Style);
+
+  verifyFormat("const Foo a;", Style);
+  verifyFormat("const Foo *a;", Style);
+  verifyFormat("const Foo &a;", Style);
+  verifyFormat("const Foo &&a;", Style);
+  verifyFormat("Foo const b;", Style);
+  verifyFormat("Foo const *b;", Style);
+  verifyFormat("Foo const &b;", Style);
+  verifyFormat("Foo const &&b;", Style);
+  verifyFormat("Foo const *b const;", Style);
+
+  verifyFormat("LLVM_NODISCARD const int &Foo();", Style);
+  verifyFormat("LLVM_NODISCARD int const &Foo();", Style);
+
+  verifyFormat("volatile const int *restrict;", Style);
+  verifyFormat("const volatile int *restrict;", Style);
+  verifyFormat("const int volatile *restrict;", Style);
+}
+
+TEST_F(FormatTest, EastConst) {
+  FormatStyle Style = getLLVMStyle();
+  Style.ConstPlacement = FormatStyle::CS_East;
+
+  verifyFormat("int const a;", Style);
+  verifyFormat("int const *a;", Style);
+  verifyFormat("int const &a;", Style);
+  verifyFormat("int const &&a;", Style);
+  verifyFormat("int const b;", Style);
+  verifyFormat("int const *b;", Style);
+  verifyFormat("int const &b;", Style);
+  verifyFormat("int const &&b;", Style);
+  verifyFormat("int const *b const;", Style);
+  verifyFormat("int *const c;", Style);
+
+  verifyFormat("Foo const a;", Style);
+  verifyFormat("Foo const *a;", Style);
+  verifyFormat("Foo const &a;", Style);
+  verifyForma

[PATCH] D102107: [OpenMP] Codegen aggregate for outlined function captures

[Alexey Bataev via Phabricator via cfe-commits]

ABataev added a comment.

In D102107#2874123 , @jdoerfert wrote:

> In D102107#2867693 , @ABataev wrote:
>
>> In D102107#2867670 , 
>> @josemonsalve2 wrote:
>>
>>> In D102107#2867417 , @ABataev 
>>> wrote:
>>>
 In D102107#2867382 , @jdoerfert 
 wrote:

> In D102107#2832740 , @ABataev 
> wrote:
>
>> In D102107#2832286 , 
>> @jdoerfert wrote:
>>
>>> In D102107#2824581 , @ABataev 
>>> wrote:
>>>
 In D102107#2823706 , 
 @jdoerfert wrote:

> In D102107#2821976 , 
> @ABataev wrote:
>
>> We used this kind of codegen initially but later found out that it 
>> causes a large overhead when gathering pointers into a record. What 
>> about hybrid scheme where the first args are passed as arguments and 
>> others (if any) are gathered into a record?
>
> I'm confused, maybe I misunderstand the problem. The parallel 
> function arguments need to go from the main thread to the workers 
> somehow, I don't see how this is done w/o a record. This patch makes 
> it explicit though.

 Pass it in a record for workers only? And use a hybrid scheme for all 
 other parallel regions.
>>>
>>> I still do not follow. What does it mean for workers only? What is a 
>>> hybrid scheme? And, probably most importantly, how would we not 
>>> eventually put everything into a record anyway?
>>
>> On the host you don’t need to put everything into a record, especially 
>> for small parallel regions. Pass some first args in registers and only 
>> the remaining args gather into the record. For workers just pass all 
>> args in the record.
>
> Could you please respond to my question so we make progress here. We 
> *always* have to pass things in a record, do you agree?

 On the GPU device, yes. And I'm absolutely fine with packing args for the 
 GPU device. But the patch packs the args not only for the GPU devices but 
 also for the host and other devices which may not require 
 packing/unpacking. For such devices/host better to avoid packing/unpacking 
 as it introduces overhead in many cases.
>>>
>>> Hi Alexey,
>>>
>>> Wouldn't you always need to pack to pass the arguments to the outlined 
>>> function? What is the benefit of avoiding packing the arguments in the 
>>> runtime call, if then you have to pack them for the outlined function?
>>>
>>> I would really appreciate an example, since I am just getting an 
>>> understanding of OpenMP in LLVM.
>>>
>>> Thanks!
>>
>> Hi, generally speaking, no, you don't need to pack them. Initially, we 
>> packed/unpacked args, but then decided not to do it.
>> Here is an example:
>>
>>   int a, b;
>>   #pragma omp parallel
>>printf("%d %d\n", a, b);
>>
>> What we generate currently is something like this:
>>
>>   %a = alloca i32
>>   %b = alloca i32
>>   call __kmpc_fork_call(..., @outlined, %a, %b)
>>   ...
>>internal @outlined(i32 *%a, i32 *%b) {
>>printf();
>>}
>>
>> `__kmpc_fork_call` inside calls `@outlined` function with the passed args.
>
> While on the user facing side this does not pack the arguments, we still do, 
> and that is the point. In the runtime `__kmp_fork_call` we do
>
>   for (i = argc - 1; i >= 0; --i)
>  *argv++ = va_arg(kmp_va_deref(ap), void *);  
>
> which packs the variadic arguments into a buffer. So eventually we have to 
> walk them and store them into a consecutive buffer. What
> happens before is that we pass some of them in registers but at the end of 
> the day we put them in memory. After all, that is what
> `extern int __kmp_invoke_microtask(microtask_t pkfn, int gtid, int npr, int 
> argc, void *argv[], ...`
> expects.

Ok, then it should be good for the host too. Would be good if you could check 
that it really does not affect the performance and then land it if so.

> If you believe we do not pack/unpack on the host, please walk me through 
> that. As far as I can tell, the "user facing side" might
> look like variadic calls all the way but that is not what is happening in the 
> runtime. Thus, there is no apparent reason to complicate
> the scheme. I'm also happy if you have timing results that indicate otherwise.




Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102107

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/c

[PATCH] D102875: [PowerPC] Add PowerPC compare and multiply related builtins and instrinsics for XL compatibility

[Victor Huang 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 rG18c19414eb70: [PowerPC] Add PowerPC compare and multiply 
related builtins and instrinsics for… (authored by NeHuang).

Changed prior to commit:
  https://reviews.llvm.org/D102875?vs=358397&id=358441#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102875

Files:
  clang/include/clang/Basic/BuiltinsPPC.def
  clang/lib/Basic/Targets/PPC.cpp
  clang/lib/Sema/SemaChecking.cpp
  clang/test/CodeGen/builtins-ppc-xlcompat-multiply-64bit-only.c
  clang/test/CodeGen/builtins-ppc-xlcompat-multiply.c
  clang/test/CodeGen/builtins-ppc-xlcompat-pwr9-64bit.c
  clang/test/CodeGen/builtins-ppc-xlcompat-pwr9-error.c
  clang/test/CodeGen/builtins-ppc-xlcompat-pwr9.c
  llvm/include/llvm/IR/IntrinsicsPowerPC.td
  llvm/lib/Target/PowerPC/PPCInstr64Bit.td
  llvm/lib/Target/PowerPC/PPCInstrInfo.td
  llvm/test/CodeGen/PowerPC/builtins-ppc-xlcompat-compare-64bit-only.ll
  llvm/test/CodeGen/PowerPC/builtins-ppc-xlcompat-compare.ll
  llvm/test/CodeGen/PowerPC/builtins-ppc-xlcompat-multiply-64bit-only.ll
  llvm/test/CodeGen/PowerPC/builtins-ppc-xlcompat-multiply.ll

Index: llvm/test/CodeGen/PowerPC/builtins-ppc-xlcompat-multiply.ll
===
--- /dev/null
+++ llvm/test/CodeGen/PowerPC/builtins-ppc-xlcompat-multiply.ll
@@ -0,0 +1,45 @@
+; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
+; RUN: llc -verify-machineinstrs -mtriple=powerpc64le-unknown-linux-gnu \
+; RUN:   -mcpu=pwr9 < %s | FileCheck %s --check-prefix=CHECK-64
+; RUN: llc -verify-machineinstrs -mtriple=powerpc64-unknown-linux-gnu \
+; RUN:   -mcpu=pwr9 < %s | FileCheck %s --check-prefix=CHECK-64
+; RUN: llc -verify-machineinstrs -mtriple=powerpc-unknown-aix \
+; RUN:   -mcpu=pwr9 < %s | FileCheck %s --check-prefix=CHECK-32
+; RUN: llc -verify-machineinstrs -mtriple=powerpc64-unknown-aix \
+; RUN:   -mcpu=pwr9 < %s | FileCheck %s --check-prefix=CHECK-64
+
+define dso_local signext i32 @test_builtin_ppc_mulhw(i32 %a, i32%b) {
+; CHECK-32-LABEL: test_builtin_ppc_mulhw:
+; CHECK-32:   # %bb.0: # %entry
+; CHECK-32-NEXT:mulhw 3, 3, 4
+; CHECK-32-NEXT:blr
+;
+; CHECK-64-LABEL: test_builtin_ppc_mulhw:
+; CHECK-64:   # %bb.0: # %entry
+; CHECK-64-NEXT:mulhw 3, 3, 4
+; CHECK-64-NEXT:extsw 3, 3
+; CHECK-64-NEXT:blr
+entry:
+  %0 = call i32 @llvm.ppc.mulhw(i32 %a, i32 %b)
+  ret i32 %0
+}
+
+declare i32 @llvm.ppc.mulhw(i32, i32)
+
+define dso_local zeroext i32 @test_builtin_ppc_mulhwu(i32 %a, i32%b) {
+; CHECK-32-LABEL: test_builtin_ppc_mulhwu:
+; CHECK-32:   # %bb.0: # %entry
+; CHECK-32-NEXT:mulhwu 3, 3, 4
+; CHECK-32-NEXT:blr
+;
+; CHECK-64-LABEL: test_builtin_ppc_mulhwu:
+; CHECK-64:   # %bb.0: # %entry
+; CHECK-64-NEXT:mulhwu 3, 3, 4
+; CHECK-64-NEXT:clrldi 3, 3, 32
+; CHECK-64-NEXT:blr
+entry:
+  %0 = call i32 @llvm.ppc.mulhwu(i32 %a, i32 %b)
+  ret i32 %0
+}
+
+declare i32 @llvm.ppc.mulhwu(i32, i32)
Index: llvm/test/CodeGen/PowerPC/builtins-ppc-xlcompat-multiply-64bit-only.ll
===
--- /dev/null
+++ llvm/test/CodeGen/PowerPC/builtins-ppc-xlcompat-multiply-64bit-only.ll
@@ -0,0 +1,68 @@
+; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
+; RUN: llc -verify-machineinstrs -mtriple=powerpc64le-unknown-linux-gnu \
+; RUN:   -mcpu=pwr9 < %s | FileCheck %s
+; RUN: llc -verify-machineinstrs -mtriple=powerpc64-unknown-linux-gnu \
+; RUN:   -mcpu=pwr9 < %s | FileCheck %s
+; RUN: llc -verify-machineinstrs -mtriple=powerpc64-unknown-aix \
+; RUN:   -mcpu=pwr9 < %s | FileCheck %s
+
+define dso_local i64 @test_builtin_ppc_mulhd(i64 %a, i64 %b) {
+; CHECK-LABEL: test_builtin_ppc_mulhd:
+; CHECK:   # %bb.0: # %entry
+; CHECK-NEXT:mulhd 3, 3, 4
+; CHECK-NEXT:blr
+entry:
+  %0 = call i64 @llvm.ppc.mulhd(i64 %a, i64 %b)
+  ret i64 %0
+}
+
+declare i64 @llvm.ppc.mulhd(i64, i64)
+
+define dso_local i64 @test_builtin_ppc_mulhdu(i64 %a, i64 %b) {
+; CHECK-LABEL: test_builtin_ppc_mulhdu:
+; CHECK:   # %bb.0: # %entry
+; CHECK-NEXT:mulhdu 3, 3, 4
+; CHECK-NEXT:blr
+entry:
+  %0 = call i64 @llvm.ppc.mulhdu(i64 %a, i64 %b)
+  ret i64 %0
+}
+
+declare i64 @llvm.ppc.mulhdu(i64, i64)
+
+define dso_local i64 @test_builtin_ppc_maddhd(i64 %a, i64 %b, i64 %c) {
+; CHECK-LABEL: test_builtin_ppc_maddhd:
+; CHECK:   # %bb.0: # %entry
+; CHECK-NEXT:maddhd 3, 3, 4, 5
+; CHECK-NEXT:blr
+entry:
+  %0 = call i64 @llvm.ppc.maddhd(i64 %a, i64 %b, i64 %c)
+  ret i64 %0
+}
+
+declare i64 @llvm.ppc.maddhd(i64, i64, i64)
+
+define dso_local i64 @test_builtin_ppc_maddhdu(i64 %a, i64 %b, i64 %c) {
+; CHECK-LABEL: test_builtin_ppc_maddhdu:
+; CHECK:   # %bb.0: # %entry
+; CHECK-NEXT:maddhdu 3, 3, 4, 5
+; CHECK-NEXT:blr

[clang] 18c1941 - [PowerPC] Add PowerPC compare and multiply related builtins and instrinsics for XL compatibility

[Victor Huang via cfe-commits]

Author: Victor Huang
Date: 2021-07-13T16:55:09-05:00
New Revision: 18c19414eb70578d4c487d6f4b0f438aead71d6a

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

LOG: [PowerPC] Add PowerPC compare and multiply related builtins and 
instrinsics for XL compatibility

This patch is in a series of patches to provide builtins for compatibility
with the XL compiler. This patch adds the builtins and instrisics for compare
and multiply related operations.

Reviewed By: nemanjai, #powerpc

Differential revision: https://reviews.llvm.org/D102875

Added: 
clang/test/CodeGen/builtins-ppc-xlcompat-multiply-64bit-only.c
clang/test/CodeGen/builtins-ppc-xlcompat-multiply.c
clang/test/CodeGen/builtins-ppc-xlcompat-pwr9-64bit.c
clang/test/CodeGen/builtins-ppc-xlcompat-pwr9-error.c
clang/test/CodeGen/builtins-ppc-xlcompat-pwr9.c
llvm/test/CodeGen/PowerPC/builtins-ppc-xlcompat-compare-64bit-only.ll
llvm/test/CodeGen/PowerPC/builtins-ppc-xlcompat-compare.ll
llvm/test/CodeGen/PowerPC/builtins-ppc-xlcompat-multiply-64bit-only.ll
llvm/test/CodeGen/PowerPC/builtins-ppc-xlcompat-multiply.ll

Modified: 
clang/include/clang/Basic/BuiltinsPPC.def
clang/lib/Basic/Targets/PPC.cpp
clang/lib/Sema/SemaChecking.cpp
llvm/include/llvm/IR/IntrinsicsPowerPC.td
llvm/lib/Target/PowerPC/PPCInstr64Bit.td
llvm/lib/Target/PowerPC/PPCInstrInfo.td

Removed: 




diff  --git a/clang/include/clang/Basic/BuiltinsPPC.def 
b/clang/include/clang/Basic/BuiltinsPPC.def
index 6a72cc089df7e..09769b3f974eb 100644
--- a/clang/include/clang/Basic/BuiltinsPPC.def
+++ b/clang/include/clang/Basic/BuiltinsPPC.def
@@ -71,6 +71,18 @@ BUILTIN(__builtin_ppc_fctiw, "dd", "")
 BUILTIN(__builtin_ppc_fctiwz, "dd", "")
 BUILTIN(__builtin_ppc_fctudz, "dd", "")
 BUILTIN(__builtin_ppc_fctuwz, "dd", "")
+// Compare
+BUILTIN(__builtin_ppc_cmpeqb, "LLiLLiLLi", "")
+BUILTIN(__builtin_ppc_cmprb, "iCIiii", "")
+BUILTIN(__builtin_ppc_setb, "LLiLLiLLi", "")
+// Multiply
+BUILTIN(__builtin_ppc_mulhd, "LLiLiLi", "")
+BUILTIN(__builtin_ppc_mulhdu, "ULLiULiULi", "")
+BUILTIN(__builtin_ppc_mulhw, "iii", "")
+BUILTIN(__builtin_ppc_mulhwu, "UiUiUi", "")
+BUILTIN(__builtin_ppc_maddhd, "LLiLLiLLiLLi", "")
+BUILTIN(__builtin_ppc_maddhdu, "ULLiULLiULLiULLi", "")
+BUILTIN(__builtin_ppc_maddld, "LLiLLiLLiLLi", "")
 
 BUILTIN(__builtin_ppc_get_timebase, "ULLi", "n")
 

diff  --git a/clang/lib/Basic/Targets/PPC.cpp b/clang/lib/Basic/Targets/PPC.cpp
index 514f1a031ae79..b79b30d7a4cdb 100644
--- a/clang/lib/Basic/Targets/PPC.cpp
+++ b/clang/lib/Basic/Targets/PPC.cpp
@@ -130,6 +130,16 @@ static void defineXLCompatMacros(MacroBuilder &Builder) {
   Builder.defineMacro("__fctiwz", "__builtin_ppc_fctiwz");
   Builder.defineMacro("__fctudz", "__builtin_ppc_fctudz");
   Builder.defineMacro("__fctuwz", "__builtin_ppc_fctuwz");
+  Builder.defineMacro("__cmpeqb", "__builtin_ppc_cmpeqb");
+  Builder.defineMacro("__cmprb", "__builtin_ppc_cmprb");
+  Builder.defineMacro("__setb", "__builtin_ppc_setb");
+  Builder.defineMacro("__mulhd", "__builtin_ppc_mulhd");
+  Builder.defineMacro("__mulhdu", "__builtin_ppc_mulhdu");
+  Builder.defineMacro("__mulhw", "__builtin_ppc_mulhw");
+  Builder.defineMacro("__mulhwu", "__builtin_ppc_mulhwu");
+  Builder.defineMacro("__maddhd", "__builtin_ppc_maddhd");
+  Builder.defineMacro("__maddhdu", "__builtin_ppc_maddhdu");
+  Builder.defineMacro("__maddld", "__builtin_ppc_maddld");
 }
 
 /// PPCTargetInfo::getTargetDefines - Return a set of the PowerPC-specific

diff  --git a/clang/lib/Sema/SemaChecking.cpp b/clang/lib/Sema/SemaChecking.cpp
index 062c7eb4a12e5..6c6f284d1f6e5 100644
--- a/clang/lib/Sema/SemaChecking.cpp
+++ b/clang/lib/Sema/SemaChecking.cpp
@@ -3269,6 +3269,13 @@ static bool isPPC_64Builtin(unsigned BuiltinID) {
   case PPC::BI__builtin_ppc_stdcx:
   case PPC::BI__builtin_ppc_tdw:
   case PPC::BI__builtin_ppc_trapd:
+  case PPC::BI__builtin_ppc_cmpeqb:
+  case PPC::BI__builtin_ppc_setb:
+  case PPC::BI__builtin_ppc_mulhd:
+  case PPC::BI__builtin_ppc_mulhdu:
+  case PPC::BI__builtin_ppc_maddhd:
+  case PPC::BI__builtin_ppc_maddhdu:
+  case PPC::BI__builtin_ppc_maddld:
 return true;
   }
   return false;
@@ -3360,6 +3367,17 @@ bool Sema::CheckPPCBuiltinFunctionCall(const TargetInfo 
&TI, unsigned BuiltinID,
   case PPC::BI__builtin_ppc_tw:
   case PPC::BI__builtin_ppc_tdw:
 return SemaBuiltinConstantArgRange(TheCall, 2, 0, 31);
+  case PPC::BI__builtin_ppc_cmpeqb:
+  case PPC::BI__builtin_ppc_setb:
+  case PPC::BI__builtin_ppc_maddhd:
+  case PPC::BI__builtin_ppc_maddhdu:
+  case PPC::BI__builtin_ppc_maddld:
+return SemaFeatureCheck(*this, TheCall, "isa-v30-instructions",
+diag::err_ppc_builtin_only_on_arch, "9");
+  case PPC::BI__builtin_ppc_cmprb:
+re

[PATCH] D105564: Fix for DWARF parsing to better handle auto return type for member functions

[Raphael Isemann via Phabricator via cfe-commits]

teemperor requested changes to this revision.
teemperor added a comment.
This revision now requires changes to proceed.

I guess Phabricator just sent this back to review automatically when you 
updated the diff? Just mark this as 'needs review' again when this is ready for 
review. I'll send this back in the meantime to clear my review queue.




Comment at: lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp:899
+  clang::QualType qt = ClangUtil::GetQualType(function_type);
+  const auto *ft = qt->getAs();
+  TypeSystemClang *ts =

unused variable



Comment at: lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp:919
   // Parse the function children for the parameters
-
   DWARFDIE decl_ctx_die;

unrelated change?


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

https://reviews.llvm.org/D105564

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

[PATCH] D105629: [TSan] Add SystemZ support

[Ilya Leoshkevich via Phabricator via cfe-commits]

iii updated this revision to Diff 358431.
iii added a comment.

- Fix style issues (seems like arc diff is linting only the top commit?).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105629

Files:
  clang/lib/Driver/ToolChains/Linux.cpp
  compiler-rt/cmake/config-ix.cmake
  compiler-rt/lib/sanitizer_common/sanitizer_common_interceptors.inc
  compiler-rt/lib/sanitizer_common/sanitizer_linux.cpp
  compiler-rt/lib/sanitizer_common/sanitizer_linux_libcdep.cpp
  compiler-rt/lib/sanitizer_common/sanitizer_platform_limits_posix.h
  compiler-rt/lib/tsan/CMakeLists.txt
  compiler-rt/lib/tsan/go/buildgo.sh
  compiler-rt/lib/tsan/rtl/tsan_interceptors_posix.cpp
  compiler-rt/lib/tsan/rtl/tsan_interface.h
  compiler-rt/lib/tsan/rtl/tsan_platform.h
  compiler-rt/lib/tsan/rtl/tsan_platform_linux.cpp
  compiler-rt/lib/tsan/rtl/tsan_platform_posix.cpp
  compiler-rt/lib/tsan/rtl/tsan_rtl.cpp
  compiler-rt/lib/tsan/rtl/tsan_rtl_s390x.S
  compiler-rt/test/tsan/CMakeLists.txt
  compiler-rt/test/tsan/ignore_lib0.cpp
  compiler-rt/test/tsan/ignore_lib1.cpp
  compiler-rt/test/tsan/ignore_lib5.cpp
  compiler-rt/test/tsan/map32bit.cpp
  compiler-rt/test/tsan/mmap_large.cpp
  llvm/lib/Transforms/Instrumentation/ThreadSanitizer.cpp
  llvm/utils/gn/secondary/compiler-rt/lib/tsan/BUILD.gn

Index: llvm/utils/gn/secondary/compiler-rt/lib/tsan/BUILD.gn
===
--- llvm/utils/gn/secondary/compiler-rt/lib/tsan/BUILD.gn
+++ llvm/utils/gn/secondary/compiler-rt/lib/tsan/BUILD.gn
@@ -125,6 +125,8 @@
 sources += [ "rtl/tsan_rtl_ppc64.S" ]
   } else if (target_cpu == "mips64") {
 sources += [ "rtl/tsan_rtl_mips64.S" ]
+  } else if (target_cpu == "s390x") {
+sources += [ "rtl/tsan_rtl_s390x.S" ]
   }
 
   # To be able to include sanitizer_common.
Index: llvm/lib/Transforms/Instrumentation/ThreadSanitizer.cpp
===
--- llvm/lib/Transforms/Instrumentation/ThreadSanitizer.cpp
+++ llvm/lib/Transforms/Instrumentation/ThreadSanitizer.cpp
@@ -312,12 +312,21 @@
 Type *Ty = Type::getIntNTy(M.getContext(), BitSize);
 Type *PtrTy = Ty->getPointerTo();
 SmallString<32> AtomicLoadName("__tsan_atomic" + BitSizeStr + "_load");
-TsanAtomicLoad[i] =
-M.getOrInsertFunction(AtomicLoadName, Attr, Ty, PtrTy, OrdTy);
+{
+  AttributeList AL = Attr;
+  AL = AL.addParamAttribute(M.getContext(), 1, Attribute::ZExt);
+  TsanAtomicLoad[i] =
+  M.getOrInsertFunction(AtomicLoadName, AL, Ty, PtrTy, OrdTy);
+}
 
 SmallString<32> AtomicStoreName("__tsan_atomic" + BitSizeStr + "_store");
-TsanAtomicStore[i] = M.getOrInsertFunction(
-AtomicStoreName, Attr, IRB.getVoidTy(), PtrTy, Ty, OrdTy);
+{
+  AttributeList AL = Attr;
+  AL = AL.addParamAttribute(M.getContext(), 1, Attribute::ZExt);
+  AL = AL.addParamAttribute(M.getContext(), 2, Attribute::ZExt);
+  TsanAtomicStore[i] = M.getOrInsertFunction(
+  AtomicStoreName, AL, IRB.getVoidTy(), PtrTy, Ty, OrdTy);
+}
 
 for (unsigned Op = AtomicRMWInst::FIRST_BINOP;
  Op <= AtomicRMWInst::LAST_BINOP; ++Op) {
@@ -340,24 +349,44 @@
   else
 continue;
   SmallString<32> RMWName("__tsan_atomic" + itostr(BitSize) + NamePart);
-  TsanAtomicRMW[Op][i] =
-  M.getOrInsertFunction(RMWName, Attr, Ty, PtrTy, Ty, OrdTy);
+  {
+AttributeList AL = Attr;
+AL = AL.addParamAttribute(M.getContext(), 1, Attribute::ZExt);
+AL = AL.addParamAttribute(M.getContext(), 2, Attribute::ZExt);
+TsanAtomicRMW[Op][i] =
+M.getOrInsertFunction(RMWName, AL, Ty, PtrTy, Ty, OrdTy);
+  }
 }
 
 SmallString<32> AtomicCASName("__tsan_atomic" + BitSizeStr +
   "_compare_exchange_val");
-TsanAtomicCAS[i] = M.getOrInsertFunction(AtomicCASName, Attr, Ty, PtrTy, Ty,
- Ty, OrdTy, OrdTy);
+{
+  AttributeList AL = Attr;
+  AL = AL.addParamAttribute(M.getContext(), 1, Attribute::ZExt);
+  AL = AL.addParamAttribute(M.getContext(), 2, Attribute::ZExt);
+  AL = AL.addParamAttribute(M.getContext(), 3, Attribute::ZExt);
+  AL = AL.addParamAttribute(M.getContext(), 4, Attribute::ZExt);
+  TsanAtomicCAS[i] = M.getOrInsertFunction(AtomicCASName, AL, Ty, PtrTy, Ty,
+   Ty, OrdTy, OrdTy);
+}
   }
   TsanVptrUpdate =
   M.getOrInsertFunction("__tsan_vptr_update", Attr, IRB.getVoidTy(),
 IRB.getInt8PtrTy(), IRB.getInt8PtrTy());
   TsanVptrLoad = M.getOrInsertFunction("__tsan_vptr_read", Attr,
IRB.getVoidTy(), IRB.getInt8PtrTy());
-  TsanAtomicThreadFence = M.getOrInsertFunction("__tsan_atomic_thread_fence",
-Attr

[PATCH] D105749: WebAssembly: Update datalayout to match fp128 ABI change

[Derek Schuff via Phabricator via cfe-commits]

dschuff added inline comments.



Comment at: llvm/test/CodeGen/WebAssembly/varargs.ll:5
 
-target datalayout = "e-m:e-p:32:32-i64:64-n32:64-S128"
-target triple = "wasm32-unknown-unknown"
+target triple = "wasm32-unknown-emscripten"
 

sunfish wrote:
> It appears this change means that we're no longer testing varargs on 
> wasm32-unknown-unknown. Please update this test so that it tests both triples.
Done in rGd4e2693a679927a62dd738dd3bba24863dcd290a


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105749

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

[PATCH] D102875: [PowerPC] Add PowerPC compare and multiply related builtins and instrinsics for XL compatibility

[Nemanja Ivanovic via Phabricator via cfe-commits]

nemanjai accepted this revision.
nemanjai added a comment.
This revision is now accepted and ready to land.

LGTM aside from a formatting nit.




Comment at: llvm/include/llvm/IR/IntrinsicsPowerPC.td:1574
+  : GCCBuiltin<"__builtin_ppc_cmprb">,
+Intrinsic<[llvm_i32_ty], [llvm_i32_ty, llvm_i32_ty, llvm_i32_ty], 
[IntrNoMem, ImmArg>]>;
+  def int_ppc_setb

Nit: This line looks too long. Some others below as well.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102875

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

[PATCH] D105726: Added fsanitize-address-instrument-via-callback, which controls if address sanitizer will always use a callback.

[Kirill Stoimenov via Phabricator via cfe-commits]

kstoimenov updated this revision to Diff 358422.
kstoimenov added a comment.

Modified UsersManual.rst and added a test. Couldn't find a relevant section in
AddressSanitizer.rst and adding a new one is outside of the scope of this 
change.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105726

Files:
  clang/docs/UsersManual.rst
  clang/include/clang/Driver/Options.td
  clang/include/clang/Driver/SanitizerArgs.h
  clang/lib/Driver/SanitizerArgs.cpp
  clang/test/CodeGen/asan-use-callbacks.cpp
  clang/test/Driver/fsanitize.c

Index: clang/test/Driver/fsanitize.c
===
--- clang/test/Driver/fsanitize.c
+++ clang/test/Driver/fsanitize.c
@@ -247,6 +247,13 @@
 // CHECK-ASAN-GLOBALS: -cc1{{.*}}-fsanitize-address-globals-dead-stripping
 // CHECK-NO-ASAN-GLOBALS-NOT: -cc1{{.*}}-fsanitize-address-globals-dead-stripping
 
+// RUN: %clang -target x86_64-linux-gnu -fsanitize-address-instrument-via-callback %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-ASAN-CALLBACK-WARN
+// CHECK-ASAN-CALLBACK-WARN: warning: argument unused during compilation: '-fsanitize-address-instrument-via-callback'
+// RUN: %clang -target x86_64-linux-gnu -fsanitize=address -fsanitize-address-instrument-via-callback %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-ASAN-CALLBACK-OK
+// CHECK-ASAN-CALLBACK-OK: "-mllvm" "-asan-instrumentation-with-call-threshold=0"
+// RUN: %clang -target x86_64-linux-gnu -fsanitize=address -fnosanitize-address-instrument-via-callback %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-ASAN-NOCALLBACK
+// CHECK-ASAN-NOCALLBACK-NOT: "-mllvm" "-asan-instrumentation-with-call-threshold=0"
+
 // RUN: %clang -target x86_64-linux-gnu -fsanitize=address -fsanitize-address-use-odr-indicator %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-ASAN-ODR-INDICATOR
 // RUN: %clang_cl --target=x86_64-windows -fsanitize=address -fsanitize-address-use-odr-indicator -### -- %s 2>&1 | FileCheck %s --check-prefix=CHECK-ASAN-ODR-INDICATOR
 // CHECK-ASAN-ODR-INDICATOR: -cc1{{.*}}-fsanitize-address-use-odr-indicator
Index: clang/test/CodeGen/asan-use-callbacks.cpp
===
--- /dev/null
+++ clang/test/CodeGen/asan-use-callbacks.cpp
@@ -0,0 +1,13 @@
+// RUN: %clang_cc1 -S -fsanitize=address -emit-llvm -o - -fsanitize=address %s \
+// RUN: | FileCheck %s --check-prefixes=CHECK-NOCALLBACK
+// RUN: %clang_cc1 -S -fsanitize=address -emit-llvm -o - -fsanitize=address %s \
+// RUN: -fsanitize-address-instrument-via-callback \
+// RUN: | FileCheck %s --check-prefixes=CHECK-CALLBACK
+
+
+// CHECK-NOCALLBACK-NOT: call{{.*}}@__asan_load4
+// CHECK-CALLBACK: call{{.*}}@__asan_load4
+
+int inc(int *p) {
+  return ++*p;
+}
Index: clang/lib/Driver/SanitizerArgs.cpp
===
--- clang/lib/Driver/SanitizerArgs.cpp
+++ clang/lib/Driver/SanitizerArgs.cpp
@@ -805,6 +805,11 @@
 options::OPT_fno_sanitize_address_poison_custom_array_cookie,
 AsanPoisonCustomArrayCookie);
 
+AsanInstrumentViaCallback =
+Args.hasFlag(options::OPT_fsanitize_address_instrument_via_callback,
+ options::OPT_fnosanitize_address_instrument_via_callback,
+ AsanInstrumentViaCallback);
+
 // As a workaround for a bug in gold 2.26 and earlier, dead stripping of
 // globals in ASan is disabled by default on ELF targets.
 // See https://sourceware.org/bugzilla/show_bug.cgi?id=19002
@@ -1118,6 +1123,11 @@
 CmdArgs.push_back("-asan-detect-invalid-pointer-sub");
   }
 
+  if (AsanInstrumentViaCallback) {
+CmdArgs.push_back("-mllvm");
+CmdArgs.push_back("-asan-instrumentation-with-call-threshold=0");
+  }
+
   // Only pass the option to the frontend if the user requested,
   // otherwise the frontend will just use the codegen default.
   if (AsanDtorKind != llvm::AsanDtorKind::Invalid) {
Index: clang/include/clang/Driver/SanitizerArgs.h
===
--- clang/include/clang/Driver/SanitizerArgs.h
+++ clang/include/clang/Driver/SanitizerArgs.h
@@ -44,6 +44,7 @@
   bool AsanUseOdrIndicator = false;
   bool AsanInvalidPointerCmp = false;
   bool AsanInvalidPointerSub = false;
+  bool AsanInstrumentViaCallback = false;
   llvm::AsanDtorKind AsanDtorKind = llvm::AsanDtorKind::Invalid;
   std::string HwasanAbi;
   bool LinkRuntimes = true;
Index: clang/include/clang/Driver/Options.td
===
--- clang/include/clang/Driver/Options.td
+++ clang/include/clang/Driver/Options.td
@@ -1558,6 +1558,12 @@
 Group,
 Flags<[CoreOption, NoXarchOption]>,
 HelpText<"Disable origins tracking in MemorySanitizer">;
+def fsaniti

[PATCH] D105876: OMPIRBuilder for Interop directive

[Alexey Bataev via Phabricator via cfe-commits]

ABataev added inline comments.



Comment at: clang/lib/CodeGen/CGStmtOpenMP.cpp:6310-6311
+  int DependClauseCount = 0;
+  for (const auto *DC : S.getClausesOfKind())
+DependClauseCount++;
+  assert(DependClauseCount <= 1 && "Multiple OMPDependClause not supported.");

This code can be removed.



Comment at: clang/lib/CodeGen/CGStmtOpenMP.cpp:6328
+
+  int HaveNowaitClause = 0;
+  if (S.getSingleClause())

`bool`



Comment at: clang/lib/CodeGen/CGStmtOpenMP.cpp:6329
+  int HaveNowaitClause = 0;
+  if (S.getSingleClause())
+HaveNowaitClause = 1;

`hasClausesOfKind` should be better



Comment at: clang/lib/CodeGen/CGStmtOpenMP.cpp:6334
+llvm::Value *InteropvarPtr =
+(EmitLValue(C->getInteropVar()).getAddress(*this)).getPointer();
+llvm::OMPInteropType InteropType = llvm::OMPInteropType::Unknown;

`EmitLValue(C->getInteropVar()).getPointer(*this);`.



Comment at: clang/lib/CodeGen/CGStmtOpenMP.cpp:6344-6345
+  } else if (const auto *C = S.getSingleClause()) {
+llvm::Value *InteropvarPtr =
+(EmitLValue(C->getInteropVar()).getAddress(*this)).getPointer();
+OMPBuilder.createOMPInteropDestroy(Builder, InteropvarPtr, Device,

`EmitLValue(C->getInteropVar()).getPointer(*this);`.



Comment at: clang/lib/CodeGen/CGStmtOpenMP.cpp:6350-6351
+  } else if (const auto *C = S.getSingleClause()) {
+llvm::Value *InteropvarPtr =
+(EmitLValue(C->getInteropVar()).getAddress(*this)).getPointer();
+OMPBuilder.createOMPInteropUse(Builder, InteropvarPtr, Device,

`EmitLValue(C->getInteropVar()).getPointer(*this);`.



Comment at: clang/lib/CodeGen/CGStmtOpenMP.cpp:6355-6358
+  } else if (HaveNowaitClause == true) {
+llvm_unreachable("Nowait clause is used separately in Interop Directive.");
+  } else {
+llvm_unreachable("Missing Interop clauses.");

Is this allowed at all? If not, better to turn it into an `assert`.



Comment at: clang/test/OpenMP/interop_irbuilder.cpp:1
+// RUN: %clang_cc1 -verify -fopenmp  -o -  %s
+

Actual codegen checks are missing


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105876

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

[PATCH] D105907: [CallGraphSection] Add call graph section options and documentation

[Necip Fazil Yildiran via Phabricator via cfe-commits]

necipfazil added inline comments.



Comment at: clang/docs/CallGraphSection.rst:58
+
+A type identifier may be repeated in different entries. The id value 0 is
+reserved for unknown and used for indirect targets with unknown type.

morehouse wrote:
> Why would a type ID be repeated?
Current implementation [1] creates a call graph section per function comdat 
group, to which the assembly printer writes the call graph entries related to 
the function.  This is done to enable dead-stripping of call graph entries.  
Consequently, the callsites from two functions may share the same type ID but 
appear as distinct entries as they will be written to distinct sections.  
Although they are merged to a single section by the linker, the type ID 
repetition persists since the linker only concatenates.

Eliminating this to ensure that type IDs are not repeated should only decrease 
the binary size overhead.

[1] https://reviews.llvm.org/D105916 , see 
MCObjectFileInfo::getCallGraphSection()



Comment at: clang/docs/CallGraphSection.rst:148
+  "foo", "int (char, void*)", "_ZTSFicPvE.generalized", "e3804d2a7f2b03fe"
+  "main", "int ()", "_ZTSFiE.generalized", "fa6809609a76afca"
+

morehouse wrote:
> Why quotes around these table headers/entries?
Quotes are placed to espace commas (actually, there is only one) in the table 
cells.  They are not visible in the output html.



Comment at: clang/docs/CallGraphSection.rst:160
+Notice that the current implementation may have seperate entries with the same
+type id as above.
+

morehouse wrote:
> Why is this?
Please see the response above.



Comment at: clang/docs/CallGraphSection.rst:174
+fa6809609a76afca 401130
+e3804d2a7f2b03fe 401110
+

morehouse wrote:
> Do we need to list functions that don't match any callsites (e.g., `main`)?
They may be needed for dynamically loaded objects whose functions are called 
indirectly outside the object.



Comment at: clang/docs/CallGraphSection.rst:183
+401130 40115b
+401170 4011b5
+

morehouse wrote:
> So this section is useful for constructing the call graph, but we don't 
> really need it for stack trace reconstruction, right?
For stack trace reconstruction, we need the full reverse call graph, thus, this 
section. Without this section, which function makes the indirect call is 
unknown.

During stack trace reconstruction, let's say we end up in a state where an 
indirect call is seen. To take another step, we need to know which function 
made this indirect call, so that we can continue the search through the callers 
of that function.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105907

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

[PATCH] D105937: [OpenMP] Encode `omp [...] assume[...]` assumptions with `omp[x]` prefix

[Johannes Doerfert via Phabricator via cfe-commits]

jdoerfert created this revision.
jdoerfert added a reviewer: jhuber6.
Herald added subscribers: guansong, bollu, yaxunl.
jdoerfert requested review of this revision.
Herald added subscribers: cfe-commits, sstefan1.
Herald added a project: clang.

Since these assumptions are coming from OpenMP it makes sense to mark
them as such in the generic IR encoding. Standardized assumptions will
be named

  omp_ASSUMPTION_NAME

and extensions will be named

  ompx_ASSUMPTION_NAME

which is the OpenMP 5.2 syntax for "extensions" of any kind.

This also matches what the OpenMP-Opt pass expects.

Summarized,

  #pragma omp [...] assume[s] no_parallelism

now generates the same IR assumption annotation as

  __attribute__((assume("omp_no_parallelism")))


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D105937

Files:
  clang/lib/Parse/ParseOpenMP.cpp
  clang/test/OpenMP/assumes_print.cpp
  clang/test/OpenMP/assumes_template_print.cpp

Index: clang/test/OpenMP/assumes_template_print.cpp
===
--- clang/test/OpenMP/assumes_template_print.cpp
+++ clang/test/OpenMP/assumes_template_print.cpp
@@ -17,7 +17,7 @@
 struct S {
   int a;
 // CHECK: template  struct S {
-// CHECK: void foo() __attribute__((assume("global_assumption"))) {
+// CHECK: void foo() __attribute__((assume("ompx_global_assumption"))) {
   void foo() {
 #pragma omp parallel
 {}
@@ -25,15 +25,15 @@
 };
 
 // CHECK: template<> struct S {
-// CHECK: void foo() __attribute__((assume("global_assumption"))) {
+// CHECK: void foo() __attribute__((assume("ompx_global_assumption"))) {
 
 #pragma omp begin assumes no_openmp
-// CHECK: void S_with_assumes_no_call() __attribute__((assume("no_openmp"))) __attribute__((assume("global_assumption"))) {
+// CHECK: void S_with_assumes_no_call() __attribute__((assume("omp_no_openmp"))) __attribute__((assume("ompx_global_assumption"))) {
 void S_with_assumes_no_call() {
   S s;
   s.a = 0;
 }
-// CHECK: void S_with_assumes_call() __attribute__((assume("no_openmp"))) __attribute__((assume("global_assumption"))) {
+// CHECK: void S_with_assumes_call() __attribute__((assume("omp_no_openmp"))) __attribute__((assume("ompx_global_assumption"))) {
 void S_with_assumes_call() {
   S s;
   s.a = 0;
@@ -42,7 +42,7 @@
 }
 #pragma omp end assumes
 
-// CHECK: void S_without_assumes() __attribute__((assume("global_assumption"))) {
+// CHECK: void S_without_assumes() __attribute__((assume("ompx_global_assumption"))) {
 void S_without_assumes() {
   S s;
   s.foo();
@@ -54,7 +54,7 @@
 template 
 struct P {
 // CHECK: template  struct P {
-// CHECK: void foo() __attribute__((assume("global_assumption"))) {
+// CHECK: void foo() __attribute__((assume("ompx_global_assumption"))) {
   int a;
   void foo() {
 #pragma omp parallel
@@ -65,21 +65,21 @@
 // TODO: Avoid the duplication here:
 
 // CHECK: template<> struct P {
-// CHECK: void foo() __attribute__((assume("global_assumption"))) __attribute__((assume("global_assumption"))) {
+// CHECK: void foo() __attribute__((assume("ompx_global_assumption"))) __attribute__((assume("ompx_global_assumption"))) {
 
-// CHECK: void P_without_assumes() __attribute__((assume("global_assumption"))) {
+// CHECK: void P_without_assumes() __attribute__((assume("ompx_global_assumption"))) {
 void P_without_assumes() {
   P p;
   p.foo();
 }
 
 #pragma omp begin assumes no_openmp
-// CHECK: void P_with_assumes_no_call() __attribute__((assume("no_openmp"))) __attribute__((assume("global_assumption"))) {
+// CHECK: void P_with_assumes_no_call() __attribute__((assume("omp_no_openmp"))) __attribute__((assume("ompx_global_assumption"))) {
 void P_with_assumes_no_call() {
   P p;
   p.a = 0;
 }
-// CHECK: void P_with_assumes_call() __attribute__((assume("no_openmp"))) __attribute__((assume("global_assumption"))) {
+// CHECK: void P_with_assumes_call() __attribute__((assume("omp_no_openmp"))) __attribute__((assume("ompx_global_assumption"))) {
 void P_with_assumes_call() {
   P p;
   p.a = 0;
Index: clang/test/OpenMP/assumes_print.cpp
===
--- clang/test/OpenMP/assumes_print.cpp
+++ clang/test/OpenMP/assumes_print.cpp
@@ -37,8 +37,8 @@
 }
 #pragma omp end assumes
 
-// CHECK: void foo() __attribute__((assume("no_openmp_routines"))) __attribute__((assume("no_openmp")))
-// CHECK: void bar() __attribute__((assume("range_bar_only"))) __attribute__((assume("range_bar_only_2"))) __attribute__((assume("no_openmp_routines"))) __attribute__((assume("no_openmp")))
-// CHECK: void baz() __attribute__((assume("1234"))) __attribute__((assume("no_openmp_routines"))) __attribute__((assume("no_openmp")))
+// CHECK: void foo() __attribute__((assume("omp_no_openmp_routines"))) __attribute__((assume("omp_no_openmp")))
+// CHECK: void bar() __attribute__((assume("ompx_range_bar_only"))) __attribute__((assume("ompx_range_bar_onl

[PATCH] D69764: [clang-format] Add East/West Const fixer capability

[Mateusz Furdyna via Phabricator via cfe-commits]

furdyna added a comment.

> I think its worth mentioning, that my personal preference would STILL be to 
> land this inside clang-format with default configuration of "OFF", 
> I would be interested to know how many people would be unhappy if we stated 
> that "sorting includes" and "namespace comments" had to be removed from 
> clang-format and into the new tool!
> So you know, I'm pushing because I'm being ask privately to land this, 
> because I assume people want to use it, but maybe don't want to voice their 
> opinions publicly.

I was a quiet observer up to this point, but I hope that my voice will help 
asses "what community wants", at least as an additional sample point. I also 
hope that the "community" is not only defined here as "open-source projects", 
but also all those poor souls working for closed-source projects ;)

I started observing this review when I was still working for another company 
and we were really interested in this feature. We were using clang-format 
extensively on several multi-milion LOC projects with total number of 
developers going into hundreds. "sorting includes" and "namespace comments" 
were one of the features that we enabled in our code bases as soon as they 
landed. We even quietly helped to improve include sorting here, in 
clang-format, squashing some bugs or extending the use-cases. We had those 
features enabled even with known limitations because clang-format in such large 
projects is not only a "simple whitespace formatting tool" - it becomes 
emotionless policing tool and time-saver during code reviews.

It had never crossed our minds that "sorting includes" or "namespace comments" 
should be separate tools. And if we did create separate tools as opposed to 
extending clang-format, I am 90% sure they would stay closed behind corporate 
doors. Another point of view is how easy it is to integrate clang-format as an 
existing well-known tool into various IDEs vs integrating a set of separate 
code-formatting programs that can have their own amusing side-effects when 
launched in different order.

> land this inside clang-format with default configuration of "OFF",

yes please. IMHO merging this and letting it mature over time as people use it 
is the best way forward vs risking various forks to be maintained by teams 
internally and spooking potential contributors

> I would be interested to know how many people would be unhappy

at least a few hundreds

> because I assume people want to use it

a cure for that itch, yes


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

https://reviews.llvm.org/D69764

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

[PATCH] D105930: [PowerPC] Implement XL compact math builtins

[Lei Huang via Phabricator via cfe-commits]

lei updated this revision to Diff 358409.
lei added a comment.

update tc to only check for pwr7 and up


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105930

Files:
  clang/include/clang/Basic/BuiltinsPPC.def
  clang/lib/Basic/Targets/PPC.cpp
  clang/lib/Sema/SemaChecking.cpp
  clang/test/CodeGen/builtins-ppc-xlcompat-error.c
  clang/test/CodeGen/builtins-ppc-xlcompat-math.c
  clang/test/CodeGen/builtins-ppc-xlcompat-pwr9-64bit.c
  clang/test/CodeGen/builtins-ppc-xlcompat-pwr9.c
  llvm/include/llvm/IR/IntrinsicsPowerPC.td
  llvm/lib/Target/PowerPC/PPCInstrInfo.td
  llvm/lib/Target/PowerPC/PPCInstrVSX.td
  llvm/test/CodeGen/PowerPC/builtins-ppc-xlcompat-math.ll
  llvm/test/CodeGen/PowerPC/builtins-ppc-xlcompat-pwr9-64bit.ll
  llvm/test/CodeGen/PowerPC/builtins-ppc-xlcompat-pwr9.ll

Index: llvm/test/CodeGen/PowerPC/builtins-ppc-xlcompat-pwr9.ll
===
--- /dev/null
+++ llvm/test/CodeGen/PowerPC/builtins-ppc-xlcompat-pwr9.ll
@@ -0,0 +1,27 @@
+; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
+; RUN: llc -verify-machineinstrs -mtriple=powerpc64le-unknown-linux-gnu \
+; RUN:   -mcpu=pwr9 < %s | FileCheck %s
+; RUN: llc -verify-machineinstrs -mtriple=powerpc64-unknown-linux-gnu \
+; RUN:   -mcpu=pwr9 < %s | FileCheck %s
+; RUN: llc -verify-machineinstrs -mtriple=powerpc64-unknown-aix \
+; RUN:   -mcpu=pwr9 < %s | FileCheck %s
+; RUN: llc -verify-machineinstrs -mtriple=powerpc-unknown-aix \
+; RUN:   -mcpu=pwr9 < %s | FileCheck %s --check-prefix=CHECK-32BIT
+
+define dso_local zeroext i32 @extract_exp(double %d) local_unnamed_addr {
+; CHECK-LABEL: extract_exp:
+; CHECK:   # %bb.0: # %entry
+; CHECK-NEXT:xsxexpdp 3, 1
+; CHECK-NEXT:clrldi 3, 3, 32
+; CHECK-NEXT:blr
+;
+; CHECK-32BIT-LABEL: extract_exp:
+; CHECK-32BIT:   # %bb.0: # %entry
+; CHECK-32BIT-NEXT:xsxexpdp 3, 1
+; CHECK-32BIT-NEXT:# kill: def $r3 killed $r3 killed $x3
+; CHECK-32BIT-NEXT:blr
+entry:
+  %0 = tail call i32 @llvm.ppc.extract.exp(double %d)
+  ret i32 %0
+}
+declare i32 @llvm.ppc.extract.exp(double)
Index: llvm/test/CodeGen/PowerPC/builtins-ppc-xlcompat-pwr9-64bit.ll
===
--- /dev/null
+++ llvm/test/CodeGen/PowerPC/builtins-ppc-xlcompat-pwr9-64bit.ll
@@ -0,0 +1,31 @@
+; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
+; RUN: llc -verify-machineinstrs -mtriple=powerpc64le-unknown-linux-gnu \
+; RUN:   -mcpu=pwr9 < %s | FileCheck %s
+; RUN: llc -verify-machineinstrs -mtriple=powerpc64-unknown-linux-gnu \
+; RUN:   -mcpu=pwr9 < %s | FileCheck %s
+; RUN: llc -verify-machineinstrs -mtriple=powerpc64-unknown-aix \
+; RUN:   -mcpu=pwr9 < %s | FileCheck %s
+
+define dso_local i64 @extract_sig(double %d) local_unnamed_addr {
+; CHECK-LABEL: extract_sig:
+; CHECK:   # %bb.0: # %entry
+; CHECK-NEXT:xsxsigdp 3, 1
+; CHECK-NEXT:blr
+entry:
+  %0 = tail call i64 @llvm.ppc.extract.sig(double %d)
+  ret i64 %0
+}
+declare i64 @llvm.ppc.extract.sig(double)
+
+define dso_local double @insert_exp(double %d, i64 %ull) local_unnamed_addr {
+; CHECK-LABEL: insert_exp:
+; CHECK:   # %bb.0: # %entry
+; CHECK-NEXT:mffprd 3, 1
+; CHECK-NEXT:xsiexpdp 1, 3, 4
+; CHECK-NEXT:# kill: def $f1 killed $f1 killed $vsl1
+; CHECK-NEXT:blr
+entry:
+  %0 = tail call double @llvm.ppc.insert.exp(double %d, i64 %ull)
+  ret double %0
+}
+declare double @llvm.ppc.insert.exp(double, i64)
Index: llvm/test/CodeGen/PowerPC/builtins-ppc-xlcompat-math.ll
===
--- /dev/null
+++ llvm/test/CodeGen/PowerPC/builtins-ppc-xlcompat-math.ll
@@ -0,0 +1,199 @@
+; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
+; RUN: llc -verify-machineinstrs -mtriple=powerpc64le-unknown-linux-gnu < %s |\
+; RUN:   FileCheck %s --check-prefix=CHECK-PWR8
+; RUN: llc -verify-machineinstrs -mtriple=powerpc64-unknown-linux-gnu \
+; RUN:   -mcpu=pwr7 < %s | FileCheck %s --check-prefix=CHECK-PWR7
+; RUN: llc -verify-machineinstrs -mtriple=powerpc64-unknown-aix -mcpu=pwr7 \
+; RUN:   < %s | FileCheck %s --check-prefix=CHECK-PWR7
+; RUN: llc -verify-machineinstrs -mtriple=powerpc-unknown-aix -mcpu=pwr8 < %s |\
+; RUN:   FileCheck %s --check-prefix=CHECK-PWR8
+
+; Function Attrs: nounwind uwtable
+define dso_local void @mtfsb0() local_unnamed_addr #0 {
+; CHECK-PWR8-LABEL: mtfsb0:
+; CHECK-PWR8:   # %bb.0: # %entry
+; CHECK-PWR8-NEXT:mtfsb0 10
+; CHECK-PWR8-NEXT:blr
+;
+; CHECK-PWR7-LABEL: mtfsb0:
+; CHECK-PWR7:   # %bb.0: # %entry
+; CHECK-PWR7-NEXT:mtfsb0 10
+; CHECK-PWR7-NEXT:blr
+entry:
+  tail call void @llvm.ppc.mtfsb0(i32 10)
+  ret void
+}
+
+; Function Attrs: nounwind
+declare void @llvm.ppc.mtfsb0(i32)
+
+; Function Attrs: nounwind uwtable
+define dso_local void @mtfsb1() loc

[PATCH] D102875: [PowerPC] Add PowerPC compare and multiply related builtins and instrinsics for XL compatibility

[Victor Huang via Phabricator via cfe-commits]

NeHuang updated this revision to Diff 358397.
NeHuang marked 4 inline comments as done.
NeHuang added a comment.

Addressed review comments from Nemanja.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102875

Files:
  clang/include/clang/Basic/BuiltinsPPC.def
  clang/lib/Basic/Targets/PPC.cpp
  clang/lib/Sema/SemaChecking.cpp
  clang/test/CodeGen/builtins-ppc-xlcompat-multiply-64bit-only.c
  clang/test/CodeGen/builtins-ppc-xlcompat-multiply.c
  clang/test/CodeGen/builtins-ppc-xlcompat-pwr9-64bit.c
  clang/test/CodeGen/builtins-ppc-xlcompat-pwr9-error.c
  clang/test/CodeGen/builtins-ppc-xlcompat-pwr9.c
  llvm/include/llvm/IR/IntrinsicsPowerPC.td
  llvm/lib/Target/PowerPC/PPCInstr64Bit.td
  llvm/lib/Target/PowerPC/PPCInstrInfo.td
  llvm/test/CodeGen/PowerPC/builtins-ppc-xlcompat-compare-64bit-only.ll
  llvm/test/CodeGen/PowerPC/builtins-ppc-xlcompat-compare.ll
  llvm/test/CodeGen/PowerPC/builtins-ppc-xlcompat-multiply-64bit-only.ll
  llvm/test/CodeGen/PowerPC/builtins-ppc-xlcompat-multiply.ll

Index: llvm/test/CodeGen/PowerPC/builtins-ppc-xlcompat-multiply.ll
===
--- /dev/null
+++ llvm/test/CodeGen/PowerPC/builtins-ppc-xlcompat-multiply.ll
@@ -0,0 +1,45 @@
+; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
+; RUN: llc -verify-machineinstrs -mtriple=powerpc64le-unknown-linux-gnu \
+; RUN:   -mcpu=pwr9 < %s | FileCheck %s --check-prefix=CHECK-64
+; RUN: llc -verify-machineinstrs -mtriple=powerpc64-unknown-linux-gnu \
+; RUN:   -mcpu=pwr9 < %s | FileCheck %s --check-prefix=CHECK-64
+; RUN: llc -verify-machineinstrs -mtriple=powerpc-unknown-aix \
+; RUN:   -mcpu=pwr9 < %s | FileCheck %s --check-prefix=CHECK-32
+; RUN: llc -verify-machineinstrs -mtriple=powerpc64-unknown-aix \
+; RUN:   -mcpu=pwr9 < %s | FileCheck %s --check-prefix=CHECK-64
+
+define dso_local signext i32 @test_builtin_ppc_mulhw(i32 %a, i32%b) {
+; CHECK-32-LABEL: test_builtin_ppc_mulhw:
+; CHECK-32:   # %bb.0: # %entry
+; CHECK-32-NEXT:mulhw 3, 3, 4
+; CHECK-32-NEXT:blr
+;
+; CHECK-64-LABEL: test_builtin_ppc_mulhw:
+; CHECK-64:   # %bb.0: # %entry
+; CHECK-64-NEXT:mulhw 3, 3, 4
+; CHECK-64-NEXT:extsw 3, 3
+; CHECK-64-NEXT:blr
+entry:
+  %0 = call i32 @llvm.ppc.mulhw(i32 %a, i32 %b)
+  ret i32 %0
+}
+
+declare i32 @llvm.ppc.mulhw(i32, i32)
+
+define dso_local zeroext i32 @test_builtin_ppc_mulhwu(i32 %a, i32%b) {
+; CHECK-32-LABEL: test_builtin_ppc_mulhwu:
+; CHECK-32:   # %bb.0: # %entry
+; CHECK-32-NEXT:mulhwu 3, 3, 4
+; CHECK-32-NEXT:blr
+;
+; CHECK-64-LABEL: test_builtin_ppc_mulhwu:
+; CHECK-64:   # %bb.0: # %entry
+; CHECK-64-NEXT:mulhwu 3, 3, 4
+; CHECK-64-NEXT:clrldi 3, 3, 32
+; CHECK-64-NEXT:blr
+entry:
+  %0 = call i32 @llvm.ppc.mulhwu(i32 %a, i32 %b)
+  ret i32 %0
+}
+
+declare i32 @llvm.ppc.mulhwu(i32, i32)
Index: llvm/test/CodeGen/PowerPC/builtins-ppc-xlcompat-multiply-64bit-only.ll
===
--- /dev/null
+++ llvm/test/CodeGen/PowerPC/builtins-ppc-xlcompat-multiply-64bit-only.ll
@@ -0,0 +1,68 @@
+; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
+; RUN: llc -verify-machineinstrs -mtriple=powerpc64le-unknown-linux-gnu \
+; RUN:   -mcpu=pwr9 < %s | FileCheck %s
+; RUN: llc -verify-machineinstrs -mtriple=powerpc64-unknown-linux-gnu \
+; RUN:   -mcpu=pwr9 < %s | FileCheck %s
+; RUN: llc -verify-machineinstrs -mtriple=powerpc64-unknown-aix \
+; RUN:   -mcpu=pwr9 < %s | FileCheck %s
+
+define dso_local i64 @test_builtin_ppc_mulhd(i64 %a, i64 %b) {
+; CHECK-LABEL: test_builtin_ppc_mulhd:
+; CHECK:   # %bb.0: # %entry
+; CHECK-NEXT:mulhd 3, 3, 4
+; CHECK-NEXT:blr
+entry:
+  %0 = call i64 @llvm.ppc.mulhd(i64 %a, i64 %b)
+  ret i64 %0
+}
+
+declare i64 @llvm.ppc.mulhd(i64, i64)
+
+define dso_local i64 @test_builtin_ppc_mulhdu(i64 %a, i64 %b) {
+; CHECK-LABEL: test_builtin_ppc_mulhdu:
+; CHECK:   # %bb.0: # %entry
+; CHECK-NEXT:mulhdu 3, 3, 4
+; CHECK-NEXT:blr
+entry:
+  %0 = call i64 @llvm.ppc.mulhdu(i64 %a, i64 %b)
+  ret i64 %0
+}
+
+declare i64 @llvm.ppc.mulhdu(i64, i64)
+
+define dso_local i64 @test_builtin_ppc_maddhd(i64 %a, i64 %b, i64 %c) {
+; CHECK-LABEL: test_builtin_ppc_maddhd:
+; CHECK:   # %bb.0: # %entry
+; CHECK-NEXT:maddhd 3, 3, 4, 5
+; CHECK-NEXT:blr
+entry:
+  %0 = call i64 @llvm.ppc.maddhd(i64 %a, i64 %b, i64 %c)
+  ret i64 %0
+}
+
+declare i64 @llvm.ppc.maddhd(i64, i64, i64)
+
+define dso_local i64 @test_builtin_ppc_maddhdu(i64 %a, i64 %b, i64 %c) {
+; CHECK-LABEL: test_builtin_ppc_maddhdu:
+; CHECK:   # %bb.0: # %entry
+; CHECK-NEXT:maddhdu 3, 3, 4, 5
+; CHECK-NEXT:blr
+entry:
+  %0 = call i64 @llvm.ppc.maddhdu(i64 %a, i64 %b, i64 %c)
+  ret i64 %0
+}
+
+declare i64 @llvm.ppc.maddhdu(i64, i64, i64)
+
+define dso_local i64 @test_builtin_ppc_maddld(i64 %a, i64 %b, 

[PATCH] D105907: [CallGraphSection] Add call graph section options and documentation

[Matt Morehouse via Phabricator via cfe-commits]

morehouse added inline comments.



Comment at: clang/docs/CallGraphSection.rst:58
+
+A type identifier may be repeated in different entries. The id value 0 is
+reserved for unknown and used for indirect targets with unknown type.

Why would a type ID be repeated?



Comment at: clang/docs/CallGraphSection.rst:61
+
+As of now, only supported format version is described above and has version
+number 0.





Comment at: clang/docs/CallGraphSection.rst:69
+The mapping from a type to an identifier is an ABI detail.
+In the current experimental implementation, the identifier of type T is
+computed as follows:





Comment at: clang/docs/CallGraphSection.rst:148
+  "foo", "int (char, void*)", "_ZTSFicPvE.generalized", "e3804d2a7f2b03fe"
+  "main", "int ()", "_ZTSFiE.generalized", "fa6809609a76afca"
+

Why quotes around these table headers/entries?



Comment at: clang/docs/CallGraphSection.rst:160
+Notice that the current implementation may have seperate entries with the same
+type id as above.
+

Why is this?



Comment at: clang/docs/CallGraphSection.rst:174
+fa6809609a76afca 401130
+e3804d2a7f2b03fe 401110
+

Do we need to list functions that don't match any callsites (e.g., `main`)?



Comment at: clang/docs/CallGraphSection.rst:183
+401130 40115b
+401170 4011b5
+

So this section is useful for constructing the call graph, but we don't really 
need it for stack trace reconstruction, right?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105907

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

[PATCH] D20689: [clang-tidy] Add 'readability-suspicious-call-argument' check

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman accepted this revision.
aaron.ballman added a comment.

In D20689#2874473 , @whisperity wrote:

> Bump. 🙂 I would prefer this check to be able to go into Clang-Tidy 13 if it's 
> okay, together with the other check I implemented.

@alexfh has had a few weeks to respond, so I'm going to give my explicit LG 
just in case he isn't available to perform a review. Please give Alex until the 
end of the week to comment on here before landing, but given the considerable 
review and discussion on this already, I think we can address remaining 
concerns post-commit if he's unavailable for the moment.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D20689

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

[PATCH] D105930: [PowerPC] Implement XL compact math builtins

[Lei Huang via Phabricator via cfe-commits]

lei created this revision.
lei added reviewers: stefanp, nemanjai, power-llvm-team.
Herald added subscribers: shchenz, hiraditya.
lei requested review of this revision.
Herald added projects: clang, LLVM.

Implement a subset of builtins required for compatiblilty with AIX XL compiler.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D105930

Files:
  clang/include/clang/Basic/BuiltinsPPC.def
  clang/lib/Basic/Targets/PPC.cpp
  clang/lib/Sema/SemaChecking.cpp
  clang/test/CodeGen/builtins-ppc-xlcompat-error.c
  clang/test/CodeGen/builtins-ppc-xlcompat-math.c
  clang/test/CodeGen/builtins-ppc-xlcompat-pwr9-64bit.c
  clang/test/CodeGen/builtins-ppc-xlcompat-pwr9.c
  llvm/include/llvm/IR/IntrinsicsPowerPC.td
  llvm/lib/Target/PowerPC/PPCInstrInfo.td
  llvm/lib/Target/PowerPC/PPCInstrVSX.td
  llvm/test/CodeGen/PowerPC/builtins-ppc-xlcompat-math.ll
  llvm/test/CodeGen/PowerPC/builtins-ppc-xlcompat-pwr9-64bit.ll
  llvm/test/CodeGen/PowerPC/builtins-ppc-xlcompat-pwr9.ll

Index: llvm/test/CodeGen/PowerPC/builtins-ppc-xlcompat-pwr9.ll
===
--- /dev/null
+++ llvm/test/CodeGen/PowerPC/builtins-ppc-xlcompat-pwr9.ll
@@ -0,0 +1,27 @@
+; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
+; RUN: llc -verify-machineinstrs -mtriple=powerpc64le-unknown-linux-gnu \
+; RUN:   -mcpu=pwr9 < %s | FileCheck %s
+; RUN: llc -verify-machineinstrs -mtriple=powerpc64-unknown-linux-gnu \
+; RUN:   -mcpu=pwr9 < %s | FileCheck %s
+; RUN: llc -verify-machineinstrs -mtriple=powerpc64-unknown-aix \
+; RUN:   -mcpu=pwr9 < %s | FileCheck %s
+; RUN: llc -verify-machineinstrs -mtriple=powerpc-unknown-aix \
+; RUN:   -mcpu=pwr9 < %s | FileCheck %s --check-prefix=CHECK-32BIT
+
+define dso_local zeroext i32 @extract_exp(double %d) local_unnamed_addr {
+; CHECK-LABEL: extract_exp:
+; CHECK:   # %bb.0: # %entry
+; CHECK-NEXT:xsxexpdp 3, 1
+; CHECK-NEXT:clrldi 3, 3, 32
+; CHECK-NEXT:blr
+;
+; CHECK-32BIT-LABEL: extract_exp:
+; CHECK-32BIT:   # %bb.0: # %entry
+; CHECK-32BIT-NEXT:xsxexpdp 3, 1
+; CHECK-32BIT-NEXT:# kill: def $r3 killed $r3 killed $x3
+; CHECK-32BIT-NEXT:blr
+entry:
+  %0 = tail call i32 @llvm.ppc.extract.exp(double %d)
+  ret i32 %0
+}
+declare i32 @llvm.ppc.extract.exp(double)
Index: llvm/test/CodeGen/PowerPC/builtins-ppc-xlcompat-pwr9-64bit.ll
===
--- /dev/null
+++ llvm/test/CodeGen/PowerPC/builtins-ppc-xlcompat-pwr9-64bit.ll
@@ -0,0 +1,31 @@
+; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
+; RUN: llc -verify-machineinstrs -mtriple=powerpc64le-unknown-linux-gnu \
+; RUN:   -mcpu=pwr9 < %s | FileCheck %s
+; RUN: llc -verify-machineinstrs -mtriple=powerpc64-unknown-linux-gnu \
+; RUN:   -mcpu=pwr9 < %s | FileCheck %s
+; RUN: llc -verify-machineinstrs -mtriple=powerpc64-unknown-aix \
+; RUN:   -mcpu=pwr9 < %s | FileCheck %s
+
+define dso_local i64 @extract_sig(double %d) local_unnamed_addr {
+; CHECK-LABEL: extract_sig:
+; CHECK:   # %bb.0: # %entry
+; CHECK-NEXT:xsxsigdp 3, 1
+; CHECK-NEXT:blr
+entry:
+  %0 = tail call i64 @llvm.ppc.extract.sig(double %d)
+  ret i64 %0
+}
+declare i64 @llvm.ppc.extract.sig(double)
+
+define dso_local double @insert_exp(double %d, i64 %ull) local_unnamed_addr {
+; CHECK-LABEL: insert_exp:
+; CHECK:   # %bb.0: # %entry
+; CHECK-NEXT:mffprd 3, 1
+; CHECK-NEXT:xsiexpdp 1, 3, 4
+; CHECK-NEXT:# kill: def $f1 killed $f1 killed $vsl1
+; CHECK-NEXT:blr
+entry:
+  %0 = tail call double @llvm.ppc.insert.exp(double %d, i64 %ull)
+  ret double %0
+}
+declare double @llvm.ppc.insert.exp(double, i64)
Index: llvm/test/CodeGen/PowerPC/builtins-ppc-xlcompat-math.ll
===
--- /dev/null
+++ llvm/test/CodeGen/PowerPC/builtins-ppc-xlcompat-math.ll
@@ -0,0 +1,199 @@
+; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
+; RUN: llc -verify-machineinstrs -mtriple=powerpc64le-unknown-linux-gnu < %s |\
+; RUN:   FileCheck %s --check-prefix=CHECK-PWR8
+; RUN: llc -verify-machineinstrs -mtriple=powerpc64-unknown-linux-gnu < %s |\
+; RUN:   FileCheck %s --check-prefix=CHECK-PWR7
+; RUN: llc -verify-machineinstrs -mtriple=powerpc64-unknown-aix < %s |\
+; RUN:   FileCheck %s --check-prefix=CHECK-PWR7
+; RUN: llc -verify-machineinstrs -mtriple=powerpc-unknown-aix -mcpu=pwr8 < %s |\
+; RUN:   FileCheck %s --check-prefix=CHECK-PWR8
+
+; Function Attrs: nounwind uwtable
+define dso_local void @mtfsb0() local_unnamed_addr #0 {
+; CHECK-PWR8-LABEL: mtfsb0:
+; CHECK-PWR8:   # %bb.0: # %entry
+; CHECK-PWR8-NEXT:mtfsb0 10
+; CHECK-PWR8-NEXT:blr
+;
+; CHECK-PWR7-LABEL: mtfsb0:
+; CHECK-PWR7:   # %bb.0: # %entry
+; CHECK-PWR7-NEXT:mtfsb0 10
+; CHECK-PWR7-NEXT:blr
+entry:
+  tail call void @llvm.ppc.mtfsb0(i32 10)
+  ret void
+}
+
+; Function Attrs: nounwind
+declare void @llvm

[PATCH] D94098: [Clang][AArch64] Inline assembly support for the ACLE type 'data512_t'.

[Eli Friedman via Phabricator via cfe-commits]

efriedma added a comment.

In D94098#2874976 , @labrinea wrote:

> In D94098#2868751 , @efriedma wrote:
>
>> 
>
> but in my honest opinion I don't see the benefit.

The problem is, there isn't really any point to supporting "register" operands 
in this state.  LLVM will never optimize an indirect register into a direct 
register, so we're guaranteed to generate an ld64b just before the inline asm 
block for inputs, and an st64b just after the inline asm block for outputs.  At 
that point, it's not really any better than something like `__asm__ volatile 
("ld64b x0, [%0]; st64b x0,[%1]" : : "r" (input), "r" (output) : "memory", 
"x0", "x1", "x2", "x3", "x4", "x5", "x6", "x7" );`.

That is, unless we care about source compatibility with some other compiler 
that supports this, I guess.


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

https://reviews.llvm.org/D94098

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

[PATCH] D105564: Fix for DWARF parsing to better handle auto return type for member functions

[Shafik Yaghmour via Phabricator via cfe-commits]

shafik added inline comments.



Comment at: lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.h:406
 
+  virtual lldb::TypeSP
+  FindTypeForAutoReturnForDIE(const DWARFDIE &die,

teemperor wrote:
> If this is virtual then I guess `SymbolFileDWARFDwo` should overload it?
I am actually not sure if this has to be virtual or not, let me dig into this 
and see if there would be any difference for `SymbolFileDWARFDwo` or not.


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

https://reviews.llvm.org/D105564

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

[PATCH] D105457: [clang] Refactor AST printing tests to share more infrastructure

[Douglas Yung via Phabricator via cfe-commits]

dyung added a comment.

In D105457#2875058 , @glaubitz wrote:

> In D105457#2874516 , @dblaikie 
> wrote:
>
>> Any ideas what version of the standard library these buildbots are using? 
>> This /looks/ a bit like a bug in the standard library in use, perhaps? (also 
>> because it's not showing up in lots of other buildbots/developers, I assume?)
>
> I cannot speak for the other builds bots, but the cross-buildbot for m68k 
> which I maintain is running openSUSE Leap 15.3 with GCC 7.5.0.
>
> Maybe this change is compatible with newer versions of GCC only?

I'm not sure how to get the standard library version that is being used, but 
our internal upstream build bot hit this issue, and it is running ubuntu 18.04 
with gcc 7.5 as well.

My main dev machine is running ubuntu 20.04 with 9.3 and that does not show the 
failure, but another one of our internal linux machines with 18.04 and gcc 7.5 
does show the failure.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105457

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

[PATCH] D105457: [clang] Refactor AST printing tests to share more infrastructure

[John Paul Adrian Glaubitz via Phabricator via cfe-commits]

glaubitz added a comment.

In D105457#2874516 , @dblaikie wrote:

> Any ideas what version of the standard library these buildbots are using? 
> This /looks/ a bit like a bug in the standard library in use, perhaps? (also 
> because it's not showing up in lots of other buildbots/developers, I assume?)

I cannot speak for the other builds bots, but the cross-buildbot for m68k which 
I maintain is running openSUSE Leap 15.3 with GCC 7.5.0.

Maybe your change is compatible with newer versions of GCC only?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105457

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

[PATCH] D105439: [clang] protects users from relying on libc++ detail headers

[Christopher Di Bella via Phabricator via cfe-commits]

cjdb added a comment.

In D105439#2874805 , @cjdb wrote:

> In D105439#2874733 , @lebedev.ri 
> wrote:
>
>> In D105439#2874706 , @ldionne 
>> wrote:
>>
>>> I'm not entirely sure I understand the purpose of this patch. So the idea 
>>> is that let's say a tool suggests including `<__algorithm/find.h>` to get 
>>> the definition of `std::find` as a IWYU fix-it sort of suggestion, the user 
>>> would naively do that, and then the compiler (with this patch) would error 
>>> out saying "woops, you can't include that libc++ detail header". Is that 
>>> the idea?
>>>
>>> If that's it, then I would much rather fix the tools that incorrectly 
>>> suggest including those implementation detail headers in the first place. 
>>> Users will be less confused and we won't have to special-case a special 
>>> directory name, which I can imagine could cause issues. I think it's great 
>>> to try and give the proper diagnostic to users, but I think the correct 
>>> place to do that is in the tool that suggests it in the first place. 
>>> Thoughts?
>>
>> Regardless of whether this is about enhacing IWYU QoL or completely 
>> preventing inclusion of separate sub-headers,
>> it seems like that should be done in libc++ itself, it already has the means 
>> for that.
>
> I've already pointed out that it can't be done in libc++. The proposed header 
> alternative doesn't translate to Clang modules, and private modules tank 
> build times.

After a bit more experimenting (I was benchmarking to provide evidence), it 
seems as though private headers impact the first run of `llvm-lit` on libc++ 
tests, but not subsequent ones. Since this patch is user-oriented, I'm now in 
agreement that it //can// be punted back to the libc++ space. Thanks 
@lebedev.ri and apologies for my initial misleading assertion!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105439

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

[PATCH] D105295: [CUDA] Only allow NVIDIA offload-arch during CUDA compilation.

[Artem Belevich via Phabricator via cfe-commits]

tra added a comment.

In D105295#2874935 , @tra wrote:

> Ugh. I broke the cuda-bad-arch.cu test.

Should be fixed in 25629bb45f0a4b8c8e99dbde4f4a7e3d980b9fd7 



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105295

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

[clang] 25629bb - Fix cuda-bad-arch.cu test.

[Artem Belevich via cfe-commits]

Author: Artem Belevich
Date: 2021-07-13T11:57:25-07:00
New Revision: 25629bb45f0a4b8c8e99dbde4f4a7e3d980b9fd7

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

LOG: Fix cuda-bad-arch.cu test.

Tests for correctness of HIP architecture need `- xhip`

Added: 


Modified: 
clang/test/Driver/cuda-arch-translation.cu
clang/test/Driver/cuda-bad-arch.cu
clang/test/Driver/cuda-flush-denormals-to-zero.cu

Removed: 




diff  --git a/clang/test/Driver/cuda-arch-translation.cu 
b/clang/test/Driver/cuda-arch-translation.cu
index b574d082218e..683add533879 100644
--- a/clang/test/Driver/cuda-arch-translation.cu
+++ b/clang/test/Driver/cuda-arch-translation.cu
@@ -6,67 +6,69 @@
 // REQUIRES: nvptx-registered-target
 
 // RUN: %clang -### -target x86_64-linux-gnu -c --cuda-gpu-arch=sm_20 %s 2>&1 \
-// RUN: | FileCheck -check-prefixes=COMMON,SM20 %s
+// RUN: | FileCheck -check-prefixes=CUDA,SM20 %s
 // RUN: %clang -### -target x86_64-linux-gnu -c --cuda-gpu-arch=sm_21 %s 2>&1 \
-// RUN: | FileCheck -check-prefixes=COMMON,SM21 %s
+// RUN: | FileCheck -check-prefixes=CUDA,SM21 %s
 // RUN: %clang -### -target x86_64-linux-gnu -c --cuda-gpu-arch=sm_30 %s 2>&1 \
-// RUN: | FileCheck -check-prefixes=COMMON,SM30 %s
+// RUN: | FileCheck -check-prefixes=CUDA,SM30 %s
 // RUN: %clang -### -target x86_64-linux-gnu -c --cuda-gpu-arch=sm_32 %s 2>&1 \
-// RUN: | FileCheck -check-prefixes=COMMON,SM32 %s
+// RUN: | FileCheck -check-prefixes=CUDA,SM32 %s
 // RUN: %clang -### -target x86_64-linux-gnu -c --cuda-gpu-arch=sm_35 %s 2>&1 \
-// RUN: | FileCheck -check-prefixes=COMMON,SM35 %s
+// RUN: | FileCheck -check-prefixes=CUDA,SM35 %s
 // RUN: %clang -### -target x86_64-linux-gnu -c --cuda-gpu-arch=sm_37 %s 2>&1 \
-// RUN: | FileCheck -check-prefixes=COMMON,SM37 %s
+// RUN: | FileCheck -check-prefixes=CUDA,SM37 %s
 // RUN: %clang -### -target x86_64-linux-gnu -c --cuda-gpu-arch=sm_50 %s 2>&1 \
-// RUN: | FileCheck -check-prefixes=COMMON,SM50 %s
+// RUN: | FileCheck -check-prefixes=CUDA,SM50 %s
 // RUN: %clang -### -target x86_64-linux-gnu -c --cuda-gpu-arch=sm_52 %s 2>&1 \
-// RUN: | FileCheck -check-prefixes=COMMON,SM52 %s
+// RUN: | FileCheck -check-prefixes=CUDA,SM52 %s
 // RUN: %clang -### -target x86_64-linux-gnu -c --cuda-gpu-arch=sm_53 %s 2>&1 \
-// RUN: | FileCheck -check-prefixes=COMMON,SM53 %s
+// RUN: | FileCheck -check-prefixes=CUDA,SM53 %s
 // RUN: %clang -### -target x86_64-linux-gnu -c --cuda-gpu-arch=sm_60 %s 2>&1 \
-// RUN: | FileCheck -check-prefixes=COMMON,SM60 %s
+// RUN: | FileCheck -check-prefixes=CUDA,SM60 %s
 // RUN: %clang -### -target x86_64-linux-gnu -c --cuda-gpu-arch=sm_61 %s 2>&1 \
-// RUN: | FileCheck -check-prefixes=COMMON,SM61 %s
+// RUN: | FileCheck -check-prefixes=CUDA,SM61 %s
 // RUN: %clang -### -target x86_64-linux-gnu -c --cuda-gpu-arch=sm_62 %s 2>&1 \
-// RUN: | FileCheck -check-prefixes=COMMON,SM62 %s
+// RUN: | FileCheck -check-prefixes=CUDA,SM62 %s
 // RUN: %clang -### -target x86_64-linux-gnu -c --cuda-gpu-arch=sm_70 %s 2>&1 \
-// RUN: | FileCheck -check-prefixes=COMMON,SM70 %s
-// RUN: %clang -### -target x86_64-linux-gnu -c --cuda-gpu-arch=gfx600 %s 2>&1 
\
-// RUN: | FileCheck -check-prefixes=COMMON,GFX600 %s
-// RUN: %clang -### -target x86_64-linux-gnu -c --cuda-gpu-arch=gfx601 %s 2>&1 
\
-// RUN: | FileCheck -check-prefixes=COMMON,GFX601 %s
-// RUN: %clang -### -target x86_64-linux-gnu -c --cuda-gpu-arch=gfx602 %s 2>&1 
\
-// RUN: | FileCheck -check-prefixes=COMMON,GFX602 %s
-// RUN: %clang -### -target x86_64-linux-gnu -c --cuda-gpu-arch=gfx700 %s 2>&1 
\
-// RUN: | FileCheck -check-prefixes=COMMON,GFX700 %s
-// RUN: %clang -### -target x86_64-linux-gnu -c --cuda-gpu-arch=gfx701 %s 2>&1 
\
-// RUN: | FileCheck -check-prefixes=COMMON,GFX701 %s
-// RUN: %clang -### -target x86_64-linux-gnu -c --cuda-gpu-arch=gfx702 %s 2>&1 
\
-// RUN: | FileCheck -check-prefixes=COMMON,GFX702 %s
-// RUN: %clang -### -target x86_64-linux-gnu -c --cuda-gpu-arch=gfx703 %s 2>&1 
\
-// RUN: | FileCheck -check-prefixes=COMMON,GFX703 %s
-// RUN: %clang -### -target x86_64-linux-gnu -c --cuda-gpu-arch=gfx704 %s 2>&1 
\
-// RUN: | FileCheck -check-prefixes=COMMON,GFX704 %s
-// RUN: %clang -### -target x86_64-linux-gnu -c --cuda-gpu-arch=gfx705 %s 2>&1 
\
-// RUN: | FileCheck -check-prefixes=COMMON,GFX705 %s
-// RUN: %clang -### -target x86_64-linux-gnu -c --cuda-gpu-arch=gfx801 %s 2>&1 
\
-// RUN: | FileCheck -check-prefixes=COMMON,GFX801 %s
-// RUN: %clang -### -target x86_64-linux-gnu -c --cuda-gpu-arch=gfx802 %s 2>&1 
\
-// RUN: | FileCheck -check-prefixes=COMMON,GFX802 %s
-// RUN: %clang -### -target x86_64-linux-gnu -c --cuda-gpu-arch=gfx803 %s 2>&1 
\
-// RUN: | FileCheck -check-prefixes=COMMON,GFX803 %s
-// RUN: %clang -### -target x86_64-linux-gnu -c --cuda-gpu-arch=gfx805 

[PATCH] D105295: [CUDA] Only allow NVIDIA offload-arch during CUDA compilation.

[Douglas Yung via Phabricator via cfe-commits]

dyung added a comment.

I think your change also broke cuda-flush-denormals-to-zero.cu:

https://lab.llvm.org/buildbot/#/builders/139/builds/7048


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105295

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

[PATCH] D105926: [PowerPC] Extra test case for LDARX

[Albion Fung via Phabricator via cfe-commits]

Conanap created this revision.
Herald added subscribers: shchenz, kbarton, nemanjai.
Conanap requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

An extra test case added for the builtin __LDARX.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D105926

Files:
  clang/test/CodeGen/builtins-ppc-xlcompat-check-ldarx-opt.ll

Index: clang/test/CodeGen/builtins-ppc-xlcompat-check-ldarx-opt.ll
===
--- /dev/null
+++ clang/test/CodeGen/builtins-ppc-xlcompat-check-ldarx-opt.ll
@@ -0,0 +1,160 @@
+; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
+; RUN: llc -verify-machineinstrs -mtriple=powerpc64le-unknown-linux-gnu \
+; RUN:   -mcpu=pwr8 < %s | FileCheck %s --check-prefix=CHECK
+; RUN: llc -verify-machineinstrs -mtriple=powerpc64-unknown-linux-gnu \
+; RUN:   -mcpu=pwr8 < %s | FileCheck %s --check-prefix=CHECK
+; RUN: llc -verify-machineinstrs -mtriple=powerpc64-unknown-aix \
+; RUN:   -mcpu=pwr8 < %s | FileCheck %s --check-prefix=CHECK-AIX
+
+; Function Attrs: noinline nounwind optnone uwtable
+define dso_local signext i32 @main() #0 {
+; CHECK-LABEL: main:
+; CHECK:   # %bb.0: # %entry
+; CHECK-NEXT:li 3, 0
+; CHECK-NEXT:stw 3, -12(1)
+; CHECK-NEXT:li 3, -1
+; CHECK-NEXT:std 3, -32(1)
+; CHECK-NEXT:li 3, 0
+; CHECK-NEXT:std 3, -40(1)
+; CHECK-NEXT:  .LBB0_1: # %do.body
+; CHECK-NEXT:#
+; CHECK-NEXT:addi 3, 1, -32
+; CHECK-NEXT:#APP
+; CHECK-NEXT:ldarx 3, 0, 3
+; CHECK-NEXT:#NO_APP
+; CHECK-NEXT:std 3, -24(1)
+; CHECK-NEXT:addi 3, 1, -32
+; CHECK-NEXT:ld 4, -24(1)
+; CHECK-NEXT:ld 5, -40(1)
+; CHECK-NEXT:and 4, 4, 5
+; CHECK-NEXT:stdcx. 4, 0, 3
+; CHECK-NEXT:mfocrf 3, 128
+; CHECK-NEXT:srwi 3, 3, 28
+; CHECK-NEXT:stw 3, -44(1)
+; CHECK-NEXT:  # %bb.2: # %do.cond
+; CHECK-NEXT:#
+; CHECK-NEXT:lwz 3, -44(1)
+; CHECK-NEXT:cmplwi 3, 0
+; CHECK-NEXT:beq 0, .LBB0_1
+; CHECK-NEXT:b .LBB0_3
+; CHECK-NEXT:  .LBB0_3: # %do.end
+; CHECK-NEXT:ld 3, -32(1)
+; CHECK-NEXT:cmpdi 3, 0
+; CHECK-NEXT:bne 0, .LBB0_5
+; CHECK-NEXT:  # %bb.4: # %if.then
+; CHECK-NEXT:li 3, 55
+; CHECK-NEXT:stw 3, -12(1)
+; CHECK-NEXT:b .LBB0_6
+; CHECK-NEXT:  .LBB0_5: # %if.end
+; CHECK-NEXT:li 3, 66
+; CHECK-NEXT:stw 3, -12(1)
+; CHECK-NEXT:  .LBB0_6: # %return
+; CHECK-NEXT:lwa 3, -12(1)
+; CHECK-NEXT:blr
+;
+; CHECK-AIX-LABEL: main:
+; CHECK-AIX:   # %bb.0: # %entry
+; CHECK-AIX-NEXT:li 3, 0
+; CHECK-AIX-NEXT:stw 3, -12(1)
+; CHECK-AIX-NEXT:li 4, -1
+; CHECK-AIX-NEXT:std 4, -32(1)
+; CHECK-AIX-NEXT:std 3, -40(1)
+; CHECK-AIX-NEXT:b L..BB0_1
+; CHECK-AIX-NEXT:  L..BB0_1: # %do.body
+; CHECK-AIX-NEXT:#
+; CHECK-AIX-NEXT:addi 3, 1, -32
+; CHECK-AIX-NEXT:#APP
+; CHECK-AIX-NEXT:ldarx 4, 0, 3
+; CHECK-AIX-NEXT:#NO_APP
+; CHECK-AIX-NEXT:std 4, -24(1)
+; CHECK-AIX-NEXT:ld 4, -24(1)
+; CHECK-AIX-NEXT:ld 5, -40(1)
+; CHECK-AIX-NEXT:and 4, 4, 5
+; CHECK-AIX-NEXT:stdcx. 4, 0, 3
+; CHECK-AIX-NEXT:mfocrf 3, 128
+; CHECK-AIX-NEXT:srwi 3, 3, 28
+; CHECK-AIX-NEXT:stw 3, -44(1)
+; CHECK-AIX-NEXT:b L..BB0_2
+; CHECK-AIX-NEXT:  L..BB0_2: # %do.cond
+; CHECK-AIX-NEXT:#
+; CHECK-AIX-NEXT:lwz 3, -44(1)
+; CHECK-AIX-NEXT:cmplwi 3, 0
+; CHECK-AIX-NEXT:beq 0, L..BB0_1
+; CHECK-AIX-NEXT:b L..BB0_3
+; CHECK-AIX-NEXT:  L..BB0_3: # %do.end
+; CHECK-AIX-NEXT:ld 3, -32(1)
+; CHECK-AIX-NEXT:cmpldi 3, 0
+; CHECK-AIX-NEXT:bne 0, L..BB0_5
+; CHECK-AIX-NEXT:b L..BB0_4
+; CHECK-AIX-NEXT:  L..BB0_4: # %if.then
+; CHECK-AIX-NEXT:li 3, 55
+; CHECK-AIX-NEXT:stw 3, -12(1)
+; CHECK-AIX-NEXT:b L..BB0_6
+; CHECK-AIX-NEXT:  L..BB0_5: # %if.end
+; CHECK-AIX-NEXT:li 3, 66
+; CHECK-AIX-NEXT:stw 3, -12(1)
+; CHECK-AIX-NEXT:b L..BB0_6
+; CHECK-AIX-NEXT:  L..BB0_6: # %return
+; CHECK-AIX-NEXT:lwa 3, -12(1)
+; CHECK-AIX-NEXT:blr
+entry:
+  %retval = alloca i32, align 4
+  %x = alloca i64, align 8
+  %x64 = alloca i64, align 8
+  %andval = alloca i64, align 8
+  %k = alloca i32, align 4
+  store i32 0, i32* %retval, align 4
+  store i64 -1, i64* %x64, align 8
+  store i64 0, i64* %andval, align 8
+  br label %do.body
+
+do.body:  ; preds = %do.cond, %entry
+  %0 = call i64 asm sideeffect "ldarx $0, ${1:y}", "=r,*Z,~{memory}"(i64* %x64)
+  store i64 %0, i64* %x, align 8
+  %1 = bitcast i64* %x64 to i8*
+  %2 = load i64, i64* %x, align 8
+  %3 = load i64, i64* %andval, align 8
+  %and = and i64 %2, %3
+  %4 = call i32 @llvm.ppc.stdcx(i8* %1, i64 %and)
+  store i32 %4, i32* %k, align 4
+  br label %do.cond
+
+do.cond:  ; preds = %do.body
+  %5 = load i32, i32* %k, align 4
+  %tobool = icmp ne i32 %5, 0
+  %lnot = xor i1 %tobool, true
+  br i1 %lnot, label %do.body, label %do.e

[PATCH] D94098: [Clang][AArch64] Inline assembly support for the ACLE type 'data512_t'.

[Alexandros Lamprineas via Phabricator via cfe-commits]

labrinea added a comment.

In D94098#2868751 , @efriedma wrote:

> The part I'm confused about is that you're forcing it to use "*r".  At the IR 
> level, LLVM handles something like `call void asm sideeffect "#$0", "r"([8 x 
> i64] %c)` fine.  You'll have to do a bit of work to teach clang to emit that, 
> but it shouldn't be that hard.  I think you can deal with it on the isel end 
> with some relatively small changes to D94097 
> .

If you discard my patch and look at the codegen for `__asm__ volatile ("st64b 
%0,[%1]" : : "r" (*input), "r" (addr) : "memory" );`, which uses the struct foo 
as an input operand, you'll see that clang is already passing it by reference. 
All I am doing is making this behavior consistent for output operands too. 
Whether llvm can deal with indirect asm register operands or not is a separate 
story (see llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp:8740). I think 
that making clang emit what you sugggested (to pass [8 x i64] by value) is 
inevitably going to be inelegant in a similar way that the previous revision of 
this patch was. Moreover, taking this route entails introducing more inelegant 
changes in D94097  (workarounds for MVT::i64x8 
in getCopyToParts() of the same file I previously mentioned). I have been 
unsuccessfully trying all the above and I can continue my efforts for a little 
more, but in my honest opinion I don't see the benefit.


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

https://reviews.llvm.org/D94098

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

[PATCH] D69764: [clang-format] Add East/West Const fixer capability

[Björn Schäpers via Phabricator via cfe-commits]

HazardyKnusperkeks added a comment.

I already said I would like that in `clang-format` and would directly add that 
to my config.

I also think that there should be no problem in having that in `clang-format`, 
include sorting has a bigger chance of breaking code, yeah only with poorly 
designed headers but these exist, something which can not be fixed in 
clang-format itself, but only with `// clang-format off` or a elaborated 
sorting configuration. Breaking `const` moves can be fixed in `clang-format` 
and since it is off by default I really don't see a problem.

For the option: Maybe it should directly be prepared to sort all kinds of 
qualifiers, even if they are not added in this patch.




Comment at: clang/docs/ClangFormatStyleOptions.rst:1378
 
+**ConstStyle** (``ConstAlignmentStyle``)
+  Different ways to arrange const.

davidstone wrote:
> steveire wrote:
> > klimek wrote:
> > > MyDeveloperDay wrote:
> > > > aaron.ballman wrote:
> > > > > MyDeveloperDay wrote:
> > > > > > klimek wrote:
> > > > > > > Personally, I'm somewhat against having 3 different aliases for 
> > > > > > > the options. I'd chose one, even though it doesn't make everybody 
> > > > > > > happy, and move on. I'm fine with East/West as long as the 
> > > > > > > documentation makes it clear what it is.
> > > > > > If I have to drop the other options, I think I'd want to go with 
> > > > > > East/West const as I feel it has more momentum, just letting people 
> > > > > > know before I change the code back (to my original patch ;-) )
> > > > > > 
> > > > > > https://www.youtube.com/watch?v=gRmI_gsNqcI
> > > > > > 
> > > > > > {F10954065}
> > > > > > 
> > > > > @klimek I requested that we do not go with East/West the options and 
> > > > > I'm still pretty insistent on it. East/West is a kitschy way to 
> > > > > phrase it that I think is somewhat US-centric (where we make a pretty 
> > > > > big distinction between the east and west coasts). I do not want to 
> > > > > have to mentally map left/right to the less-clear east/west in the 
> > > > > config file. Would you be fine if we only had Left/Right instead of 
> > > > > East/West? I would be fine with that option, but figured enough 
> > > > > people like the cute East/West designation that we might as well 
> > > > > support it.
> > > > Just for a reference, I'm not from the US and I think east/west still 
> > > > translates pretty well. I was happy to support the others. 
> > > I'd be fine with only having left/right; my personal feeling is also that 
> > > west-const / east-const has kinda become a term of art, though, so I 
> > > really don't know which one is "right" :)
> > > 
> > > Generally, I think this is one of the cases where, given good docs, we're 
> > > quickly spending more engineering hours discussing the right solution 
> > > than it'll cost aggregated over all future users, under the assumption 
> > > that people do not write new configs very often, and the few who will, 
> > > will quickly remember.
> > > 
> > > I'd be fine with only having left/right; my personal feeling is also that 
> > > west-const / east-const has kinda become a term of art, though, so I 
> > > really don't know which one is "right" :)
> > 
> > This reminds me of the joke that Americans drive on the "Right" side of the 
> > road, and English drive on the "Correct" side. Sort of gives a different 
> > meaning to `ConstStyle : Right` and that the alternative is `Wrong` :). 
> > Maybe that language ambiguity is why `East`/`West` caught on.
> > 
> > > people do not write new configs very often
> > 
> > Agreed. It seems a small number of strong views might influence this enough 
> > to make `East`/`West` not be used. What a pity.
> I'd also add that the original "joke" was `const west` vs `east const` -- the 
> terms put the const where they would apply in the style. This seems to have 
> gotten lost in the retelling and now the const is always on the right.
> 
> I'd favor `Left` and `Right`. `East` and `West` have "caught on" now, but 
> it's caught on among the small group of C++ enthusiasts and still has a sort 
> of ingroup joke feel to it. I instinctively know my preferred style is "east" 
> because the phrase "east const" feels more natural to me because I've said it 
> more. It took me a bit of repetition of thinking "East is right, I put the 
> const on the right" to get there.
> 
> `East` and `West` also sets a precedent for future options to refer to 
> positions as `North` and `South`.
I also think `Left` and `Right` are the better choices, but I would be full in 
favor of also parsing `West` and `East`. :)



Comment at: clang/lib/Format/EastWestConstFixer.cpp:293
+  Tok->Next->Next->Next && Tok->Next->Next->Next->is(tok::kw_const)) {
+swapFourTokens(SourceMgr, Fixes, Tok, Tok->Next, Tok->Next, 
Tok->Next->Next->Next,
+ /*West=*/true);

aaron.ballman wrote:
> curdeius wrote:
> > MyDeve

[PATCH] D105876: OMPIRBuilder for Interop directive

[Johannes Doerfert via Phabricator via cfe-commits]

jdoerfert added a subscriber: mikerice.
jdoerfert added a comment.

There are 3 clang tidy warnings to address. Overall this is a good first step. 
@ABataev @mikerice is there any major problem with this? If not we should try 
to get it in asap and improve it in tree.




Comment at: llvm/include/llvm/Frontend/OpenMP/OMPConstants.h:133
 
+enum class OMPInteropType { Unknown, Target, TargetSync };
+

move into the omp namespace and add doxygen documentation.



Comment at: llvm/include/llvm/Frontend/OpenMP/OMPIRBuilder.h:797
+   llvm::Value *NumDependences,
+   llvm::Value *DependenceAddress, int HaveNowaitClause);
+

Also elsewhere.



Comment at: llvm/lib/Frontend/OpenMP/OMPIRBuilder.cpp:2192
+  ConstantInt *InteropTypeVal =
+  ConstantInt::get(M.getContext(), APInt(64, (int)InteropType, true));
+  if (NumDependences == nullptr) {

Also similarly elsewhere.



Comment at: llvm/lib/Frontend/OpenMP/OMPIRBuilder.cpp:2194
+  if (NumDependences == nullptr) {
+NumDependences = ConstantInt::get(M.getContext(), APInt(32, 0, true));
+PointerType *PointerTy_0 = llvm::Type::getInt8PtrTy(M.getContext());





Comment at: llvm/lib/Frontend/OpenMP/OMPIRBuilder.cpp:2264
+  return Builder.CreateCall(Fn, Args);
+}
+

Remove all the `llvm::` in this file.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105876

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

[PATCH] D105295: [CUDA] Only allow NVIDIA offload-arch during CUDA compilation.

[Artem Belevich via Phabricator via cfe-commits]

tra added a comment.

Ugh. I broke the cuda-bad-arch.cu test.




Comment at: clang/test/Driver/cuda-bad-arch.cu:30
 // RUN: | FileCheck -check-prefix OK %s
 // RUN: %clang -### -target x86_64-linux-gnu --cuda-gpu-arch=gfx90a -c %s 2>&1 
\
 // RUN: | FileCheck -check-prefix OK %s

HIP tests should've used `-x hip`. I'll fix the test shortly.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105295

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

[PATCH] D69764: [clang-format] Add East/West Const fixer capability

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added a comment.

In D69764#2874790 , @MyDeveloperDay 
wrote:

>> so there's something like precedent here
>
> I think its worth mentioning, that my personal preference would STILL be to 
> land this inside clang-format with default configuration of "OFF", where 
> there is also significant existing precedent for passes that change non 
> whitespace and even add tokens.

Fair.

> I still believe clang-format is the best location, I think its the most 
> optimal, and I think its the fairest (because those that want it get it, and 
> those that don't aren't forced to have it). But doing this as another tool 
> would be a `compromise`, in my view an inferior one to it being in 
> clang-format, but at least we could set out clear goals where allowing code 
> modification was the intent (as this seems to be the major sticking point)
>
> I would be interested to know how many people would be unhappy if we stated 
> that "sorting includes" and "namespace comments" had to be removed from 
> clang-format and into the new tool! I am thinking it would be fairly 
> significant. (I'm not suggesting we would, just making a point)

I would be in favor of such a migration for sorting includes. I want my code 
formatting tool to not break my code. I recognize the tool already potentially 
breaks code when reordering fragile includes, but I think that was a mistake 
that should not be purposefully repeated without the community actively saying 
that's the direction they want the tool to go in. Personally, I'd be opposed to 
such a direction (each new breaking transformation supplied by the tool makes 
the tool that much less trustworthy in common use cases like CI pipelines), but 
perhaps the community has an appetite for such a change.

(Btw, I don't see how namespace comments really relate -- those don't break 
code that I'm aware of. If the concern is "but they're not whitespace"; they 
are as far as the compiler is concerned.)

> So you know, I'm pushing because I'm being ask privately to land this, 
> because I assume people want to use it, but maybe don't want to voice their 
> opinions publicly.
>
> I don't want to fragment the community by pushing an agenda (something I see 
> you seem to care about),  but I would also like to think that those of us who 
> contribute to clang-format regularly can help shape a future for it moving 
> forward.

I am not the code owner for this tool, so I think the decision ultimately lands 
on @rsmith as we have no code owner specifically for this component. However: 
https://reviews.llvm.org/D69764#2056105 so it's not like I'm alone in my 
concerns.


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

https://reviews.llvm.org/D69764

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

[PATCH] D105726: Added fsanitize-address-instrument-via-callback, which controls if address sanitizer will always use a callback.

[Vitaly Buka via Phabricator via cfe-commits]

vitalybuka requested changes to this revision.
vitalybuka added a comment.
This revision now requires changes to proceed.

I took another looks and noticed:
also clang/docs/UsersManual.rst
and maybe clang/docs/AddressSanitizer.rst
also could you add some trivial test that the flag affects generated code, 
similar to clang/test/CodeGen/asan-use-after-return.cpp


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105726

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

[PATCH] D105564: Fix for DWARF parsing to better handle auto return type for member functions

[Shafik Yaghmour via Phabricator via cfe-commits]

shafik updated this revision to Diff 358373.
shafik added a comment.

- Modified `FindTypeForAutoReturnForDIE` to take into account if we have 
multiple symbols with the same name.
- Modified `ParseSubroutine` to take into account that case we get the 
definition first, this can happen when we set a breakpoint inside the 
definition.
- Added new tests suggested by Raphael.


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

https://reviews.llvm.org/D105564

Files:
  lldb/source/Plugins/ExpressionParser/Clang/ASTResultSynthesizer.cpp
  lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
  lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
  lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.h
  lldb/test/API/lang/cpp/auto_return/Makefile
  lldb/test/API/lang/cpp/auto_return/TestCppAutoReturn.py
  lldb/test/API/lang/cpp/auto_return/main.cpp
  lldb/test/API/lang/cpp/auto_return/other.cpp
  lldb/test/Shell/SymbolFile/DWARF/x86/auto_return_symtab.s

Index: lldb/test/Shell/SymbolFile/DWARF/x86/auto_return_symtab.s
===
--- /dev/null
+++ lldb/test/Shell/SymbolFile/DWARF/x86/auto_return_symtab.s
@@ -0,0 +1,257 @@
+# This tests that lldb when using symbol table we are able to find the definition
+# for an auto return function.
+
+# RUN: llvm-mc -triple x86_64-apple-macosx10.15.0 %s -filetype=obj > %t.o
+# RUN: lldb-test symbols --dump-clang-ast %t.o | FileCheck %s
+
+# CHECK: CXXMethodDecl {{.*}} <>  f 'int ()'
+
+# This was compiled from the following code:
+#
+# struct A {
+# auto f();
+# };
+#
+# auto A::f() {
+# return 0;
+# }
+#
+# Compiled using:
+#
+#  -target x86_64-apple-macosx10.15.0
+#
+# and edited to remove some uneeded sections.
+
+	.section	__TEXT,__text,regular,pure_instructions
+	.globl	__ZN1A1fEv  ## -- Begin function _ZN1A1fEv
+	.p2align	4, 0x90
+__ZN1A1fEv: ## @_ZN1A1fEv
+Lfunc_begin0:
+	.cfi_startproc
+## %bb.0:   ## %entry
+	pushq	%rbp
+	.cfi_def_cfa_offset 16
+	.cfi_offset %rbp, -16
+	movq	%rsp, %rbp
+	.cfi_def_cfa_register %rbp
+	movq	%rdi, -8(%rbp)
+Ltmp0:
+	xorl	%eax, %eax
+	popq	%rbp
+	retq
+Ltmp1:
+Lfunc_end0:
+	.cfi_endproc
+## -- End function
+	.section	__DWARF,__debug_abbrev,regular,debug
+Lsection_abbrev:
+	.byte	1   ## Abbreviation Code
+	.byte	17  ## DW_TAG_compile_unit
+	.byte	1   ## DW_CHILDREN_yes
+	.byte	37  ## DW_AT_producer
+	.byte	14  ## DW_FORM_strp
+	.byte	19  ## DW_AT_language
+	.byte	5   ## DW_FORM_data2
+	.byte	3   ## DW_AT_name
+	.byte	14  ## DW_FORM_strp
+	.ascii	"\202|" ## DW_AT_LLVM_sysroot
+	.byte	14  ## DW_FORM_strp
+	.ascii	"\357\177"  ## DW_AT_APPLE_sdk
+	.byte	14  ## DW_FORM_strp
+	.byte	16  ## DW_AT_stmt_list
+	.byte	23  ## DW_FORM_sec_offset
+	.byte	27  ## DW_AT_comp_dir
+	.byte	14  ## DW_FORM_strp
+	.byte	17  ## DW_AT_low_pc
+	.byte	1   ## DW_FORM_addr
+	.byte	18  ## DW_AT_high_pc
+	.byte	6   ## DW_FORM_data4
+	.byte	0   ## EOM(1)
+	.byte	0   ## EOM(2)
+	.byte	2   ## Abbreviation Code
+	.byte	19  ## DW_TAG_structure_type
+	.byte	1   ## DW_CHILDREN_yes
+	.byte	54  ## DW_AT_calling_convention
+	.byte	11  ## DW_FORM_data1
+	.byte	3   ## DW_AT_name
+	.byte	14  ## DW_FORM_strp
+	.byte	11  ## DW_AT_byte_size
+	.byte	11  ## DW_FORM_data1
+	.byte	58  ## DW_AT_decl_file
+	.byte	11  ## DW_FORM_data1
+	.byte	59  ## DW_AT_decl_line
+	.byte	11  ## DW_FORM_data1
+	.byte	0   ## EOM(1)
+	.byte	0   ## EOM(2)
+	.byte	3   ## Abbreviation Code
+	.byte	46  ## DW_TAG_subprogram
+	.byte	1   ## DW_CHILDREN_yes
+	.byte	110 ## DW_AT_linkage_name
+	.byte	14  ## DW_FORM_strp
+	.byte	3   ## DW_AT_name
+	.byte	14  ## DW_FORM_strp
+	.byte	58   

[PATCH] D103096: [analyzer] Implement cast for ranges of symbolic integers.

[Denys Petrov via Phabricator via cfe-commits]

ASDenysPetrov added inline comments.



Comment at: clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp:1203
+if (!Opts.ShouldSupportSymbolicIntegerCasts)
+  return VisitSymExpr(Sym);
+

vsavchenko wrote:
> ASDenysPetrov wrote:
> > vsavchenko wrote:
> > > ASDenysPetrov wrote:
> > > > vsavchenko wrote:
> > > > > Why do you use `VisitSymExpr` here?  You want to interrupt all 
> > > > > `Visits or... I'm not sure I fully understand.
> > > > Here we want to delegate the reasoning to another handler as we don't 
> > > > support non-integral cast yet.
> > > You are not delegating it here.  `Visit` includes a runtime dispatch that 
> > > calls a correct `VisitTYPE` method.  Here you call `VisitSymExpr` 
> > > directly, which is one of the `VisitTYPE` methods.  No dispatch will 
> > > happen, and since we use `VisitSymExpr` as the last resort (it's the most 
> > > base class, if we got there, we don't actually support the expression), 
> > > you interrupt the `Visit` and go directly to "the last resort".
> > > 
> > > See the problem now?
> > OK. I reject this idea before. If we call `Visit` inside `VisitSymbolCast`, 
> > we will go into recursive loop, because it will return us back to 
> > `VisitSymbolCast` as we have passed `Sym` as is. (This is theoretically, I 
> > didn't check in practice.) Or I'm missing smth?
> > I choosed `VisitSymExpr` here because all kinds of `SymbolCast` were 
> > previously handled here. So I decided to pass all unsupproted forms of 
> > casts there.
> Did I suggest to `Visit(Sym)`?  Of course it is going to end up in a loop!  
> Why isn't it `Visit(Sym->getOperand())` here?  Before we started producing 
> casts, casts were transparent.  This logic would fit perfectly with that.
> were transparent.
Not exactly. There are still some cases when symbols are not equal to there 
roots(aka Operands). Such cases were handled by `VisitSymExpr` which uses 
`infer(Sym->getType());` instead of getOperand`. So this needs a sort of think 
twice. Also I see a problem with `EquivalenceClass`'es. Consider next:
```
int x, y;
if(x == y)
  if ((char)x == 2)
if(y == 259)
  // Here we shall update `(char)x` and find this branch infeasible.
```
Also such cases like:
```
if(x == (short)y)
  // What we should do(store) with(in) `EquivalenceClass`es.
```
Currently, I have an obscure vision of the solution.


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

https://reviews.llvm.org/D103096

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

[clang] 781929b - [PowerPC][NFC] Power ISA features for Semachecking

[Victor Huang via cfe-commits]

Author: Victor Huang
Date: 2021-07-13T13:13:34-05:00
New Revision: 781929b4236bc34681fb0783cf7b6021109fe28b

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

LOG: [PowerPC][NFC] Power ISA features for Semachecking

[NFC] This patch adds features for pwr7, pwr8, and pwr9 that can be
used for semachecking builtin functions that are only valid for certain
versions of ppc.

Reviewed By: nemanjai, #powerpc
Authored By: Quinn Pham 

Differential revision: https://reviews.llvm.org/D105501

Added: 
clang/test/Driver/ppc-isa-features.cpp

Modified: 
clang/include/clang/Basic/DiagnosticSemaKinds.td
clang/lib/Basic/Targets/PPC.cpp
clang/lib/Basic/Targets/PPC.h
clang/lib/Sema/SemaChecking.cpp
llvm/lib/Target/PowerPC/PPC.td
llvm/lib/Target/PowerPC/PPCInstrInfo.td
llvm/lib/Target/PowerPC/PPCSubtarget.cpp
llvm/lib/Target/PowerPC/PPCSubtarget.h

Removed: 




diff  --git a/clang/include/clang/Basic/DiagnosticSemaKinds.td 
b/clang/include/clang/Basic/DiagnosticSemaKinds.td
index 2d62163e3dcc..422507cd2842 100644
--- a/clang/include/clang/Basic/DiagnosticSemaKinds.td
+++ b/clang/include/clang/Basic/DiagnosticSemaKinds.td
@@ -9757,8 +9757,8 @@ def err_mips_builtin_requires_dspr2 : Error<
   "this builtin requires 'dsp r2' ASE, please use -mdspr2">;
 def err_mips_builtin_requires_msa : Error<
   "this builtin requires 'msa' ASE, please use -mmsa">;
-def err_ppc_builtin_only_on_pwr7 : Error<
-  "this builtin is only valid on POWER7 or later CPUs">;
+def err_ppc_builtin_only_on_arch : Error<
+  "this builtin is only valid on POWER%0 or later CPUs">;
 def err_ppc_invalid_use_mma_type : Error<
   "invalid use of PPC MMA type">;
 def err_x86_builtin_invalid_rounding : Error<

diff  --git a/clang/lib/Basic/Targets/PPC.cpp b/clang/lib/Basic/Targets/PPC.cpp
index b77b4a38bc46..514f1a031ae7 100644
--- a/clang/lib/Basic/Targets/PPC.cpp
+++ b/clang/lib/Basic/Targets/PPC.cpp
@@ -73,6 +73,12 @@ bool 
PPCTargetInfo::handleTargetFeatures(std::vector &Features,
   HasROPProtect = true;
 } else if (Feature == "+privileged") {
   HasPrivileged = true;
+} else if (Feature == "+isa-v207-instructions") {
+  IsISA2_07 = true;
+} else if (Feature == "+isa-v30-instructions") {
+  IsISA3_0 = true;
+} else if (Feature == "+isa-v31-instructions") {
+  IsISA3_1 = true;
 }
 // TODO: Finish this list and add an assert that we've handled them
 // all.
@@ -390,6 +396,15 @@ bool PPCTargetInfo::initFeatureMap(
 .Case("e500", true)
 .Default(false);
 
+  Features["isa-v207-instructions"] = llvm::StringSwitch(CPU)
+  .Case("ppc64le", true)
+  .Case("pwr9", true)
+  .Case("pwr8", true)
+  .Default(false);
+
+  Features["isa-v30-instructions"] =
+  llvm::StringSwitch(CPU).Case("pwr9", true).Default(false);
+
   // Power10 includes all the same features as Power9 plus any features 
specific
   // to the Power10 core.
   if (CPU == "pwr10" || CPU == "power10") {
@@ -446,6 +461,7 @@ void PPCTargetInfo::addP10SpecificFeatures(
   Features["power10-vector"] = true;
   Features["pcrelative-memops"] = true;
   Features["prefix-instrs"] = true;
+  Features["isa-v31-instructions"] = true;
   return;
 }
 
@@ -476,6 +492,9 @@ bool PPCTargetInfo::hasFeature(StringRef Feature) const {
   .Case("mma", HasMMA)
   .Case("rop-protect", HasROPProtect)
   .Case("privileged", HasPrivileged)
+  .Case("isa-v207-instructions", IsISA2_07)
+  .Case("isa-v30-instructions", IsISA3_0)
+  .Case("isa-v31-instructions", IsISA3_1)
   .Default(false);
 }
 

diff  --git a/clang/lib/Basic/Targets/PPC.h b/clang/lib/Basic/Targets/PPC.h
index bd79c68ce3f7..7c14a4eb9410 100644
--- a/clang/lib/Basic/Targets/PPC.h
+++ b/clang/lib/Basic/Targets/PPC.h
@@ -74,6 +74,9 @@ class LLVM_LIBRARY_VISIBILITY PPCTargetInfo : public 
TargetInfo {
   bool HasP10Vector = false;
   bool HasPCRelativeMemops = false;
   bool HasPrefixInstrs = false;
+  bool IsISA2_07 = false;
+  bool IsISA3_0 = false;
+  bool IsISA3_1 = false;
 
 protected:
   std::string ABI;

diff  --git a/clang/lib/Sema/SemaChecking.cpp b/clang/lib/Sema/SemaChecking.cpp
index 99621a226dea..062c7eb4a12e 100644
--- a/clang/lib/Sema/SemaChecking.cpp
+++ b/clang/lib/Sema/SemaChecking.cpp
@@ -3275,10 +3275,18 @@ static bool isPPC_64Builtin(unsigned BuiltinID) {
 }
 
 static bool SemaFeatureCheck(Sema &S, CallExpr *TheCall,
- StringRef FeatureToCheck, unsigned DiagID) {
-  if (!S.Context.getTargetInfo().hasFeature(FeatureToCheck))
-return S.Diag(TheCall->getBeginLoc(), DiagID) << TheCall-

[clang] e4585d3 - Revert "[PowerPC][NFC] Power ISA features for Semachecking"

[Victor Huang via cfe-commits]

Author: Victor Huang
Date: 2021-07-13T13:13:34-05:00
New Revision: e4585d3f4e1f076ff12db65259924492f5912b19

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

LOG: Revert "[PowerPC][NFC] Power ISA features for Semachecking"

This reverts commit 10e0cdfc6526578c8892d895c0448e77cb9ba876.

Added: 


Modified: 
clang/include/clang/Basic/DiagnosticSemaKinds.td
clang/lib/Basic/Targets/PPC.cpp
clang/lib/Basic/Targets/PPC.h
clang/lib/Sema/SemaChecking.cpp
llvm/lib/Target/PowerPC/PPC.td
llvm/lib/Target/PowerPC/PPCInstrInfo.td
llvm/lib/Target/PowerPC/PPCSubtarget.cpp
llvm/lib/Target/PowerPC/PPCSubtarget.h

Removed: 




diff  --git a/clang/include/clang/Basic/DiagnosticSemaKinds.td 
b/clang/include/clang/Basic/DiagnosticSemaKinds.td
index 422507cd2842..2d62163e3dcc 100644
--- a/clang/include/clang/Basic/DiagnosticSemaKinds.td
+++ b/clang/include/clang/Basic/DiagnosticSemaKinds.td
@@ -9757,8 +9757,8 @@ def err_mips_builtin_requires_dspr2 : Error<
   "this builtin requires 'dsp r2' ASE, please use -mdspr2">;
 def err_mips_builtin_requires_msa : Error<
   "this builtin requires 'msa' ASE, please use -mmsa">;
-def err_ppc_builtin_only_on_arch : Error<
-  "this builtin is only valid on POWER%0 or later CPUs">;
+def err_ppc_builtin_only_on_pwr7 : Error<
+  "this builtin is only valid on POWER7 or later CPUs">;
 def err_ppc_invalid_use_mma_type : Error<
   "invalid use of PPC MMA type">;
 def err_x86_builtin_invalid_rounding : Error<

diff  --git a/clang/lib/Basic/Targets/PPC.cpp b/clang/lib/Basic/Targets/PPC.cpp
index 514f1a031ae7..b77b4a38bc46 100644
--- a/clang/lib/Basic/Targets/PPC.cpp
+++ b/clang/lib/Basic/Targets/PPC.cpp
@@ -73,12 +73,6 @@ bool 
PPCTargetInfo::handleTargetFeatures(std::vector &Features,
   HasROPProtect = true;
 } else if (Feature == "+privileged") {
   HasPrivileged = true;
-} else if (Feature == "+isa-v207-instructions") {
-  IsISA2_07 = true;
-} else if (Feature == "+isa-v30-instructions") {
-  IsISA3_0 = true;
-} else if (Feature == "+isa-v31-instructions") {
-  IsISA3_1 = true;
 }
 // TODO: Finish this list and add an assert that we've handled them
 // all.
@@ -396,15 +390,6 @@ bool PPCTargetInfo::initFeatureMap(
 .Case("e500", true)
 .Default(false);
 
-  Features["isa-v207-instructions"] = llvm::StringSwitch(CPU)
-  .Case("ppc64le", true)
-  .Case("pwr9", true)
-  .Case("pwr8", true)
-  .Default(false);
-
-  Features["isa-v30-instructions"] =
-  llvm::StringSwitch(CPU).Case("pwr9", true).Default(false);
-
   // Power10 includes all the same features as Power9 plus any features 
specific
   // to the Power10 core.
   if (CPU == "pwr10" || CPU == "power10") {
@@ -461,7 +446,6 @@ void PPCTargetInfo::addP10SpecificFeatures(
   Features["power10-vector"] = true;
   Features["pcrelative-memops"] = true;
   Features["prefix-instrs"] = true;
-  Features["isa-v31-instructions"] = true;
   return;
 }
 
@@ -492,9 +476,6 @@ bool PPCTargetInfo::hasFeature(StringRef Feature) const {
   .Case("mma", HasMMA)
   .Case("rop-protect", HasROPProtect)
   .Case("privileged", HasPrivileged)
-  .Case("isa-v207-instructions", IsISA2_07)
-  .Case("isa-v30-instructions", IsISA3_0)
-  .Case("isa-v31-instructions", IsISA3_1)
   .Default(false);
 }
 

diff  --git a/clang/lib/Basic/Targets/PPC.h b/clang/lib/Basic/Targets/PPC.h
index 7c14a4eb9410..bd79c68ce3f7 100644
--- a/clang/lib/Basic/Targets/PPC.h
+++ b/clang/lib/Basic/Targets/PPC.h
@@ -74,9 +74,6 @@ class LLVM_LIBRARY_VISIBILITY PPCTargetInfo : public 
TargetInfo {
   bool HasP10Vector = false;
   bool HasPCRelativeMemops = false;
   bool HasPrefixInstrs = false;
-  bool IsISA2_07 = false;
-  bool IsISA3_0 = false;
-  bool IsISA3_1 = false;
 
 protected:
   std::string ABI;

diff  --git a/clang/lib/Sema/SemaChecking.cpp b/clang/lib/Sema/SemaChecking.cpp
index 062c7eb4a12e..99621a226dea 100644
--- a/clang/lib/Sema/SemaChecking.cpp
+++ b/clang/lib/Sema/SemaChecking.cpp
@@ -3275,18 +3275,10 @@ static bool isPPC_64Builtin(unsigned BuiltinID) {
 }
 
 static bool SemaFeatureCheck(Sema &S, CallExpr *TheCall,
- StringRef FeatureToCheck, unsigned DiagID,
- StringRef DiagArg = "") {
-  if (S.Context.getTargetInfo().hasFeature(FeatureToCheck))
-return false;
-
-  if (DiagArg.empty())
-S.Diag(TheCall->getBeginLoc(), DiagID) << TheCall->getSourceRange();
-  else
-S.Diag(TheCall->getBeginLoc(), DiagID)
-<< DiagArg << TheCall->getSourceRange();
-
-  return true;
+

[PATCH] D105384: [NVPTX, CUDA] Add .and.popc variant of the b1 MMA instruction.

[Artem Belevich via Phabricator via cfe-commits]

tra updated this revision to Diff 358365.
tra added a comment.

Updated LD/ST generation.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105384

Files:
  clang/include/clang/Basic/BuiltinsNVPTX.def
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/test/CodeGen/builtins-nvptx-mma.cu
  clang/test/CodeGen/builtins-nvptx-mma.py
  llvm/include/llvm/IR/IntrinsicsNVVM.td
  llvm/lib/Target/NVPTX/NVPTXInstrInfo.td
  llvm/lib/Target/NVPTX/NVPTXIntrinsics.td
  llvm/test/CodeGen/NVPTX/wmma.py

Index: llvm/test/CodeGen/NVPTX/wmma.py
===
--- llvm/test/CodeGen/NVPTX/wmma.py
+++ llvm/test/CodeGen/NVPTX/wmma.py
@@ -55,14 +55,14 @@
 # RUN: llc < %t-ptx65-sm_75.ll -march=nvptx64 -mcpu=sm_75 -mattr=+ptx65 \
 # RUN:   | FileCheck %t-ptx65-sm_75.ll
 
-# Check all variants of instructions supported by PTX70 on SM80+
-# RUN: %python %s --ptx=70 --gpu-arch=80 > %t-ptx70-sm_80.ll
-# RUN: FileCheck %t-ptx70-sm_80.ll < %t-ptx70-sm_80.ll \
-# RUN:   --check-prefixes=INTRINSICS,M16N16,EXTGEOM,INT,SUBINT,MMA,ALTFLOAT,DOUBLE,PTX65MMA,PTX70MMA
-# RUN: FileCheck %t-ptx70-sm_80.ll < %t-ptx70-sm_80.ll \
+# Check all variants of instructions supported by PTX71 on SM80+
+# RUN: %python %s --ptx=71 --gpu-arch=80 > %t-ptx71-sm_80.ll
+# RUN: FileCheck %t-ptx71-sm_80.ll < %t-ptx71-sm_80.ll \
+# RUN:   --check-prefixes=INTRINSICS,M16N16,EXTGEOM,INT,SUBINT,MMA,ALTFLOAT,DOUBLE,PTX65MMA,PTX71MMA
+# RUN: FileCheck %t-ptx71-sm_80.ll < %t-ptx71-sm_80.ll \
 # RUN:   --check-prefixes=INTRINSICS
-# RUN: llc < %t-ptx70-sm_80.ll -march=nvptx64 -mcpu=sm_80 -mattr=+ptx70 \
-# RUN:   | FileCheck %t-ptx70-sm_80.ll
+# RUN: llc < %t-ptx71-sm_80.ll -march=nvptx64 -mcpu=sm_80 -mattr=+ptx71 \
+# RUN:   | FileCheck %t-ptx71-sm_80.ll
 
 from __future__ import print_function
 
@@ -649,9 +649,16 @@
   print(Template(mma_template).substitute(test_params))
   return (test_params["intrinsic"], test_params["instruction"])
 
+def get_b1_ops(ptx_type):
+  if ptx_type != "b1":
+return [""]
+  if ptx_version >= 71:
+return [".xor.popc", ".and.popc"]
+  return [".xor.popc"]
+
 def gen_wmma_mma_tests():
-  wmma_intrinsic_template = "llvm.nvvm.wmma.${geom}.mma.${alayout}.${blayout}${rnd}.${intrinsic_signature}${satf}"
-  wmma_instruction_template = "wmma.mma${mma_variant}.sync${aligned}.${alayout}.${blayout}.${geom}${rnd}.${ptx_signature}${satf}"
+  wmma_intrinsic_template = "llvm.nvvm.wmma.${geom}.mma${b1op}.${alayout}.${blayout}${rnd}.${intrinsic_signature}${satf}"
+  wmma_instruction_template = "wmma.mma${b1op}.sync${aligned}.${alayout}.${blayout}.${geom}${rnd}.${ptx_signature}${satf}"
 
   generated_items=[]
 
@@ -665,29 +672,30 @@
 if not is_wmma_variant_supported(op, alayout, blayout, rnd, satf):
   continue
 
-params = {
-"aligned" : ".aligned" if ptx_version >= 63 else "",
-"alayout" : alayout,
-"blayout" : blayout,
-"intrinsic_signature" : wmma_signature(op),
-"ptx_signature" : wmma_ptx_signature(op),
-"satf"  : satf,
-"rnd"   : rnd,
-"geom"  : op.a.geom,
-"mma_variant" : ".xor.popc" if op.a.mma_type.ptx_type == "b1" else "",
-}
+for b1op in get_b1_ops(op.a.mma_type.ptx_type):
+  params = {
+  "aligned" : ".aligned" if ptx_version >= 63 else "",
+  "alayout" : alayout,
+  "blayout" : blayout,
+  "intrinsic_signature" : wmma_signature(op),
+  "ptx_signature" : wmma_ptx_signature(op),
+  "satf"  : satf,
+  "rnd"   : rnd,
+  "geom"  : op.a.geom,
+  "b1op"  : b1op
+  }
 
-intrinsic_template = wmma_intrinsic_template
-instruction_template = wmma_instruction_template
+  intrinsic_template = wmma_intrinsic_template
+  instruction_template = wmma_instruction_template
 
-generated_items.append(common_mma_test_gen(params, op,
-  intrinsic_template, instruction_template))
+  generated_items.append(common_mma_test_gen(params, op,
+ intrinsic_template, instruction_template))
 
   return generated_items
 
 def gen_mma_tests():
-  mma_intrinsic_template = "llvm.nvvm.mma.${geom}.${alayout}.${blayout}${satf}.${intrinsic_signature}"
-  mma_instruction_template = "mma.sync${aligned}.${geom}.${alayout}.${blayout}${satf}.${ptx_signature}${mma_variant}"
+  mma_intrinsic_template = "llvm.nvvm.mma${b1op}.${geom}.${alayout}.${blayout}${satf}.${intrinsic_signature}"
+  mma_instruction_template = "mma.sync${aligned}.${geom}.${alayout}.${blayout}${satf}.${ptx_signature}${b1op}"
 
   generated_items=[]
 
@@ -700,22 +708,23 @@
 if not is_mma_variant_supported(op, alayout, blayout, satf):
   continue
 
-params = {
-"aligned" : ".aligned" if ptx_version >= 63 else "",
-"alayout" : alayout,
-"blayout" : blayout,
-"intrinsic_

[PATCH] D104058: ThinLTO: Fix inline assembly references to static functions with CFI

[Sami Tolvanen via Phabricator via cfe-commits]

samitolvanen updated this revision to Diff 358364.
samitolvanen added a comment.

Moved the alias creation to module level inline assembly to avoid issues with 
LowerTypeTestsModule, based on pcc's suggestion.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104058

Files:
  llvm/lib/Transforms/IPO/ThinLTOBitcodeWriter.cpp
  llvm/test/ThinLTO/X86/devirt2.ll
  llvm/test/Transforms/ThinLTOBitcodeWriter/cfi-icall-static-inline-asm.ll
  llvm/test/Transforms/ThinLTOBitcodeWriter/split-internal2.ll
  llvm/test/Transforms/ThinLTOBitcodeWriter/split-vfunc-internal.ll

Index: llvm/test/Transforms/ThinLTOBitcodeWriter/split-vfunc-internal.ll
===
--- llvm/test/Transforms/ThinLTOBitcodeWriter/split-vfunc-internal.ll
+++ llvm/test/Transforms/ThinLTOBitcodeWriter/split-vfunc-internal.ll
@@ -2,6 +2,8 @@
 ; RUN: llvm-modextract -b -n 0 -o - %t | llvm-dis | FileCheck --check-prefix=M0 %s
 ; RUN: llvm-modextract -b -n 1 -o - %t | llvm-dis | FileCheck --check-prefix=M1 %s
 
+target triple = "x86_64-unknown-linux-gnu"
+
 define [1 x i8*]* @source() {
   ret [1 x i8*]* @g
 }
Index: llvm/test/Transforms/ThinLTOBitcodeWriter/split-internal2.ll
===
--- llvm/test/Transforms/ThinLTOBitcodeWriter/split-internal2.ll
+++ llvm/test/Transforms/ThinLTOBitcodeWriter/split-internal2.ll
@@ -7,6 +7,8 @@
 ; RUN: llvm-bcanalyzer -dump %t0 | FileCheck --check-prefix=BCA0 %s
 ; RUN: llvm-bcanalyzer -dump %t1 | FileCheck --check-prefix=BCA1 %s
 
+target triple = "x86_64-unknown-linux-gnu"
+
 ; ERROR: llvm-modextract: error: module index out of range; bitcode file contains 2 module(s)
 
 ; BCA0: setName(NewName);
   ImportGV->setVisibility(GlobalValue::HiddenVisibility);
 }
+
+if (Function *F = dyn_cast(&ExportGV)) {
+  // Create a local alias with the original name to avoid breaking
+  // references from inline assembly.
+  std::string Alias = ".set " + OldName + "," + NewName + "\n";
+  ExportM.appendModuleInlineAsm(Alias);
+}
   }
 
   if (!RenamedComdats.empty())
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D105629: [TSan] Add SystemZ support

[Ilya Leoshkevich via Phabricator via cfe-commits]

iii updated this revision to Diff 358363.
iii added a comment.

Based on Ulrich's feedback I tested the series on RHEL7, which, in
addition to an old kernel, contains an old glibc and an old toolchain.
This uncovered a few extra issues, which are fixed here:

- Call __tls_get_offset() in order to force TLS allocation.
- Align thread_registry_placeholder.
- Protect the address space "tail" in two steps: until the 4-level page table 
boundary (this must succeed) and then until the 5-level page table boundary 
(this may fail).

Also, the Go support is finally working
(https://github.com/iii-i/go/tree/tsan-s390x), so, since we need to
make another round anyway, I've included the LLVM part here as well.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105629

Files:
  clang/lib/Driver/ToolChains/Linux.cpp
  compiler-rt/cmake/config-ix.cmake
  compiler-rt/lib/sanitizer_common/sanitizer_common_interceptors.inc
  compiler-rt/lib/sanitizer_common/sanitizer_linux.cpp
  compiler-rt/lib/sanitizer_common/sanitizer_linux_libcdep.cpp
  compiler-rt/lib/sanitizer_common/sanitizer_platform_limits_posix.h
  compiler-rt/lib/tsan/CMakeLists.txt
  compiler-rt/lib/tsan/go/buildgo.sh
  compiler-rt/lib/tsan/rtl/tsan_interceptors_posix.cpp
  compiler-rt/lib/tsan/rtl/tsan_interface.h
  compiler-rt/lib/tsan/rtl/tsan_platform.h
  compiler-rt/lib/tsan/rtl/tsan_platform_linux.cpp
  compiler-rt/lib/tsan/rtl/tsan_platform_posix.cpp
  compiler-rt/lib/tsan/rtl/tsan_rtl.cpp
  compiler-rt/lib/tsan/rtl/tsan_rtl_s390x.S
  compiler-rt/test/tsan/CMakeLists.txt
  compiler-rt/test/tsan/ignore_lib0.cpp
  compiler-rt/test/tsan/ignore_lib1.cpp
  compiler-rt/test/tsan/ignore_lib5.cpp
  compiler-rt/test/tsan/map32bit.cpp
  compiler-rt/test/tsan/mmap_large.cpp
  llvm/lib/Transforms/Instrumentation/ThreadSanitizer.cpp
  llvm/utils/gn/secondary/compiler-rt/lib/tsan/BUILD.gn

Index: llvm/utils/gn/secondary/compiler-rt/lib/tsan/BUILD.gn
===
--- llvm/utils/gn/secondary/compiler-rt/lib/tsan/BUILD.gn
+++ llvm/utils/gn/secondary/compiler-rt/lib/tsan/BUILD.gn
@@ -125,6 +125,8 @@
 sources += [ "rtl/tsan_rtl_ppc64.S" ]
   } else if (target_cpu == "mips64") {
 sources += [ "rtl/tsan_rtl_mips64.S" ]
+  } else if (target_cpu == "s390x") {
+sources += [ "rtl/tsan_rtl_s390x.S" ]
   }
 
   # To be able to include sanitizer_common.
Index: llvm/lib/Transforms/Instrumentation/ThreadSanitizer.cpp
===
--- llvm/lib/Transforms/Instrumentation/ThreadSanitizer.cpp
+++ llvm/lib/Transforms/Instrumentation/ThreadSanitizer.cpp
@@ -312,12 +312,21 @@
 Type *Ty = Type::getIntNTy(M.getContext(), BitSize);
 Type *PtrTy = Ty->getPointerTo();
 SmallString<32> AtomicLoadName("__tsan_atomic" + BitSizeStr + "_load");
-TsanAtomicLoad[i] =
-M.getOrInsertFunction(AtomicLoadName, Attr, Ty, PtrTy, OrdTy);
+{
+  AttributeList AL = Attr;
+  AL = AL.addParamAttribute(M.getContext(), 1, Attribute::ZExt);
+  TsanAtomicLoad[i] =
+  M.getOrInsertFunction(AtomicLoadName, AL, Ty, PtrTy, OrdTy);
+}
 
 SmallString<32> AtomicStoreName("__tsan_atomic" + BitSizeStr + "_store");
-TsanAtomicStore[i] = M.getOrInsertFunction(
-AtomicStoreName, Attr, IRB.getVoidTy(), PtrTy, Ty, OrdTy);
+{
+  AttributeList AL = Attr;
+  AL = AL.addParamAttribute(M.getContext(), 1, Attribute::ZExt);
+  AL = AL.addParamAttribute(M.getContext(), 2, Attribute::ZExt);
+  TsanAtomicStore[i] = M.getOrInsertFunction(
+  AtomicStoreName, AL, IRB.getVoidTy(), PtrTy, Ty, OrdTy);
+}
 
 for (unsigned Op = AtomicRMWInst::FIRST_BINOP;
  Op <= AtomicRMWInst::LAST_BINOP; ++Op) {
@@ -340,24 +349,44 @@
   else
 continue;
   SmallString<32> RMWName("__tsan_atomic" + itostr(BitSize) + NamePart);
-  TsanAtomicRMW[Op][i] =
-  M.getOrInsertFunction(RMWName, Attr, Ty, PtrTy, Ty, OrdTy);
+  {
+AttributeList AL = Attr;
+AL = AL.addParamAttribute(M.getContext(), 1, Attribute::ZExt);
+AL = AL.addParamAttribute(M.getContext(), 2, Attribute::ZExt);
+TsanAtomicRMW[Op][i] =
+M.getOrInsertFunction(RMWName, AL, Ty, PtrTy, Ty, OrdTy);
+  }
 }
 
 SmallString<32> AtomicCASName("__tsan_atomic" + BitSizeStr +
   "_compare_exchange_val");
-TsanAtomicCAS[i] = M.getOrInsertFunction(AtomicCASName, Attr, Ty, PtrTy, Ty,
- Ty, OrdTy, OrdTy);
+{
+  AttributeList AL = Attr;
+  AL = AL.addParamAttribute(M.getContext(), 1, Attribute::ZExt);
+  AL = AL.addParamAttribute(M.getContext(), 2, Attribute::ZExt);
+  AL = AL.addParamAttribute(M.getContext(), 3, Attribute::ZExt);
+  AL = AL.addParamAttribute(M.getContext(), 4, Attribute::ZExt);
+  TsanAtomicCAS[i] = M.get

[PATCH] D105439: [clang] protects users from relying on libc++ detail headers

[Christopher Di Bella via Phabricator via cfe-commits]

cjdb added a comment.

In D105439#2874733 , @lebedev.ri 
wrote:

> In D105439#2874706 , @ldionne wrote:
>
>> I'm not entirely sure I understand the purpose of this patch. So the idea is 
>> that let's say a tool suggests including `<__algorithm/find.h>` to get the 
>> definition of `std::find` as a IWYU fix-it sort of suggestion, the user 
>> would naively do that, and then the compiler (with this patch) would error 
>> out saying "woops, you can't include that libc++ detail header". Is that the 
>> idea?
>>
>> If that's it, then I would much rather fix the tools that incorrectly 
>> suggest including those implementation detail headers in the first place. 
>> Users will be less confused and we won't have to special-case a special 
>> directory name, which I can imagine could cause issues. I think it's great 
>> to try and give the proper diagnostic to users, but I think the correct 
>> place to do that is in the tool that suggests it in the first place. 
>> Thoughts?
>
> Regardless of whether this is about enhacing IWYU QoL or completely 
> preventing inclusion of separate sub-headers,
> it seems like that should be done in libc++ itself, it already has the means 
> for that.

I've already pointed out that it can't be done in libc++. The proposed header 
alternative doesn't translate to Clang modules, and private modules tank build 
times.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105439

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

[PATCH] D105439: [clang] protects users from relying on libc++ detail headers

[Christopher Di Bella via Phabricator via cfe-commits]

cjdb added a comment.

In D105439#2874706 , @ldionne wrote:

> I'm not entirely sure I understand the purpose of this patch. So the idea is 
> that let's say a tool suggests including `<__algorithm/find.h>` to get the 
> definition of `std::find` as a IWYU fix-it sort of suggestion, the user would 
> naively do that, and then the compiler (with this patch) would error out 
> saying "woops, you can't include that libc++ detail header". Is that the idea?
>
> If that's it, then I would much rather fix the tools that incorrectly suggest 
> including those implementation detail headers in the first place. ... I think 
> it's great to try and give the proper diagnostic to users, but I think the 
> correct place to do that is in the tool that suggests it in the first place. 
> Thoughts?

There's way more reviewer focus on tooling in this patch than there should be. 
Fixing non-LLVM tools is not a feasible request: I barely have enough time to 
try and make sure that LLVM tooling is going to respond to our libc++ changes. 
The point of this patch is to help //users// in a variety of situations.

1. They explicitly include a detail libc++ header. I've observed this quite 
frequently with the `bits/` headers in libstdc++, and even Boost, and while it 
might seem like a good idea at the time, it's going to inevitably cause pain 
down the road (as I have experienced when trying to upgrade an employer's Boost 
library). This is akin to wearing a seatbelt.
2. Tools that auto-include the detail thing and then get checked into a 
library's trunk without the author noticing (this happens to me more often than 
I'd care to admit). This can impact downstream users. I don't really have a 
good car analogy for this situation, but it lowers the chance for negligence.
  1. Yes, tool QoI is important and should be fixed too, but //people// have a 
habit of trusting their tools, and this is a good way to get tools to improve 
their QoI.
  2. Putting the burden on tooling also doesn't take into consideration that 
some people are neurodiverse, and it might be difficult for them to even 
remember to go back and check that the "IWYU fix-it" is correct. That's not 
complacency or naivety or inexperience; this is how some people's brains are 
hardwired.
3. Hyrum's law is boss here. It doesn't matter how much we improve external 
tooling: if a user //can// include our details, some folks inevitably will.

> Users will be less confused and we won't have to special-case a special 
> directory name, which I can imagine could cause issues.

I'm not sure why users will be more confused if we do this?

-

I do plan to improve QoI for LLVM tooling in other areas, but this patch is 
essentially a catch-all handbrake. It's best if you put attention on people, 
and human behaviour: this is a human problem that I'm trying to solve, not a 
technical one.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105439

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

[PATCH] D69764: [clang-format] Add East/West Const fixer capability

[MyDeveloperDay via Phabricator via cfe-commits]

MyDeveloperDay added a comment.

> so there's something like precedent here

I think its worth mentioning, that my personal preference would STILL be to 
land this inside clang-format with default configuration of "OFF", where there 
is also significant existing precedent for passes that change non whitespace 
and even add tokens.

I still believe clang-format is the best location, I think its the most 
optimal, and I think its the fairest (because those that want it get it, and 
those that don't aren't forced to have it). But doing this as another tool 
would be a `compromise`, in my view an inferior one to it being in 
clang-format, but at least we could set out clear goals where allowing code 
modification was the intent (as this seems to be the major sticking point)

I would be interested to know how many people would be unhappy if we stated 
that "sorting includes" and "namespace comments" had to be removed from 
clang-format and into the new tool! I am thinking it would be fairly 
significant. (I'm not suggesting we would, just making a point)

So you know, I'm pushing because I'm being ask privately to land this, because 
I assume people want to use it, but maybe don't want to voice their opinions 
publicly.

I don't want to fragment the community by pushing an agenda (something I see 
you seem to care about),  but I would also like to think that those of us who 
contribute to clang-format regularly can help shape a future for it moving 
forward.


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

https://reviews.llvm.org/D69764

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

[PATCH] D105295: [CUDA] Only allow NVIDIA offload-arch during CUDA compilation.

[Artem Belevich 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 rG01d3a3dcabaf: [CUDA] Only allow NVIDIA offload-arch during 
CUDA compilation. (authored by tra).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105295

Files:
  clang/lib/Driver/Driver.cpp
  clang/test/Driver/cuda-bad-arch.cu


Index: clang/test/Driver/cuda-bad-arch.cu
===
--- clang/test/Driver/cuda-bad-arch.cu
+++ clang/test/Driver/cuda-bad-arch.cu
@@ -10,6 +10,8 @@
 // RUN: | FileCheck -check-prefix BAD %s
 // RUN: %clang -### -target x86_64-linux-gnu --cuda-gpu-arch=sm_19 -c %s 2>&1 \
 // RUN: | FileCheck -check-prefix BAD %s
+// RUN: %clang -### -target x86_64-linux-gnu --cuda-gpu-arch=gfx900 -c %s 2>&1 
\
+// RUN: | FileCheck -check-prefix BAD %s
 
 // BAD: error: Unsupported CUDA gpu architecture
 
Index: clang/lib/Driver/Driver.cpp
===
--- clang/lib/Driver/Driver.cpp
+++ clang/lib/Driver/Driver.cpp
@@ -2785,7 +2785,7 @@
 
 StringRef getCanonicalOffloadArch(StringRef ArchStr) override {
   CudaArch Arch = StringToCudaArch(ArchStr);
-  if (Arch == CudaArch::UNKNOWN) {
+  if (Arch == CudaArch::UNKNOWN || !IsNVIDIAGpuArch(Arch)) {
 C.getDriver().Diag(clang::diag::err_drv_cuda_bad_gpu_arch) << ArchStr;
 return StringRef();
   }


Index: clang/test/Driver/cuda-bad-arch.cu
===
--- clang/test/Driver/cuda-bad-arch.cu
+++ clang/test/Driver/cuda-bad-arch.cu
@@ -10,6 +10,8 @@
 // RUN: | FileCheck -check-prefix BAD %s
 // RUN: %clang -### -target x86_64-linux-gnu --cuda-gpu-arch=sm_19 -c %s 2>&1 \
 // RUN: | FileCheck -check-prefix BAD %s
+// RUN: %clang -### -target x86_64-linux-gnu --cuda-gpu-arch=gfx900 -c %s 2>&1 \
+// RUN: | FileCheck -check-prefix BAD %s
 
 // BAD: error: Unsupported CUDA gpu architecture
 
Index: clang/lib/Driver/Driver.cpp
===
--- clang/lib/Driver/Driver.cpp
+++ clang/lib/Driver/Driver.cpp
@@ -2785,7 +2785,7 @@
 
 StringRef getCanonicalOffloadArch(StringRef ArchStr) override {
   CudaArch Arch = StringToCudaArch(ArchStr);
-  if (Arch == CudaArch::UNKNOWN) {
+  if (Arch == CudaArch::UNKNOWN || !IsNVIDIAGpuArch(Arch)) {
 C.getDriver().Diag(clang::diag::err_drv_cuda_bad_gpu_arch) << ArchStr;
 return StringRef();
   }
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] 01d3a3d - [CUDA] Only allow NVIDIA offload-arch during CUDA compilation.

[Artem Belevich via cfe-commits]

Author: Artem Belevich
Date: 2021-07-13T11:09:14-07:00
New Revision: 01d3a3dcabaf862581b1d1aee604fcee6a18b240

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

LOG: [CUDA] Only allow NVIDIA offload-arch during CUDA compilation.

Otherwise, if someone specifies a valid AMD arch, we may end up triggering an
assertion on unexpected arch later on.

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

Added: 


Modified: 
clang/lib/Driver/Driver.cpp
clang/test/Driver/cuda-bad-arch.cu

Removed: 




diff  --git a/clang/lib/Driver/Driver.cpp b/clang/lib/Driver/Driver.cpp
index 6ea6e2e47e639..cbc853370e89d 100644
--- a/clang/lib/Driver/Driver.cpp
+++ b/clang/lib/Driver/Driver.cpp
@@ -2785,7 +2785,7 @@ class OffloadingActionBuilder final {
 
 StringRef getCanonicalOffloadArch(StringRef ArchStr) override {
   CudaArch Arch = StringToCudaArch(ArchStr);
-  if (Arch == CudaArch::UNKNOWN) {
+  if (Arch == CudaArch::UNKNOWN || !IsNVIDIAGpuArch(Arch)) {
 C.getDriver().Diag(clang::diag::err_drv_cuda_bad_gpu_arch) << ArchStr;
 return StringRef();
   }

diff  --git a/clang/test/Driver/cuda-bad-arch.cu 
b/clang/test/Driver/cuda-bad-arch.cu
index 22a7be1e7d839..b60a04162b2e8 100644
--- a/clang/test/Driver/cuda-bad-arch.cu
+++ b/clang/test/Driver/cuda-bad-arch.cu
@@ -10,6 +10,8 @@
 // RUN: | FileCheck -check-prefix BAD %s
 // RUN: %clang -### -target x86_64-linux-gnu --cuda-gpu-arch=sm_19 -c %s 2>&1 \
 // RUN: | FileCheck -check-prefix BAD %s
+// RUN: %clang -### -target x86_64-linux-gnu --cuda-gpu-arch=gfx900 -c %s 2>&1 
\
+// RUN: | FileCheck -check-prefix BAD %s
 
 // BAD: error: Unsupported CUDA gpu architecture
 



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

[PATCH] D105457: [clang] Refactor AST printing tests to share more infrastructure

[Nathan Ridge via Phabricator via cfe-commits]

nridge added a comment.

To be honest, I don't really understand this error. It seems to come from a 
compile step (not a link step), and it comes from the assembler and says 
"symbol ... is already defined"? I don't think I've seen an error like that 
before. (Typically, errors about duplicate definitions would come from the 
linker.)

Any suggestions for what it might indicate or how to investigate are welcome.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105457

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

[PATCH] D105693: [analyzer][solver][NFC] Refactor how we detect (dis)equalities

[Valeriy Savchenko 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 rG60bd8cbc0c84: [analyzer][solver][NFC] Refactor how we detect 
(dis)equalities (authored by vsavchenko).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105693

Files:
  clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp
  clang/test/Analysis/equality_tracking.c

Index: clang/test/Analysis/equality_tracking.c
===
--- clang/test/Analysis/equality_tracking.c
+++ clang/test/Analysis/equality_tracking.c
@@ -219,3 +219,17 @@
   if (c < 0)
 ;
 }
+
+void implyDisequalityFromGT(int a, int b) {
+  if (a > b) {
+clang_analyzer_eval(a == b); // expected-warning{{FALSE}}
+clang_analyzer_eval(a != b); // expected-warning{{TRUE}}
+  }
+}
+
+void implyDisequalityFromLT(int a, int b) {
+  if (a < b) {
+clang_analyzer_eval(a == b); // expected-warning{{FALSE}}
+clang_analyzer_eval(a != b); // expected-warning{{TRUE}}
+  }
+}
Index: clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp
===
--- clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp
+++ clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp
@@ -684,58 +684,30 @@
 //   Equality/diseqiality abstraction
 //===--===//
 
-/// A small helper structure representing symbolic equality.
+/// A small helper function for detecting symbolic (dis)equality.
 ///
 /// Equality check can have different forms (like a == b or a - b) and this
 /// class encapsulates those away if the only thing the user wants to check -
-/// whether it's equality/diseqiality or not and have an easy access to the
-/// compared symbols.
-struct EqualityInfo {
-public:
-  SymbolRef Left, Right;
-  // true for equality and false for disequality.
-  bool IsEquality = true;
-
-  void invert() { IsEquality = !IsEquality; }
-  /// Extract equality information from the given symbol and the constants.
-  ///
-  /// This function assumes the following expression Sym + Adjustment != Int.
-  /// It is a default because the most widespread case of the equality check
-  /// is (A == B) + 0 != 0.
-  static Optional extract(SymbolRef Sym, const llvm::APSInt &Int,
-const llvm::APSInt &Adjustment) {
-// As of now, the only equality form supported is Sym + 0 != 0.
-if (!Int.isNullValue() || !Adjustment.isNullValue())
-  return llvm::None;
-
-return extract(Sym);
-  }
-  /// Extract equality information from the given symbol.
-  static Optional extract(SymbolRef Sym) {
-return EqualityExtractor().Visit(Sym);
+/// whether it's equality/diseqiality or not.
+///
+/// \returns true if assuming this Sym to be true means equality of operands
+///  false if it means disequality of operands
+///  None otherwise
+Optional meansEquality(const SymSymExpr *Sym) {
+  switch (Sym->getOpcode()) {
+  case BO_Sub:
+// This case is: A - B != 0 -> disequality check.
+return false;
+  case BO_EQ:
+// This case is: A == B != 0 -> equality check.
+return true;
+  case BO_NE:
+// This case is: A != B != 0 -> diseqiality check.
+return false;
+  default:
+return llvm::None;
   }
-
-private:
-  class EqualityExtractor
-  : public SymExprVisitor> {
-  public:
-Optional VisitSymSymExpr(const SymSymExpr *Sym) const {
-  switch (Sym->getOpcode()) {
-  case BO_Sub:
-// This case is: A - B != 0 -> disequality check.
-return EqualityInfo{Sym->getLHS(), Sym->getRHS(), false};
-  case BO_EQ:
-// This case is: A == B != 0 -> equality check.
-return EqualityInfo{Sym->getLHS(), Sym->getRHS(), true};
-  case BO_NE:
-// This case is: A != B != 0 -> diseqiality check.
-return EqualityInfo{Sym->getLHS(), Sym->getRHS(), false};
-  default:
-return llvm::None;
-  }
-}
-  };
-};
+}
 
 //===--===//
 //Intersection functions
@@ -866,7 +838,13 @@
   }
 
   RangeSet VisitSymSymExpr(const SymSymExpr *Sym) {
-return VisitBinaryOperator(Sym);
+return intersect(
+RangeFactory,
+// If Sym is (dis)equality, we might have some information
+// on that in our equality classes data structure.
+getRangeForEqualities(Sym),
+// And we should always check what we can get from the operands.
+VisitBinaryOperator(Sym));
   }
 
 private:
@@ -907,9 +885,6 @@
 // calculate the effective range set by intersecting the range set
 // for A - B and the negated range set of B - A.
 getRangeForNegatedSub(Sym),
-// If Sym is (dis)equality, we mi

[PATCH] D105692: [analyzer][solver][NFC] Introduce ConstraintAssignor

[Valeriy Savchenko 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 rGf26deb4e6ba7: [analyzer][solver][NFC] Introduce 
ConstraintAssignor (authored by vsavchenko).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105692

Files:
  clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp

Index: clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp
===
--- clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp
+++ clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp
@@ -669,6 +669,17 @@
   return getConstraint(State, EquivalenceClass::find(State, Sym));
 }
 
+LLVM_NODISCARD ProgramStateRef setConstraint(ProgramStateRef State,
+ EquivalenceClass Class,
+ RangeSet Constraint) {
+  return State->set(Class, Constraint);
+}
+
+LLVM_NODISCARD ProgramStateRef setConstraints(ProgramStateRef State,
+  ConstraintRangeTy Constraints) {
+  return State->set(Constraints);
+}
+
 //===--===//
 //   Equality/diseqiality abstraction
 //===--===//
@@ -1373,6 +1384,182 @@
   return {RangeFactory, ValueFactory.getValue(Min), ValueFactory.getValue(Max)};
 }
 
+//===--===//
+// Constraint assignment logic
+//===--===//
+
+/// ConstraintAssignorBase is a small utility class that unifies visitor
+/// for ranges with a visitor for constraints (rangeset/range/constant).
+///
+/// It is designed to have one derived class, but generally it can have more.
+/// Derived class can control which types we handle by defining methods of the
+/// following form:
+///
+///   bool handle${SYMBOL}To${CONSTRAINT}(const SYMBOL *Sym,
+///   CONSTRAINT Constraint);
+///
+/// where SYMBOL is the type of the symbol (e.g. SymSymExpr, SymbolCast, etc.)
+///   CONSTRAINT is the type of constraint (RangeSet/Range/Const)
+///   return value signifies whether we should try other handle methods
+///  (i.e. false would mean to stop right after calling this method)
+template  class ConstraintAssignorBase {
+public:
+  using Const = const llvm::APSInt &;
+
+#define DISPATCH(CLASS) return assign##CLASS##Impl(cast(Sym), Constraint)
+
+#define ASSIGN(CLASS, TO, SYM, CONSTRAINT) \
+  if (!static_cast(this)->assign##CLASS##To##TO(SYM, CONSTRAINT))   \
+  return false
+
+  void assign(SymbolRef Sym, RangeSet Constraint) {
+assignImpl(Sym, Constraint);
+  }
+
+  bool assignImpl(SymbolRef Sym, RangeSet Constraint) {
+switch (Sym->getKind()) {
+#define SYMBOL(Id, Parent) \
+  case SymExpr::Id##Kind:  \
+DISPATCH(Id);
+#include "clang/StaticAnalyzer/Core/PathSensitive/Symbols.def"
+}
+llvm_unreachable("Unknown SymExpr kind!");
+  }
+
+#define DEFAULT_ASSIGN(Id) \
+  bool assign##Id##To##RangeSet(const Id *Sym, RangeSet Constraint) {  \
+return true;   \
+  }\
+  bool assign##Id##To##Range(const Id *Sym, Range Constraint) { return true; } \
+  bool assign##Id##To##Const(const Id *Sym, Const Constraint) { return true; }
+
+  // When we dispatch for constraint types, we first try to check
+  // if the new constraint is the constant and try the corresponding
+  // assignor methods.  If it didn't interrupt, we can proceed to the
+  // range, and finally to the range set.
+#define CONSTRAINT_DISPATCH(Id)\
+  if (const llvm::APSInt *Const = Constraint.getConcreteValue()) { \
+ASSIGN(Id, Const, Sym, *Const);\
+  }\
+  if (Constraint.size() == 1) {\
+ASSIGN(Id, Range, Sym, *Constraint.begin());   \
+  }\
+  ASSIGN(Id, RangeSet, Sym, Constraint)
+
+  // Our internal assign method first tries to call assignor methods for all
+  // constraint types that apply.  And if not interrupted, continues with its
+  // parent class.
+#define SYMBOL(Id, Parent)   

[clang] f26deb4 - [analyzer][solver][NFC] Introduce ConstraintAssignor

[Valeriy Savchenko via cfe-commits]

Author: Valeriy Savchenko
Date: 2021-07-13T21:00:30+03:00
New Revision: f26deb4e6ba7e00c57b4be888c4d20c95a881154

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

LOG: [analyzer][solver][NFC] Introduce ConstraintAssignor

The new component is a symmetric response to SymbolicRangeInferrer.
While the latter is the unified component, which answers all the
questions what does the solver knows about a particular symbolic
expression, assignor associates new constraints (aka "assumes")
with symbolic expressions and can imply additional knowledge that
the solver can extract and use later on.

- Why do we need it and why is SymbolicRangeInferrer not enough?

As it is noted before, the inferrer only helps us to get the most
precise range information based on the existing knowledge and on the
mathematical foundations of different operations that symbolic
expressions actually represent.  It doesn't introduce new constraints.

The assignor, on the other hand, can impose constraints on other
symbols using the same domain knowledge.

- But for some expressions, SymbolicRangeInferrer looks into constraints
  for similar expressions, why can't we do that for all the cases?

That's correct!  But in order to do something like this, we should
have a finite number of possible "similar expressions".

Let's say we are asked about `$a - $b` and we know something about
`$b - $a`.  The inferrer can invert this expression and check
constraints for `$b - $a`.  This is simple!
But let's say we are asked about `$a` and we know that `$a * $b != 0`.
In this situation, we can imply that `$a != 0`, but the inferrer shouldn't
try every possible symbolic expression `X` to check if `$a * X` or
`X * $a` is constrained to non-zero.

With the assignor mechanism, we can catch this implication right at
the moment we associate `$a * $b` with non-zero range, and set similar
constraints for `$a` and `$b` as well.

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

Added: 


Modified: 
clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp

Removed: 




diff  --git a/clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp 
b/clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp
index bc8c83132c5d7..803cc5efd0c1e 100644
--- a/clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp
+++ b/clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp
@@ -669,6 +669,17 @@ LLVM_NODISCARD inline const RangeSet 
*getConstraint(ProgramStateRef State,
   return getConstraint(State, EquivalenceClass::find(State, Sym));
 }
 
+LLVM_NODISCARD ProgramStateRef setConstraint(ProgramStateRef State,
+ EquivalenceClass Class,
+ RangeSet Constraint) {
+  return State->set(Class, Constraint);
+}
+
+LLVM_NODISCARD ProgramStateRef setConstraints(ProgramStateRef State,
+  ConstraintRangeTy Constraints) {
+  return State->set(Constraints);
+}
+
 
//===--===//
 //   Equality/diseqiality abstraction
 
//===--===//
@@ -1373,6 +1384,182 @@ RangeSet 
SymbolicRangeInferrer::VisitBinaryOperator(Range LHS,
   return {RangeFactory, ValueFactory.getValue(Min), 
ValueFactory.getValue(Max)};
 }
 
+//===--===//
+// Constraint assignment logic
+//===--===//
+
+/// ConstraintAssignorBase is a small utility class that unifies visitor
+/// for ranges with a visitor for constraints (rangeset/range/constant).
+///
+/// It is designed to have one derived class, but generally it can have more.
+/// Derived class can control which types we handle by defining methods of the
+/// following form:
+///
+///   bool handle${SYMBOL}To${CONSTRAINT}(const SYMBOL *Sym,
+///   CONSTRAINT Constraint);
+///
+/// where SYMBOL is the type of the symbol (e.g. SymSymExpr, SymbolCast, etc.)
+///   CONSTRAINT is the type of constraint (RangeSet/Range/Const)
+///   return value signifies whether we should try other handle methods
+///  (i.e. false would mean to stop right after calling this method)
+template  class ConstraintAssignorBase {
+public:
+  using Const = const llvm::APSInt &;
+
+#define DISPATCH(CLASS) return assign##CLASS##Impl(cast(Sym), 
Constraint)
+
+#define ASSIGN(CLASS, TO, SYM, CONSTRAINT) 
\
+  if (!static_cast(this)->assign##CLASS##To##TO(SYM, CONSTRAINT))   
\
+  return false
+
+  void assign(SymbolRef Sym, RangeSet Constraint) {
+  

[clang] 60bd8cb - [analyzer][solver][NFC] Refactor how we detect (dis)equalities

[Valeriy Savchenko via cfe-commits]

Author: Valeriy Savchenko
Date: 2021-07-13T21:00:30+03:00
New Revision: 60bd8cbc0c84a41146b1ad6c832fa75f48cd2568

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

LOG: [analyzer][solver][NFC] Refactor how we detect (dis)equalities

This patch simplifies the way we deal with (dis)equalities.
Due to the symmetry between constraint handler and range inferrer,
we can have very similar implementations of logic handling
questions about (dis)equality and assumptions involving (dis)equality.

It also helps us to remove one more visitor, and removes uncertainty
that we got all the right places to put `trackNE` and `trackEQ`.

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

Added: 


Modified: 
clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp
clang/test/Analysis/equality_tracking.c

Removed: 




diff  --git a/clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp 
b/clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp
index 803cc5efd0c1..9e014e9fce4e 100644
--- a/clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp
+++ b/clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp
@@ -684,58 +684,30 @@ LLVM_NODISCARD ProgramStateRef 
setConstraints(ProgramStateRef State,
 //   Equality/diseqiality abstraction
 
//===--===//
 
-/// A small helper structure representing symbolic equality.
+/// A small helper function for detecting symbolic (dis)equality.
 ///
 /// Equality check can have 
diff erent forms (like a == b or a - b) and this
 /// class encapsulates those away if the only thing the user wants to check -
-/// whether it's equality/diseqiality or not and have an easy access to the
-/// compared symbols.
-struct EqualityInfo {
-public:
-  SymbolRef Left, Right;
-  // true for equality and false for disequality.
-  bool IsEquality = true;
-
-  void invert() { IsEquality = !IsEquality; }
-  /// Extract equality information from the given symbol and the constants.
-  ///
-  /// This function assumes the following expression Sym + Adjustment != Int.
-  /// It is a default because the most widespread case of the equality check
-  /// is (A == B) + 0 != 0.
-  static Optional extract(SymbolRef Sym, const llvm::APSInt &Int,
-const llvm::APSInt &Adjustment) {
-// As of now, the only equality form supported is Sym + 0 != 0.
-if (!Int.isNullValue() || !Adjustment.isNullValue())
-  return llvm::None;
-
-return extract(Sym);
-  }
-  /// Extract equality information from the given symbol.
-  static Optional extract(SymbolRef Sym) {
-return EqualityExtractor().Visit(Sym);
+/// whether it's equality/diseqiality or not.
+///
+/// \returns true if assuming this Sym to be true means equality of operands
+///  false if it means disequality of operands
+///  None otherwise
+Optional meansEquality(const SymSymExpr *Sym) {
+  switch (Sym->getOpcode()) {
+  case BO_Sub:
+// This case is: A - B != 0 -> disequality check.
+return false;
+  case BO_EQ:
+// This case is: A == B != 0 -> equality check.
+return true;
+  case BO_NE:
+// This case is: A != B != 0 -> diseqiality check.
+return false;
+  default:
+return llvm::None;
   }
-
-private:
-  class EqualityExtractor
-  : public SymExprVisitor> {
-  public:
-Optional VisitSymSymExpr(const SymSymExpr *Sym) const {
-  switch (Sym->getOpcode()) {
-  case BO_Sub:
-// This case is: A - B != 0 -> disequality check.
-return EqualityInfo{Sym->getLHS(), Sym->getRHS(), false};
-  case BO_EQ:
-// This case is: A == B != 0 -> equality check.
-return EqualityInfo{Sym->getLHS(), Sym->getRHS(), true};
-  case BO_NE:
-// This case is: A != B != 0 -> diseqiality check.
-return EqualityInfo{Sym->getLHS(), Sym->getRHS(), false};
-  default:
-return llvm::None;
-  }
-}
-  };
-};
+}
 
 
//===--===//
 //Intersection functions
@@ -866,7 +838,13 @@ class SymbolicRangeInferrer
   }
 
   RangeSet VisitSymSymExpr(const SymSymExpr *Sym) {
-return VisitBinaryOperator(Sym);
+return intersect(
+RangeFactory,
+// If Sym is (dis)equality, we might have some information
+// on that in our equality classes data structure.
+getRangeForEqualities(Sym),
+// And we should always check what we can get from the operands.
+VisitBinaryOperator(Sym));
   }
 
 private:
@@ -907,9 +885,6 @@ class SymbolicRangeInferrer
 // calculate the effective range set by intersecting the range set
 // for A - B and the negated range set of B - 

[PATCH] D105439: [clang] protects users from relying on libc++ detail headers

[Roman Lebedev via Phabricator via cfe-commits]

lebedev.ri added a comment.

In D105439#2874706 , @ldionne wrote:

> I'm not entirely sure I understand the purpose of this patch. So the idea is 
> that let's say a tool suggests including `<__algorithm/find.h>` to get the 
> definition of `std::find` as a IWYU fix-it sort of suggestion, the user would 
> naively do that, and then the compiler (with this patch) would error out 
> saying "woops, you can't include that libc++ detail header". Is that the idea?
>
> If that's it, then I would much rather fix the tools that incorrectly suggest 
> including those implementation detail headers in the first place. Users will 
> be less confused and we won't have to special-case a special directory name, 
> which I can imagine could cause issues. I think it's great to try and give 
> the proper diagnostic to users, but I think the correct place to do that is 
> in the tool that suggests it in the first place. Thoughts?

Regardless of whether this is about enhacing IWYU QoL or completely preventing 
inclusion of separate sub-headers,
it seems like that should be done in libc++ itself, it already has the means 
for that.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105439

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

[PATCH] D105873: Fix utils/update_cc_test_checks/check-globals.test on stand-alone builds

[Tom Stellard 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 rG303ddb60a2d2: Fix 
utils/update_cc_test_checks/check-globals.test on stand-alone builds (authored 
by tstellar).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105873

Files:
  clang/test/CMakeLists.txt
  clang/test/lit.site.cfg.py.in
  clang/test/utils/update_cc_test_checks/lit.local.cfg


Index: clang/test/utils/update_cc_test_checks/lit.local.cfg
===
--- clang/test/utils/update_cc_test_checks/lit.local.cfg
+++ clang/test/utils/update_cc_test_checks/lit.local.cfg
@@ -19,7 +19,7 @@
 script_path = os.path.join(config.llvm_src_root, 'utils',
'update_cc_test_checks.py')
 assert os.path.isfile(script_path)
-lit = shell_quote(os.path.join(config.llvm_src_root, 'utils', 'lit', 'lit.py'))
+lit = config.llvm_external_lit if config.llvm_external_lit else 
shell_quote(os.path.join(config.llvm_src_root, 'utils', 'lit', 'lit.py'))
 python = shell_quote(config.python_executable)
 config.substitutions.append(
 ('%update_cc_test_checks', "%s %s %s" % (
Index: clang/test/lit.site.cfg.py.in
===
--- clang/test/lit.site.cfg.py.in
+++ clang/test/lit.site.cfg.py.in
@@ -34,6 +34,7 @@
 config.use_z3_solver = lit_config.params.get('USE_Z3_SOLVER', 
"@USE_Z3_SOLVER@")
 config.has_plugins = @LLVM_ENABLE_PLUGINS@
 config.clang_vendor_uti = "@CLANG_VENDOR_UTI@"
+config.llvm_external_lit = path(r"@LLVM_EXTERNAL_LIT@")
 
 # Support substitution of the tools and libs dirs with user parameters. This is
 # used when we can't determine the tool dir at configuration time.
Index: clang/test/CMakeLists.txt
===
--- clang/test/CMakeLists.txt
+++ clang/test/CMakeLists.txt
@@ -33,6 +33,7 @@
   "LLVM_LIBS_DIR"
   "SHLIBDIR"
   "LLVM_LIT_TOOLS_DIR"
+  "LLVM_EXTERNAL_LIT"
   "CLANG_BINARY_DIR"
   "CLANG_SOURCE_DIR"
   "CLANG_TOOLS_DIR"


Index: clang/test/utils/update_cc_test_checks/lit.local.cfg
===
--- clang/test/utils/update_cc_test_checks/lit.local.cfg
+++ clang/test/utils/update_cc_test_checks/lit.local.cfg
@@ -19,7 +19,7 @@
 script_path = os.path.join(config.llvm_src_root, 'utils',
'update_cc_test_checks.py')
 assert os.path.isfile(script_path)
-lit = shell_quote(os.path.join(config.llvm_src_root, 'utils', 'lit', 'lit.py'))
+lit = config.llvm_external_lit if config.llvm_external_lit else shell_quote(os.path.join(config.llvm_src_root, 'utils', 'lit', 'lit.py'))
 python = shell_quote(config.python_executable)
 config.substitutions.append(
 ('%update_cc_test_checks', "%s %s %s" % (
Index: clang/test/lit.site.cfg.py.in
===
--- clang/test/lit.site.cfg.py.in
+++ clang/test/lit.site.cfg.py.in
@@ -34,6 +34,7 @@
 config.use_z3_solver = lit_config.params.get('USE_Z3_SOLVER', "@USE_Z3_SOLVER@")
 config.has_plugins = @LLVM_ENABLE_PLUGINS@
 config.clang_vendor_uti = "@CLANG_VENDOR_UTI@"
+config.llvm_external_lit = path(r"@LLVM_EXTERNAL_LIT@")
 
 # Support substitution of the tools and libs dirs with user parameters. This is
 # used when we can't determine the tool dir at configuration time.
Index: clang/test/CMakeLists.txt
===
--- clang/test/CMakeLists.txt
+++ clang/test/CMakeLists.txt
@@ -33,6 +33,7 @@
   "LLVM_LIBS_DIR"
   "SHLIBDIR"
   "LLVM_LIT_TOOLS_DIR"
+  "LLVM_EXTERNAL_LIT"
   "CLANG_BINARY_DIR"
   "CLANG_SOURCE_DIR"
   "CLANG_TOOLS_DIR"
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] 303ddb6 - Fix utils/update_cc_test_checks/check-globals.test on stand-alone builds

[Tom Stellard via cfe-commits]

Author: Tom Stellard
Date: 2021-07-13T10:47:30-07:00
New Revision: 303ddb60a2d28fb7603266d8977f69ac77b194dd

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

LOG: Fix utils/update_cc_test_checks/check-globals.test on stand-alone builds

We want to use LLVM_EXTERNAL_LIT if defined for the %lit substitution.

Reviewed By: jdenny

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

Added: 


Modified: 
clang/test/CMakeLists.txt
clang/test/lit.site.cfg.py.in
clang/test/utils/update_cc_test_checks/lit.local.cfg

Removed: 




diff  --git a/clang/test/CMakeLists.txt b/clang/test/CMakeLists.txt
index e2f6d6772dea3..52a3a3b761af0 100644
--- a/clang/test/CMakeLists.txt
+++ b/clang/test/CMakeLists.txt
@@ -33,6 +33,7 @@ configure_lit_site_cfg(
   "LLVM_LIBS_DIR"
   "SHLIBDIR"
   "LLVM_LIT_TOOLS_DIR"
+  "LLVM_EXTERNAL_LIT"
   "CLANG_BINARY_DIR"
   "CLANG_SOURCE_DIR"
   "CLANG_TOOLS_DIR"

diff  --git a/clang/test/lit.site.cfg.py.in b/clang/test/lit.site.cfg.py.in
index f31ede2c39575..7b174e681bf34 100644
--- a/clang/test/lit.site.cfg.py.in
+++ b/clang/test/lit.site.cfg.py.in
@@ -34,6 +34,7 @@ config.python_executable = "@Python3_EXECUTABLE@"
 config.use_z3_solver = lit_config.params.get('USE_Z3_SOLVER', 
"@USE_Z3_SOLVER@")
 config.has_plugins = @LLVM_ENABLE_PLUGINS@
 config.clang_vendor_uti = "@CLANG_VENDOR_UTI@"
+config.llvm_external_lit = path(r"@LLVM_EXTERNAL_LIT@")
 
 # Support substitution of the tools and libs dirs with user parameters. This is
 # used when we can't determine the tool dir at configuration time.

diff  --git a/clang/test/utils/update_cc_test_checks/lit.local.cfg 
b/clang/test/utils/update_cc_test_checks/lit.local.cfg
index cbcc05dff4ca7..14d1ba260bb4a 100644
--- a/clang/test/utils/update_cc_test_checks/lit.local.cfg
+++ b/clang/test/utils/update_cc_test_checks/lit.local.cfg
@@ -19,7 +19,7 @@ extra_args += ' --opt ' + shell_quote(opt_path)
 script_path = os.path.join(config.llvm_src_root, 'utils',
'update_cc_test_checks.py')
 assert os.path.isfile(script_path)
-lit = shell_quote(os.path.join(config.llvm_src_root, 'utils', 'lit', 'lit.py'))
+lit = config.llvm_external_lit if config.llvm_external_lit else 
shell_quote(os.path.join(config.llvm_src_root, 'utils', 'lit', 'lit.py'))
 python = shell_quote(config.python_executable)
 config.substitutions.append(
 ('%update_cc_test_checks', "%s %s %s" % (



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

[PATCH] D105439: [clang] protects users from relying on libc++ detail headers

[Louis Dionne via Phabricator via cfe-commits]

ldionne added a comment.

I'm not entirely sure I understand the purpose of this patch. So the idea is 
that let's say a tool suggests including `<__algorithm/find.h>` to get the 
definition of `std::find` as a IWYU fix-it sort of suggestion, the user would 
naively do that, and then the compiler (with this patch) would error out saying 
"woops, you can't include that libc++ detail header". Is that the idea?

If that's it, then I would much rather fix the tools that incorrectly suggest 
including those implementation detail headers in the first place. Users will be 
less confused and we won't have to special-case a special directory name, which 
I can imagine could cause issues. I think it's great to try and give the proper 
diagnostic to users, but I think the correct place to do that is in the tool 
that suggests it in the first place. Thoughts?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105439

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

[PATCH] D103096: [analyzer] Implement cast for ranges of symbolic integers.

[Valeriy Savchenko via Phabricator via cfe-commits]

vsavchenko added a comment.

OK, thanks for putting a summary.  I now got a good idea why you need both.
At the same time, take a look at D105692 .  
I'm about to land it and I think it's going to be useful for you.


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

https://reviews.llvm.org/D103096

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

[PATCH] D105693: [analyzer][solver][NFC] Refactor how we detect (dis)equalities

[Valeriy Savchenko via Phabricator via cfe-commits]

vsavchenko added inline comments.



Comment at: clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp:687
 
 /// A small helper structure representing symbolic equality.
 ///

martong wrote:
> This is no longer a `structure`.
Good catch!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105693

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

[PATCH] D105693: [analyzer][solver][NFC] Refactor how we detect (dis)equalities

[Valeriy Savchenko via Phabricator via cfe-commits]

vsavchenko updated this revision to Diff 358341.
vsavchenko marked an inline comment as done.
vsavchenko added a comment.

Fix comments


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105693

Files:
  clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp
  clang/test/Analysis/equality_tracking.c

Index: clang/test/Analysis/equality_tracking.c
===
--- clang/test/Analysis/equality_tracking.c
+++ clang/test/Analysis/equality_tracking.c
@@ -219,3 +219,17 @@
   if (c < 0)
 ;
 }
+
+void implyDisequalityFromGT(int a, int b) {
+  if (a > b) {
+clang_analyzer_eval(a == b); // expected-warning{{FALSE}}
+clang_analyzer_eval(a != b); // expected-warning{{TRUE}}
+  }
+}
+
+void implyDisequalityFromLT(int a, int b) {
+  if (a < b) {
+clang_analyzer_eval(a == b); // expected-warning{{FALSE}}
+clang_analyzer_eval(a != b); // expected-warning{{TRUE}}
+  }
+}
Index: clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp
===
--- clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp
+++ clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp
@@ -684,58 +684,30 @@
 //   Equality/diseqiality abstraction
 //===--===//
 
-/// A small helper structure representing symbolic equality.
+/// A small helper function for detecting symbolic (dis)equality.
 ///
 /// Equality check can have different forms (like a == b or a - b) and this
 /// class encapsulates those away if the only thing the user wants to check -
-/// whether it's equality/diseqiality or not and have an easy access to the
-/// compared symbols.
-struct EqualityInfo {
-public:
-  SymbolRef Left, Right;
-  // true for equality and false for disequality.
-  bool IsEquality = true;
-
-  void invert() { IsEquality = !IsEquality; }
-  /// Extract equality information from the given symbol and the constants.
-  ///
-  /// This function assumes the following expression Sym + Adjustment != Int.
-  /// It is a default because the most widespread case of the equality check
-  /// is (A == B) + 0 != 0.
-  static Optional extract(SymbolRef Sym, const llvm::APSInt &Int,
-const llvm::APSInt &Adjustment) {
-// As of now, the only equality form supported is Sym + 0 != 0.
-if (!Int.isNullValue() || !Adjustment.isNullValue())
-  return llvm::None;
-
-return extract(Sym);
-  }
-  /// Extract equality information from the given symbol.
-  static Optional extract(SymbolRef Sym) {
-return EqualityExtractor().Visit(Sym);
+/// whether it's equality/diseqiality or not.
+///
+/// \returns true if assuming this Sym to be true means equality of operands
+///  false if it means disequality of operands
+///  None otherwise
+Optional meansEquality(const SymSymExpr *Sym) {
+  switch (Sym->getOpcode()) {
+  case BO_Sub:
+// This case is: A - B != 0 -> disequality check.
+return false;
+  case BO_EQ:
+// This case is: A == B != 0 -> equality check.
+return true;
+  case BO_NE:
+// This case is: A != B != 0 -> diseqiality check.
+return false;
+  default:
+return llvm::None;
   }
-
-private:
-  class EqualityExtractor
-  : public SymExprVisitor> {
-  public:
-Optional VisitSymSymExpr(const SymSymExpr *Sym) const {
-  switch (Sym->getOpcode()) {
-  case BO_Sub:
-// This case is: A - B != 0 -> disequality check.
-return EqualityInfo{Sym->getLHS(), Sym->getRHS(), false};
-  case BO_EQ:
-// This case is: A == B != 0 -> equality check.
-return EqualityInfo{Sym->getLHS(), Sym->getRHS(), true};
-  case BO_NE:
-// This case is: A != B != 0 -> diseqiality check.
-return EqualityInfo{Sym->getLHS(), Sym->getRHS(), false};
-  default:
-return llvm::None;
-  }
-}
-  };
-};
+}
 
 //===--===//
 //Intersection functions
@@ -866,7 +838,13 @@
   }
 
   RangeSet VisitSymSymExpr(const SymSymExpr *Sym) {
-return VisitBinaryOperator(Sym);
+return intersect(
+RangeFactory,
+// If Sym is (dis)equality, we might have some information
+// on that in our equality classes data structure.
+getRangeForEqualities(Sym),
+// And we should always check what we can get from the operands.
+VisitBinaryOperator(Sym));
   }
 
 private:
@@ -907,9 +885,6 @@
 // calculate the effective range set by intersecting the range set
 // for A - B and the negated range set of B - A.
 getRangeForNegatedSub(Sym),
-// If Sym is (dis)equality, we might have some information on that
-// in our equality classes data structure.
-getRangeForEqualities

[PATCH] D69764: [clang-format] Add East/West Const fixer capability

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added a comment.

In D69764#2874464 , @atomgalaxy wrote:

> It's very difficult to use a compile_commands database if you can't
> actually check out all the code and a remote service builds it for you.



In D69764#2874514 , @MyDeveloperDay 
wrote:

>> FWIW, if you use the compile commands database, the only thing you need to 
>> do on the command line is specify the checks to enable or disable.
>
> The project I work on doesn't have/use compile commands databases? if you are 
> make based system or some other legacy build system you just may not have 
> this, so I don't want to limit the uses to just those projects that do.

These are both fair criticisms (that I agree with!). However, adding an 
entirely new tool is a pretty heavy approach and I think we should only do it 
when there's a strong use case (and there may be such a strong case in this 
instance). However, I just now realize that we've added other tools for this 
sort of thing in the past -- we have `clang-change-namespace` and 
`clang-reorder-fields` which are not entirely unrelated to this same concept, 
so there's something like precedent here.


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

https://reviews.llvm.org/D69764

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