[PATCH] D49899: Force test/Driver/fuchsia.c(pp) to use lld

2018-08-06 Thread David Greene via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rL339036: Force test/Driver/fuchsia.c(pp) to use lld (authored 
by greened, committed by ).
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D49899?vs=157689&id=159336#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D49899

Files:
  cfe/trunk/test/Driver/fuchsia.c
  cfe/trunk/test/Driver/fuchsia.cpp

Index: cfe/trunk/test/Driver/fuchsia.cpp
===
--- cfe/trunk/test/Driver/fuchsia.cpp
+++ cfe/trunk/test/Driver/fuchsia.cpp
@@ -1,5 +1,5 @@
 // RUN: %clangxx %s -### -no-canonical-prefixes --target=x86_64-unknown-fuchsia \
-// RUN: --sysroot=%S/platform 2>&1 | FileCheck %s
+// RUN: --sysroot=%S/platform -fuse-ld=lld 2>&1 | FileCheck %s
 // CHECK: {{.*}}clang{{.*}}" "-cc1"
 // CHECK: "-triple" "x86_64-fuchsia"
 // CHECK: "-fuse-init-array"
@@ -21,11 +21,13 @@
 // CHECK-NOT: crtend.o
 // CHECK-NOT: crtn.o
 
-// RUN: %clangxx %s -### --target=x86_64-unknown-fuchsia -stdlib=libstdc++ 2>&1 \
+// RUN: %clangxx %s -### --target=x86_64-unknown-fuchsia -stdlib=libstdc++ \
+// RUN: -fuse-ld=lld 2>&1 \
 // RUN: | FileCheck %s -check-prefix=CHECK-STDLIB
 // CHECK-STDLIB: error: invalid library name in argument '-stdlib=libstdc++'
 
-// RUN: %clangxx %s -### --target=x86_64-unknown-fuchsia -static-libstdc++ 2>&1 \
+// RUN: %clangxx %s -### --target=x86_64-unknown-fuchsia -static-libstdc++ \
+// RUN: -fuse-ld=lld 2>&1 \
 // RUN: | FileCheck %s -check-prefix=CHECK-STATIC
 // CHECK-STATIC: "-Bstatic"
 // CHECK-STATIC: "-lc++"
Index: cfe/trunk/test/Driver/fuchsia.c
===
--- cfe/trunk/test/Driver/fuchsia.c
+++ cfe/trunk/test/Driver/fuchsia.c
@@ -1,10 +1,10 @@
 // RUN: %clang %s -### -no-canonical-prefixes --target=x86_64-fuchsia \
 // RUN: -resource-dir=%S/Inputs/resource_dir_with_per_target_subdir \
-// RUN: --sysroot=%S/platform 2>&1 \
+// RUN: --sysroot=%S/platform -fuse-ld=lld 2>&1 \
 // RUN: | FileCheck -check-prefixes=CHECK,CHECK-X86_64 %s
 // RUN: %clang %s -### -no-canonical-prefixes --target=aarch64-fuchsia \
 // RUN: -resource-dir=%S/Inputs/resource_dir_with_per_target_subdir \
-// RUN: --sysroot=%S/platform 2>&1 \
+// RUN: --sysroot=%S/platform -fuse-ld=lld 2>&1 \
 // RUN: | FileCheck -check-prefixes=CHECK,CHECK-AARCH64 %s
 // CHECK: {{.*}}clang{{.*}}" "-cc1"
 // CHECK: "--mrelax-relocations"
@@ -31,38 +31,40 @@
 // CHECK-NOT: crtend.o
 // CHECK-NOT: crtn.o
 
-// RUN: %clang %s -### --target=x86_64-fuchsia -rtlib=libgcc 2>&1 \
+// RUN: %clang %s -### --target=x86_64-fuchsia -rtlib=libgcc -fuse-ld=lld 2>&1 \
 // RUN: | FileCheck %s -check-prefix=CHECK-RTLIB
 // CHECK-RTLIB: error: invalid runtime library name in argument '-rtlib=libgcc'
 
-// RUN: %clang %s -### --target=x86_64-fuchsia -static 2>&1 \
+// RUN: %clang %s -### --target=x86_64-fuchsia -static -fuse-ld=lld 2>&1 \
 // RUN: | FileCheck %s -check-prefix=CHECK-STATIC
 // CHECK-STATIC: "-Bstatic"
 // CHECK-STATIC: "-Bdynamic"
 // CHECK-STATIC: "-lc"
 
-// RUN: %clang %s -### --target=x86_64-fuchsia -shared 2>&1 \
+// RUN: %clang %s -### --target=x86_64-fuchsia -shared -fuse-ld=lld 2>&1 \
 // RUN: | FileCheck %s -check-prefix=CHECK-SHARED
 // CHECK-SHARED-NOT: "-pie"
 // CHECK-SHARED: "-shared"
 
-// RUN: %clang %s -### --target=x86_64-fuchsia -r 2>&1 \
+// RUN: %clang %s -### --target=x86_64-fuchsia -r -fuse-ld=lld 2>&1 \
 // RUN: | FileCheck %s -check-prefix=CHECK-RELOCATABLE
 // CHECK-RELOCATABLE-NOT: "-pie"
 // CHECK-RELOCATABLE-NOT: "--build-id"
 // CHECK-RELOCATABLE: "-r"
 
 // RUN: %clang %s -### --target=x86_64-fuchsia \
 // RUN: -fsanitize=safe-stack 2>&1 \
 // RUN: -resource-dir=%S/Inputs/resource_dir_with_per_target_subdir \
+// RUN: -fuse-ld=lld \
 // RUN: | FileCheck %s -check-prefix=CHECK-SAFESTACK
 // CHECK-SAFESTACK: "-fsanitize=safe-stack"
 // CHECK-SAFESTACK-NOT: "{{.*[/\\]}}libclang_rt.safestack.a"
 // CHECK-SAFESTACK-NOT: "__safestack_init"
 
 // RUN: %clang %s -### --target=x86_64-fuchsia \
 // RUN: -fsanitize=address 2>&1 \
 // RUN: -resource-dir=%S/Inputs/resource_dir_with_per_target_subdir \
+// RUN: -fuse-ld=lld \
 // RUN: | FileCheck %s -check-prefix=CHECK-ASAN-X86
 // CHECK-ASAN-X86: "-fsanitize=address"
 // CHECK-ASAN-X86: "-fsanitize-address-globals-dead-stripping"
@@ -73,6 +75,7 @@
 // RUN: %clang %s -### --target=aarch64-fuchsia \
 // RUN: -fsanitize=address 2>&1 \
 // RUN: -resource-dir=%S/Inputs/resource_dir_with_per_target_subdir \
+// RUN: -fuse-ld=lld \
 // RUN: | FileCheck %s -check-prefix=CHECK-ASAN-AARCH64
 // CHECK-ASAN-AARCH64: "-fsanitize=address"
 // CHECK-ASAN-AARCH64: "-fsanitize-address-globals-dead-stripping"
@@ -83,6 +86,7 @@
 // RUN: %clang %s -### --target=x86_64-fuchsia \
 // RUN: -fsanitize=address -fPIC -shared 2>&1 \
 // RUN:  

[PATCH] D49244: Always search sysroot for GCC installs

2018-08-06 Thread David Greene via Phabricator via cfe-commits
greened added a comment.

Ping...


Repository:
  rC Clang

https://reviews.llvm.org/D49244



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


[PATCH] D49897: [WebAssembly] Force use of lld for test/Driver/wasm-toolchain.c(pp)

2018-08-06 Thread David Greene via Phabricator via cfe-commits
greened added a comment.

In https://reviews.llvm.org/D49897#1180338, @sbc100 wrote:

> How do you configure clang to use a different linker?  It looks like 
> getDefaultLinker() is hardcoded, but maybe I'm missing something.


I pass -fuse-ld in the test RUN lines.


Repository:
  rC Clang

https://reviews.llvm.org/D49897



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


[PATCH] D49897: [WebAssembly] Force use of lld for test/Driver/wasm-toolchain.c(pp)

2018-08-07 Thread David Greene via Phabricator via cfe-commits
greened added a comment.

In https://reviews.llvm.org/D49897#1189688, @sbc100 wrote:

> But in the CL description you say "..when configuring clang to use a 
> different linker by default".  How is this possible?i.e. do you have a 
> config where these tests are currently failing?


Yes, I do.  I configured with -DCLANG_DEFAULT_LINKER=gold.


Repository:
  rC Clang

https://reviews.llvm.org/D49897



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


[PATCH] D49897: [WebAssembly] Force use of lld for test/Driver/wasm-toolchain.c(pp)

2018-08-07 Thread David Greene via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rC339158: [WebAssembly] Force use of lld for 
test/Driver/wasm-toolchain.c(pp) (authored by greened, committed by ).

Repository:
  rC Clang

https://reviews.llvm.org/D49897

Files:
  test/Driver/wasm-toolchain.c
  test/Driver/wasm-toolchain.cpp


Index: test/Driver/wasm-toolchain.cpp
===
--- test/Driver/wasm-toolchain.cpp
+++ test/Driver/wasm-toolchain.cpp
@@ -12,12 +12,12 @@
 
 // A basic C++ link command-line.
 
-// RUN: %clangxx -### -no-canonical-prefixes -target wasm32-unknown-unknown 
--sysroot=/foo --stdlib=c++ %s 2>&1 | FileCheck -check-prefix=LINK %s
+// RUN: %clangxx -### -no-canonical-prefixes -target wasm32-unknown-unknown 
--sysroot=/foo --stdlib=c++ -fuse-ld=lld %s 2>&1 | FileCheck -check-prefix=LINK 
%s
 // LINK: clang{{.*}}" "-cc1" {{.*}} "-o" "[[temp:[^"]*]]"
 // LINK: lld{{.*}}" "-flavor" "wasm" "-L/foo/lib" "crt1.o" "[[temp]]" "-lc++" 
"-lc++abi" "-lc" "{{.*[/\\]}}libclang_rt.builtins-wasm32.a" "-o" "a.out"
 
 // A basic C++ link command-line with optimization.
 
-// RUN: %clangxx -### -O2 -no-canonical-prefixes -target 
wasm32-unknown-unknown --sysroot=/foo %s --stdlib=c++ 2>&1 | FileCheck 
-check-prefix=LINK_OPT %s
+// RUN: %clangxx -### -O2 -no-canonical-prefixes -target 
wasm32-unknown-unknown --sysroot=/foo %s --stdlib=c++ -fuse-ld=lld 2>&1 | 
FileCheck -check-prefix=LINK_OPT %s
 // LINK_OPT: clang{{.*}}" "-cc1" {{.*}} "-o" "[[temp:[^"]*]]"
 // LINK_OPT: lld{{.*}}" "-flavor" "wasm" "-L/foo/lib" "crt1.o" "[[temp]]" 
"-lc++" "-lc++abi" "-lc" "{{.*[/\\]}}libclang_rt.builtins-wasm32.a" "-o" "a.out"
Index: test/Driver/wasm-toolchain.c
===
--- test/Driver/wasm-toolchain.c
+++ test/Driver/wasm-toolchain.c
@@ -12,12 +12,12 @@
 
 // A basic C link command-line.
 
-// RUN: %clang -### -no-canonical-prefixes -target wasm32-unknown-unknown 
--sysroot=/foo %s 2>&1 | FileCheck -check-prefix=LINK %s
+// RUN: %clang -### -no-canonical-prefixes -target wasm32-unknown-unknown 
--sysroot=/foo -fuse-ld=lld %s 2>&1 | FileCheck -check-prefix=LINK %s
 // LINK: clang{{.*}}" "-cc1" {{.*}} "-o" "[[temp:[^"]*]]"
 // LINK: lld{{.*}}" "-flavor" "wasm" "-L/foo/lib" "crt1.o" "[[temp]]" "-lc" 
"{{.*[/\\]}}libclang_rt.builtins-wasm32.a" "-o" "a.out"
 
 // A basic C link command-line with optimization.
 
-// RUN: %clang -### -O2 -no-canonical-prefixes -target wasm32-unknown-unknown 
--sysroot=/foo %s 2>&1 | FileCheck -check-prefix=LINK_OPT %s
+// RUN: %clang -### -O2 -no-canonical-prefixes -target wasm32-unknown-unknown 
--sysroot=/foo -fuse-ld=lld %s 2>&1 | FileCheck -check-prefix=LINK_OPT %s
 // LINK_OPT: clang{{.*}}" "-cc1" {{.*}} "-o" "[[temp:[^"]*]]"
 // LINK_OPT: lld{{.*}}" "-flavor" "wasm" "-L/foo/lib" "crt1.o" "[[temp]]" 
"-lc" "{{.*[/\\]}}libclang_rt.builtins-wasm32.a" "-o" "a.out"


Index: test/Driver/wasm-toolchain.cpp
===
--- test/Driver/wasm-toolchain.cpp
+++ test/Driver/wasm-toolchain.cpp
@@ -12,12 +12,12 @@
 
 // A basic C++ link command-line.
 
-// RUN: %clangxx -### -no-canonical-prefixes -target wasm32-unknown-unknown --sysroot=/foo --stdlib=c++ %s 2>&1 | FileCheck -check-prefix=LINK %s
+// RUN: %clangxx -### -no-canonical-prefixes -target wasm32-unknown-unknown --sysroot=/foo --stdlib=c++ -fuse-ld=lld %s 2>&1 | FileCheck -check-prefix=LINK %s
 // LINK: clang{{.*}}" "-cc1" {{.*}} "-o" "[[temp:[^"]*]]"
 // LINK: lld{{.*}}" "-flavor" "wasm" "-L/foo/lib" "crt1.o" "[[temp]]" "-lc++" "-lc++abi" "-lc" "{{.*[/\\]}}libclang_rt.builtins-wasm32.a" "-o" "a.out"
 
 // A basic C++ link command-line with optimization.
 
-// RUN: %clangxx -### -O2 -no-canonical-prefixes -target wasm32-unknown-unknown --sysroot=/foo %s --stdlib=c++ 2>&1 | FileCheck -check-prefix=LINK_OPT %s
+// RUN: %clangxx -### -O2 -no-canonical-prefixes -target wasm32-unknown-unknown --sysroot=/foo %s --stdlib=c++ -fuse-ld=lld 2>&1 | FileCheck -check-prefix=LINK_OPT %s
 // LINK_OPT: clang{{.*}}" "-cc1" {{.*}} "-o" "[[temp:[^"]*]]"
 // LINK_OPT: lld{{.*}}" "-flavor" "wasm" "-L/foo/lib" "crt1.o" "[[temp]]" "-lc++" "-lc++abi" "-lc" "{{.*[/\\]}}libclang_rt.builtins-wasm32.a" "-o" "a.out"
Index: test/Driver/wasm-toolchain.c
===
--- test/Driver/wasm-toolchain.c
+++ test/Driver/wasm-toolchain.c
@@ -12,12 +12,12 @@
 
 // A basic C link command-line.
 
-// RUN: %clang -### -no-canonical-prefixes -target wasm32-unknown-unknown --sysroot=/foo %s 2>&1 | FileCheck -check-prefix=LINK %s
+// RUN: %clang -### -no-canonical-prefixes -target wasm32-unknown-unknown --sysroot=/foo -fuse-ld=lld %s 2>&1 | FileCheck -check-prefix=LINK %s
 // LINK: clang{{.*}}" "-cc1" {{.*}} "-o" "[[temp:[^"]*]]"
 // LINK: lld{{.*}}" "-flavor" "wasm" "-L/foo/lib" "crt1.o" "[[temp]]" "-lc" "{{.*[/\\]}}libclang_rt.builtins-wasm32.a" "-o" "a.out"

[PATCH] D49244: Always search sysroot for GCC installs

2018-08-14 Thread David Greene via Phabricator via cfe-commits
greened added a comment.

Ping?


Repository:
  rC Clang

https://reviews.llvm.org/D49244



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


[PATCH] D49244: Always search sysroot for GCC installs

2018-08-22 Thread David Greene via Phabricator via cfe-commits
greened added a comment.

Ping?


Repository:
  rC Clang

https://reviews.llvm.org/D49244



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


[PATCH] D49244: Always search sysroot for GCC installs

2018-08-27 Thread David Greene via Phabricator via cfe-commits
greened added a comment.

Ping.  It's been well over a month now.  What's the best way to get this 
reviewed?


Repository:
  rC Clang

https://reviews.llvm.org/D49244



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


[PATCH] D49244: Always search sysroot for GCC installs

2018-08-29 Thread David Greene via Phabricator via cfe-commits
greened added a comment.

I agree that option 2 seems best.  It's consistent with options overriding more 
general configuration/environment variables and more specific options 
overriding more general options.  If it turns out option 1 is needed in the 
future, it should be a simple change given an option 2 implementation.


Repository:
  rC Clang

https://reviews.llvm.org/D49244



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


[PATCH] D49244: Always search sysroot for GCC installs

2018-07-23 Thread David Greene via Phabricator via cfe-commits
greened added a comment.

Ping.


Repository:
  rC Clang

https://reviews.llvm.org/D49244



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


[PATCH] D49897: [WebAssembly] Force use of lld for test/Driver/wasm-toolchain.c(pp)

2018-07-26 Thread David Greene via Phabricator via cfe-commits
greened created this revision.
greened added reviewers: sbc100, sunfish.
Herald added subscribers: cfe-commits, aheejin, jgravelle-google, dschuff.

lld is the only supported linker that works for WebAssembly, so ensure clang is 
using it for this test.  This gets the tests passing when configuring clang to 
use a different linker by default.


Repository:
  rC Clang

https://reviews.llvm.org/D49897

Files:
  test/Driver/wasm-toolchain.c
  test/Driver/wasm-toolchain.cpp


Index: test/Driver/wasm-toolchain.cpp
===
--- test/Driver/wasm-toolchain.cpp
+++ test/Driver/wasm-toolchain.cpp
@@ -12,12 +12,12 @@
 
 // A basic C++ link command-line.
 
-// RUN: %clangxx -### -no-canonical-prefixes -target wasm32-unknown-unknown 
--sysroot=/foo --stdlib=c++ %s 2>&1 | FileCheck -check-prefix=LINK %s
+// RUN: %clangxx -### -no-canonical-prefixes -target wasm32-unknown-unknown 
--sysroot=/foo --stdlib=c++ -fuse-ld=lld %s 2>&1 | FileCheck -check-prefix=LINK 
%s
 // LINK: clang{{.*}}" "-cc1" {{.*}} "-o" "[[temp:[^"]*]]"
 // LINK: lld{{.*}}" "-flavor" "wasm" "-L/foo/lib" "crt1.o" "[[temp]]" "-lc++" 
"-lc++abi" "-lc" "{{.*[/\\]}}libclang_rt.builtins-wasm32.a" "-o" "a.out"
 
 // A basic C++ link command-line with optimization.
 
-// RUN: %clangxx -### -O2 -no-canonical-prefixes -target 
wasm32-unknown-unknown --sysroot=/foo %s --stdlib=c++ 2>&1 | FileCheck 
-check-prefix=LINK_OPT %s
+// RUN: %clangxx -### -O2 -no-canonical-prefixes -target 
wasm32-unknown-unknown --sysroot=/foo %s --stdlib=c++ -fuse-ld=lld 2>&1 | 
FileCheck -check-prefix=LINK_OPT %s
 // LINK_OPT: clang{{.*}}" "-cc1" {{.*}} "-o" "[[temp:[^"]*]]"
 // LINK_OPT: lld{{.*}}" "-flavor" "wasm" "-L/foo/lib" "crt1.o" "[[temp]]" 
"-lc++" "-lc++abi" "-lc" "{{.*[/\\]}}libclang_rt.builtins-wasm32.a" "-o" "a.out"
Index: test/Driver/wasm-toolchain.c
===
--- test/Driver/wasm-toolchain.c
+++ test/Driver/wasm-toolchain.c
@@ -12,12 +12,12 @@
 
 // A basic C link command-line.
 
-// RUN: %clang -### -no-canonical-prefixes -target wasm32-unknown-unknown 
--sysroot=/foo %s 2>&1 | FileCheck -check-prefix=LINK %s
+// RUN: %clang -### -no-canonical-prefixes -target wasm32-unknown-unknown 
--sysroot=/foo -fuse-ld=lld %s 2>&1 | FileCheck -check-prefix=LINK %s
 // LINK: clang{{.*}}" "-cc1" {{.*}} "-o" "[[temp:[^"]*]]"
 // LINK: lld{{.*}}" "-flavor" "wasm" "-L/foo/lib" "crt1.o" "[[temp]]" "-lc" 
"{{.*[/\\]}}libclang_rt.builtins-wasm32.a" "-o" "a.out"
 
 // A basic C link command-line with optimization.
 
-// RUN: %clang -### -O2 -no-canonical-prefixes -target wasm32-unknown-unknown 
--sysroot=/foo %s 2>&1 | FileCheck -check-prefix=LINK_OPT %s
+// RUN: %clang -### -O2 -no-canonical-prefixes -target wasm32-unknown-unknown 
--sysroot=/foo -fuse-ld=lld %s 2>&1 | FileCheck -check-prefix=LINK_OPT %s
 // LINK_OPT: clang{{.*}}" "-cc1" {{.*}} "-o" "[[temp:[^"]*]]"
 // LINK_OPT: lld{{.*}}" "-flavor" "wasm" "-L/foo/lib" "crt1.o" "[[temp]]" 
"-lc" "{{.*[/\\]}}libclang_rt.builtins-wasm32.a" "-o" "a.out"


Index: test/Driver/wasm-toolchain.cpp
===
--- test/Driver/wasm-toolchain.cpp
+++ test/Driver/wasm-toolchain.cpp
@@ -12,12 +12,12 @@
 
 // A basic C++ link command-line.
 
-// RUN: %clangxx -### -no-canonical-prefixes -target wasm32-unknown-unknown --sysroot=/foo --stdlib=c++ %s 2>&1 | FileCheck -check-prefix=LINK %s
+// RUN: %clangxx -### -no-canonical-prefixes -target wasm32-unknown-unknown --sysroot=/foo --stdlib=c++ -fuse-ld=lld %s 2>&1 | FileCheck -check-prefix=LINK %s
 // LINK: clang{{.*}}" "-cc1" {{.*}} "-o" "[[temp:[^"]*]]"
 // LINK: lld{{.*}}" "-flavor" "wasm" "-L/foo/lib" "crt1.o" "[[temp]]" "-lc++" "-lc++abi" "-lc" "{{.*[/\\]}}libclang_rt.builtins-wasm32.a" "-o" "a.out"
 
 // A basic C++ link command-line with optimization.
 
-// RUN: %clangxx -### -O2 -no-canonical-prefixes -target wasm32-unknown-unknown --sysroot=/foo %s --stdlib=c++ 2>&1 | FileCheck -check-prefix=LINK_OPT %s
+// RUN: %clangxx -### -O2 -no-canonical-prefixes -target wasm32-unknown-unknown --sysroot=/foo %s --stdlib=c++ -fuse-ld=lld 2>&1 | FileCheck -check-prefix=LINK_OPT %s
 // LINK_OPT: clang{{.*}}" "-cc1" {{.*}} "-o" "[[temp:[^"]*]]"
 // LINK_OPT: lld{{.*}}" "-flavor" "wasm" "-L/foo/lib" "crt1.o" "[[temp]]" "-lc++" "-lc++abi" "-lc" "{{.*[/\\]}}libclang_rt.builtins-wasm32.a" "-o" "a.out"
Index: test/Driver/wasm-toolchain.c
===
--- test/Driver/wasm-toolchain.c
+++ test/Driver/wasm-toolchain.c
@@ -12,12 +12,12 @@
 
 // A basic C link command-line.
 
-// RUN: %clang -### -no-canonical-prefixes -target wasm32-unknown-unknown --sysroot=/foo %s 2>&1 | FileCheck -check-prefix=LINK %s
+// RUN: %clang -### -no-canonical-prefixes -target wasm32-unknown-unknown --sysroot=/foo -fuse-ld=lld %s 2>&1 | FileCheck -check-prefix=LINK %s
 // LINK: clang{{.*}}" "-cc1" {{.*}} "-o" "[[temp:[^"

[PATCH] D49898: Make test/Driver/baremetal.cpp work with linkers other than lld

2018-07-26 Thread David Greene via Phabricator via cfe-commits
greened created this revision.
greened added reviewers: jroelofs, hans, probinson, ismail, rtrieu.
Herald added a subscriber: cfe-commits.

This test fails if clang is configure with, for example, gold as the default 
linker.  It does not appear that this test really relies on lld so make the 
checks accept ld, ld.gold and ld.bfd too.


Repository:
  rC Clang

https://reviews.llvm.org/D49898

Files:
  test/Driver/baremetal.cpp


Index: test/Driver/baremetal.cpp
===
--- test/Driver/baremetal.cpp
+++ test/Driver/baremetal.cpp
@@ -10,7 +10,7 @@
 // CHECK-V6M-C-SAME: "-internal-isystem" 
"[[SYSROOT]]{{[/\\]+}}include{{[/\\]+}}c++{{[/\\]+}}v1"
 // CHECk-V6M-C-SAME: "-internal-isystem" "[[SYSROOT]]{{[/\\]+}}include"
 // CHECK-V6M-C-SAME: "-x" "c++" "{{.*}}baremetal.cpp"
-// CHECK-V6M-C-NEXT: "{{[^"]*}}ld.lld{{(\.exe)?}}" "{{.*}}.o" "-Bstatic"
+// CHECK-V6M-C-NEXT: "{{[^"]*}}ld{{(\.(lld|bfd|gold))?}}{{(\.exe)?}}" 
"{{.*}}.o" "-Bstatic"
 // CHECK-V6M-C-SAME: "-L[[RESOURCE_DIR:[^"]+]]{{[/\\]+}}lib{{[/\\]+}}baremetal"
 // CHECK-V6M-C-SAME: "-T" "semihosted.lds" 
"-Lsome{{[/\\]+}}directory{{[/\\]+}}user{{[/\\]+}}asked{{[/\\]+}}for"
 // CHECK-V6M-C-SAME: "-lc" "-lm" "-lclang_rt.builtins-armv6m.a"
@@ -32,7 +32,7 @@
 // RUN: -target armv6m-none-eabi \
 // RUN: --sysroot=%S/Inputs/baremetal_arm \
 // RUN:   | FileCheck --check-prefix=CHECK-V6M-DEFAULTCXX %s
-// CHECK-V6M-DEFAULTCXX: "{{[^"]*}}ld.lld{{(\.exe)?}}" "{{.*}}.o" "-Bstatic"
+// CHECK-V6M-DEFAULTCXX: "{{[^"]*}}ld{{(\.(lld|bfd|gold))?}}{{(\.exe)?}}" 
"{{.*}}.o" "-Bstatic"
 // CHECK-V6M-DEFAULTCXX-SAME: 
"-L{{[^"]*}}{{[/\\]+}}lib{{(64)?}}{{[/\\]+}}clang{{[/\\]+}}{{.*}}{{[/\\]+}}lib{{[/\\]+}}baremetal"
 // CHECK-V6M-DEFAULTCXX-SAME: "-lc++" "-lc++abi" "-lunwind"
 // CHECK-V6M-DEFAULTCXX-SAME: "-lc" "-lm" "-lclang_rt.builtins-armv6m.a"
@@ -45,7 +45,7 @@
 // RUN:   | FileCheck --check-prefix=CHECK-V6M-LIBCXX %s
 // CHECK-V6M-LIBCXX-NOT: "-internal-isystem" 
"{{[^"]+}}{{[/\\]+}}include{{[/\\]+}}c++{{[/\\]+}}{{[^v].*}}"
 // CHECK-V6M-LIBCXX: "-internal-isystem" 
"{{[^"]+}}{{[/\\]+}}include{{[/\\]+}}c++{{[/\\]+}}v1"
-// CHECK-V6M-LIBCXX: "{{[^"]*}}ld.lld{{(\.exe)?}}" "{{.*}}.o" "-Bstatic"
+// CHECK-V6M-LIBCXX: "{{[^"]*}}ld{{(\.(lld|bfd|gold))?}}{{(\.exe)?}}" 
"{{.*}}.o" "-Bstatic"
 // CHECK-V6M-LIBCXX-SAME: 
"-L{{[^"]*}}{{[/\\]+}}lib{{(64)?}}{{[/\\]+}}clang{{[/\\]+}}{{.*}}{{[/\\]+}}lib{{[/\\]+}}baremetal"
 // CHECK-V6M-LIBCXX-SAME: "-lc++" "-lc++abi" "-lunwind"
 // CHECK-V6M-LIBCXX-SAME: "-lc" "-lm" "-lclang_rt.builtins-armv6m.a"
@@ -58,7 +58,7 @@
 // RUN:   | FileCheck --check-prefix=CHECK-V6M-LIBSTDCXX %s
 // CHECK-V6M-LIBSTDCXX-NOT: "-internal-isystem" 
"{{[^"]+}}{{[/\\]+}}include{{[/\\]+}}c++{{[/\\]+}}v1"
 // CHECK-V6M-LIBSTDCXX: "-internal-isystem" 
"{{[^"]+}}{{[/\\]+}}include{{[/\\]+}}c++{{[/\\]+}}6.0.0"
-// CHECK-V6M-LIBSTDCXX: "{{[^"]*}}ld.lld{{(\.exe)?}}" "{{.*}}.o" "-Bstatic"
+// CHECK-V6M-LIBSTDCXX: "{{[^"]*}}ld{{(\.(lld|bfd|gold))?}}{{(\.exe)?}}" 
"{{.*}}.o" "-Bstatic"
 // CHECK-V6M-LIBSTDCXX-SAME: 
"-L{{[^"]*}}{{[/\\]+}}lib{{(64)?}}{{[/\\]+}}clang{{[/\\]+}}{{.*}}{{[/\\]+}}lib{{[/\\]+}}baremetal"
 // CHECK-V6M-LIBSTDCXX-SAME: "-lstdc++" "-lsupc++" "-lunwind"
 // CHECK-V6M-LIBSTDCXX-SAME: "-lc" "-lm" "-lclang_rt.builtins-armv6m.a"
@@ -69,7 +69,7 @@
 // RUN: --sysroot=%S/Inputs/baremetal_arm \
 // RUN: -nodefaultlibs \
 // RUN:   | FileCheck --check-prefix=CHECK-V6M-NDL %s
-// CHECK-V6M-NDL: "{{[^"]*}}ld.lld{{(\.exe)?}}" "{{.*}}.o" "-Bstatic"
+// CHECK-V6M-NDL: "{{[^"]*}}ld{{(\.(lld|bfd|gold))?}}{{(\.exe)?}}" "{{.*}}.o" 
"-Bstatic"
 // CHECK-V6M-NDL-SAME: 
"-L{{[^"]*}}{{[/\\]+}}lib{{(64)?}}{{[/\\]+}}clang{{[/\\]+}}{{.*}}{{[/\\]+}}lib{{[/\\]+}}baremetal"
 "-o" "{{.*}}.o"
 
 // RUN: %clangxx -target arm-none-eabi -v 2>&1 \


Index: test/Driver/baremetal.cpp
===
--- test/Driver/baremetal.cpp
+++ test/Driver/baremetal.cpp
@@ -10,7 +10,7 @@
 // CHECK-V6M-C-SAME: "-internal-isystem" "[[SYSROOT]]{{[/\\]+}}include{{[/\\]+}}c++{{[/\\]+}}v1"
 // CHECk-V6M-C-SAME: "-internal-isystem" "[[SYSROOT]]{{[/\\]+}}include"
 // CHECK-V6M-C-SAME: "-x" "c++" "{{.*}}baremetal.cpp"
-// CHECK-V6M-C-NEXT: "{{[^"]*}}ld.lld{{(\.exe)?}}" "{{.*}}.o" "-Bstatic"
+// CHECK-V6M-C-NEXT: "{{[^"]*}}ld{{(\.(lld|bfd|gold))?}}{{(\.exe)?}}" "{{.*}}.o" "-Bstatic"
 // CHECK-V6M-C-SAME: "-L[[RESOURCE_DIR:[^"]+]]{{[/\\]+}}lib{{[/\\]+}}baremetal"
 // CHECK-V6M-C-SAME: "-T" "semihosted.lds" "-Lsome{{[/\\]+}}directory{{[/\\]+}}user{{[/\\]+}}asked{{[/\\]+}}for"
 // CHECK-V6M-C-SAME: "-lc" "-lm" "-lclang_rt.builtins-armv6m.a"
@@ -32,7 +32,7 @@
 // RUN: -target armv6m-none-eabi \
 // RUN: --sysroot=%S/Inputs/baremetal_arm \
 // RUN:   | FileCheck --check-prefix=CHECK-V6M-DEFAULTCXX %s
-// CHECK-V6M-DEFAULTCXX: "{{[^"]*}}ld.lld{{(\.exe)?}}" "{{.*}}.o" "-Bstatic"
+// CHECK-V6M-DEFAULTCXX: "{{[^"]*}}ld{{(\.(lld|bfd|gold))?}}{{(\.exe)?}}" "{{.*}}.o" "-Bstatic"
 // C

[PATCH] D49899: Make test/Driver/fuchsia.c(pp) work with lld or gold

2018-07-26 Thread David Greene via Phabricator via cfe-commits
greened created this revision.
greened added reviewers: phosek, rsmith.
Herald added subscribers: cfe-commits, dexonsmith, mehdi_amini.

These tests don't appear to depend on lld.  They are invoking lto, so we should 
ensure the linker is capable of that.  Therefore, allow gold in addition to lld 
but nothing else.


Repository:
  rC Clang

https://reviews.llvm.org/D49899

Files:
  test/Driver/fuchsia.c
  test/Driver/fuchsia.cpp


Index: test/Driver/fuchsia.cpp
===
--- test/Driver/fuchsia.cpp
+++ test/Driver/fuchsia.cpp
@@ -6,7 +6,7 @@
 // CHECK: "-isysroot" "[[SYSROOT:[^"]+]]"
 // CHECK: "-internal-isystem" "{{.*[/\\]}}include{{/|}}c++{{/|}}v1"
 // CHECK: "-internal-externc-isystem" "[[SYSROOT]]{{/|}}include"
-// CHECK: {{.*}}ld.lld{{.*}}" "-z" "rodynamic"
+// CHECK: {{.*}}ld.{{(lld[^"]*" "-z" "rodynamic"|gold[^"]*")}}
 // CHECK: "--sysroot=[[SYSROOT]]"
 // CHECK: "-pie"
 // CHECK: "--build-id"
Index: test/Driver/fuchsia.c
===
--- test/Driver/fuchsia.c
+++ test/Driver/fuchsia.c
@@ -15,7 +15,7 @@
 // CHECK: "-fsanitize=safe-stack"
 // CHECK: "-stack-protector" "2"
 // CHECK: "-fno-common"
-// CHECK: {{.*}}ld.lld{{.*}}" "-z" "rodynamic"
+// CHECK: {{.*}}ld.{{(lld[^"]*" "-z" "rodynamic"|gold[^"]*")}}
 // CHECK: "--sysroot=[[SYSROOT]]"
 // CHECK: "-pie"
 // CHECK: "--build-id"


Index: test/Driver/fuchsia.cpp
===
--- test/Driver/fuchsia.cpp
+++ test/Driver/fuchsia.cpp
@@ -6,7 +6,7 @@
 // CHECK: "-isysroot" "[[SYSROOT:[^"]+]]"
 // CHECK: "-internal-isystem" "{{.*[/\\]}}include{{/|}}c++{{/|}}v1"
 // CHECK: "-internal-externc-isystem" "[[SYSROOT]]{{/|}}include"
-// CHECK: {{.*}}ld.lld{{.*}}" "-z" "rodynamic"
+// CHECK: {{.*}}ld.{{(lld[^"]*" "-z" "rodynamic"|gold[^"]*")}}
 // CHECK: "--sysroot=[[SYSROOT]]"
 // CHECK: "-pie"
 // CHECK: "--build-id"
Index: test/Driver/fuchsia.c
===
--- test/Driver/fuchsia.c
+++ test/Driver/fuchsia.c
@@ -15,7 +15,7 @@
 // CHECK: "-fsanitize=safe-stack"
 // CHECK: "-stack-protector" "2"
 // CHECK: "-fno-common"
-// CHECK: {{.*}}ld.lld{{.*}}" "-z" "rodynamic"
+// CHECK: {{.*}}ld.{{(lld[^"]*" "-z" "rodynamic"|gold[^"]*")}}
 // CHECK: "--sysroot=[[SYSROOT]]"
 // CHECK: "-pie"
 // CHECK: "--build-id"
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D49899: Make test/Driver/fuchsia.c(pp) work with lld or gold

2018-07-27 Thread David Greene via Phabricator via cfe-commits
greened updated this revision to Diff 157689.
greened added a comment.

The Fuchsia driver relies on lld so invoke clang with -fuse-ld=lld.  This gets 
the test passing when the clang default linker is something other than lld.


https://reviews.llvm.org/D49899

Files:
  test/Driver/fuchsia.c
  test/Driver/fuchsia.cpp

Index: test/Driver/fuchsia.cpp
===
--- test/Driver/fuchsia.cpp
+++ test/Driver/fuchsia.cpp
@@ -1,5 +1,5 @@
 // RUN: %clangxx %s -### -no-canonical-prefixes --target=x86_64-unknown-fuchsia \
-// RUN: --sysroot=%S/platform 2>&1 | FileCheck %s
+// RUN: --sysroot=%S/platform -fuse-ld=lld 2>&1 | FileCheck %s
 // CHECK: {{.*}}clang{{.*}}" "-cc1"
 // CHECK: "-triple" "x86_64-fuchsia"
 // CHECK: "-fuse-init-array"
@@ -21,11 +21,13 @@
 // CHECK-NOT: crtend.o
 // CHECK-NOT: crtn.o
 
-// RUN: %clangxx %s -### --target=x86_64-unknown-fuchsia -stdlib=libstdc++ 2>&1 \
+// RUN: %clangxx %s -### --target=x86_64-unknown-fuchsia -stdlib=libstdc++ \
+// RUN: -fuse-ld=lld 2>&1 \
 // RUN: | FileCheck %s -check-prefix=CHECK-STDLIB
 // CHECK-STDLIB: error: invalid library name in argument '-stdlib=libstdc++'
 
-// RUN: %clangxx %s -### --target=x86_64-unknown-fuchsia -static-libstdc++ 2>&1 \
+// RUN: %clangxx %s -### --target=x86_64-unknown-fuchsia -static-libstdc++ \
+// RUN: -fuse-ld=lld 2>&1 \
 // RUN: | FileCheck %s -check-prefix=CHECK-STATIC
 // CHECK-STATIC: "-Bstatic"
 // CHECK-STATIC: "-lc++"
Index: test/Driver/fuchsia.c
===
--- test/Driver/fuchsia.c
+++ test/Driver/fuchsia.c
@@ -1,10 +1,10 @@
 // RUN: %clang %s -### -no-canonical-prefixes --target=x86_64-fuchsia \
 // RUN: -resource-dir=%S/Inputs/resource_dir_with_per_target_subdir \
-// RUN: --sysroot=%S/platform 2>&1 \
+// RUN: --sysroot=%S/platform -fuse-ld=lld 2>&1 \
 // RUN: | FileCheck -check-prefixes=CHECK,CHECK-X86_64 %s
 // RUN: %clang %s -### -no-canonical-prefixes --target=aarch64-fuchsia \
 // RUN: -resource-dir=%S/Inputs/resource_dir_with_per_target_subdir \
-// RUN: --sysroot=%S/platform 2>&1 \
+// RUN: --sysroot=%S/platform -fuse-ld=lld 2>&1 \
 // RUN: | FileCheck -check-prefixes=CHECK,CHECK-AARCH64 %s
 // CHECK: {{.*}}clang{{.*}}" "-cc1"
 // CHECK: "--mrelax-relocations"
@@ -31,38 +31,40 @@
 // CHECK-NOT: crtend.o
 // CHECK-NOT: crtn.o
 
-// RUN: %clang %s -### --target=x86_64-fuchsia -rtlib=libgcc 2>&1 \
+// RUN: %clang %s -### --target=x86_64-fuchsia -rtlib=libgcc -fuse-ld=lld 2>&1 \
 // RUN: | FileCheck %s -check-prefix=CHECK-RTLIB
 // CHECK-RTLIB: error: invalid runtime library name in argument '-rtlib=libgcc'
 
-// RUN: %clang %s -### --target=x86_64-fuchsia -static 2>&1 \
+// RUN: %clang %s -### --target=x86_64-fuchsia -static -fuse-ld=lld 2>&1 \
 // RUN: | FileCheck %s -check-prefix=CHECK-STATIC
 // CHECK-STATIC: "-Bstatic"
 // CHECK-STATIC: "-Bdynamic"
 // CHECK-STATIC: "-lc"
 
-// RUN: %clang %s -### --target=x86_64-fuchsia -shared 2>&1 \
+// RUN: %clang %s -### --target=x86_64-fuchsia -shared -fuse-ld=lld 2>&1 \
 // RUN: | FileCheck %s -check-prefix=CHECK-SHARED
 // CHECK-SHARED-NOT: "-pie"
 // CHECK-SHARED: "-shared"
 
-// RUN: %clang %s -### --target=x86_64-fuchsia -r 2>&1 \
+// RUN: %clang %s -### --target=x86_64-fuchsia -r -fuse-ld=lld 2>&1 \
 // RUN: | FileCheck %s -check-prefix=CHECK-RELOCATABLE
 // CHECK-RELOCATABLE-NOT: "-pie"
 // CHECK-RELOCATABLE-NOT: "--build-id"
 // CHECK-RELOCATABLE: "-r"
 
 // RUN: %clang %s -### --target=x86_64-fuchsia \
 // RUN: -fsanitize=safe-stack 2>&1 \
 // RUN: -resource-dir=%S/Inputs/resource_dir_with_per_target_subdir \
+// RUN: -fuse-ld=lld \
 // RUN: | FileCheck %s -check-prefix=CHECK-SAFESTACK
 // CHECK-SAFESTACK: "-fsanitize=safe-stack"
 // CHECK-SAFESTACK-NOT: "{{.*[/\\]}}libclang_rt.safestack.a"
 // CHECK-SAFESTACK-NOT: "__safestack_init"
 
 // RUN: %clang %s -### --target=x86_64-fuchsia \
 // RUN: -fsanitize=address 2>&1 \
 // RUN: -resource-dir=%S/Inputs/resource_dir_with_per_target_subdir \
+// RUN: -fuse-ld=lld \
 // RUN: | FileCheck %s -check-prefix=CHECK-ASAN-X86
 // CHECK-ASAN-X86: "-fsanitize=address"
 // CHECK-ASAN-X86: "-fsanitize-address-globals-dead-stripping"
@@ -73,6 +75,7 @@
 // RUN: %clang %s -### --target=aarch64-fuchsia \
 // RUN: -fsanitize=address 2>&1 \
 // RUN: -resource-dir=%S/Inputs/resource_dir_with_per_target_subdir \
+// RUN: -fuse-ld=lld \
 // RUN: | FileCheck %s -check-prefix=CHECK-ASAN-AARCH64
 // CHECK-ASAN-AARCH64: "-fsanitize=address"
 // CHECK-ASAN-AARCH64: "-fsanitize-address-globals-dead-stripping"
@@ -83,6 +86,7 @@
 // RUN: %clang %s -### --target=x86_64-fuchsia \
 // RUN: -fsanitize=address -fPIC -shared 2>&1 \
 // RUN: -resource-dir=%S/Inputs/resource_dir_with_per_target_subdir \
+// RUN: -fuse-ld=lld \
 // RUN: | FileCheck %s -check-prefix=CHECK-ASAN-SHARED
 // CHECK-ASAN-SHARED: "-fsan

[PATCH] D49899: Force test/Driver/fuchsia.c(pp) to use lld

2018-07-27 Thread David Greene via Phabricator via cfe-commits
greened added a comment.

In https://reviews.llvm.org/D49899#1178545, @ruiu wrote:

> > The Fuchsia driver relies on lld so invoke clang with -fuse-ld=lld. This 
> > gets the test passing when the clang default linker is something other than 
> > lld.
>
> Does it work if lld is not installed at all? I believe if the driver cannot 
> find a specified linker, it reports an error instead of trying to execute a 
> nonexistent file.


Not it does not.  There does not seem to be a way to disable a test if lld is 
not available.  I couldn't find anything appropriate for a REQUIRES in
the test.  I would like to leave that work for another time.  This at least 
gets things working a little better.


https://reviews.llvm.org/D49899



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


[PATCH] D49244: Always search sysroot for GCC installs

2018-07-30 Thread David Greene via Phabricator via cfe-commits
greened added a comment.

Ping.


Repository:
  rC Clang

https://reviews.llvm.org/D49244



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


[PATCH] D49898: Make test/Driver/baremetal.cpp work with linkers other than lld

2018-07-30 Thread David Greene via Phabricator via cfe-commits
greened added a comment.

I think I need an accept before this can proceed.


Repository:
  rC Clang

https://reviews.llvm.org/D49898



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


[PATCH] D49898: Make test/Driver/baremetal.cpp work with linkers other than lld

2018-07-30 Thread David Greene via Phabricator via cfe-commits
greened closed this revision.
greened added a comment.

Committed in 338290.


Repository:
  rC Clang

https://reviews.llvm.org/D49898



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


[PATCH] D48487: [X86][AVX512] Lowering _mm512_[max|min]_p[s|d] to native IR

2018-06-22 Thread David Greene via Phabricator via cfe-commits
greened added a comment.

In https://reviews.llvm.org/D48487#1140703, @RKSimon wrote:

> I haven't used the AVX512 versions, but I do know plenty of cases that rely 
> on the 'use the second op if there is a NAN or both zeros' special cases in 
> the SSE version of these FMIN/FMAX intrinsics.


Yes, this behavior is important for AVX512 as well.  Any lowering must preserve 
the full semantics of the intrinsics.


Repository:
  rC Clang

https://reviews.llvm.org/D48487



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


[PATCH] D49244: Always search sysroot for GCC installs

2018-10-12 Thread David Greene via Phabricator via cfe-commits
greened added a comment.

Ping.  This is impacting our ability to get clang functioning.


Repository:
  rC Clang

https://reviews.llvm.org/D49244



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


[PATCH] D49244: Always search sysroot for GCC installs

2018-10-22 Thread David Greene via Phabricator via cfe-commits
greened closed this revision.
greened added a comment.

Fixed in r344901.


Repository:
  rC Clang

https://reviews.llvm.org/D49244



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


[PATCH] D53770: Support g++ headers in include/g++

2018-10-26 Thread David Greene via Phabricator via cfe-commits
greened created this revision.
greened added reviewers: danalbert, dlj, atanasyan, phosek.
Herald added a subscriber: cfe-commits.

Some gcc installations put C++ headers in PREFIX/include/g++ without indicating 
a gcc version at all.  Typically this is because the version is encoded 
somewhere in PREFIX.


Repository:
  rC Clang

https://reviews.llvm.org/D53770

Files:
  lib/Driver/ToolChains/Linux.cpp


Index: lib/Driver/ToolChains/Linux.cpp
===
--- lib/Driver/ToolChains/Linux.cpp
+++ lib/Driver/ToolChains/Linux.cpp
@@ -924,6 +924,9 @@
   // Freescale SDK C++ headers are directly in /usr/include/c++,
   // without a subdirectory corresponding to the gcc version.
   LibDir.str() + "/../include/c++",
+  // Some gcc installations put headers under "g++" without a
+  // version suffix.
+  LibDir.str() + "/../include/g++",
   };
 
   for (const auto &IncludePath : LibStdCXXIncludePathCandidates) {


Index: lib/Driver/ToolChains/Linux.cpp
===
--- lib/Driver/ToolChains/Linux.cpp
+++ lib/Driver/ToolChains/Linux.cpp
@@ -924,6 +924,9 @@
   // Freescale SDK C++ headers are directly in /usr/include/c++,
   // without a subdirectory corresponding to the gcc version.
   LibDir.str() + "/../include/c++",
+  // Some gcc installations put headers under "g++" without a
+  // version suffix.
+  LibDir.str() + "/../include/g++",
   };
 
   for (const auto &IncludePath : LibStdCXXIncludePathCandidates) {
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D53770: Support g++ headers in include/g++

2018-10-29 Thread David Greene via Phabricator via cfe-commits
greened added inline comments.



Comment at: lib/Driver/ToolChains/Linux.cpp:927-928
   LibDir.str() + "/../include/c++",
+  // Some gcc installations put headers under "g++" without a
+  // version suffix.
+  LibDir.str() + "/../include/g++",

rsmith wrote:
> It'd be useful to say who this "some" is, so we can check whether this is 
> still a valid concern in the future.
I will try to find out where we got the package from.


Repository:
  rC Clang

https://reviews.llvm.org/D53770



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


[PATCH] D53770: Support g++ headers in include/g++

2018-10-30 Thread David Greene via Phabricator via cfe-commits
greened updated this revision to Diff 171801.
greened edited the summary of this revision.
greened added a comment.

Explain that Cray packages gcc such that headers are in include/g++.


Repository:
  rC Clang

https://reviews.llvm.org/D53770

Files:
  lib/Driver/ToolChains/Linux.cpp


Index: lib/Driver/ToolChains/Linux.cpp
===
--- lib/Driver/ToolChains/Linux.cpp
+++ lib/Driver/ToolChains/Linux.cpp
@@ -924,6 +924,9 @@
   // Freescale SDK C++ headers are directly in /usr/include/c++,
   // without a subdirectory corresponding to the gcc version.
   LibDir.str() + "/../include/c++",
+  // Cray's gcc installation puts headers under "g++" without a
+  // version suffix.
+  LibDir.str() + "/../include/g++",
   };
 
   for (const auto &IncludePath : LibStdCXXIncludePathCandidates) {


Index: lib/Driver/ToolChains/Linux.cpp
===
--- lib/Driver/ToolChains/Linux.cpp
+++ lib/Driver/ToolChains/Linux.cpp
@@ -924,6 +924,9 @@
   // Freescale SDK C++ headers are directly in /usr/include/c++,
   // without a subdirectory corresponding to the gcc version.
   LibDir.str() + "/../include/c++",
+  // Cray's gcc installation puts headers under "g++" without a
+  // version suffix.
+  LibDir.str() + "/../include/g++",
   };
 
   for (const auto &IncludePath : LibStdCXXIncludePathCandidates) {
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D53770: Support g++ headers in include/g++

2018-11-13 Thread David Greene via Phabricator via cfe-commits
This revision was not accepted when it landed; it landed in state "Needs 
Review".
This revision was automatically updated to reflect the committed changes.
Closed by commit rL346802: [Driver] Support g++ headers in include/g++ 
(authored by greened, committed by ).
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D53770?vs=171801&id=173934#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D53770

Files:
  cfe/trunk/lib/Driver/ToolChains/Linux.cpp
  
cfe/trunk/test/Driver/Inputs/cray_suse_gcc_tree/opt/gcc/8.2.0/snos/include/g++/backward/.keep
  
cfe/trunk/test/Driver/Inputs/cray_suse_gcc_tree/opt/gcc/8.2.0/snos/lib/gcc/x86_64-suse-linux/8.2.0/crtbegin.o
  cfe/trunk/test/Driver/Inputs/cray_suse_gcc_tree/usr/include/c++/4.8/.keep
  
cfe/trunk/test/Driver/Inputs/cray_suse_gcc_tree/usr/lib/gcc/x86_64-suse-linux/8.2.0/crtbegin.o
  cfe/trunk/test/Driver/linux-header-search.cpp


Index: cfe/trunk/test/Driver/linux-header-search.cpp
===
--- cfe/trunk/test/Driver/linux-header-search.cpp
+++ cfe/trunk/test/Driver/linux-header-search.cpp
@@ -517,3 +517,15 @@
 // CHECK-OE-AARCH64: "-isysroot" "[[SYSROOT:[^"]+]]"
 // CHECK-OE-AARCH64: "-internal-isystem" 
"[[SYSROOT]]/usr/lib64/aarch64-oe-linux/6.3.0/../../../include/c++/6.3.0"
 // CHECK-OE-AARCH64: "-internal-isystem" 
"[[SYSROOT]]/usr/lib64/aarch64-oe-linux/6.3.0/../../../include/c++/6.3.0/backward"
+
+// Check header search with Cray's gcc package.
+// RUN: %clang -no-canonical-prefixes %s -### -fsyntax-only 2>&1 \
+// RUN: -target x86_64-unknown-linux-gnu -stdlib=libstdc++ \
+// RUN: --sysroot=%S/Inputs/cray_suse_gcc_tree \
+// RUN: --gcc-toolchain="%S/Inputs/cray_suse_gcc_tree/opt/gcc/8.2.0/snos" \
+// RUN:   | FileCheck --check-prefix=CHECK-CRAY-X86 %s
+
+// CHECK-CRAY-X86: "{{[^"]*}}clang{{[^"]*}}" "-cc1"
+// CHECK-CRAY-X86: "-isysroot" "[[SYSROOT:[^"]+]]"
+// CHECK-CRAY-X86: "-internal-isystem" 
"[[SYSROOT]]/opt/gcc/8.2.0/snos/lib/gcc/x86_64-suse-linux/8.2.0/../../../../include/g++"
+// CHECK-CRAY-X86: "-internal-isystem" 
"[[SYSROOT]]/opt/gcc/8.2.0/snos/lib/gcc/x86_64-suse-linux/8.2.0/../../../../include/g++/backward"
Index: cfe/trunk/lib/Driver/ToolChains/Linux.cpp
===
--- cfe/trunk/lib/Driver/ToolChains/Linux.cpp
+++ cfe/trunk/lib/Driver/ToolChains/Linux.cpp
@@ -930,6 +930,9 @@
   // Freescale SDK C++ headers are directly in /usr/include/c++,
   // without a subdirectory corresponding to the gcc version.
   LibDir.str() + "/../include/c++",
+  // Cray's gcc installation puts headers under "g++" without a
+  // version suffix.
+  LibDir.str() + "/../include/g++",
   };
 
   for (const auto &IncludePath : LibStdCXXIncludePathCandidates) {


Index: cfe/trunk/test/Driver/linux-header-search.cpp
===
--- cfe/trunk/test/Driver/linux-header-search.cpp
+++ cfe/trunk/test/Driver/linux-header-search.cpp
@@ -517,3 +517,15 @@
 // CHECK-OE-AARCH64: "-isysroot" "[[SYSROOT:[^"]+]]"
 // CHECK-OE-AARCH64: "-internal-isystem" "[[SYSROOT]]/usr/lib64/aarch64-oe-linux/6.3.0/../../../include/c++/6.3.0"
 // CHECK-OE-AARCH64: "-internal-isystem" "[[SYSROOT]]/usr/lib64/aarch64-oe-linux/6.3.0/../../../include/c++/6.3.0/backward"
+
+// Check header search with Cray's gcc package.
+// RUN: %clang -no-canonical-prefixes %s -### -fsyntax-only 2>&1 \
+// RUN: -target x86_64-unknown-linux-gnu -stdlib=libstdc++ \
+// RUN: --sysroot=%S/Inputs/cray_suse_gcc_tree \
+// RUN: --gcc-toolchain="%S/Inputs/cray_suse_gcc_tree/opt/gcc/8.2.0/snos" \
+// RUN:   | FileCheck --check-prefix=CHECK-CRAY-X86 %s
+
+// CHECK-CRAY-X86: "{{[^"]*}}clang{{[^"]*}}" "-cc1"
+// CHECK-CRAY-X86: "-isysroot" "[[SYSROOT:[^"]+]]"
+// CHECK-CRAY-X86: "-internal-isystem" "[[SYSROOT]]/opt/gcc/8.2.0/snos/lib/gcc/x86_64-suse-linux/8.2.0/../../../../include/g++"
+// CHECK-CRAY-X86: "-internal-isystem" "[[SYSROOT]]/opt/gcc/8.2.0/snos/lib/gcc/x86_64-suse-linux/8.2.0/../../../../include/g++/backward"
Index: cfe/trunk/lib/Driver/ToolChains/Linux.cpp
===
--- cfe/trunk/lib/Driver/ToolChains/Linux.cpp
+++ cfe/trunk/lib/Driver/ToolChains/Linux.cpp
@@ -930,6 +930,9 @@
   // Freescale SDK C++ headers are directly in /usr/include/c++,
   // without a subdirectory corresponding to the gcc version.
   LibDir.str() + "/../include/c++",
+  // Cray's gcc installation puts headers under "g++" without a
+  // version suffix.
+  LibDir.str() + "/../include/g++",
   };
 
   for (const auto &IncludePath : LibStdCXXIncludePathCandidates) {
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D53770: Support g++ headers in include/g++

2018-11-13 Thread David Greene via Phabricator via cfe-commits
greened added a comment.

Oops, I didn't realize this hadn't been formally accepted yet.  Still learning 
the Phab process.  Let me know if you want it reverted for a formal accept.


Repository:
  rL LLVM

https://reviews.llvm.org/D53770



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


[PATCH] D49244: Always search sysroot for GCC installs

2018-10-05 Thread David Greene via Phabricator via cfe-commits
greened updated this revision to Diff 168472.
greened added a comment.

Updated to implement option 2.  I'm not totally happy with passing a StringRef 
just to check if it's non-empty but opted to reduce the size of the diff rather 
than refactor a bunch of stuff.


Repository:
  rC Clang

https://reviews.llvm.org/D49244

Files:
  lib/Driver/ToolChains/Gnu.cpp


Index: lib/Driver/ToolChains/Gnu.cpp
===
--- lib/Driver/ToolChains/Gnu.cpp
+++ lib/Driver/ToolChains/Gnu.cpp
@@ -1618,10 +1618,18 @@
   return GoodVersion;
 }
 
-static llvm::StringRef getGCCToolchainDir(const ArgList &Args) {
+static llvm::StringRef getGCCToolchainDir(const ArgList &Args,
+  llvm::StringRef SysRoot) {
   const Arg *A = Args.getLastArg(clang::driver::options::OPT_gcc_toolchain);
   if (A)
 return A->getValue();
+
+  // If we have a SysRoot, ignore GCC_INSTALL_PREFIX.
+  // GCC_INSTALL_PREFIX specifies the gcc installation for the default
+  // sysroot and is likely not valid with a different sysroot.
+  if (!SysRoot.empty())
+return "";
+
   return GCC_INSTALL_PREFIX;
 }
 
@@ -1653,7 +1661,7 @@
   SmallVector Prefixes(D.PrefixDirs.begin(),
D.PrefixDirs.end());
 
-  StringRef GCCToolchainDir = getGCCToolchainDir(Args);
+  StringRef GCCToolchainDir = getGCCToolchainDir(Args, D.SysRoot);
   if (GCCToolchainDir != "") {
 if (GCCToolchainDir.back() == '/')
   GCCToolchainDir = GCCToolchainDir.drop_back(); // remove the /


Index: lib/Driver/ToolChains/Gnu.cpp
===
--- lib/Driver/ToolChains/Gnu.cpp
+++ lib/Driver/ToolChains/Gnu.cpp
@@ -1618,10 +1618,18 @@
   return GoodVersion;
 }
 
-static llvm::StringRef getGCCToolchainDir(const ArgList &Args) {
+static llvm::StringRef getGCCToolchainDir(const ArgList &Args,
+  llvm::StringRef SysRoot) {
   const Arg *A = Args.getLastArg(clang::driver::options::OPT_gcc_toolchain);
   if (A)
 return A->getValue();
+
+  // If we have a SysRoot, ignore GCC_INSTALL_PREFIX.
+  // GCC_INSTALL_PREFIX specifies the gcc installation for the default
+  // sysroot and is likely not valid with a different sysroot.
+  if (!SysRoot.empty())
+return "";
+
   return GCC_INSTALL_PREFIX;
 }
 
@@ -1653,7 +1661,7 @@
   SmallVector Prefixes(D.PrefixDirs.begin(),
D.PrefixDirs.end());
 
-  StringRef GCCToolchainDir = getGCCToolchainDir(Args);
+  StringRef GCCToolchainDir = getGCCToolchainDir(Args, D.SysRoot);
   if (GCCToolchainDir != "") {
 if (GCCToolchainDir.back() == '/')
   GCCToolchainDir = GCCToolchainDir.drop_back(); // remove the /
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D58548: IR: Support parsing numeric block ids, and emit them in textual output.

2019-02-22 Thread David Greene via Phabricator via cfe-commits
greened added a comment.

+1.  Is there any reason not to use "%4" in the definition?

  define i32 @f(i32, i32) {
%3 = add i32 %0, %1
br label %4
  
  %4:
ret i32 %3
  }

Maybe it creates an ambiguity in the grammar or something.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D58548



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


[PATCH] D49244: Always search sysroot for GCC installs

2018-07-12 Thread David Greene via Phabricator via cfe-commits
greened created this revision.
greened added reviewers: rsmith, mcrosier, danalbert.
greened added a project: clang.
Herald added a subscriber: cfe-commits.

Previously, if clang was configured with -DGCC_INSTALL_PREFIX, then it would 
not search a provided sysroot for a gcc install.  This caused a number of 
regression tests to fail.  Add sysroot to the list of paths to search, even if 
a gcc toolchain is provided with cmake or a command-line option.  The sysroot 
is searched after the provided install.


Repository:
  rC Clang

https://reviews.llvm.org/D49244

Files:
  lib/Driver/ToolChains/Gnu.cpp


Index: lib/Driver/ToolChains/Gnu.cpp
===
--- lib/Driver/ToolChains/Gnu.cpp
+++ lib/Driver/ToolChains/Gnu.cpp
@@ -1670,6 +1670,15 @@
   GCCToolchainDir = GCCToolchainDir.drop_back(); // remove the /
 
 Prefixes.push_back(GCCToolchainDir);
+
+// If we have a SysRoot, try that too as GCCToolchainDir may not
+// have support for the target.  This can happen, for example, if
+// clang was configured with -DGCC_INSTALL_PREFIX and we run
+// regression tests with --sysroot.
+if (!D.SysRoot.empty()) {
+  Prefixes.push_back(D.SysRoot);
+  AddDefaultGCCPrefixes(TargetTriple, Prefixes, D.SysRoot);
+}
   } else {
 // If we have a SysRoot, try that first.
 if (!D.SysRoot.empty()) {


Index: lib/Driver/ToolChains/Gnu.cpp
===
--- lib/Driver/ToolChains/Gnu.cpp
+++ lib/Driver/ToolChains/Gnu.cpp
@@ -1670,6 +1670,15 @@
   GCCToolchainDir = GCCToolchainDir.drop_back(); // remove the /
 
 Prefixes.push_back(GCCToolchainDir);
+
+// If we have a SysRoot, try that too as GCCToolchainDir may not
+// have support for the target.  This can happen, for example, if
+// clang was configured with -DGCC_INSTALL_PREFIX and we run
+// regression tests with --sysroot.
+if (!D.SysRoot.empty()) {
+  Prefixes.push_back(D.SysRoot);
+  AddDefaultGCCPrefixes(TargetTriple, Prefixes, D.SysRoot);
+}
   } else {
 // If we have a SysRoot, try that first.
 if (!D.SysRoot.empty()) {
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D49244: Always search sysroot for GCC installs

2018-07-17 Thread David Greene via Phabricator via cfe-commits
greened added a comment.

Ping.


Repository:
  rC Clang

https://reviews.llvm.org/D49244



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


[PATCH] D67550: [AArch64][SVE] Implement unpack intrinsics

2019-10-10 Thread David Greene via Phabricator via cfe-commits
greened added inline comments.



Comment at: lib/Target/AArch64/SVEInstrFormats.td:836
 class sve_int_perm_unpk sz16_64, bits<2> opc, string asm,
-ZPRRegOp zprty1, ZPRRegOp zprty2>
+ZPRRegOp zprty1, ZPRRegOp zprty2, SDPatternOperator op>
 : I<(outs zprty1:$Zd), (ins zprty2:$Zn),

Where is `op` used?  I assume that comes later but it would help to understand 
where this is going.


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

https://reviews.llvm.org/D67550



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


[PATCH] D67551: [AArch64][SVE] Implement sdot and udot (lane) intrinsics

2019-10-10 Thread David Greene via Phabricator via cfe-commits
greened added a comment.

LGTM.


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

https://reviews.llvm.org/D67551



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


[PATCH] D67550: [AArch64][SVE] Implement unpack intrinsics

2019-10-17 Thread David Greene via Phabricator via cfe-commits
greened accepted this revision.
greened added a comment.
This revision is now accepted and ready to land.

LGTM.


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

https://reviews.llvm.org/D67550



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


[PATCH] D83004: [UpdateCCTestChecks] Include generated functions if asked

2020-07-22 Thread David Greene via Phabricator via cfe-commits
greened marked an inline comment as done.
greened added inline comments.



Comment at: llvm/utils/update_cc_test_checks.py:133
+  parser.add_argument('--include-generated-funcs', action='store_true',
+  help='Output checks for functions not in source')
   parser.add_argument('tests', nargs='+')

jdoerfert wrote:
> greened wrote:
> > jdoerfert wrote:
> > > greened wrote:
> > > > greened wrote:
> > > > > jdoerfert wrote:
> > > > > > I think this should go into common.py (after D78618). I would also 
> > > > > > make this the default but OK.
> > > > > Yes I suppose it should in case `opt` and friends generate functions. 
> > > > >  I hadn't considered that use-case.
> > > > > 
> > > > > While I would like to make it default unfortunately it would require 
> > > > > updating a bunch of the existing clang tests which doesn't seem too 
> > > > > friendly.  See the patch update comment for details.
> > > > > 
> > > > Just realized it wouldn't necessarily require regeneration of tests, it 
> > > > would just cause regenerated tests to change a lot when they are 
> > > > eventually regenerated.  We should discuss as to whether that's 
> > > > acceptable.  I think for now this should be non-default to at least get 
> > > > the functionality in without disturbing existing users and then we can 
> > > > discuss a separate change to make it default.
> > > > 
> > > > It's also possible we could change how clang orders functions.  I 
> > > > discovered there's a difference in clang 10 vs. 11 in the order 
> > > > functions are output when OpenMP outlining happens.  clang 10 seems to 
> > > > preserve the source order of functions and clang 11 does not.  Perhaps 
> > > > that needs to be fixed as I don't know whether that change was 
> > > > intentional or not.
> > > Best case, without the option the original behavior is preserved. Is that 
> > > not the case?
> > That's right.  I was referring to making this behavior default.  If we do 
> > that, we could clean up the script code a bit but it would mean clang tests 
> > would change pretty dramatically when they are regenerated.  If we fix the 
> > clang output, the test changes wouldn't be so dramatic.
> > 
> > The way clang is behaving now, I would expect any tests that use 
> > `-fopenmp`, have multiple functions with OpenMP regions and use function 
> > prototypes for some of those functions would break given clang's reordering 
> > of function definitions.  Perhaps we don't have any tests like that though.
> We (almost) do not have OpenMP tests with autogenerated test lines. 
> Partially, because we do not test new functions. I would really like this to 
> be available for OpenMP, both in _cc_ and IR tests. If people can opt out of 
> this, especially if the default is "off", the ordering is not a problem 
> (IMHO). With UTC_ARGS we also remember the choice so I really don't see the 
> downside to this being in the common part for all scripts.
I agree it can be in the common part. I'll move it there and will leave it off 
by default so it doesn't disturb existing tests.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D83004



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


[PATCH] D83004: [UpdateCCTestChecks] Include generated functions if asked

2020-07-22 Thread David Greene via Phabricator via cfe-commits
greened updated this revision to Diff 279932.
greened added a comment.

Updated to move the option into `common.py`.  Also had to rework the output 
loop to account for differences between python 2 and 3.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D83004

Files:
  clang/test/utils/update_cc_test_checks/Inputs/generated-funcs.c
  
clang/test/utils/update_cc_test_checks/Inputs/generated-funcs.c.generated.expected
  
clang/test/utils/update_cc_test_checks/Inputs/generated-funcs.c.no-generated.expected
  clang/test/utils/update_cc_test_checks/generated-funcs.test
  llvm/utils/UpdateTestChecks/asm.py
  llvm/utils/UpdateTestChecks/common.py
  llvm/utils/update_cc_test_checks.py
  llvm/utils/update_llc_test_checks.py
  llvm/utils/update_test_checks.py

Index: llvm/utils/update_test_checks.py
===
--- llvm/utils/update_test_checks.py
+++ llvm/utils/update_test_checks.py
@@ -137,9 +137,11 @@
   prefix_list.append((check_prefixes, tool_cmd_args))
 
 func_dict = {}
+func_order = {}
 for prefixes, _ in prefix_list:
   for prefix in prefixes:
 func_dict.update({prefix: dict()})
+func_order.update({prefix: []})
 for prefixes, opt_args in prefix_list:
   common.debug('Extracted opt cmd: ' + opt_basename + ' ' + opt_args)
   common.debug('Extracted FileCheck prefixes: ' + str(prefixes))
@@ -147,7 +149,7 @@
   raw_tool_output = common.invoke_tool(args.opt_binary, opt_args, test)
   common.build_function_body_dictionary(
   common.OPT_FUNCTION_RE, common.scrub_body, [],
-  raw_tool_output, prefixes, func_dict, args.verbose,
+  raw_tool_output, prefixes, func_dict, func_order, args.verbose,
   args.function_signature)
 
 is_in_function = False
Index: llvm/utils/update_llc_test_checks.py
===
--- llvm/utils/update_llc_test_checks.py
+++ llvm/utils/update_llc_test_checks.py
@@ -123,10 +123,12 @@
 autogenerated_note = (comment_sym + ADVERT + 'utils/' + script_name)
 
 func_dict = {}
+func_order = {}
 for p in run_list:
   prefixes = p[0]
   for prefix in prefixes:
 func_dict.update({prefix: dict()})
+func_order.update({prefix: []})
 for prefixes, llc_args, triple_in_cmd, march_in_cmd in run_list:
   common.debug('Extracted LLC cmd:', llc_tool, llc_args)
   common.debug('Extracted FileCheck prefixes:', str(prefixes))
@@ -138,7 +140,7 @@
 triple = asm.get_triple_from_march(march_in_cmd)
 
   asm.build_function_body_dictionary_for_triple(args, raw_tool_output,
-  triple, prefixes, func_dict)
+  triple, prefixes, func_dict, func_order)
 
 is_in_function = False
 is_in_function_start = False
Index: llvm/utils/update_cc_test_checks.py
===
--- llvm/utils/update_cc_test_checks.py
+++ llvm/utils/update_cc_test_checks.py
@@ -168,7 +168,8 @@
   return args
 
 
-def get_function_body(args, filename, clang_args, extra_commands, prefixes, triple_in_cmd, func_dict):
+def get_function_body(args, filename, clang_args, extra_commands, prefixes,
+  triple_in_cmd, func_dict, func_order):
   # TODO Clean up duplication of asm/common build_function_body_dictionary
   # Invoke external tool and extract function bodies.
   raw_tool_output = common.invoke_tool(args.clang, clang_args, filename)
@@ -188,7 +189,8 @@
   if '-emit-llvm' in clang_args:
 common.build_function_body_dictionary(
 common.OPT_FUNCTION_RE, common.scrub_body, [],
-raw_tool_output, prefixes, func_dict, args.verbose, args.function_signature)
+raw_tool_output, prefixes, func_dict, func_order, args.verbose,
+args.function_signature)
   else:
 print('The clang command line should include -emit-llvm as asm tests '
   'are discouraged in Clang testsuite.', file=sys.stderr)
@@ -267,15 +269,18 @@
 
 # Execute clang, generate LLVM IR, and extract functions.
 func_dict = {}
+func_order = {}
 for p in run_list:
   prefixes = p[0]
   for prefix in prefixes:
 func_dict.update({prefix: dict()})
+func_order.update({prefix: []})
 for prefixes, clang_args, extra_commands, triple_in_cmd in run_list:
   common.debug('Extracted clang cmd: clang {}'.format(clang_args))
   common.debug('Extracted FileCheck prefixes: {}'.format(prefixes))
 
-  get_function_body(args, filename, clang_args, extra_commands, prefixes, triple_in_cmd, func_dict)
+  get_function_body(args, filename, clang_args, extra_commands, prefixes,
+triple_in_cmd, func_dict, func_order)
 
   # Invoke clang -Xclang -ast-dump=json to get mapping from start lines to
   # mangled names. Forward all clang ar

[PATCH] D83004: [UpdateCCTestChecks] Include generated functions if asked

2020-07-06 Thread David Greene via Phabricator via cfe-commits
greened updated this revision to Diff 275831.
greened added a comment.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Fixed various bugs, added tests.

This now has two modes because generated function output can't be ordered with 
respect to source file functions.  When clang generates functions it can 
sometimes output original source functions in a different (non-source) order so 
checks can't be placed next to their definitions in the source file.

I don't particularly like this mode dichotomy but unifying it would necessitate 
updating a whole lot of clang tests.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D83004

Files:
  clang/test/utils/update_cc_test_checks/Inputs/generated-funcs.c
  
clang/test/utils/update_cc_test_checks/Inputs/generated-funcs.c.generated.expected
  
clang/test/utils/update_cc_test_checks/Inputs/generated-funcs.c.no-generated.expected
  clang/test/utils/update_cc_test_checks/generated-funcs.test
  llvm/utils/UpdateTestChecks/asm.py
  llvm/utils/UpdateTestChecks/common.py
  llvm/utils/update_cc_test_checks.py
  llvm/utils/update_llc_test_checks.py
  llvm/utils/update_test_checks.py

Index: llvm/utils/update_test_checks.py
===
--- llvm/utils/update_test_checks.py
+++ llvm/utils/update_test_checks.py
@@ -137,9 +137,11 @@
   prefix_list.append((check_prefixes, tool_cmd_args))
 
 func_dict = {}
+func_order = {}
 for prefixes, _ in prefix_list:
   for prefix in prefixes:
 func_dict.update({prefix: dict()})
+func_order.update({prefix: []})
 for prefixes, opt_args in prefix_list:
   common.debug('Extracted opt cmd: ' + opt_basename + ' ' + opt_args)
   common.debug('Extracted FileCheck prefixes: ' + str(prefixes))
@@ -147,7 +149,7 @@
   raw_tool_output = common.invoke_tool(args.opt_binary, opt_args, test)
   common.build_function_body_dictionary(
   common.OPT_FUNCTION_RE, common.scrub_body, [],
-  raw_tool_output, prefixes, func_dict, args.verbose,
+  raw_tool_output, prefixes, func_dict, func_order, args.verbose,
   args.function_signature)
 
 is_in_function = False
Index: llvm/utils/update_llc_test_checks.py
===
--- llvm/utils/update_llc_test_checks.py
+++ llvm/utils/update_llc_test_checks.py
@@ -123,10 +123,12 @@
 autogenerated_note = (comment_sym + ADVERT + 'utils/' + script_name)
 
 func_dict = {}
+func_order = {}
 for p in run_list:
   prefixes = p[0]
   for prefix in prefixes:
 func_dict.update({prefix: dict()})
+func_order.update({prefix: []})
 for prefixes, llc_args, triple_in_cmd, march_in_cmd in run_list:
   common.debug('Extracted LLC cmd:', llc_tool, llc_args)
   common.debug('Extracted FileCheck prefixes:', str(prefixes))
@@ -138,7 +140,7 @@
 triple = asm.get_triple_from_march(march_in_cmd)
 
   asm.build_function_body_dictionary_for_triple(args, raw_tool_output,
-  triple, prefixes, func_dict)
+  triple, prefixes, func_dict, func_order)
 
 is_in_function = False
 is_in_function_start = False
Index: llvm/utils/update_cc_test_checks.py
===
--- llvm/utils/update_cc_test_checks.py
+++ llvm/utils/update_cc_test_checks.py
@@ -129,6 +129,8 @@
   help='Use more regex for x86 matching to reduce diffs between various subtargets')
   parser.add_argument('--function-signature', action='store_true',
   help='Keep function signature information around for the check line')
+  parser.add_argument('--include-generated-funcs', action='store_true',
+  help='Output checks for functions not in source')
   parser.add_argument('tests', nargs='+')
   args = common.parse_commandline_args(parser)
   args.clang_args = shlex.split(args.clang_args or '')
@@ -168,7 +170,8 @@
   return args
 
 
-def get_function_body(args, filename, clang_args, extra_commands, prefixes, triple_in_cmd, func_dict):
+def get_function_body(args, filename, clang_args, extra_commands, prefixes,
+  triple_in_cmd, func_dict, func_order):
   # TODO Clean up duplication of asm/common build_function_body_dictionary
   # Invoke external tool and extract function bodies.
   raw_tool_output = common.invoke_tool(args.clang, clang_args, filename)
@@ -188,7 +191,8 @@
   if '-emit-llvm' in clang_args:
 common.build_function_body_dictionary(
 common.OPT_FUNCTION_RE, common.scrub_body, [],
-raw_tool_output, prefixes, func_dict, args.verbose, args.function_signature)
+raw_tool_output, prefixes, func_dict, func_order, args.verbose,
+args.function_signature)
   else:
 print('The clang command line should include -emit-llvm as asm t

[PATCH] D83004: [UpdateCCTestChecks] Include generated functions if asked

2020-07-06 Thread David Greene via Phabricator via cfe-commits
greened marked an inline comment as done.
greened added inline comments.



Comment at: llvm/utils/update_cc_test_checks.py:133
+  parser.add_argument('--include-generated-funcs', action='store_true',
+  help='Output checks for functions not in source')
   parser.add_argument('tests', nargs='+')

jdoerfert wrote:
> I think this should go into common.py (after D78618). I would also make this 
> the default but OK.
Yes I suppose it should in case `opt` and friends generate functions.  I hadn't 
considered that use-case.

While I would like to make it default unfortunately it would require updating a 
bunch of the existing clang tests which doesn't seem too friendly.  See the 
patch update comment for details.



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D83004



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


[PATCH] D83004: [UpdateCCTestChecks] Include generated functions if asked

2020-07-06 Thread David Greene via Phabricator via cfe-commits
greened added a comment.

In D83004#2129362 , @jdoerfert wrote:

> This is great! Just a few days ago I added a TODO in one of the tests I 
> created asking for this: D82722  :)


Glad to help!

> Will this work for all test scripts?

Obviously right now it's only enabled for clang but it should be 
straightforward to add to the other test scripts.  Al the infrastructure is 
there, the various drivers just have to use it.

> Will this make the `prefix_exclusions` logic obsolete?

Yeah, I think it might.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D83004



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


[PATCH] D83004: [UpdateCCTestChecks] Include generated functions if asked

2020-07-06 Thread David Greene via Phabricator via cfe-commits
greened added a comment.

In D83004#2134303 , @greened wrote:

>




> I don't particularly like this mode dichotomy but unifying it would 
> necessitate updating a whole lot of clang tests.

Axtually that's not strictly true,  It would just change the tests 
singificantly when they are updated for some other reason.  Whether that is 
reasonable is something we should discuss.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D83004



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


[PATCH] D83004: [UpdateCCTestChecks] Include generated functions if asked

2020-07-06 Thread David Greene via Phabricator via cfe-commits
greened marked an inline comment as done.
greened added inline comments.



Comment at: llvm/utils/update_cc_test_checks.py:133
+  parser.add_argument('--include-generated-funcs', action='store_true',
+  help='Output checks for functions not in source')
   parser.add_argument('tests', nargs='+')

greened wrote:
> jdoerfert wrote:
> > I think this should go into common.py (after D78618). I would also make 
> > this the default but OK.
> Yes I suppose it should in case `opt` and friends generate functions.  I 
> hadn't considered that use-case.
> 
> While I would like to make it default unfortunately it would require updating 
> a bunch of the existing clang tests which doesn't seem too friendly.  See the 
> patch update comment for details.
> 
Just realized it wouldn't necessarily require regeneration of tests, it would 
just cause regenerated tests to change a lot when they are eventually 
regenerated.  We should discuss as to whether that's acceptable.  I think for 
now this should be non-default to at least get the functionality in without 
disturbing existing users and then we can discuss a separate change to make it 
default.

It's also possible we could change how clang orders functions.  I discovered 
there's a difference in clang 10 vs. 11 in the order functions are output when 
OpenMP outlining happens.  clang 10 seems to preserve the source order of 
functions and clang 11 does not.  Perhaps that needs to be fixed as I don't 
know whether that change was intentional or not.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D83004



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


[PATCH] D83004: [UpdateCCTestChecks] Include generated functions if asked

2020-07-07 Thread David Greene via Phabricator via cfe-commits
greened marked an inline comment as done.
greened added inline comments.



Comment at: llvm/utils/update_cc_test_checks.py:133
+  parser.add_argument('--include-generated-funcs', action='store_true',
+  help='Output checks for functions not in source')
   parser.add_argument('tests', nargs='+')

jdoerfert wrote:
> greened wrote:
> > greened wrote:
> > > jdoerfert wrote:
> > > > I think this should go into common.py (after D78618). I would also make 
> > > > this the default but OK.
> > > Yes I suppose it should in case `opt` and friends generate functions.  I 
> > > hadn't considered that use-case.
> > > 
> > > While I would like to make it default unfortunately it would require 
> > > updating a bunch of the existing clang tests which doesn't seem too 
> > > friendly.  See the patch update comment for details.
> > > 
> > Just realized it wouldn't necessarily require regeneration of tests, it 
> > would just cause regenerated tests to change a lot when they are eventually 
> > regenerated.  We should discuss as to whether that's acceptable.  I think 
> > for now this should be non-default to at least get the functionality in 
> > without disturbing existing users and then we can discuss a separate change 
> > to make it default.
> > 
> > It's also possible we could change how clang orders functions.  I 
> > discovered there's a difference in clang 10 vs. 11 in the order functions 
> > are output when OpenMP outlining happens.  clang 10 seems to preserve the 
> > source order of functions and clang 11 does not.  Perhaps that needs to be 
> > fixed as I don't know whether that change was intentional or not.
> Best case, without the option the original behavior is preserved. Is that not 
> the case?
That's right.  I was referring to making this behavior default.  If we do that, 
we could clean up the script code a bit but it would mean clang tests would 
change pretty dramatically when they are regenerated.  If we fix the clang 
output, the test changes wouldn't be so dramatic.

The way clang is behaving now, I would expect any tests that use `-fopenmp`, 
have multiple functions with OpenMP regions and use function prototypes for 
some of those functions would break given clang's reordering of function 
definitions.  Perhaps we don't have any tests like that though.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D83004



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


[PATCH] D78565: [clang][doc] Clang ARM CPU command line argument reference

2020-04-22 Thread David Greene via Phabricator via cfe-commits
greened added a comment.

In D78565#1996297 , @SjoerdMeijer 
wrote:

> Fair enough, perhaps the audience is too small here on llvm.org for this and 
> this is too niche. In A-profile we have the same problem, so could the 
> exercise for an A-core here, but can't spend time on that now, so will 
> abandon this.


I would find this extremely valuable in the clang documentation.  Not sure why 
this should be put on developer.arm.com as it is compiler-specific as wel as 
(sub-)target-specific.


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

https://reviews.llvm.org/D78565



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


[PATCH] D78565: [clang][doc] Clang ARM CPU command line argument reference

2020-04-22 Thread David Greene via Phabricator via cfe-commits
greened added a comment.

In D78565#1997372 , @greened wrote:

> In D78565#1996297 , @SjoerdMeijer 
> wrote:
>
> > Fair enough, perhaps the audience is too small here on llvm.org for this 
> > and this is too niche. In A-profile we have the same problem, so could the 
> > exercise for an A-core here, but can't spend time on that now, so will 
> > abandon this.
>
>
> I would find this extremely valuable in the clang documentation.  Not sure 
> why this should be put on developer.arm.com as it is compiler-specific as wel 
> as (sub-)target-specific.


To be clear, I also like Peter's suggestion of documenting all `-m` options as 
gcc does.  There's room for both-and here.


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

https://reviews.llvm.org/D78565



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


[PATCH] D66524: [SVE][Inline-Asm] Add constraints for SVE predicate registers

2019-09-03 Thread David Greene via Phabricator via cfe-commits
greened added inline comments.



Comment at: docs/LangRef.rst:3818
+- ``Upl``: One of the low eight SVE predicate registers (P0 to P7)
+- ``Upa``: Any of the SVE predicate registers (P0 to P15)
 

What do these names mean?  " predicate lower|all?"  I see they are 
the names used in gcc, so I guess it makes sense to use them here.  Are these 
names used in the SVE architecture manual somewhere?  I cannot find them.



Comment at: lib/Target/AArch64/AArch64ISelLowering.cpp:5747
+
+PredicateConstraint isPredicateConstraint(StringRef Constraint) {
+  PredicateConstraint P = PredicateConstraint::Invalid;

rovka wrote:
> Nit: I think get- or parsePredicateConstraint reads better, since this 
> doesn't return a simple yes/no answer.
+1.


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

https://reviews.llvm.org/D66524



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


[PATCH] D83004: [UpdateCCTestChecks] Include generated functions if asked

2020-09-15 Thread David Greene via Phabricator via cfe-commits
greened added a comment.

In D83004#2250897 , @jdoerfert wrote:

> reverse ping?

Heh.  Getting back to this now.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D83004

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


[PATCH] D83004: [UpdateCCTestChecks] Include generated functions if asked

2020-09-15 Thread David Greene via Phabricator via cfe-commits
greened added a comment.

In D83004#2168427 , @jdoerfert wrote:

> Due to D82995  I realized we should have a 
> test of this in `llvm/test/tools/UpdateTestChecks` as well.

Do you mean a test for recognizing the option in `common.py`?  I'm not sure 
what you're asking for here.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D83004

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


[PATCH] D83004: [UpdateCCTestChecks] Include generated functions if asked

2020-09-16 Thread David Greene via Phabricator via cfe-commits
greened added a comment.

In D83004#2274687 , @jdoerfert wrote:

> 



>> Do you mean a test for recognizing the option in `common.py`?  I'm not sure 
>> what you're asking for here.
>
> The function is recognized in common.py, right? Can't you run the 
> update_test_check.py it with that option now? If so, we could have a test for 
> it, using, for example, hot-cold splitting or attributor with the 
> `-attributor-allow-deep-wrappers` and a `linkonce_odr` function that is 
> called.

Makes sense.  I'll work on it.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D83004

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


[PATCH] D83004: [UpdateCCTestChecks] Include generated functions if asked

2020-09-18 Thread David Greene via Phabricator via cfe-commits
greened added a comment.

In D83004#2278681 , @arichardson wrote:

> Maybe add another test that checks for the @__cxx_global_var_init() 
> constructor function?
> E.g. something like this:
>
>   int init_func(int arg) {
>   return arg + 1;
>   }
>   
>   int my_global = init_func(2);

Can you explain what this would test beyond the provided OpenMP tests?  
Remember, the tests are for the update tool itself, not to test that the 
compiler is doing the right thing.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D83004

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


[PATCH] D83004: [UpdateCCTestChecks] Include generated functions if asked

2020-09-18 Thread David Greene via Phabricator via cfe-commits
greened added inline comments.



Comment at: llvm/utils/update_cc_test_checks.py:274-277
   prefixes = p[0]
   for prefix in prefixes:
 func_dict.update({prefix: dict()})
+func_order.update({prefix: []})

arichardson wrote:
> This should avoid a few update() calls. Not that performance really matters 
> here.
> This should avoid a few update() calls. Not that performance really matters 
> here.

Wouldn't it iterate over the prefix list twice?  In any event, I was trying to 
follow existing style and wanted to rewrite as little existing code as possible.



Comment at: llvm/utils/update_cc_test_checks.py:331
+# are ordered by prefix instead of by function as in "normal"
+# mode.
+if '-emit-llvm' in clang_args:

arichardson wrote:
> jdoerfert wrote:
> > This is all unfortunate but at least for OpenMP not easily changeable. 
> > Let's go with this.
> How difficult would it be to only use this behaviour if the normal one fails? 
> 
> If we encounter a function that's not in the source code we just append the 
> check lines for the generate function where we last added checks. And if we 
> then see a function where the order doesn't match the source order fall back 
> to just emitting all checks at the end of the file?
> How difficult would it be to only use this behaviour if the normal one fails? 
> 
> If we encounter a function that's not in the source code we just append the 
> check lines for the generate function where we last added checks. And if we 
> then see a function where the order doesn't match the source order fall back 
> to just emitting all checks at the end of the file?

The problem is that this loop is driven by lines as they appear in the source 
file and uses a dictionary to look up the tool output for that function.  
Because of this checks will *always* be placed in the source before each 
function and there is no way to tell if the checks you're adding are from 
out-of-order tool output.  Changing this would be a complete rewrite of the 
algorithm, which I wanted to avoid for this enhancement.  Of course we can 
always rewrite it later but I think that is best done as a separate change.

The other two tools use a similar algorithm.  In fact it *may* be possible to 
further refactor this code to share the check output driver.  But again, that 
involves changing existing code and is best left to a separate change I think.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D83004

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


[PATCH] D83004: [UpdateCCTestChecks] Include generated functions if asked

2020-09-23 Thread David Greene via Phabricator via cfe-commits
greened added a comment.

In D83004#2287851 , @dmajor wrote:

> The expensive-checks bots have been red for several days. Could you please 
> take a look or revert?

Working on it...


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D83004

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


[PATCH] D83004: [UpdateCCTestChecks] Include generated functions if asked

2020-09-23 Thread David Greene via Phabricator via cfe-commits
greened added a comment.

In D83004#2290157 , @greened wrote:

> In D83004#2287851 , @dmajor wrote:
>
>> The expensive-checks bots have been red for several days. Could you please 
>> take a look or revert?
>
> Working on it...

I've removed this test as it seems to expose a bug in MachineOutliner for 
RISCV.  Since that's not at all related to this change it made the most sense 
to me to just remove the test.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D83004

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


[PATCH] D112177: [clang] Do not duplicate "EnableSplitLTOUnit" module flag

2021-12-02 Thread David Greene via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG53adfa8750ea: [clang] Do not duplicate 
"EnableSplitLTOUnit" module flag (authored by greened).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112177

Files:
  clang/lib/CodeGen/BackendUtil.cpp
  clang/test/CodeGen/enable-split-lto-unit.ll


Index: clang/test/CodeGen/enable-split-lto-unit.ll
===
--- /dev/null
+++ clang/test/CodeGen/enable-split-lto-unit.ll
@@ -0,0 +1,25 @@
+; Test that we do not duplicate the EnableSplitLTOUnit module flag.
+;
+; Disable the verifier so the compiler doesn't abort and thus lead to empty
+; output and false pass.
+;
+; RUN: %clang_cc1 -fno-legacy-pass-manager -emit-llvm-bc -flto=full 
-disable-llvm-verifier -o - %s | llvm-dis | FileCheck %s --check-prefix=FULL-NPM
+; RUN: %clang_cc1 -fno-legacy-pass-manager -emit-llvm-bc -flto=thin 
-disable-llvm-verifier -o - %s | llvm-dis | FileCheck %s --check-prefix=THIN-NPM
+; RUN: %clang_cc1 -flegacy-pass-manager -emit-llvm-bc -flto=full 
-disable-llvm-verifier -o - %s | llvm-dis | FileCheck %s --check-prefix=FULL-OPM
+; RUN: %clang_cc1 -flegacy-pass-manager -emit-llvm-bc -flto=thin 
-disable-llvm-verifier -o - %s | llvm-dis | FileCheck %s --check-prefix=THIN-OPM
+
+define dso_local void @main() local_unnamed_addr {
+entry:
+  ret void
+}
+
+; FULL-NPM-NOT: !llvm.module.flags = !{!0, !1, !2, !3, !3}
+; FULL-OPM-NOT: !llvm.module.flags = !{!0, !1, !2, !3, !3}
+; THIN-NPM-NOT: !llvm.module.flags = !{!0, !1, !2, !3, !4}
+; THIN-OPM-NOT: !llvm.module.flags = !{!0, !1, !2, !3, !4}
+!llvm.module.flags = !{!0, !1, !2, !3}
+
+!0 = !{i32 1, !"wchar_size", i32 2}
+!1 = !{i32 7, !"frame-pointer", i32 2}
+!2 = !{i32 1, !"ThinLTO", i32 0}
+!3 = !{i32 1, !"EnableSplitLTOUnit", i32 1}
Index: clang/lib/CodeGen/BackendUtil.cpp
===
--- clang/lib/CodeGen/BackendUtil.cpp
+++ clang/lib/CodeGen/BackendUtil.cpp
@@ -1034,8 +1034,9 @@
 if (!ThinLinkOS)
   return;
   }
-  TheModule->addModuleFlag(Module::Error, "EnableSplitLTOUnit",
-   CodeGenOpts.EnableSplitLTOUnit);
+  if (!TheModule->getModuleFlag("EnableSplitLTOUnit"))
+TheModule->addModuleFlag(Module::Error, "EnableSplitLTOUnit",
+ CodeGenOpts.EnableSplitLTOUnit);
   PerModulePasses.add(createWriteThinLTOBitcodePass(
   *OS, ThinLinkOS ? &ThinLinkOS->os() : nullptr));
 } else {
@@ -1049,8 +1050,9 @@
   if (EmitLTOSummary) {
 if (!TheModule->getModuleFlag("ThinLTO"))
   TheModule->addModuleFlag(Module::Error, "ThinLTO", uint32_t(0));
-TheModule->addModuleFlag(Module::Error, "EnableSplitLTOUnit",
- uint32_t(1));
+if (!TheModule->getModuleFlag("EnableSplitLTOUnit"))
+  TheModule->addModuleFlag(Module::Error, "EnableSplitLTOUnit",
+   uint32_t(1));
   }
 
   PerModulePasses.add(createBitcodeWriterPass(
@@ -1451,8 +1453,9 @@
 if (!ThinLinkOS)
   return;
   }
-  TheModule->addModuleFlag(Module::Error, "EnableSplitLTOUnit",
-   CodeGenOpts.EnableSplitLTOUnit);
+  if (!TheModule->getModuleFlag("EnableSplitLTOUnit"))
+TheModule->addModuleFlag(Module::Error, "EnableSplitLTOUnit",
+ CodeGenOpts.EnableSplitLTOUnit);
   MPM.addPass(ThinLTOBitcodeWriterPass(*OS, ThinLinkOS ? &ThinLinkOS->os()
: nullptr));
 } else {
@@ -1465,8 +1468,9 @@
   if (EmitLTOSummary) {
 if (!TheModule->getModuleFlag("ThinLTO"))
   TheModule->addModuleFlag(Module::Error, "ThinLTO", uint32_t(0));
-TheModule->addModuleFlag(Module::Error, "EnableSplitLTOUnit",
- uint32_t(1));
+if (!TheModule->getModuleFlag("EnableSplitLTOUnit"))
+  TheModule->addModuleFlag(Module::Error, "EnableSplitLTOUnit",
+   uint32_t(1));
   }
   MPM.addPass(
   BitcodeWriterPass(*OS, CodeGenOpts.EmitLLVMUseLists, 
EmitLTOSummary));


Index: clang/test/CodeGen/enable-split-lto-unit.ll
===
--- /dev/null
+++ clang/test/CodeGen/enable-split-lto-unit.ll
@@ -0,0 +1,25 @@
+; Test that we do not duplicate the EnableSplitLTOUnit module flag.
+;
+; Disable the verifier so the compiler doesn't abort and thus lead to empty
+; output and false pass.
+;
+; RUN: %clang_cc1 -fno-legacy-pass-manager -emit-llvm-bc -flto=full -disable-llvm-verifier -o - %s | llvm-dis | FileCheck %s --check-prefix=FULL-NPM
+; RUN: %clang_cc1 -fno-legacy-pass-manager -emit-llvm-bc -flto=thin -disable-llvm-verifier -o - %s | llvm-dis | FileChe

[PATCH] D69088: [Lex] #pragma clang transform

2019-12-17 Thread David Greene via Phabricator via cfe-commits
greened added a comment.

In D69088#1772141 , @rjmccall wrote:

> This is a major new language feature, and code review is probably not the 
> right venue for reviewing it; there should be a thread on cfe-dev.  My 
> apologies if that's already been discussed and I missed it.


I agree.  I know the original RFC didn't get many responses but perhaps 
discussion will pick up given that patches now exist.  The discussion should 
happen on both cfe-dev and llvm-dev because it affects both.

In particular I'd like to understand the motivation for this.  Is it for 
experimental purposes, to aid in compiler tuning, to allow the user to override 
compiler decisions and/or something else?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D69088



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


[PATCH] D112177: [clang] Do not duplicate "EnableSplitLTOUnit" module flag

2021-10-20 Thread David Greene via Phabricator via cfe-commits
greened created this revision.
greened added reviewers: noajshu, phosek, eli.friedman, tejohnson.
greened added a project: LLVM.
Herald added subscribers: ormris, steven_wu, hiraditya, inglorion.
greened requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

If clang's output is set to bitcode and LTO is enabled, clang would
unconditionally add the flag to the module.  Unfortunately, if the input were a
bitcode or IR file and had the flag set, this would result in two copies of the
flag, which is illegal IR.  Guard the setting of the flag by checking whether it
already exists.  This follows existing practice for the related "ThinLTO" module
flag.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D112177

Files:
  clang/lib/CodeGen/BackendUtil.cpp
  clang/test/CodeGen/enable-split-lto-unit.ll


Index: clang/test/CodeGen/enable-split-lto-unit.ll
===
--- /dev/null
+++ clang/test/CodeGen/enable-split-lto-unit.ll
@@ -0,0 +1,25 @@
+; Test that we do not duplicate the EnableSplitLTOUnit module flag.
+;
+; Disable the verifier so the compiler doesn't abort and thus lead to empty
+; output and false pass.
+;
+; RUN: %clang_cc1 -fno-legacy-pass-manager -emit-llvm-bc -flto=full 
-disable-llvm-verifier -o - %s | llvm-dis | FileCheck %s --check-prefix=FULL-NPM
+; RUN: %clang_cc1 -fno-legacy-pass-manager -emit-llvm-bc -flto=thin 
-disable-llvm-verifier -o - %s | llvm-dis | FileCheck %s --check-prefix=THIN-NPM
+; RUN: %clang_cc1 -flegacy-pass-manager -emit-llvm-bc -flto=full 
-disable-llvm-verifier -o - %s | llvm-dis | FileCheck %s --check-prefix=FULL-OPM
+; RUN: %clang_cc1 -flegacy-pass-manager -emit-llvm-bc -flto=thin 
-disable-llvm-verifier -o - %s | llvm-dis | FileCheck %s --check-prefix=THIN-OPM
+
+define dso_local void @main() local_unnamed_addr {
+entry:
+  ret void
+}
+
+; FULL-NPM-NOT: !llvm.module.flags = !{!0, !1, !2, !3, !3}
+; FULL-OPM-NOT: !llvm.module.flags = !{!0, !1, !2, !3, !3}
+; THIN-NPM-NOT: !llvm.module.flags = !{!0, !1, !2, !3, !4}
+; THIN-OPM-NOT: !llvm.module.flags = !{!0, !1, !2, !3, !4}
+!llvm.module.flags = !{!0, !1, !2, !3}
+
+!0 = !{i32 1, !"wchar_size", i32 2}
+!1 = !{i32 7, !"frame-pointer", i32 2}
+!2 = !{i32 1, !"ThinLTO", i32 0}
+!3 = !{i32 1, !"EnableSplitLTOUnit", i32 1}
Index: clang/lib/CodeGen/BackendUtil.cpp
===
--- clang/lib/CodeGen/BackendUtil.cpp
+++ clang/lib/CodeGen/BackendUtil.cpp
@@ -1023,8 +1023,9 @@
 if (!ThinLinkOS)
   return;
   }
-  TheModule->addModuleFlag(Module::Error, "EnableSplitLTOUnit",
-   CodeGenOpts.EnableSplitLTOUnit);
+  if (!TheModule->getModuleFlag("EnableSplitLTOUnit"))
+TheModule->addModuleFlag(Module::Error, "EnableSplitLTOUnit",
+ CodeGenOpts.EnableSplitLTOUnit);
   PerModulePasses.add(createWriteThinLTOBitcodePass(
   *OS, ThinLinkOS ? &ThinLinkOS->os() : nullptr));
 } else {
@@ -1038,8 +1039,9 @@
   if (EmitLTOSummary) {
 if (!TheModule->getModuleFlag("ThinLTO"))
   TheModule->addModuleFlag(Module::Error, "ThinLTO", uint32_t(0));
-TheModule->addModuleFlag(Module::Error, "EnableSplitLTOUnit",
- uint32_t(1));
+if (!TheModule->getModuleFlag("EnableSplitLTOUnit"))
+  TheModule->addModuleFlag(Module::Error, "EnableSplitLTOUnit",
+   uint32_t(1));
   }
 
   PerModulePasses.add(createBitcodeWriterPass(
@@ -1438,8 +1440,9 @@
 if (!ThinLinkOS)
   return;
   }
-  TheModule->addModuleFlag(Module::Error, "EnableSplitLTOUnit",
-   CodeGenOpts.EnableSplitLTOUnit);
+  if (!TheModule->getModuleFlag("EnableSplitLTOUnit"))
+TheModule->addModuleFlag(Module::Error, "EnableSplitLTOUnit",
+ CodeGenOpts.EnableSplitLTOUnit);
   MPM.addPass(ThinLTOBitcodeWriterPass(*OS, ThinLinkOS ? &ThinLinkOS->os()
: nullptr));
 } else {
@@ -1452,8 +1455,9 @@
   if (EmitLTOSummary) {
 if (!TheModule->getModuleFlag("ThinLTO"))
   TheModule->addModuleFlag(Module::Error, "ThinLTO", uint32_t(0));
-TheModule->addModuleFlag(Module::Error, "EnableSplitLTOUnit",
- uint32_t(1));
+if (!TheModule->getModuleFlag("EnableSplitLTOUnit"))
+  TheModule->addModuleFlag(Module::Error, "EnableSplitLTOUnit",
+   uint32_t(1));
   }
   MPM.addPass(
   BitcodeWriterPass(*OS, CodeGenOpts.EmitLLVMUseLists, 
EmitLTOSummary));


Index: clang/test/CodeGen/enable-split-lto-unit.ll
===
--- /dev/null
+++ clang/test/CodeGen/enable-split-lto-unit.ll
@@ -0,0 +1,25