date:20210421

[PATCH] D101020: clang-format: [JS] do not merge side-effect imports.

2021-04-21 Thread Martin Probst via Phabricator via cfe-commits

mprobst created this revision.
mprobst added reviewers: krasimir, h-joo.
mprobst requested review of this revision.
Herald added a project: clang.

The if condition was testing the current element, but
forgot to check the previous element (doh), so it
would fail depending on sort order of the imports.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D101020

Files:
  clang/lib/Format/SortJavaScriptImports.cpp
  clang/unittests/Format/SortImportsTestJS.cpp


Index: clang/unittests/Format/SortImportsTestJS.cpp
===
--- clang/unittests/Format/SortImportsTestJS.cpp
+++ clang/unittests/Format/SortImportsTestJS.cpp
@@ -364,6 +364,13 @@
   // do merge exports
   verifySort("export {A, B} from 'foo';\n", "export {A} from 'foo';\n"
 "export   {B} from 'foo';");
+
+  // do not merge side effect imports with named ones
+  verifySort("import './a';\n"
+ "\n"
+ "import {bar} from './a';\n",
+ "import {bar} from './a';\n"
+ "import './a';\n");
 }
 
 } // end namespace
Index: clang/lib/Format/SortJavaScriptImports.cpp
===
--- clang/lib/Format/SortJavaScriptImports.cpp
+++ clang/lib/Format/SortJavaScriptImports.cpp
@@ -271,6 +271,7 @@
   //   import Default from 'foo'; on either previous or this.
   //   mismatching
   if (Reference->Category == JsModuleReference::SIDE_EFFECT ||
+  PreviousReference->Category == JsModuleReference::SIDE_EFFECT ||
   Reference->IsExport != PreviousReference->IsExport ||
   !PreviousReference->Prefix.empty() || !Reference->Prefix.empty() ||
   !PreviousReference->DefaultImport.empty() ||


Index: clang/unittests/Format/SortImportsTestJS.cpp
===
--- clang/unittests/Format/SortImportsTestJS.cpp
+++ clang/unittests/Format/SortImportsTestJS.cpp
@@ -364,6 +364,13 @@
   // do merge exports
   verifySort("export {A, B} from 'foo';\n", "export {A} from 'foo';\n"
 "export   {B} from 'foo';");
+
+  // do not merge side effect imports with named ones
+  verifySort("import './a';\n"
+ "\n"
+ "import {bar} from './a';\n",
+ "import {bar} from './a';\n"
+ "import './a';\n");
 }
 
 } // end namespace
Index: clang/lib/Format/SortJavaScriptImports.cpp
===
--- clang/lib/Format/SortJavaScriptImports.cpp
+++ clang/lib/Format/SortJavaScriptImports.cpp
@@ -271,6 +271,7 @@
   //   import Default from 'foo'; on either previous or this.
   //   mismatching
   if (Reference->Category == JsModuleReference::SIDE_EFFECT ||
+  PreviousReference->Category == JsModuleReference::SIDE_EFFECT ||
   Reference->IsExport != PreviousReference->IsExport ||
   !PreviousReference->Prefix.empty() || !Reference->Prefix.empty() ||
   !PreviousReference->DefaultImport.empty() ||
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D99949: [AMDGPU][OpenMP] Add amdgpu-arch tool to list AMD GPUs installed

2021-04-21 Thread Pushpinder Singh 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 rG722d4d8e7585: [AMDGPU][OpenMP] Add amdgpu-arch tool to list 
AMD GPUs installed (authored by pdhaliwal).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99949

Files:
  clang/include/clang/Basic/DiagnosticDriverKinds.td
  clang/include/clang/Driver/Options.td
  clang/lib/Driver/ToolChains/AMDGPU.cpp
  clang/lib/Driver/ToolChains/AMDGPU.h
  clang/lib/Driver/ToolChains/AMDGPUOpenMP.cpp
  clang/test/Driver/Inputs/amdgpu-arch/amdgpu_arch_different
  clang/test/Driver/Inputs/amdgpu-arch/amdgpu_arch_fail
  clang/test/Driver/Inputs/amdgpu-arch/amdgpu_arch_gfx906
  clang/test/Driver/Inputs/amdgpu-arch/amdgpu_arch_gfx908_gfx908
  clang/test/Driver/amdgpu-openmp-system-arch-fail.c
  clang/test/Driver/amdgpu-openmp-system-arch.c
  clang/tools/CMakeLists.txt
  clang/tools/amdgpu-arch/AMDGPUArch.cpp
  clang/tools/amdgpu-arch/CMakeLists.txt

Index: clang/tools/amdgpu-arch/CMakeLists.txt
===
--- /dev/null
+++ clang/tools/amdgpu-arch/CMakeLists.txt
@@ -0,0 +1,17 @@
+# //===--===//
+# //
+# // Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+# // See https://llvm.org/LICENSE.txt for details.
+# // SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+# //
+# //===--===//
+
+find_package(hsa-runtime64 QUIET 1.2.0 HINTS ${CMAKE_INSTALL_PREFIX} PATHS /opt/rocm)
+if (NOT ${hsa-runtime64_FOUND})
+  message(STATUS "Not building amdgpu-arch: hsa-runtime64 not found")
+  return()
+endif()
+
+add_clang_tool(amdgpu-arch AMDGPUArch.cpp)
+
+clang_target_link_libraries(amdgpu-arch PRIVATE hsa-runtime64::hsa-runtime64)
Index: clang/tools/amdgpu-arch/AMDGPUArch.cpp
===
--- /dev/null
+++ clang/tools/amdgpu-arch/AMDGPUArch.cpp
@@ -0,0 +1,59 @@
+//===- AMDGPUArch.cpp - list AMDGPU installed --*- C++ -*-===//
+//
+// 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
+//
+//===--===//
+//
+// This file implements a tool for detecting name of AMDGPU installed in system
+// using HSA. This tool is used by AMDGPU OpenMP driver.
+//
+//===--===//
+
+#include 
+#include 
+#include 
+
+static hsa_status_t iterateAgentsCallback(hsa_agent_t Agent, void *Data) {
+  hsa_device_type_t DeviceType;
+  hsa_status_t Status =
+  hsa_agent_get_info(Agent, HSA_AGENT_INFO_DEVICE, );
+
+  // continue only if device type if GPU
+  if (Status != HSA_STATUS_SUCCESS || DeviceType != HSA_DEVICE_TYPE_GPU) {
+return Status;
+  }
+
+  std::vector *GPUs =
+  static_cast *>(Data);
+  char GPUName[64];
+  Status = hsa_agent_get_info(Agent, HSA_AGENT_INFO_NAME, GPUName);
+  if (Status != HSA_STATUS_SUCCESS) {
+return Status;
+  }
+  GPUs->push_back(GPUName);
+  return HSA_STATUS_SUCCESS;
+}
+
+int main() {
+  hsa_status_t Status = hsa_init();
+  if (Status != HSA_STATUS_SUCCESS) {
+return 1;
+  }
+
+  std::vector GPUs;
+  Status = hsa_iterate_agents(iterateAgentsCallback, );
+  if (Status != HSA_STATUS_SUCCESS) {
+return 1;
+  }
+
+  for (const auto  : GPUs)
+printf("%s\n", GPU.c_str());
+
+  if (GPUs.size() < 1)
+return 1;
+
+  hsa_shut_down();
+  return 0;
+}
Index: clang/tools/CMakeLists.txt
===
--- clang/tools/CMakeLists.txt
+++ clang/tools/CMakeLists.txt
@@ -43,3 +43,5 @@
 
 # libclang may require clang-tidy in clang-tools-extra.
 add_clang_subdirectory(libclang)
+
+add_clang_subdirectory(amdgpu-arch)
Index: clang/test/Driver/amdgpu-openmp-system-arch.c
===
--- /dev/null
+++ clang/test/Driver/amdgpu-openmp-system-arch.c
@@ -0,0 +1,24 @@
+// REQUIRES: system-linux
+// REQUIRES: x86-registered-target
+// REQUIRES: amdgpu-registered-target
+// REQUIRES: shell
+
+// RUN: mkdir -p %t
+// RUN: rm -f %t/amdgpu_arch_gfx906
+// RUN: cp %S/Inputs/amdgpu-arch/amdgpu_arch_gfx906 %t/
+// RUN: cp %S/Inputs/amdgpu-arch/amdgpu_arch_gfx908_gfx908 %t/
+// RUN: chmod +x %t/amdgpu_arch_gfx906
+// RUN: chmod +x %t/amdgpu_arch_gfx908_gfx908
+
+// RUN:   %clang -### --target=x86_64-unknown-linux-gnu -fopenmp -fopenmp-targets=amdgcn-amd-amdhsa -nogpulib --amdgpu-arch-tool=%t/amdgpu_arch_gfx906 %s 2>&1 \
+// RUN:   | FileCheck %s
+// CHECK: clang{{.*}}"-cc1"{{.*}}"-triple" "amdgcn-amd-amdhsa"{{.*}}"-target-cpu"

[clang] 722d4d8 - [AMDGPU][OpenMP] Add amdgpu-arch tool to list AMD GPUs installed

2021-04-21 Thread Pushpinder Singh via cfe-commits


Author: Pushpinder Singh
Date: 2021-04-22T05:20:28Z
New Revision: 722d4d8e7585457d407d0639a4ae2610157e06a8

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

LOG: [AMDGPU][OpenMP] Add amdgpu-arch tool to list AMD GPUs installed

This patch adds new clang tool named amdgpu-arch which uses
HSA to detect installed AMDGPU and report back latter's march.
This tool is built only if system has HSA installed.

The value printed by amdgpu-arch is used to fill -march when
latter is not explicitly provided in -Xopenmp-target.

Reviewed By: JonChesterfield, gregrodgers

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

Added: 
clang/test/Driver/Inputs/amdgpu-arch/amdgpu_arch_different
clang/test/Driver/Inputs/amdgpu-arch/amdgpu_arch_fail
clang/test/Driver/Inputs/amdgpu-arch/amdgpu_arch_gfx906
clang/test/Driver/Inputs/amdgpu-arch/amdgpu_arch_gfx908_gfx908
clang/test/Driver/amdgpu-openmp-system-arch-fail.c
clang/test/Driver/amdgpu-openmp-system-arch.c
clang/tools/amdgpu-arch/AMDGPUArch.cpp
clang/tools/amdgpu-arch/CMakeLists.txt

Modified: 
clang/include/clang/Basic/DiagnosticDriverKinds.td
clang/include/clang/Driver/Options.td
clang/lib/Driver/ToolChains/AMDGPU.cpp
clang/lib/Driver/ToolChains/AMDGPU.h
clang/lib/Driver/ToolChains/AMDGPUOpenMP.cpp
clang/tools/CMakeLists.txt

Removed: 




diff  --git a/clang/include/clang/Basic/DiagnosticDriverKinds.td 
b/clang/include/clang/Basic/DiagnosticDriverKinds.td
index 5e580cc4fbb7a..a2ffe1378cb6d 100644
--- a/clang/include/clang/Basic/DiagnosticDriverKinds.td
+++ b/clang/include/clang/Basic/DiagnosticDriverKinds.td
@@ -67,6 +67,8 @@ def err_drv_no_hip_runtime : Error<
   "cannot find HIP runtime. Provide its path via --rocm-path, or pass "
   "-nogpuinc to build without HIP runtime.">;
 
+def err_drv_undetermined_amdgpu_arch : Error<
+  "Cannot determine AMDGPU architecture: %0. Consider passing it via 
--march.">;
 def err_drv_cuda_version_unsupported : Error<
   "GPU arch %0 is supported by CUDA versions between %1 and %2 (inclusive), "
   "but installation at %3 is %4. Use --cuda-path to specify a 
diff erent CUDA "

diff  --git a/clang/include/clang/Driver/Options.td 
b/clang/include/clang/Driver/Options.td
index 04a05207cc74b..df3049fe40326 100644
--- a/clang/include/clang/Driver/Options.td
+++ b/clang/include/clang/Driver/Options.td
@@ -924,6 +924,8 @@ def rocm_path_EQ : Joined<["--"], "rocm-path=">, 
Group,
   HelpText<"ROCm installation path, used for finding and automatically linking 
required bitcode libraries.">;
 def hip_path_EQ : Joined<["--"], "hip-path=">, Group,
   HelpText<"HIP runtime installation path, used for finding HIP version and 
adding HIP include path.">;
+def amdgpu_arch_tool_EQ : Joined<["--"], "amdgpu-arch-tool=">, Group,
+  HelpText<"Tool used for detecting AMD GPU arch in the system.">;
 def rocm_device_lib_path_EQ : Joined<["--"], "rocm-device-lib-path=">, 
Group,
   HelpText<"ROCm device library path. Alternative to rocm-path.">;
 def : Joined<["--"], "hip-device-lib-path=">, Alias;

diff  --git a/clang/lib/Driver/ToolChains/AMDGPU.cpp 
b/clang/lib/Driver/ToolChains/AMDGPU.cpp
index dc9c9751c851d..328753b21f8ea 100644
--- a/clang/lib/Driver/ToolChains/AMDGPU.cpp
+++ b/clang/lib/Driver/ToolChains/AMDGPU.cpp
@@ -12,9 +12,16 @@
 #include "clang/Basic/TargetID.h"
 #include "clang/Driver/Compilation.h"
 #include "clang/Driver/DriverDiagnostic.h"
+#include "clang/Driver/Options.h"
 #include "llvm/Option/ArgList.h"
+#include "llvm/Support/Error.h"
+#include "llvm/Support/FileUtilities.h"
+#include "llvm/Support/LineIterator.h"
 #include "llvm/Support/Path.h"
 #include "llvm/Support/VirtualFileSystem.h"
+#include 
+
+#define AMDGPU_ARCH_PROGRAM_NAME "amdgpu-arch"
 
 using namespace clang::driver;
 using namespace clang::driver::tools;
@@ -715,6 +722,78 @@ void AMDGPUToolChain::checkTargetID(
   }
 }
 
+llvm::Error
+AMDGPUToolChain::detectSystemGPUs(const ArgList ,
+  SmallVector ) const 
{
+  std::string Program;
+  if (Arg *A = Args.getLastArg(options::OPT_amdgpu_arch_tool_EQ))
+Program = A->getValue();
+  else
+Program = GetProgramPath(AMDGPU_ARCH_PROGRAM_NAME);
+  llvm::SmallString<64> OutputFile;
+  llvm::sys::fs::createTemporaryFile("print-system-gpus", "" /* No Suffix */,
+ OutputFile);
+  llvm::FileRemover OutputRemover(OutputFile.c_str());
+  llvm::Optional Redirects[] = {
+  {""},
+  StringRef(OutputFile),
+  {""},
+  };
+
+  std::string ErrorMessage;
+  if (int Result = llvm::sys::ExecuteAndWait(
+  Program.c_str(), {}, {}, Redirects, /* SecondsToWait */ 0,
+  /*MemoryLimit*/ 0, )) {
+if (Result > 0) {
+  ErrorMessage = "Exited with error code " +

[PATCH] D91054: [Clang][OpenMP] Frontend work for sections - D89671

2021-04-21 Thread Michael Kruse via Phabricator via cfe-commits

Meinersbur added a comment.

thanks for the update


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D91054

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

[PATCH] D91054: [Clang][OpenMP] Frontend work for sections - D89671

2021-04-21 Thread Chirag Khandelwal via Phabricator via cfe-commits

AMDChirag added a comment.

For D89671 , Johannes had some comments which 
have been taken care of. I am just waiting for him to get back on it. I'll ping 
him there.
This patch is done from my end unless someone has some comment/thought.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D91054

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

[PATCH] D100298: [Clang][Coroutine][DebugInfo] Follow-up: reduce a tests ordering requirements

2021-04-21 Thread Yifeng Dong via Phabricator via cfe-commits

dongAxis1944 accepted this revision.
dongAxis1944 added a comment.

LGTM


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

https://reviews.llvm.org/D100298

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

[clang] 26f138e - [Debug-Info] implement -gstrict-dwarf

2021-04-21 Thread Chen Zheng via cfe-commits


Author: Chen Zheng
Date: 2021-04-22T00:41:25-04:00
New Revision: 26f138eed4af8ac7f12d2f11af1ba0f8aac68d4b

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

LOG: [Debug-Info] implement -gstrict-dwarf

This patch implements -gstrict-dwarf option in clang FE.

Reviewed By: dblaikie, probinson, aprantl

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

Added: 


Modified: 
clang/docs/ClangCommandLineReference.rst
clang/include/clang/Basic/CodeGenOptions.def
clang/include/clang/Driver/Options.td
clang/lib/Driver/ToolChains/Clang.cpp
clang/test/Driver/debug-options.c

Removed: 




diff  --git a/clang/docs/ClangCommandLineReference.rst 
b/clang/docs/ClangCommandLineReference.rst
index 97812f2b6e29e..24e0040a4f50d 100644
--- a/clang/docs/ClangCommandLineReference.rst
+++ b/clang/docs/ClangCommandLineReference.rst
@@ -3546,6 +3546,8 @@ Set DWARF fission mode to either 'split' or 'single'
 
 .. option:: -gstrict-dwarf, -gno-strict-dwarf
 
+Restrict DWARF features to those defined in the specified version, avoiding 
features from later versions.
+
 .. option:: -gz=, -gz (equivalent to -gz=zlib)
 
 DWARF debug sections compression type

diff  --git a/clang/include/clang/Basic/CodeGenOptions.def 
b/clang/include/clang/Basic/CodeGenOptions.def
index 900e61eb828b5..d3ea7d2a94df5 100644
--- a/clang/include/clang/Basic/CodeGenOptions.def
+++ b/clang/include/clang/Basic/CodeGenOptions.def
@@ -293,6 +293,7 @@ VALUE_CODEGENOPT(StackAlignment, 32, 0) ///< Overrides 
default stack
 VALUE_CODEGENOPT(StackProbeSize, 32, 4096) ///< Overrides default stack
///< probe size, even if 0.
 CODEGENOPT(NoStackArgProbe, 1, 0) ///< Set when -mno-stack-arg-probe is used
+CODEGENOPT(DebugStrictDwarf, 1, 1) ///< Whether or not to use strict DWARF 
info.
 CODEGENOPT(DebugColumnInfo, 1, 0) ///< Whether or not to use column information
   ///< in debug info.
 

diff  --git a/clang/include/clang/Driver/Options.td 
b/clang/include/clang/Driver/Options.td
index d17486b13504d..04a05207cc74b 100644
--- a/clang/include/clang/Driver/Options.td
+++ b/clang/include/clang/Driver/Options.td
@@ -2788,8 +2788,10 @@ def gno_record_command_line : Flag<["-"], 
"gno-record-command-line">,
   Group;
 def : Flag<["-"], "grecord-gcc-switches">, Alias;
 def : Flag<["-"], "gno-record-gcc-switches">, Alias;
-def gstrict_dwarf : Flag<["-"], "gstrict-dwarf">, Group;
-def gno_strict_dwarf : Flag<["-"], "gno-strict-dwarf">, Group;
+defm strict_dwarf : BoolOption<"g", "strict-dwarf",
+  CodeGenOpts<"DebugStrictDwarf">, DefaultFalse,
+  PosFlag, NegFlag, BothFlags<[CoreOption]>>,
+  Group;
 defm column_info : BoolOption<"g", "column-info",
   CodeGenOpts<"DebugColumnInfo">, DefaultTrue,
   NegFlag, PosFlag, BothFlags<[CoreOption]>>,

diff  --git a/clang/lib/Driver/ToolChains/Clang.cpp 
b/clang/lib/Driver/ToolChains/Clang.cpp
index 3ccfbddc849a2..4e9f72ff96909 100644
--- a/clang/lib/Driver/ToolChains/Clang.cpp
+++ b/clang/lib/Driver/ToolChains/Clang.cpp
@@ -3962,7 +3962,14 @@ static void renderDebugOptions(const ToolChain , 
const Driver ,
   DebugInfoKind == codegenoptions::DebugDirectivesOnly)
 DebugInfoKind = codegenoptions::NoDebugInfo;
 
-  // We ignore flag -gstrict-dwarf for now.
+  // strict DWARF is set to false by default. But for DBX, we need it to be set
+  // as true by default.
+  if (const Arg *A = Args.getLastArg(options::OPT_gstrict_dwarf))
+(void)checkDebugInfoOption(A, Args, D, TC);
+  if (Args.hasFlag(options::OPT_gstrict_dwarf, options::OPT_gno_strict_dwarf,
+   DebuggerTuning == llvm::DebuggerKind::DBX))
+CmdArgs.push_back("-gstrict-dwarf");
+
   // And we handle flag -grecord-gcc-switches later with DWARFDebugFlags.
   Args.ClaimAllArgs(options::OPT_g_flags_Group);
 

diff  --git a/clang/test/Driver/debug-options.c 
b/clang/test/Driver/debug-options.c
index 00c748b1e936a..54a8a6a3f74a9 100644
--- a/clang/test/Driver/debug-options.c
+++ b/clang/test/Driver/debug-options.c
@@ -110,6 +110,18 @@
 // RUN: %clang -### -c -g %s -target powerpc64-ibm-aix-xcoff 2>&1 \
 // RUN: | FileCheck -check-prefix=G_LIMITED -check-prefix=G_DBX %s
 
+// For DBX, -g defaults to -gstrict-dwarf.
+// RUN: %clang -### -c -g %s -target powerpc-ibm-aix-xcoff 2>&1 \
+// RUN: | FileCheck -check-prefix=STRICT %s
+// RUN: %clang -### -c -g %s -target powerpc64-ibm-aix-xcoff 2>&1 \
+// RUN: | FileCheck -check-prefix=STRICT %s
+// RUN: %clang -### -c -g -gno-strict-dwarf %s -target powerpc-ibm-aix-xcoff \
+// RUN: 2>&1 | FileCheck -check-prefix=NOSTRICT %s
+// RUN: %clang -### -c -g %s -target x86_64-linux-gnu 2>&1 \
+// RUN: | FileCheck

[PATCH] D101017: [NewPM] Make GlobalsAA available earlier in the pipeline

2021-04-21 Thread Arthur Eubanks via Phabricator via cfe-commits

aeubanks created this revision.
Herald added subscribers: wenlei, steven_wu, hiraditya.
aeubanks requested review of this revision.
Herald added projects: clang, LLVM.
Herald added subscribers: llvm-commits, cfe-commits.

A future change will cause fewer analyses to be invalidated. Currently,
the passes before the inliner pipeline don't have access to GlobalsAA
since it can only be used by AAManager if it is already available. We
happen to invalidate AAManager before the inliner pipeline so that it
can be rebuilt and use GlobalsAA. But if AAManager is never invalidated,
the inliner pipeline may not have access to GlobalsAA.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D101017

Files:
  clang/test/CodeGen/thinlto-distributed-newpm.ll
  llvm/lib/Passes/PassBuilder.cpp
  llvm/test/Other/new-pm-defaults.ll
  llvm/test/Other/new-pm-thinlto-defaults.ll
  llvm/test/Other/new-pm-thinlto-postlink-pgo-defaults.ll
  llvm/test/Other/new-pm-thinlto-postlink-samplepgo-defaults.ll
  llvm/test/Other/new-pm-thinlto-prelink-pgo-defaults.ll
  llvm/test/Other/new-pm-thinlto-prelink-samplepgo-defaults.ll

Index: llvm/test/Other/new-pm-thinlto-prelink-samplepgo-defaults.ll
===
--- llvm/test/Other/new-pm-thinlto-prelink-samplepgo-defaults.ll
+++ llvm/test/Other/new-pm-thinlto-prelink-samplepgo-defaults.ll
@@ -31,6 +31,9 @@
 ; CHECK-O-NEXT: Running analysis: InnerAnalysisManagerProxy
 ; CHECK-O-NEXT: Running pass: AddDiscriminatorsPass
 ; CHECK-EP-PIPELINE-START-NEXT: Running pass: NoOpModulePass
+; CHECK-O-NEXT: Running pass: RequireAnalysisPass<{{.*}}GlobalsAA
+; CHECK-O-NEXT: Running analysis: GlobalsAA
+; CHECK-O-NEXT: Running analysis: CallGraphAnalysis
 ; CHECK-O-NEXT: Running pass: InferFunctionAttrsPass
 ; CHECK-O-NEXT: Running analysis: TargetLibraryAnalysis
 ; CHECK-O-NEXT: Starting {{.*}}Function pass manager run.
@@ -53,7 +56,6 @@
 ; CHECK-O-NEXT: Finished {{.*}}Function pass manager run.
 ; CHECK-O-NEXT: Running pass: SampleProfileLoaderPass
 ; CHECK-O-NEXT: Running analysis: ProfileSummaryAnalysis
-; CHECK-O-NEXT: Running analysis: CallGraphAnalysis
 ; CHECK-O-NEXT: Running pass: RequireAnalysisPass<{{.*}}ProfileSummaryAnalysis
 ; CHECK-O2-NEXT: Running pass: OpenMPOptPass
 ; CHECK-O3-NEXT: Running pass: OpenMPOptPass
@@ -75,8 +77,6 @@
 ; CHECK-O-NEXT: Running pass: ModuleInlinerWrapperPass
 ; CHECK-O-NEXT: Running analysis: InlineAdvisorAnalysis
 ; CHECK-O-NEXT: Starting {{.*}}Module pass manager run.
-; CHECK-O-NEXT: Running pass: RequireAnalysisPass<{{.*}}GlobalsAA
-; CHECK-O-NEXT: Running analysis: GlobalsAA
 ; CHECK-O-NEXT: Running pass: RequireAnalysisPass<{{.*}}ProfileSummaryAnalysis
 ; CHECK-O-NEXT: Running analysis: InnerAnalysisManagerProxy
 ; CHECK-O-NEXT: Running analysis: LazyCallGraphAnalysis
Index: llvm/test/Other/new-pm-thinlto-prelink-pgo-defaults.ll
===
--- llvm/test/Other/new-pm-thinlto-prelink-pgo-defaults.ll
+++ llvm/test/Other/new-pm-thinlto-prelink-pgo-defaults.ll
@@ -31,8 +31,11 @@
 ; CHECK-O-NEXT: Running pass: Annotation2Metadata
 ; CHECK-O-NEXT: Running pass: ForceFunctionAttrsPass
 ; CHECK-EP-PIPELINE-START-NEXT: Running pass: NoOpModulePass
-; CHECK-O-NEXT: Running pass: InferFunctionAttrsPass
+; CHECK-O-NEXT: Running pass: RequireAnalysisPass<{{.*}}GlobalsAA
+; CHECK-O-NEXT: Running analysis: GlobalsAA
 ; CHECK-O-NEXT: Running analysis: InnerAnalysisManagerProxy
+; CHECK-O-NEXT: Running analysis: CallGraphAnalysis
+; CHECK-O-NEXT: Running pass: InferFunctionAttrsPass
 ; CHECK-O-NEXT: Running analysis: TargetLibraryAnalysis
 ; CHECK-O-NEXT: Starting {{.*}}Function pass manager run.
 ; CHECK-O-NEXT: Running pass: LowerExpectIntrinsicPass
@@ -87,6 +90,7 @@
 ; CHECK-O-DAG: Running analysis: LoopAnalysis on foo
 ; CHECK-O-NEXT: Running analysis: BlockFrequencyAnalysis on foo
 ; CHECK-O-NEXT: Invalidating analysis: InnerAnalysisManagerProxy
+; CHECK-O123SZ-NEXT: Invalidating analysis: CallGraphAnalysis
 ; CHECK-O123SZ-NEXT: Invalidating analysis: LazyCallGraphAnalysis on
 ; CHECK-O123SZ-NEXT: Invalidating analysis: InnerAnalysisManagerProxy
 ; CHECK-O-NEXT: Running pass: RequireAnalysisPass<{{.*}}ProfileSummaryAnalysis
@@ -95,9 +99,6 @@
 ; CHECK-O-NEXT: Running analysis: OptimizationRemarkEmitterAnalysis on foo
 ; CHECK-O-NEXT: Running pass: ModuleInlinerWrapperPass
 ; CHECK-O-NEXT: Starting {{.*}}Module pass manager run.
-; CHECK-O-NEXT: Running pass: RequireAnalysisPass<{{.*}}GlobalsAA
-; CHECK-O-NEXT: Running analysis: GlobalsAA
-; CHECK-O-NEXT: Running analysis: CallGraphAnalysis
 ; CHECK-O-NEXT: Running pass: RequireAnalysisPass<{{.*}}ProfileSummaryAnalysis
 ; CHECK-O-NEXT: Running analysis: InnerAnalysisManagerProxy
 ; CHECK-O-NEXT: Running analysis: LazyCallGraphAnalysis
Index: llvm/test/Other/new-pm-thinlto-postlink-samplepgo-defaults.ll
===
---

[PATCH] D101016: [IR][sanitizer] Add module flag "frame-pointer" and set it for cc1 -mframe-pointer={non-leaf,all}

2021-04-21 Thread Fangrui Song via Phabricator via cfe-commits

MaskRay created this revision.
MaskRay added reviewers: Sanitizers, nickdesaulniers.
Herald added subscribers: dexonsmith, hiraditya.
MaskRay requested review of this revision.
Herald added projects: clang, LLVM.
Herald added subscribers: llvm-commits, cfe-commits.

The Linux kernel objtool diagnostic `call without frame pointer save/setup`
arise in multiple instrumentation passes (asan/tsan/gcov). With the mechanism
introduced in D100251 , it's trivial to 
respect the command line
-m[no-]omit-leaf-frame-pointer/-f[no-]omit-frame-pointer, so let's do it.

Fix: https://github.com/ClangBuiltLinux/linux/issues/1236 (tsan)
Fix: https://github.com/ClangBuiltLinux/linux/issues/1238 (asan)


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D101016

Files:
  clang/lib/CodeGen/CodeGenModule.cpp
  clang/test/CodeGen/asan-frame-pointer.cpp
  llvm/include/llvm/IR/Module.h
  llvm/lib/IR/Function.cpp
  llvm/lib/IR/Module.cpp
  llvm/test/Instrumentation/AddressSanitizer/module-flags.ll
  llvm/test/Instrumentation/AddressSanitizer/uwtable.ll

Index: llvm/test/Instrumentation/AddressSanitizer/module-flags.ll
===
--- llvm/test/Instrumentation/AddressSanitizer/module-flags.ll
+++ llvm/test/Instrumentation/AddressSanitizer/module-flags.ll
@@ -10,12 +10,15 @@
   ret i32 %tmp
 }
 
-!llvm.module.flags = !{!0}
+!llvm.module.flags = !{!0, !1}
 
 ;; Due to -fasynchronous-unwind-tables.
 !0 = !{i32 7, !"uwtable", i32 1}
 
+;; Due to -fno-omit-frame-pointer.
+!1 = !{i32 7, !"frame-pointer", i32 2}
+
 ;; Set the uwtable attribute on ctor/dtor.
 ; CHECK: define internal void @asan.module_ctor() #[[#ATTR:]]
 ; CHECK: define internal void @asan.module_dtor() #[[#ATTR]]
-; CHECK: attributes #[[#ATTR]] = { nounwind uwtable }
+; CHECK: attributes #[[#ATTR]] = { nounwind uwtable "frame-pointer"="all" }
Index: llvm/lib/IR/Module.cpp
===
--- llvm/lib/IR/Module.cpp
+++ llvm/lib/IR/Module.cpp
@@ -676,6 +676,15 @@
 
 void Module::setUwtable() { addModuleFlag(ModFlagBehavior::Max, "uwtable", 1); }
 
+int Module::getFramePointer() const {
+  auto *Val = cast_or_null(getModuleFlag("frame-pointer"));
+  return Val ? cast(Val->getValue())->getZExtValue() : 0;
+}
+
+void Module::setFramePointer(int V) {
+  addModuleFlag(ModFlagBehavior::Max, "frame-pointer", V);
+}
+
 void Module::setSDKVersion(const VersionTuple ) {
   SmallVector Entries;
   Entries.push_back(V.getMajor());
Index: llvm/lib/IR/Function.cpp
===
--- llvm/lib/IR/Function.cpp
+++ llvm/lib/IR/Function.cpp
@@ -335,8 +335,23 @@
   unsigned AddrSpace, const Twine ,
   Module *M) {
   auto *F = new Function(Ty, Linkage, AddrSpace, N, M);
+  AttrBuilder B;
   if (M->getUwtable())
-F->addAttribute(AttributeList::FunctionIndex, Attribute::UWTable);
+B.addAttribute(Attribute::UWTable);
+  switch (M->getFramePointer()) {
+  case 0:
+// 0 ("none") is the default.
+break;
+  case 1:
+B.addAttribute("frame-pointer", "non-leaf");
+break;
+  case 2:
+B.addAttribute("frame-pointer", "all");
+break;
+  default:
+llvm_unreachable("unknown \"frame-pointer\" value");
+  }
+  F->addAttributes(AttributeList::FunctionIndex, B);
   return F;
 }
 
Index: llvm/include/llvm/IR/Module.h
===
--- llvm/include/llvm/IR/Module.h
+++ llvm/include/llvm/IR/Module.h
@@ -890,6 +890,11 @@
   bool getUwtable() const;
   void setUwtable();
 
+  /// Get/set whether synthesized functions should get the "frame-pointer"
+  /// attribute.
+  int getFramePointer() const;
+  void setFramePointer(int V);
+
   /// @name Utility functions for querying and setting the build SDK version
   /// @{
 
Index: clang/test/CodeGen/asan-frame-pointer.cpp
===
--- /dev/null
+++ clang/test/CodeGen/asan-frame-pointer.cpp
@@ -0,0 +1,19 @@
+/// -mframe-pointer=none sets the module flag "frame-pointer" (merge behavior: max).
+/// asan synthesized ctor/dtor get the "frame-pointer" function attribute if not zero (default).
+// RUN: %clang_cc1 -emit-llvm -fsanitize=address -mframe-pointer=none %s -o - | FileCheck %s --check-prefix=NONE
+// RUN: %clang_cc1 -emit-llvm -fsanitize=address -mframe-pointer=non-leaf %s -o - | FileCheck %s --check-prefix=NONLEAF
+// RUN: %clang_cc1 -emit-llvm -fsanitize=address -mframe-pointer=all %s -o - | FileCheck %s --check-prefix=ALL
+
+int global;
+
+// NONE: define internal void @asan.module_ctor() #[[#ATTR:]] {
+// NONE: define internal void @asan.module_dtor() #[[#ATTR]] {
+// NONE: attributes #[[#ATTR]] = { nounwind }
+
+// NONLEAF: define internal void @asan.module_ctor() #[[#ATTR:]] {
+// NONLEAF: define internal void @asan.module_dtor()

[PATCH] D100819: [RISCV] Implement the vneg.v builtin.

2021-04-21 Thread Hsiangkai Wang via Phabricator via cfe-commits

HsiangKai marked 3 inline comments as done.
HsiangKai added inline comments.



Comment at: clang/utils/TableGen/RISCVVEmitter.cpp:1048
+   return Cmp < 0;
+ // Some mask intrinsics use the same IRName as unmasked.
+ // Sort the unmasked intrinsics first.

craig.topper wrote:
> frasercrmck wrote:
> > Does this only affect `vneg` or are there other changes to the tablegenned 
> > code as a consequence?
> Is this needed for fneg? When we implemented this change downstream, I 
> thought it was for compares due to how vmsge.vx was handled.
Thanks for pointing it out. I reverted it.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100819

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

[PATCH] D100819: [RISCV] Implement the vneg.v builtin.

2021-04-21 Thread Hsiangkai Wang via Phabricator via cfe-commits

HsiangKai updated this revision to Diff 339452.
HsiangKai added a comment.

Address comments.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100819

Files:
  clang/include/clang/Basic/riscv_vector.td
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vneg.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vneg.c
  clang/utils/TableGen/RISCVVEmitter.cpp

Index: clang/utils/TableGen/RISCVVEmitter.cpp
===
--- clang/utils/TableGen/RISCVVEmitter.cpp
+++ clang/utils/TableGen/RISCVVEmitter.cpp
@@ -1050,8 +1050,7 @@
   for (auto  : Defs) {
 StringRef CurIRName = Def->getIRName();
 if (CurIRName != PrevDef->getIRName() ||
-(CurIRName.empty() &&
- Def->getManualCodegen() != PrevDef->getManualCodegen())) {
+(Def->getManualCodegen() != PrevDef->getManualCodegen())) {
   PrevDef->emitCodeGenSwitchBody(OS);
 }
 PrevDef = Def.get();
Index: clang/test/CodeGen/RISCV/rvv-intrinsics/vneg.c
===
--- /dev/null
+++ clang/test/CodeGen/RISCV/rvv-intrinsics/vneg.c
@@ -0,0 +1,625 @@
+// NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py
+// REQUIRES: riscv-registered-target
+// RUN: %clang_cc1 -triple riscv32 -target-feature +experimental-v \
+// RUN:   -disable-O0-optnone -emit-llvm %s -o - | opt -S -mem2reg | FileCheck --check-prefix=CHECK-RV32 %s
+// RUN: %clang_cc1 -triple riscv64 -target-feature +experimental-v \
+// RUN:   -disable-O0-optnone -emit-llvm %s -o - | opt -S -mem2reg | FileCheck --check-prefix=CHECK-RV64 %s
+
+#include 
+
+// CHECK-RV32-LABEL: @test_vneg_v_i8mf8(
+// CHECK-RV32-NEXT:  entry:
+// CHECK-RV32-NEXT:[[TMP0:%.*]] = call  @llvm.riscv.vrsub.nxv1i8.i8.i32( [[OP1:%.*]], i8 0, i32 [[VL:%.*]])
+// CHECK-RV32-NEXT:ret  [[TMP0]]
+//
+// CHECK-RV64-LABEL: @test_vneg_v_i8mf8(
+// CHECK-RV64-NEXT:  entry:
+// CHECK-RV64-NEXT:[[TMP0:%.*]] = call  @llvm.riscv.vrsub.nxv1i8.i8.i64( [[OP1:%.*]], i8 0, i64 [[VL:%.*]])
+// CHECK-RV64-NEXT:ret  [[TMP0]]
+//
+vint8mf8_t test_vneg_v_i8mf8 (vint8mf8_t op1, size_t vl) {
+  return vneg_v_i8mf8(op1, vl);
+}
+
+// CHECK-RV32-LABEL: @test_vneg_v_i8mf4(
+// CHECK-RV32-NEXT:  entry:
+// CHECK-RV32-NEXT:[[TMP0:%.*]] = call  @llvm.riscv.vrsub.nxv2i8.i8.i32( [[OP1:%.*]], i8 0, i32 [[VL:%.*]])
+// CHECK-RV32-NEXT:ret  [[TMP0]]
+//
+// CHECK-RV64-LABEL: @test_vneg_v_i8mf4(
+// CHECK-RV64-NEXT:  entry:
+// CHECK-RV64-NEXT:[[TMP0:%.*]] = call  @llvm.riscv.vrsub.nxv2i8.i8.i64( [[OP1:%.*]], i8 0, i64 [[VL:%.*]])
+// CHECK-RV64-NEXT:ret  [[TMP0]]
+//
+vint8mf4_t test_vneg_v_i8mf4 (vint8mf4_t op1, size_t vl) {
+  return vneg_v_i8mf4(op1, vl);
+}
+
+// CHECK-RV32-LABEL: @test_vneg_v_i8mf2(
+// CHECK-RV32-NEXT:  entry:
+// CHECK-RV32-NEXT:[[TMP0:%.*]] = call  @llvm.riscv.vrsub.nxv4i8.i8.i32( [[OP1:%.*]], i8 0, i32 [[VL:%.*]])
+// CHECK-RV32-NEXT:ret  [[TMP0]]
+//
+// CHECK-RV64-LABEL: @test_vneg_v_i8mf2(
+// CHECK-RV64-NEXT:  entry:
+// CHECK-RV64-NEXT:[[TMP0:%.*]] = call  @llvm.riscv.vrsub.nxv4i8.i8.i64( [[OP1:%.*]], i8 0, i64 [[VL:%.*]])
+// CHECK-RV64-NEXT:ret  [[TMP0]]
+//
+vint8mf2_t test_vneg_v_i8mf2 (vint8mf2_t op1, size_t vl) {
+  return vneg_v_i8mf2(op1, vl);
+}
+
+// CHECK-RV32-LABEL: @test_vneg_v_i8m1(
+// CHECK-RV32-NEXT:  entry:
+// CHECK-RV32-NEXT:[[TMP0:%.*]] = call  @llvm.riscv.vrsub.nxv8i8.i8.i32( [[OP1:%.*]], i8 0, i32 [[VL:%.*]])
+// CHECK-RV32-NEXT:ret  [[TMP0]]
+//
+// CHECK-RV64-LABEL: @test_vneg_v_i8m1(
+// CHECK-RV64-NEXT:  entry:
+// CHECK-RV64-NEXT:[[TMP0:%.*]] = call  @llvm.riscv.vrsub.nxv8i8.i8.i64( [[OP1:%.*]], i8 0, i64 [[VL:%.*]])
+// CHECK-RV64-NEXT:ret  [[TMP0]]
+//
+vint8m1_t test_vneg_v_i8m1 (vint8m1_t op1, size_t vl) {
+  return vneg_v_i8m1(op1, vl);
+}
+
+// CHECK-RV32-LABEL: @test_vneg_v_i8m2(
+// CHECK-RV32-NEXT:  entry:
+// CHECK-RV32-NEXT:[[TMP0:%.*]] = call  @llvm.riscv.vrsub.nxv16i8.i8.i32( [[OP1:%.*]], i8 0, i32 [[VL:%.*]])
+// CHECK-RV32-NEXT:ret  [[TMP0]]
+//
+// CHECK-RV64-LABEL: @test_vneg_v_i8m2(
+// CHECK-RV64-NEXT:  entry:
+// CHECK-RV64-NEXT:[[TMP0:%.*]] = call  @llvm.riscv.vrsub.nxv16i8.i8.i64( [[OP1:%.*]], i8 0, i64 [[VL:%.*]])
+// CHECK-RV64-NEXT:ret  [[TMP0]]
+//
+vint8m2_t test_vneg_v_i8m2 (vint8m2_t op1, size_t vl) {
+  return vneg_v_i8m2(op1, vl);
+}
+
+// CHECK-RV32-LABEL: @test_vneg_v_i8m4(
+// CHECK-RV32-NEXT:  entry:
+// CHECK-RV32-NEXT:[[TMP0:%.*]] = call  @llvm.riscv.vrsub.nxv32i8.i8.i32( [[OP1:%.*]], i8 0, i32 [[VL:%.*]])
+// CHECK-RV32-NEXT:ret  [[TMP0]]
+//
+// CHECK-RV64-LABEL: @test_vneg_v_i8m4(
+// CHECK-RV64-NEXT:  entry:
+// CHECK-RV64-NEXT:[[TMP0:%.*]] = call  @llvm.riscv.vrsub.nxv32i8.i8.i64( [[OP1:%.*]], i8 0, i64 [[VL:%.*]])
+// CHECK-RV64-NEXT:ret  [[TMP0]]
+//
+vint8m4_t test_vneg_v_i8m4 (vint8m4_t op1, size_t vl) {
+  return vneg_v_i8m4(op1, vl);
+}

[PATCH] D100830: [RISCV] [1/2] Add IR intrinsic for Zbp extension

2021-04-21 Thread Craig Topper via Phabricator via cfe-commits

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

LGTM


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100830

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

[PATCH] D95976: [OpenMP] Simplify offloading parallel call codegen

2021-04-21 Thread Giorgis Georgakoudis 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 rGa2dbfb6b72db: [OpenMP] Simplify offloading parallel call 
codegen (authored by ggeorgakoudis).

Changed prior to commit:
  https://reviews.llvm.org/D95976?vs=339334=339441#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D95976

Files:
  clang/lib/CodeGen/CGOpenMPRuntimeGPU.cpp
  clang/test/OpenMP/nvptx_allocate_codegen.cpp
  clang/test/OpenMP/nvptx_data_sharing.cpp
  clang/test/OpenMP/nvptx_distribute_parallel_generic_mode_codegen.cpp
  clang/test/OpenMP/nvptx_lambda_capturing.cpp
  clang/test/OpenMP/nvptx_multi_target_parallel_codegen.cpp
  clang/test/OpenMP/nvptx_nested_parallel_codegen.cpp
  clang/test/OpenMP/nvptx_parallel_codegen.cpp
  clang/test/OpenMP/nvptx_parallel_for_codegen.cpp
  clang/test/OpenMP/nvptx_target_codegen.cpp
  clang/test/OpenMP/nvptx_target_parallel_codegen.cpp
  clang/test/OpenMP/nvptx_target_parallel_num_threads_codegen.cpp
  clang/test/OpenMP/nvptx_target_teams_codegen.cpp
  clang/test/OpenMP/nvptx_target_teams_distribute_codegen.cpp
  clang/test/OpenMP/nvptx_target_teams_distribute_parallel_for_codegen.cpp
  
clang/test/OpenMP/nvptx_target_teams_distribute_parallel_for_generic_mode_codegen.cpp
  clang/test/OpenMP/nvptx_target_teams_distribute_parallel_for_simd_codegen.cpp
  clang/test/OpenMP/nvptx_teams_reduction_codegen.cpp
  clang/test/OpenMP/remarks_parallel_in_multiple_target_state_machines.c
  clang/test/OpenMP/remarks_parallel_in_target_state_machine.c
  clang/test/OpenMP/target_parallel_debug_codegen.cpp
  clang/test/OpenMP/target_parallel_for_debug_codegen.cpp
  llvm/include/llvm/Frontend/OpenMP/OMPKinds.def
  llvm/lib/Transforms/IPO/OpenMPOpt.cpp
  llvm/test/Transforms/OpenMP/gpu_state_machine_function_ptr_replacement.ll
  openmp/libomptarget/deviceRTLs/common/generated_microtask_cases.gen
  openmp/libomptarget/deviceRTLs/common/src/omptarget.cu
  openmp/libomptarget/deviceRTLs/common/src/parallel.cu
  openmp/libomptarget/deviceRTLs/common/src/support.cu
  openmp/libomptarget/deviceRTLs/common/support.h
  openmp/libomptarget/deviceRTLs/interface.h
  openmp/libomptarget/test/offloading/bug49779.cpp
  openmp/libomptarget/utils/generate_microtask_cases.py

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

[PATCH] D100981: Delete le32/le64 targets

2021-04-21 Thread Fangrui Song 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 rG77ac823fd285: Delete le32/le64 targets (authored by MaskRay).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100981

Files:
  clang/include/clang/Basic/BuiltinsLe64.def
  clang/include/clang/Basic/TargetBuiltins.h
  clang/include/clang/module.modulemap
  clang/lib/Basic/CMakeLists.txt
  clang/lib/Basic/Targets.cpp
  clang/lib/Basic/Targets/Le64.cpp
  clang/lib/Basic/Targets/Le64.h
  clang/lib/Basic/Targets/OSTargets.h
  clang/lib/CodeGen/ItaniumCXXABI.cpp
  clang/lib/CodeGen/TargetInfo.cpp
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/test/CodeGen/ext-int-cc.c
  clang/test/CodeGen/le32-arguments.c
  clang/test/CodeGen/le32-libcall-pow.c
  clang/test/CodeGen/le32-regparm.c
  clang/test/CodeGen/le32-vaarg.c
  clang/test/CodeGen/pr18235.c
  clang/test/CodeGen/target-data.c
  clang/test/CodeGenCXX/member-function-pointers.cpp
  clang/test/CodeGenCXX/static-init-pnacl.cpp
  clang/test/Driver/le32-toolchain.c
  clang/test/Driver/le32-unknown-nacl.cpp
  clang/test/Driver/le64-unknown-unknown.cpp
  clang/test/Headers/stdarg.cpp
  llvm/include/llvm/ADT/Triple.h
  llvm/lib/Support/Triple.cpp
  llvm/test/CodeGen/Generic/no-target.ll
  llvm/unittests/ADT/TripleTest.cpp
  llvm/utils/gn/secondary/clang/lib/Basic/BUILD.gn

Index: llvm/utils/gn/secondary/clang/lib/Basic/BUILD.gn
===
--- llvm/utils/gn/secondary/clang/lib/Basic/BUILD.gn
+++ llvm/utils/gn/secondary/clang/lib/Basic/BUILD.gn
@@ -93,7 +93,6 @@
 "Targets/BPF.cpp",
 "Targets/Hexagon.cpp",
 "Targets/Lanai.cpp",
-"Targets/Le64.cpp",
 "Targets/M68k.cpp",
 "Targets/MSP430.cpp",
 "Targets/Mips.cpp",
Index: llvm/unittests/ADT/TripleTest.cpp
===
--- llvm/unittests/ADT/TripleTest.cpp
+++ llvm/unittests/ADT/TripleTest.cpp
@@ -1044,14 +1044,6 @@
   EXPECT_EQ(Triple::renderscript32, T.get32BitArchVariant().getArch());
   EXPECT_EQ(Triple::renderscript64, T.get64BitArchVariant().getArch());
 
-  T.setArch(Triple::le32);
-  EXPECT_EQ(Triple::le32, T.get32BitArchVariant().getArch());
-  EXPECT_EQ(Triple::le64, T.get64BitArchVariant().getArch());
-
-  T.setArch(Triple::le64);
-  EXPECT_EQ(Triple::le32, T.get32BitArchVariant().getArch());
-  EXPECT_EQ(Triple::le64, T.get64BitArchVariant().getArch());
-
   T.setArch(Triple::armeb);
   EXPECT_EQ(Triple::armeb, T.get32BitArchVariant().getArch());
   EXPECT_EQ(Triple::aarch64_be, T.get64BitArchVariant().getArch());
@@ -1166,14 +1158,6 @@
   EXPECT_EQ(Triple::tce, T.getBigEndianArchVariant().getArch());
   EXPECT_EQ(Triple::tcele, T.getLittleEndianArchVariant().getArch());
 
-  T.setArch(Triple::le32);
-  EXPECT_EQ(Triple::UnknownArch, T.getBigEndianArchVariant().getArch());
-  EXPECT_EQ(Triple::le32, T.getLittleEndianArchVariant().getArch());
-
-  T.setArch(Triple::le64);
-  EXPECT_EQ(Triple::UnknownArch, T.getBigEndianArchVariant().getArch());
-  EXPECT_EQ(Triple::le64, T.getLittleEndianArchVariant().getArch());
-
   T.setArch(Triple::csky);
   EXPECT_EQ(Triple::UnknownArch, T.getBigEndianArchVariant().getArch());
   EXPECT_EQ(Triple::csky, T.getLittleEndianArchVariant().getArch());
Index: llvm/test/CodeGen/Generic/no-target.ll
===
--- llvm/test/CodeGen/Generic/no-target.ll
+++ /dev/null
@@ -1,3 +0,0 @@
-; RUN: not llc -mtriple le32-unknown-nacl %s -o - 2>&1 | FileCheck %s
-
-; CHECK: error: unable to get target for 'le32-unknown-nacl'
Index: llvm/lib/Support/Triple.cpp
===
--- llvm/lib/Support/Triple.cpp
+++ llvm/lib/Support/Triple.cpp
@@ -42,8 +42,6 @@
   case hsail:  return "hsail";
   case kalimba:return "kalimba";
   case lanai:  return "lanai";
-  case le32:   return "le32";
-  case le64:   return "le64";
   case m68k:   return "m68k";
   case mips64: return "mips64";
   case mips64el:   return "mips64el";
@@ -136,9 +134,6 @@
   case nvptx:   return "nvvm";
   case nvptx64: return "nvvm";
 
-  case le32:return "le32";
-  case le64:return "le64";
-
   case amdil:
   case amdil64: return "amdil";
 
@@ -315,8 +310,6 @@
 .Case("xcore", xcore)
 .Case("nvptx", nvptx)
 .Case("nvptx64", nvptx64)
-.Case("le32", le32)
-.Case("le64", le64)
 .Case("amdil", amdil)
 .Case("amdil64", amdil64)
 .Case("hsail", hsail)
@@ -448,8 +441,6 @@
 .Case("xcore", Triple::xcore)
 .Case("nvptx", Triple::nvptx)
 .Case("nvptx64", Triple::nvptx64)
-.Case("le32", Triple::le32)
-.Case("le64", Triple::le64)
 .Case("amdil", Triple::amdil)
 .Case("amdil64", Triple::amdil64)
 .Case("hsail",

[clang] 77ac823 - Delete le32/le64 targets

2021-04-21 Thread Fangrui Song via cfe-commits


Author: Fangrui Song
Date: 2021-04-21T18:44:12-07:00
New Revision: 77ac823fd285973cfb3517932c09d82e6a32f46d

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

LOG: Delete le32/le64 targets

They are unused now.

Note: NaCl is still used and is currently expected to be needed until 2022-06
(https://blog.chromium.org/2020/08/changes-to-chrome-app-support-timeline.html).

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

Added: 


Modified: 
clang/include/clang/Basic/TargetBuiltins.h
clang/include/clang/module.modulemap
clang/lib/Basic/CMakeLists.txt
clang/lib/Basic/Targets.cpp
clang/lib/Basic/Targets/OSTargets.h
clang/lib/CodeGen/ItaniumCXXABI.cpp
clang/lib/CodeGen/TargetInfo.cpp
clang/lib/Driver/ToolChains/Clang.cpp
clang/test/CodeGen/ext-int-cc.c
clang/test/CodeGen/target-data.c
clang/test/CodeGenCXX/member-function-pointers.cpp
clang/test/Headers/stdarg.cpp
llvm/include/llvm/ADT/Triple.h
llvm/lib/Support/Triple.cpp
llvm/unittests/ADT/TripleTest.cpp
llvm/utils/gn/secondary/clang/lib/Basic/BUILD.gn

Removed: 
clang/include/clang/Basic/BuiltinsLe64.def
clang/lib/Basic/Targets/Le64.cpp
clang/lib/Basic/Targets/Le64.h
clang/test/CodeGen/le32-arguments.c
clang/test/CodeGen/le32-libcall-pow.c
clang/test/CodeGen/le32-regparm.c
clang/test/CodeGen/le32-vaarg.c
clang/test/CodeGen/pr18235.c
clang/test/CodeGenCXX/static-init-pnacl.cpp
clang/test/Driver/le32-toolchain.c
clang/test/Driver/le32-unknown-nacl.cpp
clang/test/Driver/le64-unknown-unknown.cpp
llvm/test/CodeGen/Generic/no-target.ll



diff  --git a/clang/include/clang/Basic/BuiltinsLe64.def 
b/clang/include/clang/Basic/BuiltinsLe64.def
deleted file mode 100644
index 776492cd21b37..0
--- a/clang/include/clang/Basic/BuiltinsLe64.def
+++ /dev/null
@@ -1,18 +0,0 @@
-//==- BuiltinsLe64.def - Le64 Builtin function database --*- C++ 
-*-==//
-//
-// 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
-//
-//===--===//
-//
-// This file defines the Le64-specific builtin function database.  Users of 
this
-// file must define the BUILTIN macro to make use of this information.
-//
-//===--===//
-
-// The format of this database matches clang/Basic/Builtins.def.
-
-BUILTIN(__clear_cache, "vv*v*", "i")
-
-#undef BUILTIN

diff  --git a/clang/include/clang/Basic/TargetBuiltins.h 
b/clang/include/clang/Basic/TargetBuiltins.h
index 7fa688633ff60..ed53b10f61ef4 100644
--- a/clang/include/clang/Basic/TargetBuiltins.h
+++ b/clang/include/clang/Basic/TargetBuiltins.h
@@ -300,16 +300,6 @@ namespace clang {
 };
   }
 
-  /// Le64 builtins
-  namespace Le64 {
-  enum {
-LastTIBuiltin = clang::Builtin::FirstTSBuiltin - 1,
-  #define BUILTIN(ID, TYPE, ATTRS) BI##ID,
-  #include "clang/Basic/BuiltinsLe64.def"
-LastTSBuiltin
-  };
-  }
-
   /// SystemZ builtins
   namespace SystemZ {
 enum {
@@ -335,8 +325,7 @@ namespace clang {
PPC::LastTSBuiltin, NVPTX::LastTSBuiltin, AMDGPU::LastTSBuiltin,
X86::LastTSBuiltin, VE::LastTSBuiltin, RISCV::LastTSBuiltin,
Hexagon::LastTSBuiltin, Mips::LastTSBuiltin, XCore::LastTSBuiltin,
-   Le64::LastTSBuiltin, SystemZ::LastTSBuiltin,
-   WebAssembly::LastTSBuiltin});
+   SystemZ::LastTSBuiltin, WebAssembly::LastTSBuiltin});
 
 } // end namespace clang.
 

diff  --git a/clang/include/clang/module.modulemap 
b/clang/include/clang/module.modulemap
index 458d91cb9d95e..82aba40b9f846 100644
--- a/clang/include/clang/module.modulemap
+++ b/clang/include/clang/module.modulemap
@@ -40,7 +40,6 @@ module Clang_Basic {
   textual header "Basic/BuiltinsHexagon.def"
   textual header "Basic/BuiltinsHexagonDep.def"
   textual header "Basic/BuiltinsHexagonMapCustomDep.def"
-  textual header "Basic/BuiltinsLe64.def"
   textual header "Basic/BuiltinsMips.def"
   textual header "Basic/BuiltinsNEON.def"
   textual header "Basic/BuiltinsNVPTX.def"

diff  --git a/clang/lib/Basic/CMakeLists.txt b/clang/lib/Basic/CMakeLists.txt
index a3a8f8d68962b..4199d4d01b9dd 100644
--- a/clang/lib/Basic/CMakeLists.txt
+++ b/clang/lib/Basic/CMakeLists.txt
@@ -77,7 +77,6 @@ add_clang_library(clangBasic
   Targets/BPF.cpp
   Targets/Hexagon.cpp
   Targets/Lanai.cpp
-  Targets/Le64.cpp
   Targets/M68k.cpp
   Targets/MSP430.cpp
   Targets/Mips.cpp

diff  --git a/clang/lib/Basic/Targets.cpp b/clang/lib/Basic/Targets.cpp
index 8df5cb7a3a61a..685700fbd22d4 100644
--- a/clang/lib/Basic/Targets.cpp
+++

[PATCH] D93031: Enable fexec-charset option

2021-04-21 Thread Joerg Sonnenberger via Phabricator via cfe-commits

joerg added a comment.

"Keeping the original spelling around" would assume that the input is not using 
a stateful encoding. That seems worse as assumption than giving the canonical 
output in UTF-8 and shifting the problem to the user's editor?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93031

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

[PATCH] D100739: [Coroutines] Handle overaligned frame allocation (2)

2021-04-21 Thread Xun Li via Phabricator via cfe-commits

lxfind added a comment.

Thanks for working on this.
I am still having a bit hard time understanding the solution.
A few questions:

1. I assume this patch is to solve the problem where the promise object is not 
aligned according to its alignof annotation, right? The title/wording is a bit 
misleading. Usually "handling XXX" means XXX is a situation/problem that wasn't 
handle properly before, and it's being handled here. I don't really understand 
what "handle overaligned frame allocation" means. Isn't frame allocation 
under-aligned being the problem?
2. What is the purpose of coro.align intrinsic?
3. Could you provide some examples of what the IR might look like after this 
patch? Either that or a more detailed explanation of how this works in the 
summary.
4. Do you think it might be cleaner to introduce a new variant of coro.size 
instead of adding arguments to it? For example, coro.size.aligned(). This way, 
you can avoid changing any test file for non-switch-lowering test files, but 
focus on all switch-lowering tests.
5. Typically, coro.free is used by a comparison with nullptr. This is to enable 
CoroElide. See: https://llvm.org/docs/Coroutines.html#llvm-coro-free-intrinsic. 
So I don't think you can load from it directly.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100739

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

[PATCH] D100981: Delete le32/le64 targets

2021-04-21 Thread Derek Schuff via Phabricator via cfe-commits

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

Thanks. I had heard in the past that there were some other folks who had used 
le32/le64 as a "generic" target (in fact that's why it's named so generically, 
rather than being called "pnacl" or similar) but I haven't heard of anything 
recently, and as you can see nobody has upstreamed any support for other OS or 
target specializations or asked to collaborate on it. Practically speaking even 
a target that wants fairly generic bitcode would probably want its own triple, 
so unless this removal captures someone's attention who wants to keep 
maintaining it, this should be fine to remove.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100981

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

[PATCH] D101000: Coverage: Document how to collect a profile without a filesystem

2021-04-21 Thread Duncan P. N. Exon Smith via Phabricator via cfe-commits

dexonsmith marked an inline comment as done.
dexonsmith added inline comments.



Comment at: clang/docs/SourceBasedCodeCoverage.rst:368
+
+In C++ files, declare these as ``extern "C"``.
+

vsk wrote:
> I think we should leave a note about how to avoid pulling in unwanted symbol 
> references, and perhaps reference the preceding section about using the 
> runtime without its static initializer.
Improved this a bit; let me know if you suggested text that makes the unwanted 
symbol reference stuff a bit more clear.

Note, BTW, that I've made this a sub-section of "Using the profiling runtime 
without static initializers"; if you think it should be a peer section that's 
an option too.


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

https://reviews.llvm.org/D101000

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

[PATCH] D101000: Coverage: Document how to collect a profile without a filesystem

2021-04-21 Thread Duncan P. N. Exon Smith via Phabricator via cfe-commits

dexonsmith updated this revision to Diff 339423.
dexonsmith added a comment.

Incorporate feedback from @vsk:

- a bit more explanatory text for the overall context
- explicitly reference the static initializers


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

https://reviews.llvm.org/D101000

Files:
  clang/docs/SourceBasedCodeCoverage.rst


Index: clang/docs/SourceBasedCodeCoverage.rst
===
--- clang/docs/SourceBasedCodeCoverage.rst
+++ clang/docs/SourceBasedCodeCoverage.rst
@@ -346,6 +346,34 @@
 
 In C++ files, declare these as ``extern "C"``.
 
+Using the profiling runtime without a filesystem
+
+
+The profiling runtime also supports freestanding environments that lack a
+filesystem. The runtime ships as a static archive that's structured to make
+dependencies on a hosted environment optional, depending on what features
+the client application uses.
+
+The first step is to export ``__llvm_profile_runtime``, as above, to disable
+the default static initializers. Instead of calling the ``*_file()`` APIs
+described above, use the following to save the profile directly to a buffer
+under your control:
+
+* Forward-declare ``uint64_t __llvm_profile_get_size_for_buffer(void)`` and
+  call it to determine the size of the profile. You'll need to allocate a
+  buffer of this size.
+
+* Forward-declare ``int __llvm_profile_write_buffer(char *Buffer)`` and call it
+  to copy the current counters to ``Buffer``, which is expected to already be
+  allocated and big enough for the profile.
+
+* Optionally, forward-declare ``void __llvm_profile_reset_counters(void)`` and
+  call it to reset the counters before entering a specific section to be
+  profiled. This is only useful if there is some setup that should be excluded
+  from the profile.
+
+In C++ files, declare these as ``extern "C"``.
+
 Collecting coverage reports for the llvm project
 
 


Index: clang/docs/SourceBasedCodeCoverage.rst
===
--- clang/docs/SourceBasedCodeCoverage.rst
+++ clang/docs/SourceBasedCodeCoverage.rst
@@ -346,6 +346,34 @@
 
 In C++ files, declare these as ``extern "C"``.
 
+Using the profiling runtime without a filesystem
+
+
+The profiling runtime also supports freestanding environments that lack a
+filesystem. The runtime ships as a static archive that's structured to make
+dependencies on a hosted environment optional, depending on what features
+the client application uses.
+
+The first step is to export ``__llvm_profile_runtime``, as above, to disable
+the default static initializers. Instead of calling the ``*_file()`` APIs
+described above, use the following to save the profile directly to a buffer
+under your control:
+
+* Forward-declare ``uint64_t __llvm_profile_get_size_for_buffer(void)`` and
+  call it to determine the size of the profile. You'll need to allocate a
+  buffer of this size.
+
+* Forward-declare ``int __llvm_profile_write_buffer(char *Buffer)`` and call it
+  to copy the current counters to ``Buffer``, which is expected to already be
+  allocated and big enough for the profile.
+
+* Optionally, forward-declare ``void __llvm_profile_reset_counters(void)`` and
+  call it to reset the counters before entering a specific section to be
+  profiled. This is only useful if there is some setup that should be excluded
+  from the profile.
+
+In C++ files, declare these as ``extern "C"``.
+
 Collecting coverage reports for the llvm project
 
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D100251: [IR][sanitizer] Set nounwind on module ctor/dtor, additionally set uwtable if -fasynchronous-unwind-tables

2021-04-21 Thread Fangrui Song via Phabricator via cfe-commits

This revision was automatically updated to reflect the committed changes.
Closed by commit rG775a9483e55e: [IR][sanitizer] Set nounwind on module 
ctor/dtor, additionally set uwtable if… (authored by MaskRay).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100251

Files:
  clang/lib/CodeGen/CodeGenModule.cpp
  clang/test/CodeGen/asan-globals.cpp
  clang/test/CodeGen/asan-new-pm.ll
  clang/test/CodeGen/asan-no-globals-no-comdat.cpp
  llvm/include/llvm/IR/Function.h
  llvm/include/llvm/IR/Module.h
  llvm/lib/IR/Function.cpp
  llvm/lib/IR/Module.cpp
  llvm/lib/Transforms/Instrumentation/AddressSanitizer.cpp
  llvm/lib/Transforms/Utils/ModuleUtils.cpp
  llvm/test/Instrumentation/AddressSanitizer/basic.ll
  llvm/test/Instrumentation/AddressSanitizer/no-globals.ll
  llvm/test/Instrumentation/AddressSanitizer/uwtable.ll
  llvm/test/Instrumentation/HWAddressSanitizer/basic.ll
  llvm/test/Instrumentation/HWAddressSanitizer/with-calls.ll
  llvm/test/Instrumentation/MemorySanitizer/msan_basic.ll
  
llvm/test/Instrumentation/SanitizerCoverage/trace-pc-guard-inline-8bit-counters.ll
  llvm/test/Instrumentation/SanitizerCoverage/trace-pc-guard-inline-bool-flag.ll
  llvm/test/Instrumentation/SanitizerCoverage/trace-pc-guard.ll

Index: llvm/test/Instrumentation/SanitizerCoverage/trace-pc-guard.ll
===
--- llvm/test/Instrumentation/SanitizerCoverage/trace-pc-guard.ll
+++ llvm/test/Instrumentation/SanitizerCoverage/trace-pc-guard.ll
@@ -60,5 +60,7 @@
   ret void
 }
 
-; ELF-LABEL: define internal void @sancov.module_ctor_trace_pc_guard() comdat {
-; MACHO-LABEL: define internal void @sancov.module_ctor_trace_pc_guard() {
+; ELF-LABEL: define internal void @sancov.module_ctor_trace_pc_guard() #2 comdat {
+; MACHO-LABEL: define internal void @sancov.module_ctor_trace_pc_guard() #2 {
+
+; CHECK: attributes #2 = { nounwind }
Index: llvm/test/Instrumentation/SanitizerCoverage/trace-pc-guard-inline-bool-flag.ll
===
--- llvm/test/Instrumentation/SanitizerCoverage/trace-pc-guard-inline-bool-flag.ll
+++ llvm/test/Instrumentation/SanitizerCoverage/trace-pc-guard-inline-bool-flag.ll
@@ -4,8 +4,8 @@
 ; Module ctors should have stable names across modules, not something like
 ; @sancov.module_ctor.3 that may cause duplicate ctors after linked together.
 
-; CHECK: define internal void @sancov.module_ctor_trace_pc_guard() comdat {
-; CHECK: define internal void @sancov.module_ctor_bool_flag() comdat {
+; CHECK: define internal void @sancov.module_ctor_trace_pc_guard() #[[#]] comdat {
+; CHECK: define internal void @sancov.module_ctor_bool_flag() #[[#]] comdat {
 
 target datalayout = "e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128-n8:16:32:64"
 target triple = "x86_64-unknown-linux-gnu"
Index: llvm/test/Instrumentation/SanitizerCoverage/trace-pc-guard-inline-8bit-counters.ll
===
--- llvm/test/Instrumentation/SanitizerCoverage/trace-pc-guard-inline-8bit-counters.ll
+++ llvm/test/Instrumentation/SanitizerCoverage/trace-pc-guard-inline-8bit-counters.ll
@@ -4,8 +4,8 @@
 ; Module ctors should have stable names across modules, not something like
 ; @sancov.module_ctor.3 that may cause duplicate ctors after linked together.
 
-; CHECK: define internal void @sancov.module_ctor_trace_pc_guard() comdat {
-; CHECK: define internal void @sancov.module_ctor_8bit_counters() comdat {
+; CHECK: define internal void @sancov.module_ctor_trace_pc_guard() #[[#]] comdat {
+; CHECK: define internal void @sancov.module_ctor_8bit_counters() #[[#]] comdat {
 
 target datalayout = "e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128-n8:16:32:64"
 target triple = "x86_64-unknown-linux-gnu"
Index: llvm/test/Instrumentation/MemorySanitizer/msan_basic.ll
===
--- llvm/test/Instrumentation/MemorySanitizer/msan_basic.ll
+++ llvm/test/Instrumentation/MemorySanitizer/msan_basic.ll
@@ -1013,7 +1013,7 @@
 ; CHECK-NEXT: ret i8*
 
 
-; CHECK-LABEL: define internal void @msan.module_ctor() {
+; CHECK-LABEL: define internal void @msan.module_ctor() #[[#ATTR:]] {
 ; CHECK: call void @__msan_init()
 
 ; CHECK-CALLS: declare void @__msan_maybe_warning_1(i8 zeroext, i32 zeroext)
@@ -1024,3 +1024,5 @@
 ; CHECK-CALLS: declare void @__msan_maybe_store_origin_4(i32 zeroext, i8*, i32 zeroext)
 ; CHECK-CALLS: declare void @__msan_maybe_warning_8(i64 zeroext, i32 zeroext)
 ; CHECK-CALLS: declare void @__msan_maybe_store_origin_8(i64 zeroext, i8*, i32 zeroext)
+
+; CHECK:   attributes #[[#ATTR]] = { nounwind }
Index: llvm/test/Instrumentation/HWAddressSanitizer/with-calls.ll

[clang] 775a948 - [IR][sanitizer] Set nounwind on module ctor/dtor, additionally set uwtable if -fasynchronous-unwind-tables

2021-04-21 Thread Fangrui Song via cfe-commits


Author: Fangrui Song
Date: 2021-04-21T15:58:20-07:00
New Revision: 775a9483e55efb365691bc425ed107568ad6daf8

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

LOG: [IR][sanitizer] Set nounwind on module ctor/dtor, additionally set uwtable 
if -fasynchronous-unwind-tables

On ELF targets, if a function has uwtable or personality, or does not have
nounwind (`needsUnwindTableEntry`), it marks that `.eh_frame` is needed in the 
module.

Then, a function gets `.eh_frame` if `needsUnwindTableEntry` or `-g[123]` is 
specified.
(i.e. If -g[123], every function gets `.eh_frame`.
This behavior is strange but that is the status quo on GCC and Clang.)

Let's take asan as an example. Other sanitizers are similar.
`asan.module_[cd]tor` has no attribute. `needsUnwindTableEntry` returns true,
so every function gets `.eh_frame` if `-g[123]` is specified.
This is the root cause that
`-fno-exceptions -fno-asynchronous-unwind-tables -g` produces .debug_frame
while
`-fno-exceptions -fno-asynchronous-unwind-tables -g -fsanitize=address` 
produces .eh_frame.

This patch

* sets the nounwind attribute on sanitizer module ctor/dtor.
* let Clang emit a module flag metadata "uwtable" for 
-fasynchronous-unwind-tables. If "uwtable" is set, sanitizer module ctor/dtor 
additionally get the uwtable attribute.

The "uwtable" mechanism is generic: synthesized functions not cloned/specialized
from existing ones should consider `Function::createWithDefaultAttr` instead of
`Function::create` if they want to get some default attributes which
have more of module semantics.

Other candidates: "frame-pointer" 
(https://github.com/ClangBuiltLinux/linux/issues/955
https://github.com/ClangBuiltLinux/linux/issues/1238), dso_local, etc.

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

Added: 
llvm/test/Instrumentation/AddressSanitizer/uwtable.ll

Modified: 
clang/lib/CodeGen/CodeGenModule.cpp
clang/test/CodeGen/asan-globals.cpp
clang/test/CodeGen/asan-new-pm.ll
clang/test/CodeGen/asan-no-globals-no-comdat.cpp
llvm/include/llvm/IR/Function.h
llvm/include/llvm/IR/Module.h
llvm/lib/IR/Function.cpp
llvm/lib/IR/Module.cpp
llvm/lib/Transforms/Instrumentation/AddressSanitizer.cpp
llvm/lib/Transforms/Utils/ModuleUtils.cpp
llvm/test/Instrumentation/AddressSanitizer/basic.ll
llvm/test/Instrumentation/AddressSanitizer/no-globals.ll
llvm/test/Instrumentation/HWAddressSanitizer/basic.ll
llvm/test/Instrumentation/HWAddressSanitizer/with-calls.ll
llvm/test/Instrumentation/MemorySanitizer/msan_basic.ll

llvm/test/Instrumentation/SanitizerCoverage/trace-pc-guard-inline-8bit-counters.ll

llvm/test/Instrumentation/SanitizerCoverage/trace-pc-guard-inline-bool-flag.ll
llvm/test/Instrumentation/SanitizerCoverage/trace-pc-guard.ll

Removed: 




diff  --git a/clang/lib/CodeGen/CodeGenModule.cpp 
b/clang/lib/CodeGen/CodeGenModule.cpp
index a5229261bea7b..6b966e7ca1338 100644
--- a/clang/lib/CodeGen/CodeGenModule.cpp
+++ b/clang/lib/CodeGen/CodeGenModule.cpp
@@ -741,6 +741,8 @@ void CodeGenModule::Release() {
 
   if (CodeGenOpts.NoPLT)
 getModule().setRtLibUseGOT();
+  if (CodeGenOpts.UnwindTables)
+getModule().setUwtable();
 
   SimplifyPersonality();
 

diff  --git a/clang/test/CodeGen/asan-globals.cpp 
b/clang/test/CodeGen/asan-globals.cpp
index cb6f2174c6a5c..f49a180c5868f 100644
--- a/clang/test/CodeGen/asan-globals.cpp
+++ b/clang/test/CodeGen/asan-globals.cpp
@@ -27,7 +27,8 @@ void func() {
 // ASAN: @__special_global{{.*}} global { i32, [60 x i8] }{{.*}}, align 32
 // KASAN: @__special_global{{.*}} global i32
 
-// CHECK-LABEL: define internal void @asan.module_ctor
+/// Without -fasynchronous-unwind-tables, ctor and dtor get the uwtable 
attribute.
+// CHECK-LABEL: define internal void @asan.module_ctor() #[[#ATTR:]] {
 // ASAN-NEXT: call void @__asan_init
 // ASAN-NEXT: call void @__asan_version_mismatch_check
 // KASAN-NOT: call void @__asan_init
@@ -36,10 +37,19 @@ void func() {
 // KASAN-NEXT: call void @__asan_register_globals({{.*}}, i{{32|64}} 5)
 // CHECK-NEXT: ret void
 
-// CHECK-LABEL: define internal void @asan.module_dtor
+// CHECK:  define internal void @asan.module_dtor() #[[#ATTR]] {
 // CHECK-NEXT: call void @__asan_unregister_globals
 // CHECK-NEXT: ret void
 
+// CHECK: attributes #[[#ATTR]] = { nounwind }
+
+/// If -fasynchronous-unwind-tables, set the module flag "uwtable". ctor/dtor
+/// will thus get the uwtable attribute.
+// RUN: %clang_cc1 -emit-llvm -fsanitize=address -munwind-tables -o - %s | 
FileCheck %s --check-prefixes=UWTABLE
+// UWTABLE: define internal void @asan.module_dtor() #[[#ATTR:]] {
+// UWTABLE: attributes #[[#ATTR]] = { nounwind uwtable }
+// UWTABLE: ![[#]] = !{i32 7, !"uwtable", i32 1}
+
 // CHECK:

[PATCH] D100869: [libcxx] Stop using use c++ subdirectory for libc++ library

2021-04-21 Thread Petr Hosek via Phabricator via cfe-commits

This revision was not accepted when it landed; it landed in state "Needs 
Review".
This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rGf749550cfe9f: [libcxx] Stop using use c++ subdirectory for 
libc++ library (authored by phosek).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100869

Files:
  clang/include/clang/Driver/ToolChain.h
  clang/lib/Driver/ToolChain.cpp
  clang/lib/Driver/ToolChains/Fuchsia.cpp
  
clang/test/Driver/Inputs/basic_fuchsia_tree/lib/aarch64-fuchsia/asan+noexcept/libc++.so
  clang/test/Driver/Inputs/basic_fuchsia_tree/lib/aarch64-fuchsia/asan/libc++.so
  
clang/test/Driver/Inputs/basic_fuchsia_tree/lib/aarch64-fuchsia/c++/asan+noexcept/libc++.so
  
clang/test/Driver/Inputs/basic_fuchsia_tree/lib/aarch64-fuchsia/c++/asan/libc++.so
  clang/test/Driver/Inputs/basic_fuchsia_tree/lib/aarch64-fuchsia/c++/libc++.so
  
clang/test/Driver/Inputs/basic_fuchsia_tree/lib/aarch64-fuchsia/c++/noexcept/libc++.so
  
clang/test/Driver/Inputs/basic_fuchsia_tree/lib/aarch64-fuchsia/c++/relative-vtables+noexcept/libc++.so
  
clang/test/Driver/Inputs/basic_fuchsia_tree/lib/aarch64-fuchsia/c++/relative-vtables/libc++.so
  clang/test/Driver/Inputs/basic_fuchsia_tree/lib/aarch64-fuchsia/libc++.so
  
clang/test/Driver/Inputs/basic_fuchsia_tree/lib/aarch64-fuchsia/noexcept/libc++.so
  
clang/test/Driver/Inputs/basic_fuchsia_tree/lib/aarch64-fuchsia/relative-vtables+noexcept/libc++.so
  
clang/test/Driver/Inputs/basic_fuchsia_tree/lib/aarch64-fuchsia/relative-vtables/libc++.so
  
clang/test/Driver/Inputs/basic_fuchsia_tree/lib/x86_64-fuchsia/asan+noexcept/libc++.so
  clang/test/Driver/Inputs/basic_fuchsia_tree/lib/x86_64-fuchsia/asan/libc++.so
  
clang/test/Driver/Inputs/basic_fuchsia_tree/lib/x86_64-fuchsia/c++/asan+noexcept/libc++.so
  
clang/test/Driver/Inputs/basic_fuchsia_tree/lib/x86_64-fuchsia/c++/asan/libc++.so
  
clang/test/Driver/Inputs/basic_fuchsia_tree/lib/x86_64-fuchsia/c++/hwasan+noexcept/libc++.so
  
clang/test/Driver/Inputs/basic_fuchsia_tree/lib/x86_64-fuchsia/c++/hwasan/libc++.so
  clang/test/Driver/Inputs/basic_fuchsia_tree/lib/x86_64-fuchsia/c++/libc++.so
  
clang/test/Driver/Inputs/basic_fuchsia_tree/lib/x86_64-fuchsia/c++/noexcept/libc++.so
  
clang/test/Driver/Inputs/basic_fuchsia_tree/lib/x86_64-fuchsia/c++/relative-vtables+asan+noexcept/libc++.so
  
clang/test/Driver/Inputs/basic_fuchsia_tree/lib/x86_64-fuchsia/c++/relative-vtables+asan/libc++.so
  
clang/test/Driver/Inputs/basic_fuchsia_tree/lib/x86_64-fuchsia/c++/relative-vtables+hwasan+noexcept/libc++.so
  
clang/test/Driver/Inputs/basic_fuchsia_tree/lib/x86_64-fuchsia/c++/relative-vtables+hwasan/libc++.so
  
clang/test/Driver/Inputs/basic_fuchsia_tree/lib/x86_64-fuchsia/c++/relative-vtables+noexcept/libc++.so
  
clang/test/Driver/Inputs/basic_fuchsia_tree/lib/x86_64-fuchsia/c++/relative-vtables/libc++.so
  
clang/test/Driver/Inputs/basic_fuchsia_tree/lib/x86_64-fuchsia/hwasan+noexcept/libc++.so
  
clang/test/Driver/Inputs/basic_fuchsia_tree/lib/x86_64-fuchsia/hwasan/libc++.so
  clang/test/Driver/Inputs/basic_fuchsia_tree/lib/x86_64-fuchsia/libc++.so
  
clang/test/Driver/Inputs/basic_fuchsia_tree/lib/x86_64-fuchsia/noexcept/libc++.so
  
clang/test/Driver/Inputs/basic_fuchsia_tree/lib/x86_64-fuchsia/relative-vtables+asan+noexcept/libc++.so
  
clang/test/Driver/Inputs/basic_fuchsia_tree/lib/x86_64-fuchsia/relative-vtables+asan/libc++.so
  
clang/test/Driver/Inputs/basic_fuchsia_tree/lib/x86_64-fuchsia/relative-vtables+hwasan+noexcept/libc++.so
  
clang/test/Driver/Inputs/basic_fuchsia_tree/lib/x86_64-fuchsia/relative-vtables+hwasan/libc++.so
  
clang/test/Driver/Inputs/basic_fuchsia_tree/lib/x86_64-fuchsia/relative-vtables+noexcept/libc++.so
  
clang/test/Driver/Inputs/basic_fuchsia_tree/lib/x86_64-fuchsia/relative-vtables/libc++.so
  
clang/test/Driver/Inputs/basic_linux_libcxx_tree/usr/lib/x86_64-linux-gnu/.keep
  
clang/test/Driver/Inputs/basic_linux_libcxx_tree/usr/lib/x86_64-linux-gnu/c++/.keep
  
clang/test/Driver/Inputs/resource_dir_with_per_target_subdir/lib/aarch64-fuchsia/asan/.keep
  
clang/test/Driver/Inputs/resource_dir_with_per_target_subdir/lib/aarch64-fuchsia/noexcept/.keep
  
clang/test/Driver/Inputs/resource_dir_with_per_target_subdir/lib/x86_64-fuchsia/asan/.keep
  
clang/test/Driver/Inputs/resource_dir_with_per_target_subdir/lib/x86_64-fuchsia/noexcept/.keep
  clang/test/Driver/fuchsia.cpp
  clang/test/Driver/linux-per-target-runtime-dir.c
  libcxx/CMakeLists.txt
  libcxxabi/CMakeLists.txt
  libunwind/CMakeLists.txt

Index: libunwind/CMakeLists.txt
===
--- libunwind/CMakeLists.txt
+++ libunwind/CMakeLists.txt
@@ -115,8 +115,8 @@
 ${CMAKE_MODULE_PATH})
 
 if(LLVM_ENABLE_PER_TARGET_RUNTIME_DIR AND NOT APPLE)
-  set(LIBUNWIND_LIBRARY_DIR

[clang] f749550 - [libcxx] Stop using use c++ subdirectory for libc++ library

2021-04-21 Thread Petr Hosek via cfe-commits


Author: Petr Hosek
Date: 2021-04-21T15:39:03-07:00
New Revision: f749550cfe9f0bf2364abb2139835348587062ed

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

LOG: [libcxx] Stop using use c++ subdirectory for libc++ library

The new layout more closely matches the layout used by other compilers.
This is only used when LLVM_ENABLE_PER_TARGET_RUNTIME_DIR is enabled.

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

Added: 

clang/test/Driver/Inputs/basic_fuchsia_tree/lib/aarch64-fuchsia/asan+noexcept/libc++.so

clang/test/Driver/Inputs/basic_fuchsia_tree/lib/aarch64-fuchsia/asan/libc++.so
clang/test/Driver/Inputs/basic_fuchsia_tree/lib/aarch64-fuchsia/libc++.so

clang/test/Driver/Inputs/basic_fuchsia_tree/lib/aarch64-fuchsia/noexcept/libc++.so

clang/test/Driver/Inputs/basic_fuchsia_tree/lib/aarch64-fuchsia/relative-vtables+noexcept/libc++.so

clang/test/Driver/Inputs/basic_fuchsia_tree/lib/aarch64-fuchsia/relative-vtables/libc++.so

clang/test/Driver/Inputs/basic_fuchsia_tree/lib/x86_64-fuchsia/asan+noexcept/libc++.so

clang/test/Driver/Inputs/basic_fuchsia_tree/lib/x86_64-fuchsia/asan/libc++.so

clang/test/Driver/Inputs/basic_fuchsia_tree/lib/x86_64-fuchsia/hwasan+noexcept/libc++.so

clang/test/Driver/Inputs/basic_fuchsia_tree/lib/x86_64-fuchsia/hwasan/libc++.so
clang/test/Driver/Inputs/basic_fuchsia_tree/lib/x86_64-fuchsia/libc++.so

clang/test/Driver/Inputs/basic_fuchsia_tree/lib/x86_64-fuchsia/noexcept/libc++.so

clang/test/Driver/Inputs/basic_fuchsia_tree/lib/x86_64-fuchsia/relative-vtables+asan+noexcept/libc++.so

clang/test/Driver/Inputs/basic_fuchsia_tree/lib/x86_64-fuchsia/relative-vtables+asan/libc++.so

clang/test/Driver/Inputs/basic_fuchsia_tree/lib/x86_64-fuchsia/relative-vtables+hwasan+noexcept/libc++.so

clang/test/Driver/Inputs/basic_fuchsia_tree/lib/x86_64-fuchsia/relative-vtables+hwasan/libc++.so

clang/test/Driver/Inputs/basic_fuchsia_tree/lib/x86_64-fuchsia/relative-vtables+noexcept/libc++.so

clang/test/Driver/Inputs/basic_fuchsia_tree/lib/x86_64-fuchsia/relative-vtables/libc++.so

clang/test/Driver/Inputs/basic_linux_libcxx_tree/usr/lib/x86_64-linux-gnu/.keep

Modified: 
clang/include/clang/Driver/ToolChain.h
clang/lib/Driver/ToolChain.cpp
clang/lib/Driver/ToolChains/Fuchsia.cpp
clang/test/Driver/fuchsia.cpp
clang/test/Driver/linux-per-target-runtime-dir.c
libcxx/CMakeLists.txt
libcxxabi/CMakeLists.txt
libunwind/CMakeLists.txt

Removed: 

clang/test/Driver/Inputs/basic_fuchsia_tree/lib/aarch64-fuchsia/c++/asan+noexcept/libc++.so

clang/test/Driver/Inputs/basic_fuchsia_tree/lib/aarch64-fuchsia/c++/asan/libc++.so

clang/test/Driver/Inputs/basic_fuchsia_tree/lib/aarch64-fuchsia/c++/libc++.so

clang/test/Driver/Inputs/basic_fuchsia_tree/lib/aarch64-fuchsia/c++/noexcept/libc++.so

clang/test/Driver/Inputs/basic_fuchsia_tree/lib/aarch64-fuchsia/c++/relative-vtables+noexcept/libc++.so

clang/test/Driver/Inputs/basic_fuchsia_tree/lib/aarch64-fuchsia/c++/relative-vtables/libc++.so

clang/test/Driver/Inputs/basic_fuchsia_tree/lib/x86_64-fuchsia/c++/asan+noexcept/libc++.so

clang/test/Driver/Inputs/basic_fuchsia_tree/lib/x86_64-fuchsia/c++/asan/libc++.so

clang/test/Driver/Inputs/basic_fuchsia_tree/lib/x86_64-fuchsia/c++/hwasan+noexcept/libc++.so

clang/test/Driver/Inputs/basic_fuchsia_tree/lib/x86_64-fuchsia/c++/hwasan/libc++.so
clang/test/Driver/Inputs/basic_fuchsia_tree/lib/x86_64-fuchsia/c++/libc++.so

clang/test/Driver/Inputs/basic_fuchsia_tree/lib/x86_64-fuchsia/c++/noexcept/libc++.so

clang/test/Driver/Inputs/basic_fuchsia_tree/lib/x86_64-fuchsia/c++/relative-vtables+asan+noexcept/libc++.so

clang/test/Driver/Inputs/basic_fuchsia_tree/lib/x86_64-fuchsia/c++/relative-vtables+asan/libc++.so

clang/test/Driver/Inputs/basic_fuchsia_tree/lib/x86_64-fuchsia/c++/relative-vtables+hwasan+noexcept/libc++.so

clang/test/Driver/Inputs/basic_fuchsia_tree/lib/x86_64-fuchsia/c++/relative-vtables+hwasan/libc++.so

clang/test/Driver/Inputs/basic_fuchsia_tree/lib/x86_64-fuchsia/c++/relative-vtables+noexcept/libc++.so

clang/test/Driver/Inputs/basic_fuchsia_tree/lib/x86_64-fuchsia/c++/relative-vtables/libc++.so

clang/test/Driver/Inputs/basic_linux_libcxx_tree/usr/lib/x86_64-linux-gnu/c++/.keep

clang/test/Driver/Inputs/resource_dir_with_per_target_subdir/lib/aarch64-fuchsia/asan/.keep

clang/test/Driver/Inputs/resource_dir_with_per_target_subdir/lib/aarch64-fuchsia/noexcept/.keep

clang/test/Driver/Inputs/resource_dir_with_per_target_subdir/lib/x86_64-fuchsia/asan/.keep

clang/test/Driver/Inputs/resource_dir_with_per_target_subdir/lib/x86_64-fuchsia/noexcept/.keep



diff  --git

[libunwind] f749550 - [libcxx] Stop using use c++ subdirectory for libc++ library

2021-04-21 Thread Petr Hosek via cfe-commits


Author: Petr Hosek
Date: 2021-04-21T15:39:03-07:00
New Revision: f749550cfe9f0bf2364abb2139835348587062ed

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

LOG: [libcxx] Stop using use c++ subdirectory for libc++ library

The new layout more closely matches the layout used by other compilers.
This is only used when LLVM_ENABLE_PER_TARGET_RUNTIME_DIR is enabled.

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

Added: 

clang/test/Driver/Inputs/basic_fuchsia_tree/lib/aarch64-fuchsia/asan+noexcept/libc++.so

clang/test/Driver/Inputs/basic_fuchsia_tree/lib/aarch64-fuchsia/asan/libc++.so
clang/test/Driver/Inputs/basic_fuchsia_tree/lib/aarch64-fuchsia/libc++.so

clang/test/Driver/Inputs/basic_fuchsia_tree/lib/aarch64-fuchsia/noexcept/libc++.so

clang/test/Driver/Inputs/basic_fuchsia_tree/lib/aarch64-fuchsia/relative-vtables+noexcept/libc++.so

clang/test/Driver/Inputs/basic_fuchsia_tree/lib/aarch64-fuchsia/relative-vtables/libc++.so

clang/test/Driver/Inputs/basic_fuchsia_tree/lib/x86_64-fuchsia/asan+noexcept/libc++.so

clang/test/Driver/Inputs/basic_fuchsia_tree/lib/x86_64-fuchsia/asan/libc++.so

clang/test/Driver/Inputs/basic_fuchsia_tree/lib/x86_64-fuchsia/hwasan+noexcept/libc++.so

clang/test/Driver/Inputs/basic_fuchsia_tree/lib/x86_64-fuchsia/hwasan/libc++.so
clang/test/Driver/Inputs/basic_fuchsia_tree/lib/x86_64-fuchsia/libc++.so

clang/test/Driver/Inputs/basic_fuchsia_tree/lib/x86_64-fuchsia/noexcept/libc++.so

clang/test/Driver/Inputs/basic_fuchsia_tree/lib/x86_64-fuchsia/relative-vtables+asan+noexcept/libc++.so

clang/test/Driver/Inputs/basic_fuchsia_tree/lib/x86_64-fuchsia/relative-vtables+asan/libc++.so

clang/test/Driver/Inputs/basic_fuchsia_tree/lib/x86_64-fuchsia/relative-vtables+hwasan+noexcept/libc++.so

clang/test/Driver/Inputs/basic_fuchsia_tree/lib/x86_64-fuchsia/relative-vtables+hwasan/libc++.so

clang/test/Driver/Inputs/basic_fuchsia_tree/lib/x86_64-fuchsia/relative-vtables+noexcept/libc++.so

clang/test/Driver/Inputs/basic_fuchsia_tree/lib/x86_64-fuchsia/relative-vtables/libc++.so

clang/test/Driver/Inputs/basic_linux_libcxx_tree/usr/lib/x86_64-linux-gnu/.keep

Modified: 
clang/include/clang/Driver/ToolChain.h
clang/lib/Driver/ToolChain.cpp
clang/lib/Driver/ToolChains/Fuchsia.cpp
clang/test/Driver/fuchsia.cpp
clang/test/Driver/linux-per-target-runtime-dir.c
libcxx/CMakeLists.txt
libcxxabi/CMakeLists.txt
libunwind/CMakeLists.txt

Removed: 

clang/test/Driver/Inputs/basic_fuchsia_tree/lib/aarch64-fuchsia/c++/asan+noexcept/libc++.so

clang/test/Driver/Inputs/basic_fuchsia_tree/lib/aarch64-fuchsia/c++/asan/libc++.so

clang/test/Driver/Inputs/basic_fuchsia_tree/lib/aarch64-fuchsia/c++/libc++.so

clang/test/Driver/Inputs/basic_fuchsia_tree/lib/aarch64-fuchsia/c++/noexcept/libc++.so

clang/test/Driver/Inputs/basic_fuchsia_tree/lib/aarch64-fuchsia/c++/relative-vtables+noexcept/libc++.so

clang/test/Driver/Inputs/basic_fuchsia_tree/lib/aarch64-fuchsia/c++/relative-vtables/libc++.so

clang/test/Driver/Inputs/basic_fuchsia_tree/lib/x86_64-fuchsia/c++/asan+noexcept/libc++.so

clang/test/Driver/Inputs/basic_fuchsia_tree/lib/x86_64-fuchsia/c++/asan/libc++.so

clang/test/Driver/Inputs/basic_fuchsia_tree/lib/x86_64-fuchsia/c++/hwasan+noexcept/libc++.so

clang/test/Driver/Inputs/basic_fuchsia_tree/lib/x86_64-fuchsia/c++/hwasan/libc++.so
clang/test/Driver/Inputs/basic_fuchsia_tree/lib/x86_64-fuchsia/c++/libc++.so

clang/test/Driver/Inputs/basic_fuchsia_tree/lib/x86_64-fuchsia/c++/noexcept/libc++.so

clang/test/Driver/Inputs/basic_fuchsia_tree/lib/x86_64-fuchsia/c++/relative-vtables+asan+noexcept/libc++.so

clang/test/Driver/Inputs/basic_fuchsia_tree/lib/x86_64-fuchsia/c++/relative-vtables+asan/libc++.so

clang/test/Driver/Inputs/basic_fuchsia_tree/lib/x86_64-fuchsia/c++/relative-vtables+hwasan+noexcept/libc++.so

clang/test/Driver/Inputs/basic_fuchsia_tree/lib/x86_64-fuchsia/c++/relative-vtables+hwasan/libc++.so

clang/test/Driver/Inputs/basic_fuchsia_tree/lib/x86_64-fuchsia/c++/relative-vtables+noexcept/libc++.so

clang/test/Driver/Inputs/basic_fuchsia_tree/lib/x86_64-fuchsia/c++/relative-vtables/libc++.so

clang/test/Driver/Inputs/basic_linux_libcxx_tree/usr/lib/x86_64-linux-gnu/c++/.keep

clang/test/Driver/Inputs/resource_dir_with_per_target_subdir/lib/aarch64-fuchsia/asan/.keep

clang/test/Driver/Inputs/resource_dir_with_per_target_subdir/lib/aarch64-fuchsia/noexcept/.keep

clang/test/Driver/Inputs/resource_dir_with_per_target_subdir/lib/x86_64-fuchsia/asan/.keep

clang/test/Driver/Inputs/resource_dir_with_per_target_subdir/lib/x86_64-fuchsia/noexcept/.keep



diff  --git

[PATCH] D99994: [CodeView] Add CodeView support for PGO debug information

2021-04-21 Thread Reid Kleckner via Phabricator via cfe-commits

rnk added a comment.

In D4#2706515 , @Holman wrote:

> Can someone help me get this checked in?

Sure, I went ahead and pushed it.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D4

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

[PATCH] D99994: [CodeView] Add CodeView support for PGO debug information

2021-04-21 Thread Reid Kleckner 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 rG77357208c46a: [CodeView] Add CodeView support for PGO debug 
information (authored by Holman, committed by rnk).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D4

Files:
  llvm/lib/CodeGen/AsmPrinter/CodeViewDebug.cpp
  llvm/test/DebugInfo/COFF/pgo.ll

Index: llvm/test/DebugInfo/COFF/pgo.ll
===
--- /dev/null
+++ llvm/test/DebugInfo/COFF/pgo.ll
@@ -0,0 +1,165 @@
+; RUN: llc < %s -filetype=obj | llvm-readobj --codeview - | FileCheck %s
+
+; CHECK: Compile3Sym {
+; CHECK:   Flags [ (0x4)
+; CHECK: PGO (0x4)
+
+; CHECK: DisplayName: foo
+; CHECK: Kind: S_FRAMEPROC (0x1012)
+; CHECK:   ProfileGuidedOptimization (0x4)
+; CHECK:   ValidProfileCounts (0x8)
+
+; CHECK: DisplayName: foo2
+; CHECK: Kind: S_FRAMEPROC (0x1012)
+; CHECK:   ProfileGuidedOptimization (0x4)
+; CHECK:   ValidProfileCounts (0x8)
+
+; CHECK: DisplayName: bar
+; CHECK: Kind: S_FRAMEPROC (0x1012)
+; CHECK:   ProfileGuidedOptimization (0x4)
+; CHECK:   ValidProfileCounts (0x8)
+
+; CHECK: DisplayName: main
+; CHECK: Kind: S_FRAMEPROC (0x1012)
+; CHECK-NOT:   ProfileGuidedOptimization (0x4)
+; CHECK-NOT:   ValidProfileCounts (0x8)
+
+source_filename = "pgo.cpp"
+target datalayout = "e-m:w-p270:32:32-p271:32:32-p272:64:64-i64:64-f80:128-n8:16:32:64-S128"
+target triple = "x86_64-pc-windows-msvc19.28.29912"
+
+define dso_local i32 @"?foo@@YAHH@Z"(i32 %b) local_unnamed_addr #1 !dbg !43 !prof !49 {
+entry:
+  call void @llvm.dbg.value(metadata i32 %b, metadata !48, metadata !DIExpression()), !dbg !50
+  %mul = mul nsw i32 %b, 10, !dbg !51
+  ret i32 %mul, !dbg !51
+}
+
+define dso_local i32 @"?foo2@@YAHH@Z"(i32 %a) local_unnamed_addr #1 !dbg !52 !prof !55 {
+entry:
+  call void @llvm.dbg.value(metadata i32 %a, metadata !54, metadata !DIExpression()), !dbg !56
+  %mul = mul nsw i32 %a, 5, !dbg !57
+  ret i32 %mul, !dbg !57
+}
+
+define dso_local i32 @"?bar@@YAHH@Z"(i32 %num) local_unnamed_addr #1 !dbg !58 !prof !55 {
+entry:
+  call void @llvm.dbg.value(metadata i32 undef, metadata !60, metadata !DIExpression()), !dbg !61
+  %call = tail call i32 @"?foo@@YAHH@Z"(i32 1) #1, !dbg !62
+  %call1 = tail call i32 @"?foo2@@YAHH@Z"(i32 2) #1, !dbg !62
+  %mul = mul nsw i32 %call1, %call, !dbg !62
+  %call2 = tail call i32 @"?foo2@@YAHH@Z"(i32 3) #1, !dbg !62
+  %mul3 = mul nsw i32 %mul, %call2, !dbg !62
+  ret i32 %mul3, !dbg !62
+}
+
+define dso_local i32 @main(i32 %argc, i8** nocapture readnone %argv) local_unnamed_addr #1 !dbg !63 !annotation !72 {
+entry:
+  call void @llvm.dbg.value(metadata i8** %argv, metadata !70, metadata !DIExpression()), !dbg !73
+  call void @llvm.dbg.value(metadata i32 %argc, metadata !71, metadata !DIExpression()), !dbg !73
+  %cmp = icmp eq i32 %argc, 2, !dbg !74
+  br i1 %cmp, label %return, label %if.end, !dbg !74
+
+if.end:   ; preds = %entry
+  %cmp1 = icmp slt i32 %argc, 5, !dbg !75
+  br i1 %cmp1, label %if.then2, label %if.else, !dbg !75
+
+if.then2: ; preds = %if.end
+  %call = tail call i32 @"?bar@@YAHH@Z"(i32 undef) #1, !dbg !76
+  br label %return, !dbg !76
+
+if.else:  ; preds = %if.end
+  %call3 = tail call i32 @"?foo@@YAHH@Z"(i32 %argc) #1, !dbg !79
+  br label %return, !dbg !79
+
+return:   ; preds = %entry, %if.else, %if.then2
+  %retval.0 = phi i32 [ %call, %if.then2 ], [ %call3, %if.else ], [ 0, %entry ], !dbg !73
+  ret i32 %retval.0, !dbg !81
+}
+
+declare void @llvm.dbg.value(metadata, metadata, metadata) #3
+
+attributes #1 = { optsize }
+
+!llvm.dbg.cu = !{!0}
+!llvm.module.flags = !{!5, !6, !7, !8, !9, !38}
+
+!0 = distinct !DICompileUnit(language: DW_LANG_C_plus_plus_14, file: !1, producer: "clang version 13.0.0", isOptimized: true, runtimeVersion: 0, emissionKind: FullDebug, enums: !2, splitDebugInlining: false, nameTableKind: None)
+!1 = !DIFile(filename: "pgo.cpp", directory: "")
+!2 = !{}
+!5 = !{i32 2, !"CodeView", i32 1}
+!6 = !{i32 2, !"Debug Info Version", i32 3}
+!7 = !{i32 1, !"wchar_size", i32 2}
+!8 = !{i32 7, !"PIC Level", i32 2}
+!9 = !{i32 1, !"ProfileSummary", !10}
+!10 = !{!11, !12, !13, !14, !15, !16, !17, !18, !19, !20}
+!11 = !{!"ProfileFormat", !"InstrProf"}
+!12 = !{!"TotalCount", i64 2}
+!13 = !{!"MaxCount", i64 1}
+!14 = !{!"MaxInternalCount", i64 1}
+!15 = !{!"MaxFunctionCount", i64 1}
+!16 = !{!"NumCounts", i64 5}
+!17 = !{!"NumFunctions", i64 4}
+!18 = !{!"IsPartialProfile", i64 0}
+!19 = !{!"PartialProfileRatio", double 0.00e+00}
+!20 = !{!"DetailedSummary", !21}
+!21 = !{!22, !23, !24, !25, !26, !27, !28, !29, !30, !31, !32, !33, !34, !35, !36, !37}
+!22 = !{i32 1, i64

[PATCH] D101000: Coverage: Document how to collect a profile without a filesystem

2021-04-21 Thread Vedant Kumar via Phabricator via cfe-commits

vsk added a subscriber: efriedma.
vsk added a comment.

Thanks for doing this!

+ Eli to comment on whether any workarounds documented in 
https://lists.llvm.org/pipermail/llvm-dev/2017-September/117156.html are still 
necessary. To my knowledge it's not currently necessary to explicitly pass 
-mllvm -enable-value-profiling=false (as value profiling should not be enabled 
under -fcoverage-mapping -fprofile-instr-generate). It should also not be 
necessary to shave .o's out of the runtime static archive; so long as the 
static initializer isn't linked, the linker shouldn't pull in any references to 
malloc, mmap, etc.




Comment at: clang/docs/SourceBasedCodeCoverage.rst:368
+
+In C++ files, declare these as ``extern "C"``.
+

I think we should leave a note about how to avoid pulling in unwanted symbol 
references, and perhaps reference the preceding section about using the runtime 
without its static initializer.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101000

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

[PATCH] D100611: [RISCV] Add new attribute __clang_riscv_builtin_alias for intrinsics.

2021-04-21 Thread Hsiangkai Wang via Phabricator via cfe-commits

HsiangKai added inline comments.



Comment at: clang/include/clang/Basic/AttrDocs.td:2147-2150
+This attribute can only be used to set up the aliases for certain RISC-V
+C intrinsic functions; it is intended for use only inside ``riscv_*.h``
+and is not a general mechanism for declaring arbitrary aliases for
+clang builtin functions.

aaron.ballman wrote:
> HsiangKai wrote:
> > HsiangKai wrote:
> > > aaron.ballman wrote:
> > > > Why a specific attribute for only one architecture rather than a more 
> > > > general solution that can be used for multiple architectures? We 
> > > > already have `__clang_arm_builtin_alias` (with the incorrect name, so I 
> > > > guess I see where you got the __ from) and now we're extending it. I am 
> > > > not certain if there's a reason why we should use a different attribute 
> > > > for each target though.
> > > I agree with you. We should not define the attribute as target specific. 
> > > This patch is a quick solution to address the issue 
> > > https://bugs.llvm.org/show_bug.cgi?id=49962.
> > > 
> > > I will refactor this patch and try to merge it with 
> > > `__clang_arm_builtin_alias` in some way.
> > @aaron.ballman Could we land this patch first to reduce the test time?
> > I agree with you that it is better to have one unified attribute for the 
> > purpose. However, if we change the attribute defined by ARM, we need to 
> > negotiate with them and there may be already some use cases in their users. 
> > I am not sure the impact of the modification.
> > 
> > I could modify my patch to make the attribute target independent and leave 
> > ARM's attribute as before. What do you think?
> As best I can tell, at least from the attribute that we surface for the 
> users, there shouldn't be much difference between the RISC-V and the ARM 
> attributes. They're both accepted on the same subjects, have the same 
> attribute arguments, and have the same semantic effect, etc. It seems like 
> the only difference is with semantic checking of whether the builtin is valid 
> for the architecture. Based on the assumption that these are effectively 
> doing the same thing, I'd rather we land the generic attribute so that we can 
> deprecate `__clang_arm_builtin_alias` in favor of the general attribute. If 
> we add `__clang_riscv_builtin_alias` before adding the generic attribute, 
> it's one more thing for us to deprecate and then remove.
> 
> Note, I'd be totally fine if the generic attribute only handles ARM and 
> RISC-V builtins initially (and error on the other architectures). We can add 
> support for other architectures as the need arises.
> 
> Do you think that approach makes sense?
It makes sense. I will integrate D100930 into this one.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100611

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

[PATCH] D101000: Coverage: Document how to collect a profile without a filesystem

2021-04-21 Thread Duncan P. N. Exon Smith via Phabricator via cfe-commits

dexonsmith created this revision.
dexonsmith added a reviewer: vsk.
dexonsmith requested review of this revision.
Herald added a project: clang.

The profiling runtime was designed to work without static initializers
or a a filesystem (see 117cf2bd1ff585f9754b5f30f5a4cfd65b230bbf and
others). The no-static-initializers part was already documented but this
part got missed before.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D101000

Files:
  clang/docs/SourceBasedCodeCoverage.rst


Index: clang/docs/SourceBasedCodeCoverage.rst
===
--- clang/docs/SourceBasedCodeCoverage.rst
+++ clang/docs/SourceBasedCodeCoverage.rst
@@ -346,6 +346,27 @@
 
 In C++ files, declare these as ``extern "C"``.
 
+Using the profiling runtime without a filesystem
+
+
+The profiling runtime also supports environments that lack a filesystem. Here's
+how to collect the profile into a buffer under your control:
+
+* Forward-declare ``uint64_t __llvm_profile_get_size_for_buffer(void)`` and
+  call it to determine the size of the profile. You'll need to allocate a
+  buffer of this size.
+
+* Forward-declare ``int __llvm_profile_write_buffer(char *Buffer)`` and call it
+  to copy the current counters to ``Buffer``, which is expected to already be
+  allocated and big enough for the profile.
+
+* Optionally, forward-declare ``void __llvm_profile_reset_counters(void)`` and
+  call it to reset the counters before entering a specific section to be
+  profiled. This is only useful if there is some setup that should be excluded
+  from the profile.
+
+In C++ files, declare these as ``extern "C"``.
+
 Collecting coverage reports for the llvm project
 
 


Index: clang/docs/SourceBasedCodeCoverage.rst
===
--- clang/docs/SourceBasedCodeCoverage.rst
+++ clang/docs/SourceBasedCodeCoverage.rst
@@ -346,6 +346,27 @@
 
 In C++ files, declare these as ``extern "C"``.
 
+Using the profiling runtime without a filesystem
+
+
+The profiling runtime also supports environments that lack a filesystem. Here's
+how to collect the profile into a buffer under your control:
+
+* Forward-declare ``uint64_t __llvm_profile_get_size_for_buffer(void)`` and
+  call it to determine the size of the profile. You'll need to allocate a
+  buffer of this size.
+
+* Forward-declare ``int __llvm_profile_write_buffer(char *Buffer)`` and call it
+  to copy the current counters to ``Buffer``, which is expected to already be
+  allocated and big enough for the profile.
+
+* Optionally, forward-declare ``void __llvm_profile_reset_counters(void)`` and
+  call it to reset the counters before entering a specific section to be
+  profiled. This is only useful if there is some setup that should be excluded
+  from the profile.
+
+In C++ files, declare these as ``extern "C"``.
+
 Collecting coverage reports for the llvm project
 
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D85802: [clang] Add -fc++-abi= flag for specifying which C++ ABI to use

2021-04-21 Thread Leonard Chan via Phabricator via cfe-commits

leonardchan added a comment.

I got LGTM for this before, but I'll leave it open for a few days to address 
any new comments folks might have.




Comment at: clang/lib/Frontend/CompilerInvocation.cpp:3523
+else
+  Opts.CXXABI = TargetCXXABI::getKind(CXXABI);
+  }

jansvoboda11 wrote:
> The original command-line arguments must be generated from this in 
> `GenerateLangArgs`. See 
> https://clang.llvm.org/docs/InternalsManual.html#compiler-invocation for more 
> details.
Could you clarify more on this? I'm guessing you mean I should use one of the 
Marshalling Options to set `Opts.CXXABI`, but none of them seem very fitting 
here. `MarshallingInfoEnum` looks to be the most appropriate, but I think using 
it will require manually copying all the string and enum values from 
`TargetCXXABI.def`. If possible, I'd like to avoid hardcoding the enums and 
strings in `TargetCXXABI.def` elsewhere so when another ABI gets added, we'd 
only need to change that .td file and not multiple other places.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D85802

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

[PATCH] D85802: [clang] Add -fc++-abi= flag for specifying which C++ ABI to use

2021-04-21 Thread Leonard Chan via Phabricator via cfe-commits

leonardchan updated this revision to Diff 339400.
This revision is now accepted and ready to land.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D85802

Files:
  clang/include/clang/AST/ASTContext.h
  clang/include/clang/Basic/DiagnosticDriverKinds.td
  clang/include/clang/Basic/LangOptions.h
  clang/include/clang/Basic/TargetCXXABI.def
  clang/include/clang/Basic/TargetCXXABI.h
  clang/include/clang/Driver/Options.td
  clang/lib/AST/ASTContext.cpp
  clang/lib/CodeGen/CodeGenModule.cpp
  clang/lib/CodeGen/ItaniumCXXABI.cpp
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Frontend/CompilerInvocation.cpp
  clang/test/Frontend/invalid-cxx-abi.cpp

Index: clang/test/Frontend/invalid-cxx-abi.cpp
===
--- /dev/null
+++ clang/test/Frontend/invalid-cxx-abi.cpp
@@ -0,0 +1,15 @@
+// These should succeed.
+// RUN: %clang -c -fc++-abi=itanium %s
+// RUN: %clang -c -fc++-abi=arm %s
+// RUN: %clang -c -fc++-abi=ios %s
+// RUN: %clang -c -fc++-abi=aarch64 %s
+// RUN: %clang -c -fc++-abi=mips %s
+// RUN: %clang -c -fc++-abi=webassembly %s
+// RUN: %clang -c -fc++-abi=fuchsia %s
+// RUN: %clang -c -fc++-abi=xl %s
+// RUN: %clang -c -fc++-abi=microsoft %s
+
+// RUN: not %clang -c -fc++-abi=InvalidABI %s 2>&1 | FileCheck %s -check-prefix=INVALID
+// RUN: not %clang -c -fc++-abi=Fuchsia %s 2>&1 | FileCheck %s -check-prefix=CASE-SENSITIVE
+// INVALID: error: Invalid C++ ABI name 'InvalidABI'
+// CASE-SENSITIVE: error: Invalid C++ ABI name 'Fuchsia'
Index: clang/lib/Frontend/CompilerInvocation.cpp
===
--- clang/lib/Frontend/CompilerInvocation.cpp
+++ clang/lib/Frontend/CompilerInvocation.cpp
@@ -3989,6 +3989,15 @@
 }
   }
 
+  // The value can be empty, which indicates the system default should be used.
+  StringRef CXXABI = Args.getLastArgValue(OPT_fcxx_abi_EQ);
+  if (!CXXABI.empty()) {
+if (!TargetCXXABI::isABI(CXXABI))
+  Diags.Report(diag::err_invalid_cxx_abi) << CXXABI;
+else
+  Opts.CXXABI = TargetCXXABI::getKind(CXXABI);
+  }
+
   return Diags.getNumErrors() == NumErrorsBefore;
 }
 
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -5307,6 +5307,9 @@
/*Default=*/false))
 Args.AddLastArg(CmdArgs, options::OPT_ffixed_point);
 
+  if (Arg *A = Args.getLastArg(options::OPT_fcxx_abi_EQ))
+A->render(Args, CmdArgs);
+
   // Handle -{std, ansi, trigraphs} -- take the last of -{std, ansi}
   // (-ansi is equivalent to -std=c89 or -std=c++98).
   //
Index: clang/lib/CodeGen/ItaniumCXXABI.cpp
===
--- clang/lib/CodeGen/ItaniumCXXABI.cpp
+++ clang/lib/CodeGen/ItaniumCXXABI.cpp
@@ -546,7 +546,7 @@
 }
 
 CodeGen::CGCXXABI *CodeGen::CreateItaniumCXXABI(CodeGenModule ) {
-  switch (CGM.getTarget().getCXXABI().getKind()) {
+  switch (CGM.getContext().getCXXABIKind()) {
   // For IR-generation purposes, there's no significant difference
   // between the ARM and iOS ABIs.
   case TargetCXXABI::GenericARM:
Index: clang/lib/CodeGen/CodeGenModule.cpp
===
--- clang/lib/CodeGen/CodeGenModule.cpp
+++ clang/lib/CodeGen/CodeGenModule.cpp
@@ -75,7 +75,7 @@
 static const char AnnotationSection[] = "llvm.metadata";
 
 static CGCXXABI *createCXXABI(CodeGenModule ) {
-  switch (CGM.getTarget().getCXXABI().getKind()) {
+  switch (CGM.getContext().getCXXABIKind()) {
   case TargetCXXABI::AppleARM64:
   case TargetCXXABI::Fuchsia:
   case TargetCXXABI::GenericAArch64:
Index: clang/lib/AST/ASTContext.cpp
===
--- clang/lib/AST/ASTContext.cpp
+++ clang/lib/AST/ASTContext.cpp
@@ -880,10 +880,15 @@
   return CanonTTP;
 }
 
+TargetCXXABI::Kind ASTContext::getCXXABIKind() const {
+  auto Kind = getTargetInfo().getCXXABI().getKind();
+  return getLangOpts().CXXABI.getValueOr(Kind);
+}
+
 CXXABI *ASTContext::createCXXABI(const TargetInfo ) {
   if (!LangOpts.CPlusPlus) return nullptr;
 
-  switch (T.getCXXABI().getKind()) {
+  switch (getCXXABIKind()) {
   case TargetCXXABI::AppleARM64:
   case TargetCXXABI::Fuchsia:
   case TargetCXXABI::GenericARM: // Same as Itanium at this level
Index: clang/include/clang/Driver/Options.td
===
--- clang/include/clang/Driver/Options.td
+++ clang/include/clang/Driver/Options.td
@@ -1878,6 +1878,10 @@
   PosFlag, NegFlag,
   BothFlags<[CC1Option], " the experimental C++ class ABI for classes with virtual tables">>;
 
+def fcxx_abi_EQ : Joined<["-"], "fc++-abi=">,
+  Group, Flags<[CC1Option]>,
+  HelpText<"C++ ABI to use. This will override

[PATCH] D93031: Enable fexec-charset option

2021-04-21 Thread Corentin Jabot via Phabricator via cfe-commits

cor3ntin added a comment.

>> We should use the original source form of the string literal when 
>> pretty-printing a `StringLiteral` or `CharacterLiteral`; there are a bunch 
>> of UTF-8 assumptions baked into `StmtPrinter` that will need revisiting. And 
>> we'll need to modify the handful of places that put the contents of 
>> `StringLiteral`s into diagnostics (`#warning`, `#error`, `static_assert`) 
>> and make them use a different `ConversionState`, since our assumption is 
>> that diagnostic output should be in UTF-8.
>
> Yes, these are some of the complications we will need to visit in later 
> patches. We may need to somehow save the original string or reverse the 
> translation.

The operation is destructive and therefore cannot be reverted.
So I do believe the correct behavior here would indeed be to keep the original 
spelling around - with *some* of phase 5 applied (replacement of UCNs and 
replacement of numeric escape sequences.
An alternative would be to do the conversion lazily when the strings are 
evaluated, rather than during lexing, although that might be more involved


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93031

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

[PATCH] D45639: [Driver] Support default libc++ library location on Darwin

2021-04-21 Thread Louis Dionne via Phabricator via cfe-commits

ldionne added a comment.

In D45639#2706589 , @dexonsmith wrote:

> I'm not sure I'm totally following, but just want to double check that the 
> tests won't somehow use the libc++ from the SDK instead of ToT? I guess the 
> test uses `-nostdinc++` or something?
>
> Assuming that's doing what we want... I also wanted to highlight this adds a 
> dependency on bot's host clang working with the ToT libc++ headers. That's 
> probably fine -- I assume we keep the bot's Xcode relatively up-to-date -- 
> but I know @ldionne at some point was trying to avoid requiring new libc++ to 
> work with older clangs.

LLDB should either use the libc++ headers from the SDK *and* the dylib from the 
SDK, or build libc++ from scratch and test against both the trunk headers and 
the trunk dylib built for their target, not for the host as they seem to do 
right now. I'm following offline with @JDevlieghere to try and disentangle that.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D45639

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

[PATCH] D100739: [Coroutines] Handle overaligned frame allocation (2)

2021-04-21 Thread Xun Li via Phabricator via cfe-commits

lxfind added inline comments.



Comment at: clang/docs/LanguageExtensions.rst:2689
 
-  size_t __builtin_coro_size()
+  size_t __builtin_coro_size(bool alloc)
   void  *__builtin_coro_frame()

ChuanqiXu wrote:
> ychen wrote:
> > ChuanqiXu wrote:
> > > ychen wrote:
> > > > lxfind wrote:
> > > > > Do we need to change __builtin_coro_size? The argument will always be 
> > > > > 1, right?
> > > > > It only starts to change in LLVM intrinsics, if I read the impl 
> > > > > correctly.
> > > > Yeah, It is always 1 for Clang until the spec is fixed (then we could 
> > > > revert it back to 0).  Other clients using `__builtin_coro_size` may 
> > > > use 0 if the client doesn't care about overaligned frame or it could 
> > > > handle overaligned frame by itself. 
> > > BTW, is it OK to edit the `builtin`s directly? Since builtin is different 
> > > with intrinsic which is only visible in the internal of compiler, builtin 
> > > could be used by any end users. Although I know there should be  little 
> > > users who would use `__builtin_coro` APIs, I worry if there is any guide 
> > > principle for editing the `builtin`s.
> > > BTW, is it OK to edit the builtins directly? Since builtin is different 
> > > with intrinsic which is only visible in the internal of compiler, builtin 
> > > could be used by any end users. Although I know there should be little 
> > > users who would use __builtin_coro APIs, I worry if there is any guide 
> > > principle for editing the builtins.
> > 
> > I think it is ok to change these if it is justified like anything else.
> > 
> > builtins/intrinsics are interfaces on different levels. I'm trying to make 
> > __builtin_coro_size consistent with llvm.coro.size because I don't have a 
> > good reason for not doing that. (assume that we keep this opt-in 
> > overaligned frame handling in LLVM even after the spec is fixed since it 
> > helps solve a practical problem and the maintenance cost is low)
> > 
> > 
> It doesn't make sense to me that we need to change the signature for 
> `__builtin_coro_size` in this patch. In other words, why do we need to change 
> `__builtin_coro_size `? What are problems that can't be solved if we don't 
> change `__builtin_coro_size`? At least, if it is necessary to change 
> `__builtin_coro_size`, we could make it in successive patches.
Yeah I agree with ChuanqiXu, there is no need to make the builtin to be exactly 
the same as the llvm intrinsics just because they have the same name. Many of 
them are different even though they have the same name.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100739

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

[PATCH] D45639: [Driver] Support default libc++ library location on Darwin

2021-04-21 Thread Duncan P. N. Exon Smith via Phabricator via cfe-commits

dexonsmith added a comment.

> No, the bot is also meant to catch changes to libc++ breaking LLDB (or at 
> least making sure we update the corresponding data formatters).



> Given that these tests are macOS specific and already require a specific SDK, 
> I'll just update them to use the compiler from the SDK instead of the 
> just-built one.

I'm not sure I'm totally following, but just want to double check that the 
tests won't somehow use the libc++ from the SDK instead of ToT? I guess the 
test uses `-nostdinc++` or something?

Assuming that's doing what we want... I also wanted to highlight this adds a 
dependency on bot's host clang working with the ToT libc++ headers. That's 
probably fine -- I assume we keep the bot's Xcode relatively up-to-date -- but 
I know @ldionne at some point was trying to avoid requiring new libc++ to work 
with older clangs.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D45639

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

[PATCH] D100581: [Clang] -Wunused-but-set-parameter and -Wunused-but-set-variable

2021-04-21 Thread David Blaikie via Phabricator via cfe-commits

dblaikie added a comment.

In D100581#2706554 , @xbolva00 wrote:

> In D100581#2706467 , @dblaikie 
> wrote:
>
>> FWIW, I'd love it if we could do a full dead-store warning, which would be a 
>> superset of this. I think we have enough infrastructure in the analysis 
>> based warnings (I think the sufficiency of the infrastructure is 
>> demonstrated by the "may be used uninitialized" warnings). Such a warning 
>> would subsume these narrower "set but not used" type of warnings (though 
>> would require the analysis warning infrastructure).
>
>
>
> - Compile time cost could be a problem.

Given that we managed to enable -Wsometimes-uninitialized, which is a 
CFG-sensitive warning under -Wall:

  $ clang++-tot maybe-uninit.cpp -Wall -c
  maybe-uninit.cpp:4:7: warning: variable 'i' is used uninitialized whenever 
'if' condition is false [-Wsometimes-uninitialized]
if (b)
^
  maybe-uninit.cpp:6:6: note: uninitialized use occurs here
f1(i);
   ^
  maybe-uninit.cpp:4:3: note: remove the 'if' if its condition is always true
if (b)
^~
  maybe-uninit.cpp:3:8: note: initialize the variable 'i' to silence this 
warning
int i;
 ^
  = 0
  1 warning generated.

Then I think similar infrastructure could be used to implement a dead-store 
warning too.

> - Do we need stronger dead store warning? Clang analyzer checks for dead 
> stores, no?

Catching something at compile time's a fair bit of increased value over using 
the static analyzer (at least at Google we don't use the static analyzer, for 
instance)

Oh, right - https://bugs.llvm.org/show_bug.cgi?id=24506 documents one of the 
cases that came up that I think a dead store warning would be rather helpful at 
catching. (though I think we probably now catch the int case 
-Wzero-as-null-pointer-constant - though that's not on by default, for instance 
because it's too pervasive, but a dead store warning would catch the buggy case 
without require a stylistic change to a whole codebase - and also a dead store 
warning could catch the case with, say a T** parameter where you mean to set 
the caller's value to nullptr, but instead set the local copy to nullptr) - in 
these simple examples unused-but-set catches them, but it's not uncommon to 
test a parameter for non-null before writing, for instance you might mean "if 
(x) *x = nullptr" but write "if (x) x = nullptr" - dead store would catch that 
but unused-but-set would not.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100581

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

[PATCH] D100968: Update shebang for clang-format-diff script to python3.

2021-04-21 Thread Fangrui Song via Phabricator via cfe-commits

MaskRay added a comment.

Still LG:)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100968

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

[PATCH] D100581: [Clang] -Wunused-but-set-parameter and -Wunused-but-set-variable

2021-04-21 Thread Dávid Bolvanský via Phabricator via cfe-commits

xbolva00 added a comment.

In D100581#2706467 , @dblaikie wrote:

> FWIW, I'd love it if we could do a full dead-store warning, which would be a 
> superset of this. I think we have enough infrastructure in the analysis based 
> warnings (I think the sufficiency of the infrastructure is demonstrated by 
> the "may be used uninitialized" warnings). Such a warning would subsume these 
> narrower "set but not used" type of warnings (though would require the 
> analysis warning infrastructure).



- Compile time cost could be a problem.
- Do we need stronger dead store warning? Clang analyzer checks for dead 
stores, no?

I would rather have this on by default with -Wall, than something stronger off 
by default


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100581

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

[PATCH] D45639: [Driver] Support default libc++ library location on Darwin

2021-04-21 Thread Jonas Devlieghere via Phabricator via cfe-commits

JDevlieghere added a comment.

In D45639#2706364 , @JDevlieghere 
wrote:

> Given that these tests are macOS specific and already require a specific SDK, 
> I'll just update them to use the compiler from the SDK instead of the 
> just-built one.

Done in 5d1c43f333c2327be61604dc90ea675f0d1e6913 
 and 
reverted my revert (i.e. re-landed your change in 
6331680ad2ad000fdaf7e72f3c1880c7908ffa25 
).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D45639

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

[clang] 6331680 - Re-land "[Driver] Support default libc++ library location on Darwin"

2021-04-21 Thread Jonas Devlieghere via cfe-commits


Author: Jonas Devlieghere
Date: 2021-04-21T14:22:13-07:00
New Revision: 6331680ad2ad000fdaf7e72f3c1880c7908ffa25

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

LOG: Re-land "[Driver] Support default libc++ library location on Darwin"

This reverts commit 05eeed9691aeb3e0316712195b998e9078cdceb0 and after
fixing the impacted lldb tests in 5d1c43f333c2327be61604dc90ea675f0d1e6913.

  [Driver] Support default libc++ library location on Darwin

  Darwin driver currently uses libc++ headers that are part of Clang
  toolchain when available (by default ../include/c++/v1 relative to
  executable), but it completely ignores the libc++ library itself
  because it doesn't pass the location of libc++ library that's part
  of Clang (by default ../lib relative to the exceutable) to the linker
  always using the system copy of libc++.

  This may lead to subtle issues when the compilation fails because the
  headers that are part of Clang toolchain are incompatible with the
  system library. Either the driver should ignore both headers as well as
  the library, or it should always try to use both when available.

  This patch changes the driver behavior to do the latter which seems more
  reasonable, it makes it easy to test and use custom libc++ build on
  Darwin while still allowing the use of system version. This also matches
  the Clang driver behavior on other systems.

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

Added: 


Modified: 
clang/lib/Driver/ToolChains/Darwin.cpp
clang/test/Driver/darwin-ld.c

Removed: 




diff  --git a/clang/lib/Driver/ToolChains/Darwin.cpp 
b/clang/lib/Driver/ToolChains/Darwin.cpp
index bc59b6beafc7..06d4f2f4df0b 100644
--- a/clang/lib/Driver/ToolChains/Darwin.cpp
+++ b/clang/lib/Driver/ToolChains/Darwin.cpp
@@ -615,6 +615,8 @@ void darwin::Linker::ConstructJob(Compilation , const 
JobAction ,
 
   Args.AddAllArgs(CmdArgs, options::OPT_L);
 
+  getToolChain().AddFilePathLibArgs(Args, CmdArgs);
+
   AddLinkerInputs(getToolChain(), Inputs, Args, CmdArgs, JA);
   // Build the input file for -filelist (list of linker input files) in case we
   // need it later
@@ -802,6 +804,7 @@ MachO::MachO(const Driver , const llvm::Triple , 
const ArgList )
   getProgramPaths().push_back(getDriver().getInstalledDir());
   if (getDriver().getInstalledDir() != getDriver().Dir)
 getProgramPaths().push_back(getDriver().Dir);
+  getFilePaths().push_back(getDriver().Dir + "/../lib");
 }
 
 /// Darwin - Darwin tool chain for i386 and x86_64.

diff  --git a/clang/test/Driver/darwin-ld.c b/clang/test/Driver/darwin-ld.c
index 15e5d100afcb..9fe68f1821c9 100644
--- a/clang/test/Driver/darwin-ld.c
+++ b/clang/test/Driver/darwin-ld.c
@@ -365,3 +365,7 @@
 // RUN: FileCheck -check-prefix=MNO_OUTLINE %s < %t.log
 // MNO_OUTLINE: {{ld(.exe)?"}}
 // MNO_OUTLINE-SAME: "-mllvm" "-enable-machine-outliner=never"
+
+// RUN: %clang -target x86_64-apple-darwin10 -### %t.o 2> %t.log
+// RUN: FileCheck -check-prefix=INSTALL-DIR %s < %t.log
+// INSTALL-DIR: "-L{{.*}}{{/|}}..{{/|}}lib"



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

[clang] 5a2d78b - [HIP] Add option -fgpu-inline-threshold

2021-04-21 Thread Yaxun Liu via cfe-commits


Author: Yaxun (Sam) Liu
Date: 2021-04-21T17:18:18-04:00
New Revision: 5a2d78b1639738fbde85248413c1cfd2df55683a

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

LOG: [HIP] Add option -fgpu-inline-threshold

Add option -fgpu-inline-threshold for inline threshold for device compilation 
only.

Reviewed by: Artem Belevich

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

Added: 


Modified: 
clang/include/clang/Driver/Options.td
clang/lib/Driver/ToolChains/Clang.cpp
clang/test/Driver/hip-options.hip

Removed: 




diff  --git a/clang/include/clang/Driver/Options.td 
b/clang/include/clang/Driver/Options.td
index 648cfb0522e14..d17486b13504d 100644
--- a/clang/include/clang/Driver/Options.td
+++ b/clang/include/clang/Driver/Options.td
@@ -956,6 +956,9 @@ def gpu_max_threads_per_block_EQ : Joined<["--"], 
"gpu-max-threads-per-block=">,
   HelpText<"Default max threads per block for kernel launch bounds for HIP">,
   MarshallingInfoInt, "1024">,
   ShouldParseIf;
+def fgpu_inline_threshold_EQ : Joined<["-"], "fgpu-inline-threshold=">,
+  Flags<[HelpHidden]>,
+  HelpText<"Inline threshold for device compilation for CUDA/HIP">;
 def gpu_instrument_lib_EQ : Joined<["--"], "gpu-instrument-lib=">,
   HelpText<"Instrument device library for HIP, which is a LLVM bitcode 
containing "
   "__cyg_profile_func_enter and __cyg_profile_func_exit">;

diff  --git a/clang/lib/Driver/ToolChains/Clang.cpp 
b/clang/lib/Driver/ToolChains/Clang.cpp
index 95ca99565351c..ddfdda82193fa 100644
--- a/clang/lib/Driver/ToolChains/Clang.cpp
+++ b/clang/lib/Driver/ToolChains/Clang.cpp
@@ -6473,6 +6473,16 @@ void Clang::ConstructJob(Compilation , const JobAction 
,
   if (IsHIP)
 CmdArgs.push_back("-fcuda-allow-variadic-functions");
 
+  if (IsCudaDevice || IsHIPDevice) {
+StringRef InlineThresh =
+Args.getLastArgValue(options::OPT_fgpu_inline_threshold_EQ);
+if (!InlineThresh.empty()) {
+  std::string ArgStr =
+  std::string("-inline-threshold=") + InlineThresh.str();
+  CmdArgs.append({"-mllvm", Args.MakeArgStringRef(ArgStr)});
+}
+  }
+
   // OpenMP offloading device jobs take the argument -fopenmp-host-ir-file-path
   // to specify the result of the compile phase on the host, so the meaningful
   // device declarations can be identified. Also, -fopenmp-is-device is passed

diff  --git a/clang/test/Driver/hip-options.hip 
b/clang/test/Driver/hip-options.hip
index 99e9f0c247198..b592a9c837528 100644
--- a/clang/test/Driver/hip-options.hip
+++ b/clang/test/Driver/hip-options.hip
@@ -51,3 +51,8 @@
 // RUN:   --cuda-gpu-arch=gfx906  %s 2>&1 | FileCheck -check-prefix=CTA %s
 // CTA: clang{{.*}} "-triple" "x86_64-unknown-linux-gnu" {{.*}} 
"-mconstructor-aliases"
 // CTA-NOT: clang{{.*}} "-triple" "amdgcn-amd-amdhsa" {{.*}} 
"-mconstructor-aliases"
+
+// RUN: %clang -### -target x86_64-unknown-linux-gnu -nogpuinc -nogpulib \
+// RUN:   --offload-arch=gfx906 -fgpu-inline-threshold=1000 %s 2>&1 | 
FileCheck -check-prefix=THRESH %s
+// THRESH: clang{{.*}} "-triple" "amdgcn-amd-amdhsa" {{.*}} "-mllvm" 
"-inline-threshold=1000"
+// THRESH-NOT: clang{{.*}} "-triple" "x86_64-unknown-linux-gnu" {{.*}} 
"-inline-threshold=1000"



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

[PATCH] D99233: [HIP] Add option -fgpu-inline-threshold

2021-04-21 Thread Yaxun Liu 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 rG5a2d78b16397: [HIP] Add option -fgpu-inline-threshold 
(authored by yaxunl).
Herald added a project: clang.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99233

Files:
  clang/include/clang/Driver/Options.td
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/test/Driver/hip-options.hip


Index: clang/test/Driver/hip-options.hip
===
--- clang/test/Driver/hip-options.hip
+++ clang/test/Driver/hip-options.hip
@@ -51,3 +51,8 @@
 // RUN:   --cuda-gpu-arch=gfx906  %s 2>&1 | FileCheck -check-prefix=CTA %s
 // CTA: clang{{.*}} "-triple" "x86_64-unknown-linux-gnu" {{.*}} 
"-mconstructor-aliases"
 // CTA-NOT: clang{{.*}} "-triple" "amdgcn-amd-amdhsa" {{.*}} 
"-mconstructor-aliases"
+
+// RUN: %clang -### -target x86_64-unknown-linux-gnu -nogpuinc -nogpulib \
+// RUN:   --offload-arch=gfx906 -fgpu-inline-threshold=1000 %s 2>&1 | 
FileCheck -check-prefix=THRESH %s
+// THRESH: clang{{.*}} "-triple" "amdgcn-amd-amdhsa" {{.*}} "-mllvm" 
"-inline-threshold=1000"
+// THRESH-NOT: clang{{.*}} "-triple" "x86_64-unknown-linux-gnu" {{.*}} 
"-inline-threshold=1000"
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -6473,6 +6473,16 @@
   if (IsHIP)
 CmdArgs.push_back("-fcuda-allow-variadic-functions");
 
+  if (IsCudaDevice || IsHIPDevice) {
+StringRef InlineThresh =
+Args.getLastArgValue(options::OPT_fgpu_inline_threshold_EQ);
+if (!InlineThresh.empty()) {
+  std::string ArgStr =
+  std::string("-inline-threshold=") + InlineThresh.str();
+  CmdArgs.append({"-mllvm", Args.MakeArgStringRef(ArgStr)});
+}
+  }
+
   // OpenMP offloading device jobs take the argument -fopenmp-host-ir-file-path
   // to specify the result of the compile phase on the host, so the meaningful
   // device declarations can be identified. Also, -fopenmp-is-device is passed
Index: clang/include/clang/Driver/Options.td
===
--- clang/include/clang/Driver/Options.td
+++ clang/include/clang/Driver/Options.td
@@ -956,6 +956,9 @@
   HelpText<"Default max threads per block for kernel launch bounds for HIP">,
   MarshallingInfoInt, "1024">,
   ShouldParseIf;
+def fgpu_inline_threshold_EQ : Joined<["-"], "fgpu-inline-threshold=">,
+  Flags<[HelpHidden]>,
+  HelpText<"Inline threshold for device compilation for CUDA/HIP">;
 def gpu_instrument_lib_EQ : Joined<["--"], "gpu-instrument-lib=">,
   HelpText<"Instrument device library for HIP, which is a LLVM bitcode 
containing "
   "__cyg_profile_func_enter and __cyg_profile_func_exit">;


Index: clang/test/Driver/hip-options.hip
===
--- clang/test/Driver/hip-options.hip
+++ clang/test/Driver/hip-options.hip
@@ -51,3 +51,8 @@
 // RUN:   --cuda-gpu-arch=gfx906  %s 2>&1 | FileCheck -check-prefix=CTA %s
 // CTA: clang{{.*}} "-triple" "x86_64-unknown-linux-gnu" {{.*}} "-mconstructor-aliases"
 // CTA-NOT: clang{{.*}} "-triple" "amdgcn-amd-amdhsa" {{.*}} "-mconstructor-aliases"
+
+// RUN: %clang -### -target x86_64-unknown-linux-gnu -nogpuinc -nogpulib \
+// RUN:   --offload-arch=gfx906 -fgpu-inline-threshold=1000 %s 2>&1 | FileCheck -check-prefix=THRESH %s
+// THRESH: clang{{.*}} "-triple" "amdgcn-amd-amdhsa" {{.*}} "-mllvm" "-inline-threshold=1000"
+// THRESH-NOT: clang{{.*}} "-triple" "x86_64-unknown-linux-gnu" {{.*}} "-inline-threshold=1000"
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -6473,6 +6473,16 @@
   if (IsHIP)
 CmdArgs.push_back("-fcuda-allow-variadic-functions");
 
+  if (IsCudaDevice || IsHIPDevice) {
+StringRef InlineThresh =
+Args.getLastArgValue(options::OPT_fgpu_inline_threshold_EQ);
+if (!InlineThresh.empty()) {
+  std::string ArgStr =
+  std::string("-inline-threshold=") + InlineThresh.str();
+  CmdArgs.append({"-mllvm", Args.MakeArgStringRef(ArgStr)});
+}
+  }
+
   // OpenMP offloading device jobs take the argument -fopenmp-host-ir-file-path
   // to specify the result of the compile phase on the host, so the meaningful
   // device declarations can be identified. Also, -fopenmp-is-device is passed
Index: clang/include/clang/Driver/Options.td
===
--- clang/include/clang/Driver/Options.td
+++ clang/include/clang/Driver/Options.td
@@ -956,6 +956,9 @@
   HelpText<"Default max threads per block for kernel launch bounds for HIP">,
   MarshallingInfoInt,

[PATCH] D99994: [CodeView] Add CodeView support for PGO debug information

2021-04-21 Thread Michael Holman via Phabricator via cfe-commits

Holman added a comment.

Can someone help me get this checked in?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D4

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

[PATCH] D99983: Provide TreeTransform::TransformAttr the transformed statement; NFC

2021-04-21 Thread Josh Haberman via Phabricator via cfe-commits

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

This seems fine to me, but I'll defer to @rsmith for final review.


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

https://reviews.llvm.org/D99983

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

[PATCH] D100581: [Clang] -Wunused-but-set-parameter and -Wunused-but-set-variable

2021-04-21 Thread David Blaikie via Phabricator via cfe-commits

dblaikie added a comment.

FWIW, I'd love it if we could do a full dead-store warning, which would be a 
superset of this. I think we have enough infrastructure in the analysis based 
warnings (I think the sufficiency of the infrastructure is demonstrated by the 
"may be used uninitialized" warnings). Such a warning would subsume these 
narrower "set but not used" type of warnings (though would require the analysis 
warning infrastructure).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100581

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

[PATCH] D99299: Normalize interaction with boolean attributes

2021-04-21 Thread David Blaikie via Phabricator via cfe-commits

dblaikie added inline comments.



Comment at: llvm/lib/IR/Attributes.cpp:660-663
+bool AttributeImpl::getValueAsBool() const {
+  assert(getValueAsString().empty() || getValueAsString() == "false" || 
getValueAsString() == "true");
+  return getValueAsString() == "true";
+}

Is it maybe worth using named constants rather than string literals, so this 
true and false matches up with the true/false in StrBoolAttr? (I assume that's 
where these strings are produced?)



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99299

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

[PATCH] D100466: clang-format: [JS] merge import lines.

2021-04-21 Thread Jorge Gorbe Moya via Phabricator via cfe-commits

jgorbe added a comment.

Hi, one of our tests is failing because of this patch and it looks like an 
actual bug. clang-format now turns this file:

  import './a';
  import {bar} from './a';

into this:

  barimport './a';


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100466

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

[PATCH] D45639: [Driver] Support default libc++ library location on Darwin

2021-04-21 Thread Jonas Devlieghere via Phabricator via cfe-commits

JDevlieghere added a comment.

Given that these tests are macOS specific and already require a specific SDK, 
I'll just update them to use the compiler from the SDK instead of the 
just-built one.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D45639

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

[PATCH] D98450: [clang] store an identifer instead of declref for ns_error_domain attribute

2021-04-21 Thread Aaron Ballman via Phabricator via cfe-commits

aaron.ballman added a comment.

In D98450#2699970 , @arphaman wrote:

> Your argument makes sense. The problem right now is that clang doesn't allow 
> the name to be used even when the user marks up availability correctly trying 
> to guard the use of the declaration. This stems from the combination of this 
> macro in Foundation:
>
>   #define NS_ERROR_ENUM(_type, _name, _domain)  \
> enum _name : _type _name; enum __attribute__((ns_error_domain(_domain))) 
> _name : _type
>
> and the fact that when the user uses it like this:
>
>   API_AVAILABLE(ios(14.0)) API_UNAVAILABLE(macos, tvos)
>   typedef NS_ERROR_ENUM(NIErrorDomain, NIErrorCode) {
>   NIErrorA = 1,
>   };

Is there an argument missing to `NS_ERROR_ENUM`? I don't see it passing the 
domain.

> which is equivalent to:
>
>   __attribute__((availability(ios,introduced=14.0))) 
> __attribute__((availability(macos,unavailable))) 
> __attribute__((availability(tvos,unavailable)))
>   NSErrorDomain const NIErrorDomain;
>   
>   __attribute__((availability(ios,introduced=14.0))) 
> __attribute__((availability(macos,unavailable))) 
> __attribute__((availability(tvos,unavailable)))
>   typedef enum NIErrorCode : NSInteger NIErrorCode; enum 
> __attribute__((ns_error_domain(NIErrorDomain))) NIErrorCode : NSInteger {
>NIErrorA = 1
>   };
>
> In this case clang doesn't know about availability on the `NIErrorDomain` 
> declaration as it's placed on the typedef, so it reports the diagnostic that 
> `NIErrorDomain` is unavailable for macOS, even though from users perspective 
> the use is guarded correctly by the `API_UNAVAILABLE(macos, tvOS)` before the 
> NS_ERROR_ENUM macro.

Ah, thank you for the detailed explanation!

In D98450#260 , @arphaman wrote:

> I'm thinking maybe we could have an attribute that transcribes the 
> availability from the typedef to the enum, e.g.
>
>   #define NS_ERROR_ENUM(_type, _name, _domain)  \
> enum _name : _type _name; enum 
> __attribute__((transcribe_availability(_name))) 
> __attribute__((ns_error_domain(_domain))) _name : _type
>
> in that case we could teach clang that the enum should take the availability 
> attributes from the typedef and apply to the enum, which should solve the use 
> problem in the `ns_error_domain` attribute. Or potentially clang could try to 
> infer it without the new attribute just by detecting this code pattern. WDYT?

I am mostly ignorant of the availability attributes, but do you think this 
functionality would be generally useful for effectively being able to say "make 
this declaration as available as this other declaration"? e.g., if you have a 
structure and a function that are used together, you can say:

  struct __attribute__((availability(...))) S { ... };
  __attribute__((transcribe_availability(S))) void func(struct S  s);

If the attribute is generally useful, then I think it would be better to add an 
explicit attribute. That also helps tools like static analyzers or AST matchers 
to make the connection between the availabilities, which would be harder if the 
information was inferred by the frontend.


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

https://reviews.llvm.org/D98450

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

[PATCH] D93031: Enable fexec-charset option

2021-04-21 Thread Abhina Sree via Phabricator via cfe-commits

abhina.sreeskantharajan updated this revision to Diff 339355.
abhina.sreeskantharajan added a reviewer: ThePhD.
abhina.sreeskantharajan added a comment.

Thanks for catching that. This sets the   __clang_literal_encoding__ to 
Opts.ExecCharset or defaults to SystemCharset.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93031

Files:
  clang/docs/LanguageExtensions.rst
  clang/include/clang/Basic/LangOptions.h
  clang/include/clang/Basic/TokenKinds.h
  clang/include/clang/Driver/Options.td
  clang/include/clang/Lex/LiteralConverter.h
  clang/include/clang/Lex/LiteralSupport.h
  clang/include/clang/Lex/Preprocessor.h
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Frontend/CompilerInstance.cpp
  clang/lib/Frontend/InitPreprocessor.cpp
  clang/lib/Lex/CMakeLists.txt
  clang/lib/Lex/LiteralConverter.cpp
  clang/lib/Lex/LiteralSupport.cpp
  clang/test/CodeGen/systemz-charset.c
  clang/test/CodeGen/systemz-charset.cpp
  clang/test/Driver/cl-options.c
  clang/test/Driver/clang_f_opts.c
  clang/test/Preprocessor/init-s390x.c
  clang/test/Preprocessor/init-x86.c
  llvm/include/llvm/ADT/Triple.h
  llvm/lib/Support/Triple.cpp

Index: llvm/lib/Support/Triple.cpp
===
--- llvm/lib/Support/Triple.cpp
+++ llvm/lib/Support/Triple.cpp
@@ -1046,6 +1046,13 @@
   return Tmp.split('-').second;  // Strip second component
 }
 
+// System charset on z/OS is IBM-1047 and UTF-8 otherwise
+StringRef Triple::getSystemCharset() const {
+  if (getOS() == llvm::Triple::ZOS)
+return "IBM-1047";
+  return "UTF-8";
+}
+
 static unsigned EatNumber(StringRef ) {
   assert(!Str.empty() && isDigit(Str[0]) && "Not a number");
   unsigned Result = 0;
Index: llvm/include/llvm/ADT/Triple.h
===
--- llvm/include/llvm/ADT/Triple.h
+++ llvm/include/llvm/ADT/Triple.h
@@ -397,6 +397,9 @@
   /// if the environment component is present).
   StringRef getOSAndEnvironmentName() const;
 
+  /// getSystemCharset - Get the system charset of the triple.
+  StringRef getSystemCharset() const;
+
   /// @}
   /// @name Convenience Predicates
   /// @{
Index: clang/test/Preprocessor/init-x86.c
===
--- clang/test/Preprocessor/init-x86.c
+++ clang/test/Preprocessor/init-x86.c
@@ -1306,7 +1306,7 @@
 // X86_64-CLOUDABI:#define __amd64 1
 // X86_64-CLOUDABI:#define __amd64__ 1
 // X86_64-CLOUDABI:#define __clang__ 1
-// X86_64-CLOUDABI:#define __clang_literal_encoding__ {{.*}}
+// X86_64-CLOUDABI:#define __clang_literal_encoding__ UTF-8
 // X86_64-CLOUDABI:#define __clang_major__ {{.*}}
 // X86_64-CLOUDABI:#define __clang_minor__ {{.*}}
 // X86_64-CLOUDABI:#define __clang_patchlevel__ {{.*}}
Index: clang/test/Preprocessor/init-s390x.c
===
--- clang/test/Preprocessor/init-s390x.c
+++ clang/test/Preprocessor/init-s390x.c
@@ -202,4 +202,5 @@
 // S390X-ZOS:   #define __TOS_390__ 1
 // S390X-ZOS:   #define __TOS_MVS__ 1
 // S390X-ZOS:   #define __XPLINK__ 1
+// S390X-ZOS:   #define __clang_literal_encoding__ IBM-1047
 // S390X-ZOS-GNUXX: #define __wchar_t 1
Index: clang/test/Driver/clang_f_opts.c
===
--- clang/test/Driver/clang_f_opts.c
+++ clang/test/Driver/clang_f_opts.c
@@ -222,8 +222,14 @@
 // RUN: %clang -### -S -finput-charset=iso-8859-1 -o /dev/null %s 2>&1 | FileCheck -check-prefix=CHECK-INVALID-CHARSET %s
 // CHECK-INVALID-CHARSET: error: invalid value 'iso-8859-1' in '-finput-charset=iso-8859-1'
 
-// RUN: %clang -### -S -fexec-charset=iso-8859-1 -o /dev/null %s 2>&1 | FileCheck -check-prefix=CHECK-INVALID-INPUT-CHARSET %s
-// CHECK-INVALID-INPUT-CHARSET: error: invalid value 'iso-8859-1' in '-fexec-charset=iso-8859-1'
+// RUN: %clang -### -S -fexec-charset=invalid-charset -o /dev/null %s 2>&1 | FileCheck -check-prefix=CHECK-INVALID-INPUT-CHARSET %s
+// CHECK-INVALID-INPUT-CHARSET: error: invalid value 'invalid-charset' in '-fexec-charset=invalid-charset'
+
+// Test that we support the following exec charsets.
+// RUN: %clang -### -S -fexec-charset=UTF-8 -o /dev/null %s 2>&1 | FileCheck --check-prefix=INVALID %s
+// RUN: %clang -### -S -fexec-charset=ISO8859-1 -o /dev/null %s 2>&1 | FileCheck --check-prefix=INVALID %s
+// RUN: %clang -### -S -fexec-charset=IBM-1047 -o /dev/null %s 2>&1 | FileCheck --check-prefix=INVALID %s
+// INVALID-NOT: error: invalid value
 
 // Test that we don't error on these.
 // RUN: %clang -### -S -Werror\
@@ -237,7 +243,7 @@
 // RUN: -fident -fno-ident\
 // RUN: -fimplicit-templates -fno-implicit-templates  \
 // RUN: -finput-charset=UTF-8

[PATCH] D99233: [HIP] Add option --gpu-inline-threshold

2021-04-21 Thread Yaxun Liu via Phabricator via cfe-commits

yaxunl updated this revision to Diff 339353.
yaxunl marked an inline comment as done.
yaxunl edited the summary of this revision.
yaxunl added a comment.

revised by Artem's comments.


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

https://reviews.llvm.org/D99233

Files:
  clang/include/clang/Driver/Options.td
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/test/Driver/hip-options.hip


Index: clang/test/Driver/hip-options.hip
===
--- clang/test/Driver/hip-options.hip
+++ clang/test/Driver/hip-options.hip
@@ -51,3 +51,8 @@
 // RUN:   --cuda-gpu-arch=gfx906  %s 2>&1 | FileCheck -check-prefix=CTA %s
 // CTA: clang{{.*}} "-triple" "x86_64-unknown-linux-gnu" {{.*}} 
"-mconstructor-aliases"
 // CTA-NOT: clang{{.*}} "-triple" "amdgcn-amd-amdhsa" {{.*}} 
"-mconstructor-aliases"
+
+// RUN: %clang -### -target x86_64-unknown-linux-gnu -nogpuinc -nogpulib \
+// RUN:   --offload-arch=gfx906 -fgpu-inline-threshold=1000 %s 2>&1 | 
FileCheck -check-prefix=THRESH %s
+// THRESH: clang{{.*}} "-triple" "amdgcn-amd-amdhsa" {{.*}} "-mllvm" 
"-inline-threshold=1000"
+// THRESH-NOT: clang{{.*}} "-triple" "x86_64-unknown-linux-gnu" {{.*}} 
"-inline-threshold=1000"
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -6473,6 +6473,16 @@
   if (IsHIP)
 CmdArgs.push_back("-fcuda-allow-variadic-functions");
 
+  if (IsCudaDevice || IsHIPDevice) {
+StringRef InlineThresh =
+Args.getLastArgValue(options::OPT_fgpu_inline_threshold_EQ);
+if (!InlineThresh.empty()) {
+  std::string ArgStr =
+  std::string("-inline-threshold=") + InlineThresh.str();
+  CmdArgs.append({"-mllvm", Args.MakeArgStringRef(ArgStr)});
+}
+  }
+
   // OpenMP offloading device jobs take the argument -fopenmp-host-ir-file-path
   // to specify the result of the compile phase on the host, so the meaningful
   // device declarations can be identified. Also, -fopenmp-is-device is passed
Index: clang/include/clang/Driver/Options.td
===
--- clang/include/clang/Driver/Options.td
+++ clang/include/clang/Driver/Options.td
@@ -956,6 +956,9 @@
   HelpText<"Default max threads per block for kernel launch bounds for HIP">,
   MarshallingInfoInt, "1024">,
   ShouldParseIf;
+def fgpu_inline_threshold_EQ : Joined<["-"], "fgpu-inline-threshold=">,
+  Flags<[HelpHidden]>,
+  HelpText<"Inline threshold for device compilation for CUDA/HIP">;
 def gpu_instrument_lib_EQ : Joined<["--"], "gpu-instrument-lib=">,
   HelpText<"Instrument device library for HIP, which is a LLVM bitcode 
containing "
   "__cyg_profile_func_enter and __cyg_profile_func_exit">;


Index: clang/test/Driver/hip-options.hip
===
--- clang/test/Driver/hip-options.hip
+++ clang/test/Driver/hip-options.hip
@@ -51,3 +51,8 @@
 // RUN:   --cuda-gpu-arch=gfx906  %s 2>&1 | FileCheck -check-prefix=CTA %s
 // CTA: clang{{.*}} "-triple" "x86_64-unknown-linux-gnu" {{.*}} "-mconstructor-aliases"
 // CTA-NOT: clang{{.*}} "-triple" "amdgcn-amd-amdhsa" {{.*}} "-mconstructor-aliases"
+
+// RUN: %clang -### -target x86_64-unknown-linux-gnu -nogpuinc -nogpulib \
+// RUN:   --offload-arch=gfx906 -fgpu-inline-threshold=1000 %s 2>&1 | FileCheck -check-prefix=THRESH %s
+// THRESH: clang{{.*}} "-triple" "amdgcn-amd-amdhsa" {{.*}} "-mllvm" "-inline-threshold=1000"
+// THRESH-NOT: clang{{.*}} "-triple" "x86_64-unknown-linux-gnu" {{.*}} "-inline-threshold=1000"
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -6473,6 +6473,16 @@
   if (IsHIP)
 CmdArgs.push_back("-fcuda-allow-variadic-functions");
 
+  if (IsCudaDevice || IsHIPDevice) {
+StringRef InlineThresh =
+Args.getLastArgValue(options::OPT_fgpu_inline_threshold_EQ);
+if (!InlineThresh.empty()) {
+  std::string ArgStr =
+  std::string("-inline-threshold=") + InlineThresh.str();
+  CmdArgs.append({"-mllvm", Args.MakeArgStringRef(ArgStr)});
+}
+  }
+
   // OpenMP offloading device jobs take the argument -fopenmp-host-ir-file-path
   // to specify the result of the compile phase on the host, so the meaningful
   // device declarations can be identified. Also, -fopenmp-is-device is passed
Index: clang/include/clang/Driver/Options.td
===
--- clang/include/clang/Driver/Options.td
+++ clang/include/clang/Driver/Options.td
@@ -956,6 +956,9 @@
   HelpText<"Default max threads per block for kernel launch bounds for HIP">,
   MarshallingInfoInt, "1024">,
   ShouldParseIf;
+def fgpu_inline_threshold_EQ : Joined<["-"], "fgpu-inline-threshold=">,
+

[PATCH] D98798: Produce warning for performing pointer arithmetic on a null pointer.

2021-04-21 Thread Jamie Schmeiser via Phabricator via cfe-commits

jamieschmeiser added a comment.

ping


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

https://reviews.llvm.org/D98798

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

[PATCH] D100991: Fix parsing of vector keyword in presence of conflicting uses.

2021-04-21 Thread Jamie Schmeiser via Phabricator via cfe-commits

jamieschmeiser created this revision.
jamieschmeiser added reviewers: rsmith, saar.raz.
jamieschmeiser requested review of this revision.
Herald added a project: clang.

When vector is found as a type or non-type id, check if it is really the 
altivec vector token.

Call TryAltiVecVectorToken when an identifier is seen in the parser before
annotating the token.  This checks the next token where necessary to ensure
that vector is properly handled as the altivec token.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D100991

Files:
  clang/lib/Parse/Parser.cpp
  clang/test/Parser/altivec-non-type-vector.c
  clang/test/Parser/altivec-template-vector.cpp
  clang/test/Parser/altivec-typedef-vector.c


Index: clang/test/Parser/altivec-typedef-vector.c
===
--- /dev/null
+++ clang/test/Parser/altivec-typedef-vector.c
@@ -0,0 +1,7 @@
+// RUN: %clang_cc1 -target-feature +altivec -fsyntax-only %s
+
+typedef int vector;
+
+void test() {
+  vector unsigned int v = {0};
+}
Index: clang/test/Parser/altivec-template-vector.cpp
===
--- /dev/null
+++ clang/test/Parser/altivec-template-vector.cpp
@@ -0,0 +1,11 @@
+// RUN: %clang_cc1 -fsyntax-only -target-feature +altivec %s
+
+template  class vector {
+public:
+  vector(int) {}
+};
+
+void f() {
+  vector int v = {0};
+  vector vi = {0};
+}
Index: clang/test/Parser/altivec-non-type-vector.c
===
--- /dev/null
+++ clang/test/Parser/altivec-non-type-vector.c
@@ -0,0 +1,7 @@
+// RUN: %clang_cc1 -target-feature +altivec -fsyntax-only %s
+
+int vector();
+
+void test() {
+  vector unsigned int v = {0};
+}
Index: clang/lib/Parse/Parser.cpp
===
--- clang/lib/Parse/Parser.cpp
+++ clang/lib/Parse/Parser.cpp
@@ -1695,6 +1695,11 @@
 break;
 
   case Sema::NC_Type: {
+if (TryAltiVecVectorToken())
+  // vector has been found as a type id when altivec is enabled but
+  // this is followed by a declaration specifier so this is really the
+  // altivec vector token.  Leave it unannotated.
+  break;
 SourceLocation BeginLoc = NameLoc;
 if (SS.isNotEmpty())
   BeginLoc = SS.getBeginLoc();
@@ -1736,6 +1741,11 @@
 return ANK_Success;
 
   case Sema::NC_NonType:
+if (TryAltiVecVectorToken())
+  // vector has been found as a non-type id when altivec is enabled but
+  // this is followed by a declaration specifier so this is really the
+  // altivec vector token.  Leave it unannotated.
+  break;
 Tok.setKind(tok::annot_non_type);
 setNonTypeAnnotation(Tok, Classification.getNonTypeDecl());
 Tok.setLocation(NameLoc);


Index: clang/test/Parser/altivec-typedef-vector.c
===
--- /dev/null
+++ clang/test/Parser/altivec-typedef-vector.c
@@ -0,0 +1,7 @@
+// RUN: %clang_cc1 -target-feature +altivec -fsyntax-only %s
+
+typedef int vector;
+
+void test() {
+  vector unsigned int v = {0};
+}
Index: clang/test/Parser/altivec-template-vector.cpp
===
--- /dev/null
+++ clang/test/Parser/altivec-template-vector.cpp
@@ -0,0 +1,11 @@
+// RUN: %clang_cc1 -fsyntax-only -target-feature +altivec %s
+
+template  class vector {
+public:
+  vector(int) {}
+};
+
+void f() {
+  vector int v = {0};
+  vector vi = {0};
+}
Index: clang/test/Parser/altivec-non-type-vector.c
===
--- /dev/null
+++ clang/test/Parser/altivec-non-type-vector.c
@@ -0,0 +1,7 @@
+// RUN: %clang_cc1 -target-feature +altivec -fsyntax-only %s
+
+int vector();
+
+void test() {
+  vector unsigned int v = {0};
+}
Index: clang/lib/Parse/Parser.cpp
===
--- clang/lib/Parse/Parser.cpp
+++ clang/lib/Parse/Parser.cpp
@@ -1695,6 +1695,11 @@
 break;
 
   case Sema::NC_Type: {
+if (TryAltiVecVectorToken())
+  // vector has been found as a type id when altivec is enabled but
+  // this is followed by a declaration specifier so this is really the
+  // altivec vector token.  Leave it unannotated.
+  break;
 SourceLocation BeginLoc = NameLoc;
 if (SS.isNotEmpty())
   BeginLoc = SS.getBeginLoc();
@@ -1736,6 +1741,11 @@
 return ANK_Success;
 
   case Sema::NC_NonType:
+if (TryAltiVecVectorToken())
+  // vector has been found as a non-type id when altivec is enabled but
+  // this is followed by a declaration specifier so this is really the
+  // altivec vector token.  Leave it unannotated.
+  break;
 Tok.setKind(tok::annot_non_type);
 setNonTypeAnnotation(Tok, Classification.getNonTypeDecl());
 Tok.setLocation(NameLoc);
___
cfe-commits mailing list

[PATCH] D100000: [clang] WIP: Implement simpler alternative to two-phase lookup for NRVO

2021-04-21 Thread Matheus Izvekov via Phabricator via cfe-commits

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

.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D10

Files:
  clang/include/clang/AST/Expr.h
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Basic/Specifiers.h
  clang/include/clang/Sema/Sema.h
  clang/lib/AST/ASTContext.cpp
  clang/lib/AST/ExprClassification.cpp
  clang/lib/AST/JSONNodeDumper.cpp
  clang/lib/AST/TextNodeDumper.cpp
  clang/lib/CodeGen/CGDecl.cpp
  clang/lib/CodeGen/CGObjC.cpp
  clang/lib/Sema/SemaCodeComplete.cpp
  clang/lib/Sema/SemaCoroutine.cpp
  clang/lib/Sema/SemaExprCXX.cpp
  clang/lib/Sema/SemaInit.cpp
  clang/lib/Sema/SemaOverload.cpp
  clang/lib/Sema/SemaStmt.cpp
  clang/lib/Sema/SemaTemplateInstantiateDecl.cpp
  clang/test/CXX/class/class.init/class.copy.elision/p3.cpp
  clang/test/SemaCXX/P1155.cpp
  clang/test/SemaCXX/conversion-function.cpp
  clang/test/SemaCXX/coroutine-rvo.cpp
  clang/test/SemaCXX/warn-return-std-move.cpp

Index: clang/test/SemaCXX/warn-return-std-move.cpp
===
--- clang/test/SemaCXX/warn-return-std-move.cpp
+++ clang/test/SemaCXX/warn-return-std-move.cpp
@@ -1,12 +1,12 @@
-// RUN: %clang_cc1 -std=c++2b -fsyntax-only -verify=cxx20_2b,cxx2b -fcxx-exceptions -Wreturn-std-move %s
-// RUN: %clang_cc1 -std=c++20 -fsyntax-only -verify=cxx20_2b   -fcxx-exceptions -Wreturn-std-move %s
-// RUN: %clang_cc1 -std=c++17 -fsyntax-only -verify=cxx11_17   -fcxx-exceptions -Wreturn-std-move %s
-// RUN: %clang_cc1 -std=c++14 -fsyntax-only -verify=cxx11_17   -fcxx-exceptions -Wreturn-std-move %s
-// RUN: %clang_cc1 -std=c++11 -fsyntax-only -verify=cxx11_17   -fcxx-exceptions -Wreturn-std-move %s
+// RUN: %clang_cc1 -std=c++2b -fsyntax-only -verify=expected,cxx20_2b,cxx2b-fcxx-exceptions -Wreturn-std-move %s
+// RUN: %clang_cc1 -std=c++20 -fsyntax-only -verify=expected,cxx20_2b,cxx11_20 -fcxx-exceptions -Wreturn-std-move %s
+// RUN: %clang_cc1 -std=c++17 -fsyntax-only -verify=expected,cxx11_17,cxx11_20 -fcxx-exceptions -Wreturn-std-move %s
+// RUN: %clang_cc1 -std=c++14 -fsyntax-only -verify=expected,cxx11_17,cxx11_20 -fcxx-exceptions -Wreturn-std-move %s
+// RUN: %clang_cc1 -std=c++11 -fsyntax-only -verify=expected,cxx11_17,cxx11_20 -fcxx-exceptions -Wreturn-std-move %s
 
-// RUN: %clang_cc1 -std=c++17 -fsyntax-only -fcxx-exceptions -Wreturn-std-move -fdiagnostics-parseable-fixits %s 2>&1 | FileCheck %s -check-prefix=CHECK
-// RUN: %clang_cc1 -std=c++14 -fsyntax-only -fcxx-exceptions -Wreturn-std-move -fdiagnostics-parseable-fixits %s 2>&1 | FileCheck %s -check-prefix=CHECK
-// RUN: %clang_cc1 -std=c++11 -fsyntax-only -fcxx-exceptions -Wreturn-std-move -fdiagnostics-parseable-fixits %s 2>&1 | FileCheck %s -check-prefix=CHECK
+// RUN: %clang_cc1 -std=c++17 -fsyntax-only -fcxx-exceptions -Wreturn-std-move -fdiagnostics-parseable-fixits %s 2>&1 | FileCheck %s -check-prefixes=CHECK,CHECK_14_17
+// RUN: %clang_cc1 -std=c++14 -fsyntax-only -fcxx-exceptions -Wreturn-std-move -fdiagnostics-parseable-fixits %s 2>&1 | FileCheck %s -check-prefixes=CHECK,CHECK_14_17
+// RUN: %clang_cc1 -std=c++11 -fsyntax-only -fcxx-exceptions -Wreturn-std-move -fdiagnostics-parseable-fixits %s 2>&1 | FileCheck %s -check-prefixes=CHECK
 
 // definitions for std::move
 namespace std {
@@ -78,9 +78,6 @@
 Base test2() {
 Derived d2;
 return d2;  // e1
-// cxx11_17-warning@-1{{will be copied despite being returned by name}}
-// cxx11_17-note@-2{{to avoid copying}}
-// CHECK: fix-it:"{{.*}}":{[[@LINE-3]]:12-[[@LINE-3]]:14}:"std::move(d2)"
 }
 ConstructFromDerived test3() {
   Derived d3;
@@ -89,23 +86,14 @@
 ConstructFromBase test4() {
 Derived d4;
 return d4;  // e3
-// cxx11_17-warning@-1{{will be copied despite being returned by name}}
-// cxx11_17-note@-2{{to avoid copying}}
-// CHECK: fix-it:"{{.*}}":{[[@LINE-3]]:12-[[@LINE-3]]:14}:"std::move(d4)"
 }
 ConvertFromDerived test5() {
 Derived d5;
 return d5;  // e4
-// cxx11_17-warning@-1{{will be copied despite being returned by name}}
-// cxx11_17-note@-2{{to avoid copying}}
-// CHECK: fix-it:"{{.*}}":{[[@LINE-3]]:12-[[@LINE-3]]:14}:"std::move(d5)"
 }
 ConvertFromBase test6() {
 Derived d6;
 return d6;  // e5
-// cxx11_17-warning@-1{{will be copied despite being returned by name}}
-// cxx11_17-note@-2{{to avoid copying}}
-// CHECK: fix-it:"{{.*}}":{[[@LINE-3]]:12-[[@LINE-3]]:14}:"std::move(d6)"
 }
 
 // These test cases should not produce the warning.
@@ -152,30 +140,18 @@
 Derived testParam1(Derived d) { return d; }
 Base testParam2(Derived d) {
 return d;  // e6
-// cxx11_17-warning@-1{{will be copied despite being returned by name}}
-// cxx11_17-note@-2{{to avoid copying}}
-// CHECK: fix-it:"{{.*}}":{[[@LINE-3]]:12-[[@LINE-3]]:13}:"std::move(d)"
 }
 ConstructFromDerived testParam3(Derived d)

[PATCH] D99924: [clang-tidy] Avoid bugprone-macro-parentheses warnings after goto argument

2021-04-21 Thread Aaron Ballman via Phabricator via cfe-commits

aaron.ballman added a subscriber: cfe-commits.
aaron.ballman added a comment.

Adding the CFE mailing list, which was not on the review previously.


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

https://reviews.llvm.org/D99924

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

[PATCH] D97183: [analyzer] Add NoteTag for smart-ptr get()

2021-04-21 Thread Deep Majumder via Phabricator via cfe-commits

RedDocMD added a comment.

@NoQ?
(I actually should remove some extra includes and extra member fields)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D97183

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

[PATCH] D100985: [OpenCL] Remove pragma requirement for functions from Arm dot extension

2021-04-21 Thread Anastasia Stulova via Phabricator via cfe-commits

Anastasia created this revision.
Anastasia added reviewers: svenvh, mantognini.
Herald added subscribers: ebevhan, kristof.beyls, yaxunl.
Anastasia requested review of this revision.

This removed the pointless need for extension pragma since it doesn't disable 
anything properly and it doesn't need to enable anything that is not possible 
to disable.

The change doesn't break existing kernels since it allows to compile more cases 
i.e. without pragma statements but the pragma continues to be accepted.


https://reviews.llvm.org/D100985

Files:
  clang/lib/Headers/opencl-c.h
  clang/test/CodeGenOpenCL/arm-integer-dot-product.cl
  clang/test/SemaOpenCL/arm-integer-dot-product.cl

Index: clang/test/SemaOpenCL/arm-integer-dot-product.cl
===
--- clang/test/SemaOpenCL/arm-integer-dot-product.cl
+++ clang/test/SemaOpenCL/arm-integer-dot-product.cl
@@ -1,4 +1,4 @@
-// RUN: %clang_cc1 %s -triple spir-unknown-unknown -finclude-default-header -verify -cl-std=CL1.2 -emit-llvm -o - -O0
+// RUN: %clang_cc1 %s -triple spir-unknown-unknown -finclude-default-header -verify -cl-std=CL1.2 -emit-llvm -o - -cl-ext=-all
 
 void test_negative() {
 uchar4 ua8, ub8;
@@ -7,37 +7,13 @@
 short2 sa16, sb16;
 uint ur;
 int sr;
-ur = arm_dot(ua8, ub8); // expected-error{{no matching function for call to 'arm_dot'}}
-// expected-note@opencl-c.h:* {{candidate function not viable}}
-// expected-note@opencl-c.h:* {{candidate unavailable as it requires OpenCL extension 'cl_arm_integer_dot_product_int8' to be enabled}}
-sr = arm_dot(sa8, sb8); // expected-error{{no matching function for call to 'arm_dot'}}
-// expected-note@opencl-c.h:* {{candidate function not viable}}
-// expected-note@opencl-c.h:* {{candidate unavailable as it requires OpenCL extension 'cl_arm_integer_dot_product_int8' to be enabled}}
-ur = arm_dot_acc(ua8, ub8, ur); // expected-error{{no matching function for call to 'arm_dot_acc'}}
-// expected-note@opencl-c.h:* {{candidate function not viable}}
-// expected-note@opencl-c.h:* {{candidate function not viable}}
-// expected-note@opencl-c.h:* {{candidate function not viable}}
-// expected-note@opencl-c.h:* {{candidate unavailable as it requires OpenCL extension 'cl_arm_integer_dot_product_accumulate_int8' to be enabled}}
-sr = arm_dot_acc(sa8, sb8, sr); // expected-error{{no matching function for call to 'arm_dot_acc'}}
-// expected-note@opencl-c.h:* {{candidate function not viable}}
-// expected-note@opencl-c.h:* {{candidate function not viable}}
-// expected-note@opencl-c.h:* {{candidate function not viable}}
-// expected-note@opencl-c.h:* {{candidate unavailable as it requires OpenCL extension 'cl_arm_integer_dot_product_accumulate_int8' to be enabled}}
-ur = arm_dot_acc(ua16, ub16, ur); // expected-error{{no matching function for call to 'arm_dot_acc'}}
-// expected-note@opencl-c.h:* {{candidate function not viable}}
-// expected-note@opencl-c.h:* {{candidate function not viable}}
-// expected-note@opencl-c.h:* {{candidate function not viable}}
-// expected-note@opencl-c.h:* {{candidate unavailable as it requires OpenCL extension 'cl_arm_integer_dot_product_accumulate_int16' to be enabled}}
-sr = arm_dot_acc(sa16, sb16, sr); // expected-error{{no matching function for call to 'arm_dot_acc'}}
-// expected-note@opencl-c.h:* {{candidate function not viable}}
-// expected-note@opencl-c.h:* {{candidate function not viable}}
-// expected-note@opencl-c.h:* {{candidate function not viable}}
-// expected-note@opencl-c.h:* {{candidate unavailable as it requires OpenCL extension 'cl_arm_integer_dot_product_accumulate_int16' to be enabled}}
-ur = arm_dot_acc_sat(ua8, ub8, ur); // expected-error{{no matching function for call to 'arm_dot_acc_sat'}}
-// expected-note@opencl-c.h:* {{candidate function not viable}}
-// expected-note@opencl-c.h:* {{candidate unavailable as it requires OpenCL extension 'cl_arm_integer_dot_product_accumulate_saturate_int8' to be enabled}}
-sr = arm_dot_acc_sat(sa8, sb8, sr); // expected-error{{no matching function for call to 'arm_dot_acc_sat'}}
-// expected-note@opencl-c.h:* {{candidate function not viable}}
-// expected-note@opencl-c.h:* {{candidate unavailable as it requires OpenCL extension 'cl_arm_integer_dot_product_accumulate_saturate_int8' to be enabled}}
+ur = arm_dot(ua8, ub8); // expected-error{{implicit declaration of function 'arm_dot' is invalid in OpenCL}}
+sr = arm_dot(sa8, sb8);
+ur = arm_dot_acc(ua8, ub8, ur); // expected-error{{implicit declaration of function 'arm_dot_acc' is invalid in OpenCL}} //expected-note{{'arm_dot_acc' declared here}}
+sr = arm_dot_acc(sa8, sb8, sr);
+ur = arm_dot_acc(ua16, ub16, ur);
+sr = arm_dot_acc(sa16, sb16, sr);
+ur = arm_dot_acc_sat(ua8, ub8, ur); // expected-error{{implicit declaration of function 'arm_dot_acc_sat' is

[PATCH] D95976: [OpenMP] Simplify offloading parallel call codegen

2021-04-21 Thread Giorgis Georgakoudis via Phabricator via cfe-commits

ggeorgakoudis updated this revision to Diff 339334.
ggeorgakoudis added a comment.

Fix clang-format


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D95976

Files:
  clang/lib/CodeGen/CGOpenMPRuntimeGPU.cpp
  clang/test/OpenMP/nvptx_allocate_codegen.cpp
  clang/test/OpenMP/nvptx_data_sharing.cpp
  clang/test/OpenMP/nvptx_distribute_parallel_generic_mode_codegen.cpp
  clang/test/OpenMP/nvptx_lambda_capturing.cpp
  clang/test/OpenMP/nvptx_multi_target_parallel_codegen.cpp
  clang/test/OpenMP/nvptx_nested_parallel_codegen.cpp
  clang/test/OpenMP/nvptx_parallel_codegen.cpp
  clang/test/OpenMP/nvptx_parallel_for_codegen.cpp
  clang/test/OpenMP/nvptx_target_codegen.cpp
  clang/test/OpenMP/nvptx_target_parallel_codegen.cpp
  clang/test/OpenMP/nvptx_target_parallel_num_threads_codegen.cpp
  clang/test/OpenMP/nvptx_target_teams_codegen.cpp
  clang/test/OpenMP/nvptx_target_teams_distribute_codegen.cpp
  clang/test/OpenMP/nvptx_target_teams_distribute_parallel_for_codegen.cpp
  
clang/test/OpenMP/nvptx_target_teams_distribute_parallel_for_generic_mode_codegen.cpp
  clang/test/OpenMP/nvptx_target_teams_distribute_parallel_for_simd_codegen.cpp
  clang/test/OpenMP/nvptx_teams_reduction_codegen.cpp
  clang/test/OpenMP/remarks_parallel_in_multiple_target_state_machines.c
  clang/test/OpenMP/remarks_parallel_in_target_state_machine.c
  clang/test/OpenMP/target_parallel_debug_codegen.cpp
  clang/test/OpenMP/target_parallel_for_debug_codegen.cpp
  llvm/include/llvm/Frontend/OpenMP/OMPKinds.def
  llvm/lib/Transforms/IPO/OpenMPOpt.cpp
  llvm/test/Transforms/OpenMP/gpu_state_machine_function_ptr_replacement.ll
  openmp/libomptarget/deviceRTLs/common/generated_microtask_cases.gen
  openmp/libomptarget/deviceRTLs/common/src/omptarget.cu
  openmp/libomptarget/deviceRTLs/common/src/parallel.cu
  openmp/libomptarget/deviceRTLs/common/src/support.cu
  openmp/libomptarget/deviceRTLs/common/support.h
  openmp/libomptarget/deviceRTLs/interface.h
  openmp/libomptarget/test/offloading/bug49779.cpp
  openmp/libomptarget/utils/generate_microtask_cases.py

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

[PATCH] D100984: [OpenCL] Remove the need for subgroupd extension pragma in enqueue kernel builtins

2021-04-21 Thread Anastasia Stulova via Phabricator via cfe-commits

Anastasia created this revision.
Anastasia added reviewers: svenvh, azabaznov, mantognini.
Herald added subscribers: ebevhan, yaxunl.
Anastasia requested review of this revision.

There is no extension pragma requirement in the spec for these functions and 
all other builtin functions are available without the pragama.

This patch simplifies the parser and makes the language semantics consistent.


https://reviews.llvm.org/D100984

Files:
  clang/lib/Sema/SemaChecking.cpp
  clang/test/SemaOpenCL/cl20-device-side-enqueue.cl


Index: clang/test/SemaOpenCL/cl20-device-side-enqueue.cl
===
--- clang/test/SemaOpenCL/cl20-device-side-enqueue.cl
+++ clang/test/SemaOpenCL/cl20-device-side-enqueue.cl
@@ -1,4 +1,5 @@
 // RUN: %clang_cc1 %s -cl-std=CL2.0 -triple "spir-unknown-unknown" -verify 
-pedantic -fsyntax-only -DB32 -DQUALS=
+// RUN: %clang_cc1 %s -cl-std=CL2.0 -triple "spir-unknown-unknown" -verify 
-pedantic -fsyntax-only -DB32 -DQUALS= -cl-ext=-cl_khr_subgroups
 // RUN: %clang_cc1 %s -cl-std=CL2.0 -triple "spir-unknown-unknown" -verify 
-pedantic -fsyntax-only -DB32 -DQUALS="const volatile"
 // RUN: %clang_cc1 %s -cl-std=CL2.0 -triple "spir64-unknown-unknown" -verify 
-pedantic -fsyntax-only -Wconversion -DWCONV -DQUALS=
 // RUN: %clang_cc1 %s -cl-std=CL2.0 -triple "spir64-unknown-unknown" -verify 
-pedantic -fsyntax-only -Wconversion -DWCONV -DQUALS="const volatile"
@@ -212,8 +213,8 @@
   size = get_kernel_preferred_work_group_size_multiple(block_A, 1); // 
expected-error{{too many arguments to function call, expected 1, have 2}}
 }
 
+#ifdef cl_khr_subgroups
 #pragma OPENCL EXTENSION cl_khr_subgroups : enable
-
 kernel void foo(global unsigned int *buf)
 {
   ndrange_t n;
@@ -231,7 +232,7 @@
 }
 
 #pragma OPENCL EXTENSION cl_khr_subgroups : disable
-
+#else
 kernel void foo1(global unsigned int *buf)
 {
   ndrange_t n;
@@ -243,3 +244,4 @@
   ndrange_t n;
   buf[0] = get_kernel_sub_group_count_for_ndrange(n, ^(){}); // expected-error 
{{use of declaration 'get_kernel_sub_group_count_for_ndrange' requires 
cl_khr_subgroups support}}
 }
+#endif // ifdef cl_khr_subgroups
Index: clang/lib/Sema/SemaChecking.cpp
===
--- clang/lib/Sema/SemaChecking.cpp
+++ clang/lib/Sema/SemaChecking.cpp
@@ -838,8 +838,7 @@
 }
 
 static bool checkOpenCLSubgroupExt(Sema , CallExpr *Call) {
-  if (!S.getOpenCLOptions().isAvailableOption("cl_khr_subgroups",
-  S.getLangOpts())) {
+  if (!S.getOpenCLOptions().isSupported("cl_khr_subgroups", S.getLangOpts())) {
 S.Diag(Call->getBeginLoc(), diag::err_opencl_requires_extension)
 << 1 << Call->getDirectCallee() << "cl_khr_subgroups";
 return true;


Index: clang/test/SemaOpenCL/cl20-device-side-enqueue.cl
===
--- clang/test/SemaOpenCL/cl20-device-side-enqueue.cl
+++ clang/test/SemaOpenCL/cl20-device-side-enqueue.cl
@@ -1,4 +1,5 @@
 // RUN: %clang_cc1 %s -cl-std=CL2.0 -triple "spir-unknown-unknown" -verify -pedantic -fsyntax-only -DB32 -DQUALS=
+// RUN: %clang_cc1 %s -cl-std=CL2.0 -triple "spir-unknown-unknown" -verify -pedantic -fsyntax-only -DB32 -DQUALS= -cl-ext=-cl_khr_subgroups
 // RUN: %clang_cc1 %s -cl-std=CL2.0 -triple "spir-unknown-unknown" -verify -pedantic -fsyntax-only -DB32 -DQUALS="const volatile"
 // RUN: %clang_cc1 %s -cl-std=CL2.0 -triple "spir64-unknown-unknown" -verify -pedantic -fsyntax-only -Wconversion -DWCONV -DQUALS=
 // RUN: %clang_cc1 %s -cl-std=CL2.0 -triple "spir64-unknown-unknown" -verify -pedantic -fsyntax-only -Wconversion -DWCONV -DQUALS="const volatile"
@@ -212,8 +213,8 @@
   size = get_kernel_preferred_work_group_size_multiple(block_A, 1); // expected-error{{too many arguments to function call, expected 1, have 2}}
 }
 
+#ifdef cl_khr_subgroups
 #pragma OPENCL EXTENSION cl_khr_subgroups : enable
-
 kernel void foo(global unsigned int *buf)
 {
   ndrange_t n;
@@ -231,7 +232,7 @@
 }
 
 #pragma OPENCL EXTENSION cl_khr_subgroups : disable
-
+#else
 kernel void foo1(global unsigned int *buf)
 {
   ndrange_t n;
@@ -243,3 +244,4 @@
   ndrange_t n;
   buf[0] = get_kernel_sub_group_count_for_ndrange(n, ^(){}); // expected-error {{use of declaration 'get_kernel_sub_group_count_for_ndrange' requires cl_khr_subgroups support}}
 }
+#endif // ifdef cl_khr_subgroups
Index: clang/lib/Sema/SemaChecking.cpp
===
--- clang/lib/Sema/SemaChecking.cpp
+++ clang/lib/Sema/SemaChecking.cpp
@@ -838,8 +838,7 @@
 }
 
 static bool checkOpenCLSubgroupExt(Sema , CallExpr *Call) {
-  if (!S.getOpenCLOptions().isAvailableOption("cl_khr_subgroups",
-  S.getLangOpts())) {
+  if (!S.getOpenCLOptions().isSupported("cl_khr_subgroups", S.getLangOpts())) {
 S.Diag(Call->getBeginLoc(), diag::err_opencl_requires_extension)
 << 1 <<

[PATCH] D100124: [Clang][NVPTX] Add NVPTX intrinsics and builtins for CUDA PTX redux.sync instructions

2021-04-21 Thread Artem Belevich via Phabricator via cfe-commits

tra added a comment.

Do you know if any existing code already uses the `__nvvm_*` builtins for 
`cp.async`? In other words, does nvcc provide them already or is it something 
we're free to name as we wish?
I do not see any relevant intrinsics mentioned in NVVM IR spec: 
https://docs.nvidia.com/cuda/nvvm-ir-spec/index.html and I don't think NVCC's 
builtins are publicly documented anywhere.




Comment at: clang/include/clang/Basic/BuiltinsNVPTX.def:460-468
+TARGET_BUILTIN(__nvvm_redux_sync_add_s32, "SiSii", "", SM_80)
+TARGET_BUILTIN(__nvvm_redux_sync_min_s32, "SiSii", "", SM_80)
+TARGET_BUILTIN(__nvvm_redux_sync_max_s32, "SiSii", "", SM_80)
+TARGET_BUILTIN(__nvvm_redux_sync_add_u32, "UiUii", "", SM_80)
+TARGET_BUILTIN(__nvvm_redux_sync_min_u32, "UiUii", "", SM_80)
+TARGET_BUILTIN(__nvvm_redux_sync_max_u32, "UiUii", "", SM_80)
+TARGET_BUILTIN(__nvvm_redux_sync_and_b32, "iii", "", SM_80)

steffenlarsen wrote:
> tra wrote:
> > steffenlarsen wrote:
> > > tra wrote:
> > > > steffenlarsen wrote:
> > > > > tra wrote:
> > > > > > Instead of creating one builtin per integer variant, can we use a 
> > > > > > more generic builtin `__nvvm_redux_sync_add_i`, similar to how we 
> > > > > > handle `__nvvm_atom_add_gen_i` ?
> > > > > > 
> > > > > What gives me pause is that a for atomic minimum there are both 
> > > > > `__nvvm_atom_min_gen_i` and `__nvvm_atom_min_gen_ui` to distinguish 
> > > > > between signed and unsigned. What makes the difference?
> > > > > 
> > > > > That noted, I'll happily rename the builtins to be more in line with 
> > > > > the other builtins. `__nvvm_redux_sync_*_i` and 
> > > > > `__nvvm_redux_sync_*_ui` maybe?
> > > > > What gives me pause is that a for atomic minimum there are both 
> > > > > __nvvm_atom_min_gen_i and __nvvm_atom_min_gen_ui to distinguish 
> > > > > between signed and unsigned. What makes the difference?
> > > > 
> > > > Good point. We do not need unsigned variant for `add`.  We do need 
> > > > explicit signed and unsigned variants ad LLVM IR integer types do not 
> > > > take signedness into account, and the underlying min/max instructions 
> > > > do.  Maybe, rename min_i/min_ui -> min/umin as LLVM does with atomics? 
> > > > 
> > > > We may skip the `_i` suffix on logical ops as they only apply to 
> > > > integers anyways.
> > > > 
> > > Sorry, I completely missed your responses.
> > > 
> > > > Maybe, rename min_i/min_ui -> min/umin as LLVM does with atomics?
> > > 
> > > Sounds good to me. Would there also be umax and uadd?
> > > 
> > > > We may skip the _i suffix on logical ops as they only apply to integers 
> > > > anyways.
> > > 
> > > Absolutely. I'll make that happen! 
> > > Would there also be umax and uadd?
> > 
> > You will need `umax`, but there's no need for `uadd` as 2-complement 
> > addition is the same for signed/unsigned.
> > 
> > E.g `umax(0x, 1) -> 0x`, `max(-1,1) -> 1`, give different 
> > answers, but `uadd(0x, 1) -> 0` and `add(-1,1) -> 0`.
> Ah, of course. Though I do wonder as to the motivation of having signed and 
> unsigned add variants in PTX. I'll drop the unsigned variant.
It's for uniformity sake, I guess. All arithmetic ops in PTX operate on sXX/uXX 
arguments, though not all of them have to.



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

https://reviews.llvm.org/D100124

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

[PATCH] D91054: [Clang][OpenMP] Frontend work for sections - D89671

2021-04-21 Thread Michael Kruse via Phabricator via cfe-commits

Meinersbur added a comment.

What is the status of this? The parent D89671  
has been accepted, but not committed.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D91054

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

[PATCH] D99233: [HIP] Add option --gpu-inline-threshold

2021-04-21 Thread Yaxun Liu via Phabricator via cfe-commits

yaxunl marked an inline comment as done.
yaxunl added inline comments.



Comment at: clang/include/clang/Driver/Options.td:954
+def gpu_inline_threshold_EQ : Joined<["--"], "gpu-inline-threshold=">,
+  Flags<[CC1Option]>,
+  HelpText<"Inline threshold for device compilation for HIP">;

tra wrote:
> This option is only handled at the top level, it does not need `CC1Option`. 
> It does need `HelpHidden`.
> 
> Also, the option should probably be `-fgpu-inline-threshold=...` as it's a 
> parameter tweak, and not something more serious, like `--offload-arch`.
> Naming is hard. :-)
will do


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

https://reviews.llvm.org/D99233

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

[PATCH] D91950: [clang-format] Add BreakBeforeInlineASMColon configuration

2021-04-21 Thread Björn Schäpers via Phabricator via cfe-commits

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

Looks good, but please fix the clang-format notes.


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

https://reviews.llvm.org/D91950

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

[PATCH] D100983: [OpenCL] Fix optional image types

2021-04-21 Thread Anastasia Stulova via Phabricator via cfe-commits

Anastasia created this revision.
Anastasia added reviewers: svenvh, azabaznov, yaxunl.
Herald added a subscriber: ebevhan.
Anastasia requested review of this revision.

This change allows the use of identifiers for image types from 
`cl_khr_gl_msaa_sharing` freely in the kernel code if the extension is  not 
supported since they are not in the list of the reserved identifiers:
https://www.khronos.org/registry/OpenCL/specs/3.0-unified/html/OpenCL_C.html#keywords

This change also removed the need for pragma for the types in the extensions 
since the spec doesn't require the pragma uses. For example, there is the 
following wording for 3d image writes:

> The behavior of write_imagef, write_imagei and write_imageui for image 
> objects with image_channel_data_type values not specified in the description 
> above or with (x, y, z) coordinate values that are not in the range [0, image 
> width-1], [0, image height-1], and [0, image depth-1], respectively, is 
> undefined.
>
> Requires support for OpenCL C 2.0, or OpenCL C 3.0 or newer and the 
> __opencl_c_3d_image_writes feature, or the cl_khr_3d_image_writes extension.


https://reviews.llvm.org/D100983

Files:
  clang/include/clang/Basic/OpenCLImageTypes.def
  clang/lib/Parse/ParseDecl.cpp
  clang/lib/Sema/Sema.cpp
  clang/lib/Sema/SemaType.cpp
  clang/test/SemaOpenCL/access-qualifier.cl
  clang/test/SemaOpenCL/invalid-image.cl

Index: clang/test/SemaOpenCL/invalid-image.cl
===
--- clang/test/SemaOpenCL/invalid-image.cl
+++ clang/test/SemaOpenCL/invalid-image.cl
@@ -1,5 +1,6 @@
 // RUN: %clang_cc1 -verify -cl-std=clc++ %s
-// RUN: %clang_cc1 -verify %s
+// RUN: %clang_cc1 -verify %s -cl-ext=+cl_khr_gl_msaa_sharing
+// RUN: %clang_cc1 -verify %s -cl-ext=-cl_khr_gl_msaa_sharing
 // RUN: %clang_cc1 -verify -D=ATTR_TEST -fms-compatibility %s
 
 void test1(image1d_t *i) {} // expected-error-re{{pointer to type '{{__generic __read_only|__read_only}} image1d_t' is invalid in OpenCL}}
@@ -19,3 +20,9 @@
 // Test case for an infinite loop bug.
 kernel void foob(read_only __ptr32  image2d_t i) { } // expected-error{{'__ptr32' attribute only applies to pointer arguments}}
 #endif
+
+#ifndef cl_khr_gl_msaa_sharing
+// Image types from 'cl_khr_gl_msaa_sharing' are not reserved identifiers.
+typedef int image2d_msaa_t;
+#endif
+void foo(image2d_msaa_t i);
Index: clang/test/SemaOpenCL/access-qualifier.cl
===
--- clang/test/SemaOpenCL/access-qualifier.cl
+++ clang/test/SemaOpenCL/access-qualifier.cl
@@ -1,4 +1,4 @@
-// RUN: %clang_cc1 -verify -pedantic -fsyntax-only -cl-std=CL1.2 %s
+// RUN: %clang_cc1 -verify -pedantic -fsyntax-only -cl-std=CL1.2 %s -cl-ext=-cl_khr_3d_image_writes
 // RUN: %clang_cc1 -verify -pedantic -fsyntax-only -cl-std=CL2.0 %s
 
 typedef image1d_t img1d_ro_default; // expected-note {{previously declared 'read_only' here}}
Index: clang/lib/Sema/SemaType.cpp
===
--- clang/lib/Sema/SemaType.cpp
+++ clang/lib/Sema/SemaType.cpp
@@ -1711,12 +1711,20 @@
 break;
   }
 
+
   // FIXME: we want resulting declarations to be marked invalid, but claiming
   // the type is invalid is too strong - e.g. it causes ActOnTypeName to return
   // a null type.
   if (Result->containsErrors())
 declarator.setInvalidType();
 
+  if (S.getLangOpts().OpenCL && Result->isOCLImage3dWOType() &&
+  !S.getOpenCLOptions().isSupported("cl_khr_3d_image_writes", S.getLangOpts())) {
+S.Diag(DS.getTypeSpecTypeLoc(), diag::err_opencl_requires_extension)
+<< 0 << Result << "cl_khr_3d_image_writes";
+declarator.setInvalidType();
+  }
+
   if (S.getLangOpts().OpenCL &&
   S.checkOpenCLDisabledTypeDeclSpec(DS, Result))
 declarator.setInvalidType(true);
Index: clang/lib/Sema/Sema.cpp
===
--- clang/lib/Sema/Sema.cpp
+++ clang/lib/Sema/Sema.cpp
@@ -363,10 +363,6 @@
   }
 }
 
-
-#define GENERIC_IMAGE_TYPE_EXT(Type, Id, Ext) \
-setOpenCLExtensionForType(Context.Id, Ext);
-#include "clang/Basic/OpenCLImageTypes.def"
 #define EXT_OPAQUE_TYPE(ExtType, Id, Ext)  \
   if (getOpenCLOptions().isSupported(#Ext, getLangOpts())) {   \
 addImplicitTypedef(#ExtType, Context.Id##Ty);  \
Index: clang/lib/Parse/ParseDecl.cpp
===
--- clang/lib/Parse/ParseDecl.cpp
+++ clang/lib/Parse/ParseDecl.cpp
@@ -3071,6 +3071,23 @@
 
 SourceLocation Loc = Tok.getLocation();
 
+// Helper for image types in OpenCL.
+auto handleOpenCLImageKW = [&](StringRef Ext,
+   TypeSpecifierType ImageTypeSpec) {
+  // Check if the image type is supported and otherwise turn the keyword
+  // into an identifier because image types from

[PATCH] D100118: [clang] RFC Support new builtin __arithmetic_fence to control floating point optimization, and new clang option fprotect-parens

2021-04-21 Thread Melanie Blower via Phabricator via cfe-commits

mibintc added inline comments.



Comment at: clang/lib/CodeGen/CGBuiltin.cpp:2844
+  return RValue::get(
+  Builder.CreateArithmeticFence(ArgValue, ConvertType(ArgType)));
+return RValue::get(ArgValue);

mibintc wrote:
> mibintc wrote:
> > kpn wrote:
> > > Does this say that the fence will be silently dropped if any of the fast 
> > > math flags are disabled? Silently dropping something used for correctness 
> > > makes me nervous. Is there a case where all of these flags are required 
> > > for correct behavior of the fence?
> > Yes that is the idea, the clang builtin is only meaningful for float 
> > operations when -ffast-math is enabled.  If fast math isn't enabled then 
> > the operations should already be performed strictly.  I didn't have 
> > "isFast", should rewrite with isFast to make it easier to understand 
> Oops I'm wrong. @kbsmith1 tells me only the reassoc bit is interesting. i'll 
> need to fix this in the documentation etc. Thanks for your careful reading. 
BTW in the options parsing, any of the unsafe fp math options freciprocal-math, 
fsigned-zeros and fapprox-func have the effect of enabing 
LangOptions.AllowFPReassoc.  This is in the file Options.td


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100118

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

[PATCH] D100756: [llvm-rc] [4/4] Add a GNU windres-like frontend to llvm-rc

2021-04-21 Thread Martin Storsjö via Phabricator via cfe-commits

mstorsjo marked an inline comment as done.
mstorsjo added inline comments.



Comment at: llvm/tools/llvm-rc/llvm-rc.cpp:300
+
+std::string unescape(StringRef S) {
+  std::string Out;

aganea wrote:
> mstorsjo wrote:
> > aganea wrote:
> > > I would also need this function in D43002 (see unescapeSlashes), do you 
> > > think we can move it to `sys::path` or any other "support" lib?
> > This does things differently than your function - this converts `\\\"` into 
> > `\"` while your version leaves `\\"` if I read it correctly.
> > 
> > (I'm also considering a different, platform specific unescaping strategy - 
> > that'd be closer to how GNU windres behaves, but makes for a more 
> > inconsistent tool. Keeping the logic here makes it easier to tweak if 
> > needed.)
> I think `unescapeSlashes` in D43002 was only a quick hack to allow 
> copy-pasting a command-line file name from LIT outputs into the VS debugger 
> options dialog. If the file name contains double quotes I would expect it to 
> be converted as you do, but double quotes cannot happen in file names on 
> Windows. In theory one could use the `S_OBJNAME` and `LF_BUILDINFO` records 
> to repro a clang-cl build command on Linux, but that seems improbable? (since 
> the feature is meant to be used on Windows)
Hmm, right. In any case - for that patch, I guess one would have to specify 
which unescaping one expects to do.

This one here is (currently) meant to be unix shell unescaping, but it could 
also be unix/windows shell unescaping based on what platform it runs on.



Comment at: llvm/tools/llvm-rc/llvm-rc.cpp:567
+  if (InputArgs.hasArg(OPT_lang_id)) {
+if (InputArgs.getLastArgValue(OPT_lang_id).getAsInteger(16, Opts.LangId))
+  fatalError("Invalid language id: " +

aganea wrote:
> mstorsjo wrote:
> > aganea wrote:
> > > There was a latent issue here - unrelated to the moving of code around - 
> > > I don't know if you want to fix it now or after? That is, `s/16/0/`.
> > Hmm, as far as I can see, both rc.exe and GNU windres interpret values as 
> > hexadecimal - if I run e.g. `rc.exe -l 40 test.rc`, where `40` is 
> > ambiguous, I get language id 64.
> Ok, we only have stuff like `rc.exe /l 0x0409` in our build scripts, the 0x 
> in front isn't consumed, I though it was mandatory.
Ah, I see. I guess that's just good form to be explicit as user, as it indeed 
is quite ambiguous otherwise.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100756

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

[PATCH] D45639: [Driver] Support default libc++ library location on Darwin

2021-04-21 Thread Jonas Devlieghere via Phabricator via cfe-commits

JDevlieghere added a comment.

In D45639#2705919 , @phosek wrote:

> In D45639#2705702 , @ldionne wrote:
>
>> In D45639#2703913 , @JDevlieghere 
>> wrote:
>>
>>> This breaks `TestAppleSimulatorOSType.py ` on GreenDragon. First failed 
>>> build: http://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/31346/
>>> [...]
>>>
>>> Based on your description above, shouldn't it prefer the libc++ form the 
>>> sysroot?
>>
>> Actually, it's the other way around. In the discussion above, we say it's 
>> the toolchain path first, then anything provided with `-L`, and then the 
>> sysroot. Here you have a dylib in the toolchain root (assuming that's what 
>> `jenkins/workspace/lldb-cmake/lldb-build` is), so it's using that. It seems 
>> that the library built in the toolchain root is built for x68_64 (probably 
>> your host), whereas you'd need it to be built for the target (i386 
>> simulator).
>
> Correct, that's exactly what's happening here. Since this bot is only running 
> `check-debuginfo` and `check-lldb`, would it make sense to stop building 
> libcxx altogether (that is drop `libcxx;libcxxabi` from 
> `LLVM_ENABLE_PROJECTS`)? That way the compiler should pick up the one inside 
> the sysroot since that's the only one available.

No, the bot is also meant to catch changes to libc++ breaking LLDB (or at least 
making sure we update the corresponding data formatters). I don't think that 
really matters for the simulator tests though. So if the toolchain takes 
precedence over `-L` too, how can I use the just-built compiler and make sure 
we continue to use the libc++ from the SDK?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D45639

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

[PATCH] D100834: Bug 49739 - [Matrix] Support #pragma clang fp

2021-04-21 Thread Hamza Mahfooz via Phabricator via cfe-commits

effective-light added a comment.

In D100834#2704330 , @fhahn wrote:

> In D100834#2702550 , @kpn wrote:
>
>> I don't know the matrix implementation so I can't swear this hits every 
>> place needed, but the uses of CGFPOptionsRAII in this patch look correct at 
>> least.
>
> Other parts of the extension include `__builtin_matrix_transpose`, indexing 
> into a matrix and casting, but I don't think the FMFs are needed there. One 
> thing that would be good to also test would be the compound operators, (`-=`, 
> `+=`, `*=`). @effective-light it would be great if you could add a test for 
> those, then LGTM from my side. If you need someone to commit the change on 
> your behalf, please let us know and share the name + email to use for the 
> commit authorship.

Ya, you can commit it under `Hamza Mahfooz `, 
thanks.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100834

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

[PATCH] D100834: Bug 49739 - [Matrix] Support #pragma clang fp

2021-04-21 Thread Hamza Mahfooz via Phabricator via cfe-commits

effective-light updated this revision to Diff 339325.
effective-light added a comment.

Add a test for compound operations


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100834

Files:
  clang/lib/CodeGen/CGExprScalar.cpp
  clang/test/CodeGen/fp-matrix-pragma.c


Index: clang/test/CodeGen/fp-matrix-pragma.c
===
--- /dev/null
+++ clang/test/CodeGen/fp-matrix-pragma.c
@@ -0,0 +1,50 @@
+// RUN: %clang -emit-llvm -S -fenable-matrix -mllvm -disable-llvm-optzns %s -o 
- | FileCheck %s
+
+typedef float fx2x2_t __attribute__((matrix_type(2, 2)));
+typedef int ix2x2_t __attribute__((matrix_type(2, 2)));
+
+fx2x2_t fp_matrix_contract(fx2x2_t a, fx2x2_t b, float c, float d) {
+// CHECK: call contract <4 x float> @llvm.matrix.multiply.v4f32.v4f32.v4f32
+// CHECK: fdiv contract <4 x float>
+// CHECK: fmul contract <4 x float>
+#pragma clang fp contract(fast)
+  return (a * b / c) * d;
+}
+
+fx2x2_t fp_matrix_reassoc(fx2x2_t a, fx2x2_t b, fx2x2_t c) {
+// CHECK: fadd reassoc <4 x float>
+// CHECK: fsub reassoc <4 x float>
+#pragma clang fp reassociate(on)
+  return a + b - c;
+}
+
+fx2x2_t fp_matrix_ops(fx2x2_t a, fx2x2_t b, fx2x2_t c) {
+// CHECK: call reassoc contract <4 x float> 
@llvm.matrix.multiply.v4f32.v4f32.v4f32
+// CHECK: fadd reassoc contract <4 x float>
+#pragma clang fp contract(fast) reassociate(on)
+  return a * b + c;
+}
+
+fx2x2_t fp_matrix_compound_ops(fx2x2_t a, fx2x2_t b, fx2x2_t c, fx2x2_t d,
+float e, float f) {
+// CHECK: call reassoc contract <4 x float> 
@llvm.matrix.multiply.v4f32.v4f32.v4f32
+// CHECK: fadd reassoc contract <4 x float>
+// CHECK: fsub reassoc contract <4 x float>
+// CHECK: fmul reassoc contract <4 x float>
+// CHECK: fdiv reassoc contract <4 x float>
+#pragma clang fp contract(fast) reassociate(on)
+  a *= b;
+  a += c;
+  a -= d;
+  a *= e;
+  a /= f;
+
+  return a;
+}
+
+ix2x2_t int_matrix_ops(ix2x2_t a, ix2x2_t b, ix2x2_t c) {
+// CHECK: call <4 x i32> @llvm.matrix.multiply.v4i32.v4i32.v4i32
+// CHECK: add <4 x i32>
+#pragma clang fp contract(fast) reassociate(on)
+  return a * b + c;
+}
Index: clang/lib/CodeGen/CGExprScalar.cpp
===
--- clang/lib/CodeGen/CGExprScalar.cpp
+++ clang/lib/CodeGen/CGExprScalar.cpp
@@ -732,6 +732,7 @@
   BO->getLHS()->getType().getCanonicalType());
   auto *RHSMatTy = dyn_cast(
   BO->getRHS()->getType().getCanonicalType());
+  CodeGenFunction::CGFPOptionsRAII FPOptsRAII(CGF, Ops.FPFeatures);
   if (LHSMatTy && RHSMatTy)
 return MB.CreateMatrixMultiply(Ops.LHS, Ops.RHS, 
LHSMatTy->getNumRows(),
LHSMatTy->getNumColumns(),
@@ -3206,6 +3207,7 @@
 "first operand must be a matrix");
 assert(BO->getRHS()->getType().getCanonicalType()->isArithmeticType() &&
"second operand must be an arithmetic type");
+CodeGenFunction::CGFPOptionsRAII FPOptsRAII(CGF, Ops.FPFeatures);
 return MB.CreateScalarDiv(Ops.LHS, Ops.RHS,
   Ops.Ty->hasUnsignedIntegerRepresentation());
   }
@@ -3585,6 +3587,7 @@
 
   if (op.Ty->isConstantMatrixType()) {
 llvm::MatrixBuilder MB(Builder);
+CodeGenFunction::CGFPOptionsRAII FPOptsRAII(CGF, op.FPFeatures);
 return MB.CreateAdd(op.LHS, op.RHS);
   }
 
@@ -3734,6 +3737,7 @@
 
 if (op.Ty->isConstantMatrixType()) {
   llvm::MatrixBuilder MB(Builder);
+  CodeGenFunction::CGFPOptionsRAII FPOptsRAII(CGF, op.FPFeatures);
   return MB.CreateSub(op.LHS, op.RHS);
 }
 


Index: clang/test/CodeGen/fp-matrix-pragma.c
===
--- /dev/null
+++ clang/test/CodeGen/fp-matrix-pragma.c
@@ -0,0 +1,50 @@
+// RUN: %clang -emit-llvm -S -fenable-matrix -mllvm -disable-llvm-optzns %s -o - | FileCheck %s
+
+typedef float fx2x2_t __attribute__((matrix_type(2, 2)));
+typedef int ix2x2_t __attribute__((matrix_type(2, 2)));
+
+fx2x2_t fp_matrix_contract(fx2x2_t a, fx2x2_t b, float c, float d) {
+// CHECK: call contract <4 x float> @llvm.matrix.multiply.v4f32.v4f32.v4f32
+// CHECK: fdiv contract <4 x float>
+// CHECK: fmul contract <4 x float>
+#pragma clang fp contract(fast)
+  return (a * b / c) * d;
+}
+
+fx2x2_t fp_matrix_reassoc(fx2x2_t a, fx2x2_t b, fx2x2_t c) {
+// CHECK: fadd reassoc <4 x float>
+// CHECK: fsub reassoc <4 x float>
+#pragma clang fp reassociate(on)
+  return a + b - c;
+}
+
+fx2x2_t fp_matrix_ops(fx2x2_t a, fx2x2_t b, fx2x2_t c) {
+// CHECK: call reassoc contract <4 x float> @llvm.matrix.multiply.v4f32.v4f32.v4f32
+// CHECK: fadd reassoc contract <4 x float>
+#pragma clang fp contract(fast) reassociate(on)
+  return a * b + c;
+}
+
+fx2x2_t fp_matrix_compound_ops(fx2x2_t a, fx2x2_t b, fx2x2_t c, fx2x2_t d,
+float e, float f) {
+// CHECK: call reassoc contract <4 x float>

[PATCH] D99233: [HIP] Add option --gpu-inline-threshold

2021-04-21 Thread Artem Belevich via Phabricator via cfe-commits

tra added a comment.

> The planned new option for offloading will be a more generic solution, 
> however, I expect it will take time to develop and be adopted.

Agreed. OK, let's use a hidden option until we have a better way of dealing 
with this.




Comment at: clang/include/clang/Driver/Options.td:954
+def gpu_inline_threshold_EQ : Joined<["--"], "gpu-inline-threshold=">,
+  Flags<[CC1Option]>,
+  HelpText<"Inline threshold for device compilation for HIP">;

This option is only handled at the top level, it does not need `CC1Option`. It 
does need `HelpHidden`.

Also, the option should probably be `-fgpu-inline-threshold=...` as it's a 
parameter tweak, and not something more serious, like `--offload-arch`.
Naming is hard. :-)


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

https://reviews.llvm.org/D99233

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

[PATCH] D100981: Delete le32/le64 targets

2021-04-21 Thread Fangrui Song via Phabricator via cfe-commits

MaskRay created this revision.
MaskRay added a reviewer: dschuff.
Herald added subscribers: dexonsmith, jfb, hiraditya, mgorny.
MaskRay requested review of this revision.
Herald added subscribers: llvm-commits, cfe-commits, aheejin.
Herald added projects: clang, LLVM.

They are unused now.

Note: NaCl is still used and is currently expected to be needed until 2022-06
(https://blog.chromium.org/2020/08/changes-to-chrome-app-support-timeline.html).


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D100981

Files:
  clang/include/clang/Basic/BuiltinsLe64.def
  clang/include/clang/Basic/TargetBuiltins.h
  clang/include/clang/module.modulemap
  clang/lib/Basic/CMakeLists.txt
  clang/lib/Basic/Targets.cpp
  clang/lib/Basic/Targets/Le64.cpp
  clang/lib/Basic/Targets/Le64.h
  clang/lib/Basic/Targets/OSTargets.h
  clang/lib/CodeGen/ItaniumCXXABI.cpp
  clang/lib/CodeGen/TargetInfo.cpp
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/test/CodeGen/ext-int-cc.c
  clang/test/CodeGen/le32-arguments.c
  clang/test/CodeGen/le32-libcall-pow.c
  clang/test/CodeGen/le32-regparm.c
  clang/test/CodeGen/le32-vaarg.c
  clang/test/CodeGen/pr18235.c
  clang/test/CodeGen/target-data.c
  clang/test/CodeGenCXX/member-function-pointers.cpp
  clang/test/CodeGenCXX/static-init-pnacl.cpp
  clang/test/Driver/le32-toolchain.c
  clang/test/Driver/le32-unknown-nacl.cpp
  clang/test/Driver/le64-unknown-unknown.cpp
  clang/test/Headers/stdarg.cpp
  llvm/include/llvm/ADT/Triple.h
  llvm/lib/Support/Triple.cpp
  llvm/test/CodeGen/Generic/no-target.ll
  llvm/unittests/ADT/TripleTest.cpp
  llvm/utils/gn/secondary/clang/lib/Basic/BUILD.gn

Index: llvm/utils/gn/secondary/clang/lib/Basic/BUILD.gn
===
--- llvm/utils/gn/secondary/clang/lib/Basic/BUILD.gn
+++ llvm/utils/gn/secondary/clang/lib/Basic/BUILD.gn
@@ -93,7 +93,6 @@
 "Targets/BPF.cpp",
 "Targets/Hexagon.cpp",
 "Targets/Lanai.cpp",
-"Targets/Le64.cpp",
 "Targets/M68k.cpp",
 "Targets/MSP430.cpp",
 "Targets/Mips.cpp",
Index: llvm/unittests/ADT/TripleTest.cpp
===
--- llvm/unittests/ADT/TripleTest.cpp
+++ llvm/unittests/ADT/TripleTest.cpp
@@ -1044,14 +1044,6 @@
   EXPECT_EQ(Triple::renderscript32, T.get32BitArchVariant().getArch());
   EXPECT_EQ(Triple::renderscript64, T.get64BitArchVariant().getArch());
 
-  T.setArch(Triple::le32);
-  EXPECT_EQ(Triple::le32, T.get32BitArchVariant().getArch());
-  EXPECT_EQ(Triple::le64, T.get64BitArchVariant().getArch());
-
-  T.setArch(Triple::le64);
-  EXPECT_EQ(Triple::le32, T.get32BitArchVariant().getArch());
-  EXPECT_EQ(Triple::le64, T.get64BitArchVariant().getArch());
-
   T.setArch(Triple::armeb);
   EXPECT_EQ(Triple::armeb, T.get32BitArchVariant().getArch());
   EXPECT_EQ(Triple::aarch64_be, T.get64BitArchVariant().getArch());
@@ -1166,14 +1158,6 @@
   EXPECT_EQ(Triple::tce, T.getBigEndianArchVariant().getArch());
   EXPECT_EQ(Triple::tcele, T.getLittleEndianArchVariant().getArch());
 
-  T.setArch(Triple::le32);
-  EXPECT_EQ(Triple::UnknownArch, T.getBigEndianArchVariant().getArch());
-  EXPECT_EQ(Triple::le32, T.getLittleEndianArchVariant().getArch());
-
-  T.setArch(Triple::le64);
-  EXPECT_EQ(Triple::UnknownArch, T.getBigEndianArchVariant().getArch());
-  EXPECT_EQ(Triple::le64, T.getLittleEndianArchVariant().getArch());
-
   T.setArch(Triple::csky);
   EXPECT_EQ(Triple::UnknownArch, T.getBigEndianArchVariant().getArch());
   EXPECT_EQ(Triple::csky, T.getLittleEndianArchVariant().getArch());
Index: llvm/test/CodeGen/Generic/no-target.ll
===
--- llvm/test/CodeGen/Generic/no-target.ll
+++ /dev/null
@@ -1,3 +0,0 @@
-; RUN: not llc -mtriple le32-unknown-nacl %s -o - 2>&1 | FileCheck %s
-
-; CHECK: error: unable to get target for 'le32-unknown-nacl'
Index: llvm/lib/Support/Triple.cpp
===
--- llvm/lib/Support/Triple.cpp
+++ llvm/lib/Support/Triple.cpp
@@ -42,8 +42,6 @@
   case hsail:  return "hsail";
   case kalimba:return "kalimba";
   case lanai:  return "lanai";
-  case le32:   return "le32";
-  case le64:   return "le64";
   case m68k:   return "m68k";
   case mips64: return "mips64";
   case mips64el:   return "mips64el";
@@ -136,9 +134,6 @@
   case nvptx:   return "nvvm";
   case nvptx64: return "nvvm";
 
-  case le32:return "le32";
-  case le64:return "le64";
-
   case amdil:
   case amdil64: return "amdil";
 
@@ -315,8 +310,6 @@
 .Case("xcore", xcore)
 .Case("nvptx", nvptx)
 .Case("nvptx64", nvptx64)
-.Case("le32", le32)
-.Case("le64", le64)
 .Case("amdil", amdil)
 .Case("amdil64", amdil64)
 .Case("hsail", hsail)
@@ -448,8 +441,6 @@
 .Case("xcore", Triple::xcore)
 .Case("nvptx", Triple::nvptx)
 .Case("nvptx64",

[PATCH] D45639: [Driver] Support default libc++ library location on Darwin

2021-04-21 Thread Petr Hosek via Phabricator via cfe-commits

phosek added a comment.

In D45639#2705702 , @ldionne wrote:

> In D45639#2703913 , @JDevlieghere 
> wrote:
>
>> This breaks `TestAppleSimulatorOSType.py ` on GreenDragon. First failed 
>> build: http://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/31346/
>> [...]
>>
>> Based on your description above, shouldn't it prefer the libc++ form the 
>> sysroot?
>
> Actually, it's the other way around. In the discussion above, we say it's the 
> toolchain path first, then anything provided with `-L`, and then the sysroot. 
> Here you have a dylib in the toolchain root (assuming that's what 
> `jenkins/workspace/lldb-cmake/lldb-build` is), so it's using that. It seems 
> that the library built in the toolchain root is built for x68_64 (probably 
> your host), whereas you'd need it to be built for the target (i386 simulator).

Correct, that's exactly what's happening here. Since this bot is only running 
`check-debuginfo` and `check-lldb`, would it make sense to stop building libcxx 
altogether (that is drop `libcxx;libcxxabi` from `LLVM_ENABLE_PROJECTS`)? That 
way the compiler should pick up the one inside the sysroot since that's the 
only one available.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D45639

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

[PATCH] D95976: [OpenMP] Simplify offloading parallel call codegen

2021-04-21 Thread Michael Kruse via Phabricator via cfe-commits

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

This test seem to pass on Windows now. Please still fix the clang-format 
remarks, such as going over 80 characters on a line.




Comment at: clang/lib/CodeGen/CGOpenMPRuntimeGPU.cpp:1150
   llvm::Value *IsMaster =
   Bld.CreateICmpEQ(RT.getGPUThreadID(CGF), getMasterThreadID(CGF));
   Bld.CreateCondBr(IsMaster, MasterBB, EST.ExitBB);

ggeorgakoudis wrote:
> Meinersbur wrote:
> > There seem to be more unordered codegen calls, such as this one.
> Some previous emitted values can be re-used, e.g., GPUThreadID in line 1150 
> can re-use the value from line 1140 , instead of re-emitted. I've kept 
> emitting them as it was previously done. What is the preferred way to handle 
> those? 
`getGPUThreadID`/`getMasterThreadID` could cache the value if used multiple 
times., but it would also require to put them into the entry block to be 
available anywhere in the function.

Otherwise, use a best-effort to minimize overhead even if the optimizer cannot 
unify them or in debug builds.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D95976

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

[PATCH] D99983: Provide TreeTransform::TransformAttr the transformed statement; NFC

2021-04-21 Thread Aaron Ballman via Phabricator via cfe-commits

aaron.ballman updated this revision to Diff 339319.
aaron.ballman added a comment.

Now that [[clang::musttail]] has landed, I can show the refactoring I had in 
mind by implementing it myself. WDYT of this approach?


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

https://reviews.llvm.org/D99983

Files:
  clang/lib/Sema/SemaStmt.cpp
  clang/lib/Sema/SemaStmtAttr.cpp
  clang/lib/Sema/SemaTemplateInstantiate.cpp
  clang/lib/Sema/TreeTransform.h

Index: clang/lib/Sema/TreeTransform.h
===
--- clang/lib/Sema/TreeTransform.h
+++ clang/lib/Sema/TreeTransform.h
@@ -379,8 +379,14 @@
   /// of attribute. Subclasses may override this function to transform
   /// attributed statements using some other mechanism.
   ///
+  /// The \c TransformedStmt parameter points to the substituted statement and
+  /// is non-const explicitly so that transformations of the attribute that
+  /// need to set state on the statement they apply to can do so if needed.
+  /// Note that \c TransformedStmt will be null when transforming type
+  /// attributes.
+  ///
   /// \returns the transformed attribute
-  const Attr *TransformAttr(const Attr *S);
+  const Attr *TransformAttr(const Attr *S, Stmt *TransformedStmt);
 
 /// Transform the specified attribute.
 ///
@@ -388,10 +394,12 @@
 /// spelling to transform expressions stored within the attribute.
 ///
 /// \returns the transformed attribute.
-#define ATTR(X)
-#define PRAGMA_SPELLING_ATTR(X)\
-  const X##Attr *Transform##X##Attr(const X##Attr *R) { return R; }
+#define ATTR(X)\
+  const X##Attr *Transform##X##Attr(const X##Attr *R, Stmt *TransformedStmt) { \
+return R;  \
+  }
 #include "clang/Basic/AttrList.inc"
+#undef ATTR
 
   /// Transform the given expression.
   ///
@@ -6745,7 +6753,8 @@
 
   // oldAttr can be null if we started with a QualType rather than a TypeLoc.
   const Attr *oldAttr = TL.getAttr();
-  const Attr *newAttr = oldAttr ? getDerived().TransformAttr(oldAttr) : nullptr;
+  const Attr *newAttr =
+  oldAttr ? getDerived().TransformAttr(oldAttr, nullptr) : nullptr;
   if (oldAttr && !newAttr)
 return QualType();
 
@@ -7298,19 +7307,20 @@
 }
 
 template 
-const Attr *TreeTransform::TransformAttr(const Attr *R) {
-  if (!R)
-return R;
+const Attr *TreeTransform::TransformAttr(const Attr *A,
+  Stmt *TransformedStmt) {
+  if (!A)
+return A;
 
-  switch (R->getKind()) {
+  switch (A->getKind()) {
 // Transform attributes with a pragma spelling by calling TransformXXXAttr.
-#define ATTR(X)
-#define PRAGMA_SPELLING_ATTR(X)\
+#define ATTR(X)\
   case attr::X:\
-return getDerived().Transform##X##Attr(cast(R));
+return getDerived().Transform##X##Attr(cast(A), TransformedStmt);
 #include "clang/Basic/AttrList.inc"
+#undef ATTR
   default:
-return R;
+return A;
   }
 }
 
@@ -7318,21 +7328,27 @@
 StmtResult
 TreeTransform::TransformAttributedStmt(AttributedStmt *S,
 StmtDiscardKind SDK) {
+  // Transform the attributed statement first so that we can pass the
+  // transformed version in to the attribute handler. This is necessary because
+  // attributes that need to perform semantic checking are more likely to need
+  // the transformed statement than statement semantic checking is likely to
+  // need the transformed attributes. In such a case, the TransformFooAttr()
+  // function can mutate the non-const transformed statement that it is passed.
+  StmtResult SubStmt = getDerived().TransformStmt(S->getSubStmt(), SDK);
+  if (SubStmt.isInvalid())
+return StmtError();
+
   bool AttrsChanged = false;
   SmallVector Attrs;
 
   // Visit attributes and keep track if any are transformed.
   for (const auto *I : S->getAttrs()) {
-const Attr *R = getDerived().TransformAttr(I);
+const Attr *R = getDerived().TransformAttr(I, SubStmt.get());
 AttrsChanged |= (I != R);
 if (R)
   Attrs.push_back(R);
   }
 
-  StmtResult SubStmt = getDerived().TransformStmt(S->getSubStmt(), SDK);
-  if (SubStmt.isInvalid())
-return StmtError();
-
   if (SubStmt.get() == S->getSubStmt() && !AttrsChanged)
 return S;
 
Index: clang/lib/Sema/SemaTemplateInstantiate.cpp
===
--- clang/lib/Sema/SemaTemplateInstantiate.cpp
+++ clang/lib/Sema/SemaTemplateInstantiate.cpp
@@ -1074,7 +1074,10 @@
   NamedDecl *FirstQualifierInScope = nullptr,
   bool AllowInjectedClassName = false);
 
-const LoopHintAttr

[PATCH] D100611: [RISCV] Add new attribute __clang_riscv_builtin_alias for intrinsics.

2021-04-21 Thread Aaron Ballman via Phabricator via cfe-commits

aaron.ballman added inline comments.



Comment at: clang/include/clang/Basic/AttrDocs.td:2147-2150
+This attribute can only be used to set up the aliases for certain RISC-V
+C intrinsic functions; it is intended for use only inside ``riscv_*.h``
+and is not a general mechanism for declaring arbitrary aliases for
+clang builtin functions.

HsiangKai wrote:
> HsiangKai wrote:
> > aaron.ballman wrote:
> > > Why a specific attribute for only one architecture rather than a more 
> > > general solution that can be used for multiple architectures? We already 
> > > have `__clang_arm_builtin_alias` (with the incorrect name, so I guess I 
> > > see where you got the __ from) and now we're extending it. I am not 
> > > certain if there's a reason why we should use a different attribute for 
> > > each target though.
> > I agree with you. We should not define the attribute as target specific. 
> > This patch is a quick solution to address the issue 
> > https://bugs.llvm.org/show_bug.cgi?id=49962.
> > 
> > I will refactor this patch and try to merge it with 
> > `__clang_arm_builtin_alias` in some way.
> @aaron.ballman Could we land this patch first to reduce the test time?
> I agree with you that it is better to have one unified attribute for the 
> purpose. However, if we change the attribute defined by ARM, we need to 
> negotiate with them and there may be already some use cases in their users. I 
> am not sure the impact of the modification.
> 
> I could modify my patch to make the attribute target independent and leave 
> ARM's attribute as before. What do you think?
As best I can tell, at least from the attribute that we surface for the users, 
there shouldn't be much difference between the RISC-V and the ARM attributes. 
They're both accepted on the same subjects, have the same attribute arguments, 
and have the same semantic effect, etc. It seems like the only difference is 
with semantic checking of whether the builtin is valid for the architecture. 
Based on the assumption that these are effectively doing the same thing, I'd 
rather we land the generic attribute so that we can deprecate 
`__clang_arm_builtin_alias` in favor of the general attribute. If we add 
`__clang_riscv_builtin_alias` before adding the generic attribute, it's one 
more thing for us to deprecate and then remove.

Note, I'd be totally fine if the generic attribute only handles ARM and RISC-V 
builtins initially (and error on the other architectures). We can add support 
for other architectures as the need arises.

Do you think that approach makes sense?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100611

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

[clang] 0798842 - [OPENMP]Fix PR49698: OpenMP declare mapper causes segmentation fault.

2021-04-21 Thread Alexey Bataev via cfe-commits


Author: Alexey Bataev
Date: 2021-04-21T10:38:31-07:00
New Revision: 079884225a5571f4caf1a9c71b6748db8192e383

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

LOG: [OPENMP]Fix PR49698: OpenMP declare mapper causes segmentation fault.

The implicitly generated mappings for allocation/deallocation in mappers
runtime should be mapped as implicit, also no need to clear member_of
flag to avoid ref counter increment. Also, the ref counter should not be
incremented for the very first element that comes from the mapper
function.

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

Added: 

openmp/libomptarget/test/mapping/declare_mapper_nested_default_mappers_array.cpp

openmp/libomptarget/test/mapping/declare_mapper_nested_default_mappers_array_subscript.cpp

openmp/libomptarget/test/mapping/declare_mapper_nested_default_mappers_complex_structure.cpp

openmp/libomptarget/test/mapping/declare_mapper_nested_default_mappers_ptr_subscript.cpp

openmp/libomptarget/test/mapping/declare_mapper_nested_default_mappers_var.cpp

Modified: 
clang/lib/CodeGen/CGOpenMPRuntime.cpp
clang/test/OpenMP/declare_mapper_codegen.cpp
openmp/libomptarget/src/omptarget.cpp

Removed: 




diff  --git a/clang/lib/CodeGen/CGOpenMPRuntime.cpp 
b/clang/lib/CodeGen/CGOpenMPRuntime.cpp
index 18ad5066fbba2..0a408837d1c6a 100644
--- a/clang/lib/CodeGen/CGOpenMPRuntime.cpp
+++ b/clang/lib/CodeGen/CGOpenMPRuntime.cpp
@@ -10005,8 +10005,10 @@ void CGOpenMPRuntime::emitUDMapperArrayInitOrDel(
   llvm::Value *MapTypeArg = MapperCGF.Builder.CreateAnd(
   MapType,
   MapperCGF.Builder.getInt64(~(MappableExprsHandler::OMP_MAP_TO |
-   MappableExprsHandler::OMP_MAP_FROM |
-   MappableExprsHandler::OMP_MAP_MEMBER_OF)));
+   MappableExprsHandler::OMP_MAP_FROM)));
+  MapTypeArg = MapperCGF.Builder.CreateOr(
+  MapTypeArg,
+  MapperCGF.Builder.getInt64(MappableExprsHandler::OMP_MAP_IMPLICIT));
 
   // Call the runtime API __tgt_push_mapper_component to fill up the runtime
   // data structure.

diff  --git a/clang/test/OpenMP/declare_mapper_codegen.cpp 
b/clang/test/OpenMP/declare_mapper_codegen.cpp
index 2c488c556a5e3..61eec7a017323 100644
--- a/clang/test/OpenMP/declare_mapper_codegen.cpp
+++ b/clang/test/OpenMP/declare_mapper_codegen.cpp
@@ -118,8 +118,11 @@ class C {
 // CK0: [[INIT]]
 // CK0-64-DAG: [[ARRSIZE:%.+]] = mul nuw i64 [[SIZE]], 16
 // CK0-32-DAG: [[ARRSIZE:%.+]] = mul nuw i64 [[SIZE]], 8
-// CK0-DAG: [[ITYPE:%.+]] = and i64 [[TYPE]], 281474976710652
-// CK0: call void @__tgt_push_mapper_component(i8* [[HANDLE]], i8* [[BPTR]], 
i8* [[BEGIN]], i64 [[ARRSIZE]], i64 [[ITYPE]], {{.*}})
+
+// Remove movement mappings and mark as implicit
+// CK0-DAG: [[ITYPE:%.+]] = and i64 [[TYPE]], -4
+// CK0-DAG: [[ITYPE1:%.+]] = or i64 [[ITYPE]], 512
+// CK0: call void @__tgt_push_mapper_component(i8* [[HANDLE]], i8* [[BPTR]], 
i8* [[BEGIN]], i64 [[ARRSIZE]], i64 [[ITYPE1]], {{.*}})
 // CK0: br label %[[LHEAD:[^,]+]]
 
 // CK0: [[LHEAD]]
@@ -228,8 +231,11 @@ class C {
 // CK0: [[EVALDEL]]
 // CK0-64-DAG: [[ARRSIZE:%.+]] = mul nuw i64 [[SIZE]], 16
 // CK0-32-DAG: [[ARRSIZE:%.+]] = mul nuw i64 [[SIZE]], 8
-// CK0-DAG: [[DTYPE:%.+]] = and i64 [[TYPE]], 281474976710652
-// CK0: call void @__tgt_push_mapper_component(i8* [[HANDLE]], i8* [[BPTR]], 
i8* [[BEGIN]], i64 [[ARRSIZE]], i64 [[DTYPE]], {{.*}})
+
+// Remove movement mappings and mark as implicit
+// CK0-DAG: [[DTYPE:%.+]] = and i64 [[TYPE]], -4
+// CK0-DAG: [[DTYPE1:%.+]] = or i64 [[DTYPE]], 512
+// CK0: call void @__tgt_push_mapper_component(i8* [[HANDLE]], i8* [[BPTR]], 
i8* [[BEGIN]], i64 [[ARRSIZE]], i64 [[DTYPE1]], {{.*}})
 // CK0: br label %[[DONE]]
 // CK0: [[DONE]]
 // CK0: ret void
@@ -672,8 +678,11 @@ class C {
 
 // CK1: [[INITEVALDEL]]
 // CK1-DAG: [[ARRSIZE:%.+]] = mul nuw i64 [[SIZE]], 4
-// CK1-DAG: [[ITYPE:%.+]] = and i64 [[TYPE]], 281474976710652
-// CK1: call void @__tgt_push_mapper_component(i8* [[HANDLE]], i8* [[BPTR]], 
i8* [[BEGIN]], i64 [[ARRSIZE]], i64 [[ITYPE]], {{.*}})
+
+// Remove movement mappings and mark as implicit
+// CK1-DAG: [[ITYPE:%.+]] = and i64 [[TYPE]], -4
+// CK1-DAG: [[ITYPE1:%.+]] = or i64 [[ITYPE]], 512
+// CK1: call void @__tgt_push_mapper_component(i8* [[HANDLE]], i8* [[BPTR]], 
i8* [[BEGIN]], i64 [[ARRSIZE]], i64 [[ITYPE1]], {{.*}})
 // CK1: br label %[[LHEAD:[^,]+]]
 
 // CK1: [[LHEAD]]
@@ -718,8 +727,11 @@ class C {
 // CK1: [[ISNOTDEL:%.+]] = icmp ne i64 [[TYPEDEL]], 0
 // CK1: [[CMP1:%.+]] = and i1 [[ISARRAY]], [[ISNOTDEL]]
 // CK1-DAG: [[ARRSIZE:%.+]] = mul nuw i64 [[SIZE]], 4
-// CK1-DAG: [[DTYPE:%.+]] = and i64 [[TYPE]], 281474976710652
-// CK1: call void @__tgt_push_mapper_component(i8*

[PATCH] D100673: [OPENMP]Fix PR49698: OpenMP declare mapper causes segmentation fault.

2021-04-21 Thread Alexey Bataev 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 rG079884225a55: [OPENMP]Fix PR49698: OpenMP declare mapper 
causes segmentation fault. (authored by ABataev).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100673

Files:
  clang/lib/CodeGen/CGOpenMPRuntime.cpp
  clang/test/OpenMP/declare_mapper_codegen.cpp
  openmp/libomptarget/src/omptarget.cpp
  
openmp/libomptarget/test/mapping/declare_mapper_nested_default_mappers_array.cpp
  
openmp/libomptarget/test/mapping/declare_mapper_nested_default_mappers_array_subscript.cpp
  
openmp/libomptarget/test/mapping/declare_mapper_nested_default_mappers_complex_structure.cpp
  
openmp/libomptarget/test/mapping/declare_mapper_nested_default_mappers_ptr_subscript.cpp
  openmp/libomptarget/test/mapping/declare_mapper_nested_default_mappers_var.cpp

Index: openmp/libomptarget/test/mapping/declare_mapper_nested_default_mappers_var.cpp
===
--- /dev/null
+++ openmp/libomptarget/test/mapping/declare_mapper_nested_default_mappers_var.cpp
@@ -0,0 +1,62 @@
+// RUN: %libomptarget-compilexx-run-and-check-aarch64-unknown-linux-gnu
+// RUN: %libomptarget-compilexx-run-and-check-powerpc64-ibm-linux-gnu
+// RUN: %libomptarget-compilexx-run-and-check-powerpc64le-ibm-linux-gnu
+// RUN: %libomptarget-compilexx-run-and-check-x86_64-pc-linux-gnu
+// RUN: %libomptarget-compilexx-run-and-check-nvptx64-nvidia-cuda
+
+#include 
+#include 
+
+typedef struct {
+  int a;
+  double *b;
+} C1;
+#pragma omp declare mapper(C1 s) map(to : s.a) map(from : s.b [0:2])
+
+typedef struct {
+  int a;
+  double *b;
+  C1 c;
+} C;
+#pragma omp declare mapper(C s) map(to : s.a, s.c) map(from : s.b [0:2])
+
+typedef struct {
+  int e;
+  C f;
+  int h;
+} D;
+
+int main() {
+  constexpr int N = 10;
+  D s;
+  s.e = 111;
+  s.f.a = 222;
+  s.f.c.a = 777;
+  double x[2];
+  double x1[2];
+  x[1] = 20;
+  s.f.b = [0];
+  s.f.c.b = [0];
+  s.h = N;
+
+  printf("%d %d %d %4.5f %d\n", s.e, s.f.a, s.f.c.a, s.f.b[1],
+ s.f.b == [0] ? 1 : 0);
+  // CHECK: 111 222 777 20.0 1
+
+  __intptr_t p = reinterpret_cast<__intptr_t>([0]);
+
+#pragma omp target map(tofrom : s) firstprivate(p)
+  {
+printf("%d %d %d\n", s.f.a, s.f.c.a,
+   s.f.b == reinterpret_cast(p) ? 1 : 0);
+// CHECK: 222 777 0
+s.e = 333;
+s.f.a = 444;
+s.f.c.a = 555;
+s.f.b[1] = 40;
+  }
+
+  printf("%d %d %d %4.5f %d\n", s.e, s.f.a, s.f.c.a, s.f.b[1],
+ s.f.b == [0] ? 1 : 0);
+  // CHECK: 333 222 777 40.0 1
+}
Index: openmp/libomptarget/test/mapping/declare_mapper_nested_default_mappers_ptr_subscript.cpp
===
--- /dev/null
+++ openmp/libomptarget/test/mapping/declare_mapper_nested_default_mappers_ptr_subscript.cpp
@@ -0,0 +1,62 @@
+// RUN: %libomptarget-compilexx-run-and-check-aarch64-unknown-linux-gnu
+// RUN: %libomptarget-compilexx-run-and-check-powerpc64-ibm-linux-gnu
+// RUN: %libomptarget-compilexx-run-and-check-powerpc64le-ibm-linux-gnu
+// RUN: %libomptarget-compilexx-run-and-check-x86_64-pc-linux-gnu
+// RUN: %libomptarget-compilexx-run-and-check-nvptx64-nvidia-cuda
+
+#include 
+#include 
+
+typedef struct {
+  int a;
+  double *b;
+} C1;
+#pragma omp declare mapper(C1 s) map(to : s.a) map(from : s.b [0:2])
+
+typedef struct {
+  int a;
+  double *b;
+  C1 c;
+} C;
+#pragma omp declare mapper(C s) map(to : s.a, s.c) map(from : s.b [0:2])
+
+typedef struct {
+  int e;
+  C f;
+  int h;
+} D;
+
+int main() {
+  constexpr int N = 10;
+  D s;
+  s.e = 111;
+  s.f.a = 222;
+  s.f.c.a = 777;
+  double x[2];
+  double x1[2];
+  x[1] = 20;
+  s.f.b = [0];
+  s.f.c.b = [0];
+  s.h = N;
+
+  D *sp = 
+
+  printf("%d %d %d %4.5f %d\n", sp[0].e, sp[0].f.a, sp[0].f.c.a, sp[0].f.b[1],
+ sp[0].f.b == [0] ? 1 : 0);
+  // CHECK: 111 222 777 20.0 1
+
+  __intptr_t p = reinterpret_cast<__intptr_t>([0]);
+#pragma omp target map(tofrom : sp[0]) firstprivate(p)
+  {
+printf("%d %d %d\n", sp[0].f.a, sp[0].f.c.a,
+   sp[0].f.b == reinterpret_cast(p) ? 1 : 0);
+// CHECK: 222 777 0
+sp[0].e = 333;
+sp[0].f.a = 444;
+sp[0].f.c.a = 555;
+sp[0].f.b[1] = 40;
+  }
+  printf("%d %d %d %4.5f %d\n", sp[0].e, sp[0].f.a, sp[0].f.c.a, sp[0].f.b[1],
+ sp[0].f.b == [0] ? 1 : 0);
+  // CHECK: 333 222 777 40.0 1
+}
Index: openmp/libomptarget/test/mapping/declare_mapper_nested_default_mappers_complex_structure.cpp
===
--- /dev/null
+++ openmp/libomptarget/test/mapping/declare_mapper_nested_default_mappers_complex_structure.cpp
@@ -0,0 +1,129 @@
+// RUN: %libomptarget-compilexx-run-and-check-aarch64-unknown-linux-gnu
+// RUN: %libomptarget-compilexx-run-and-check-powerpc64-ibm-linux-gnu
+// RUN:

[PATCH] D100980: [OpenCL] Allow use of double type without extension pragma

2021-04-21 Thread Anastasia Stulova via Phabricator via cfe-commits

Anastasia created this revision.
Anastasia added reviewers: svenvh, azabaznov.
Herald added subscribers: ebevhan, yaxunl.
Anastasia requested review of this revision.

OpenCL specification doesn't require the pragma for the uses of `double` type 
when it is supported by the targets. The wording in the spec is as follows:

> 80. Only if double precision is supported. In OpenCL C 3.0 this will be 
> indicated by the presence of the __opencl_c_fp64 feature macro.

in contrast to `half` type

> 79. Only if the cl_khr_fp16 extension is supported and has been enabled.

This is primarily due to the fact that `double` is a type from C99 spec where 
it can be used without any pragmas. This is to align the core OpenCL behavior 
with C.


https://reviews.llvm.org/D100980

Files:
  clang/lib/Sema/Sema.cpp
  clang/lib/Sema/SemaType.cpp
  clang/test/SemaOpenCL/extensions.cl


Index: clang/test/SemaOpenCL/extensions.cl
===
--- clang/test/SemaOpenCL/extensions.cl
+++ clang/test/SemaOpenCL/extensions.cl
@@ -43,9 +43,17 @@
 #endif
 
 #if (defined(__OPENCL_C_VERSION__) && __OPENCL_C_VERSION__ < 120)
-void f1(double da) { // expected-error {{type 'double' requires cl_khr_fp64 
support}}
-  double d; // expected-error {{type 'double' requires cl_khr_fp64 support}}
-  (void) 1.0; // expected-warning {{double precision constant requires 
cl_khr_fp64}}
+void f1(double da) {
+#ifdef NOFP64
+// expected-error@-2 {{type 'double' requires cl_khr_fp64 support}}
+#endif
+  double d;
+#ifdef NOFP64
+// expected-error@-2 {{type 'double' requires cl_khr_fp64 support}}
+#endif
+  // FIXME: this diagnostic depends on the extension pragma in the earlier 
versions.
+  // There is no indication that this behavior is expected.
+  (void)1.0; // expected-warning {{double precision constant requires 
cl_khr_fp64}}
 }
 #endif
 
@@ -79,13 +87,11 @@
   double4 d4 = {0.0f, 2.0f, 3.0f, 1.0f};
 #ifdef NOFP64
 // expected-error@-3 {{use of type 'double' requires cl_khr_fp64 support}}
-// expected-error@-3 {{use of type 'double4' (vector of 4 'double' values) 
requires cl_khr_fp64 support}}
 #endif
 
-  (void) 1.0;
-
+  (void)1.0;
 #ifdef NOFP64
-// expected-warning@-3{{double precision constant requires cl_khr_fp64, 
casting to single precision}}
+// expected-warning@-2{{double precision constant requires cl_khr_fp64, 
casting to single precision}}
 #endif
 }
 
@@ -96,6 +102,9 @@
 
 #if (defined(__OPENCL_C_VERSION__) && __OPENCL_C_VERSION__ < 120)
 void f3(void) {
-  double d; // expected-error {{type 'double' requires cl_khr_fp64 support}}
+  double d;
+#ifdef NOFP64
+// expected-error@-2 {{type 'double' requires cl_khr_fp64 support}}
+#endif
 }
 #endif
Index: clang/lib/Sema/SemaType.cpp
===
--- clang/lib/Sema/SemaType.cpp
+++ clang/lib/Sema/SemaType.cpp
@@ -1524,6 +1524,10 @@
 break;
   case DeclSpec::TST_float:   Result = Context.FloatTy; break;
   case DeclSpec::TST_double:
+if (S.getLangOpts().OpenCL &&
+!S.getOpenCLOptions().isSupported("cl_khr_fp64", S.getLangOpts()))
+  S.Diag(DS.getTypeSpecTypeLoc(), diag::err_opencl_requires_extension)
+  << 0 << Context.DoubleTy << "cl_khr_fp64";
 if (DS.getTypeSpecWidth() == TypeSpecifierWidth::Long)
   Result = Context.LongDoubleTy;
 else
Index: clang/lib/Sema/Sema.cpp
===
--- clang/lib/Sema/Sema.cpp
+++ clang/lib/Sema/Sema.cpp
@@ -363,7 +363,6 @@
   }
 }
 
-setOpenCLExtensionForType(Context.DoubleTy, "cl_khr_fp64");
 
 #define GENERIC_IMAGE_TYPE_EXT(Type, Id, Ext) \
 setOpenCLExtensionForType(Context.Id, Ext);


Index: clang/test/SemaOpenCL/extensions.cl
===
--- clang/test/SemaOpenCL/extensions.cl
+++ clang/test/SemaOpenCL/extensions.cl
@@ -43,9 +43,17 @@
 #endif
 
 #if (defined(__OPENCL_C_VERSION__) && __OPENCL_C_VERSION__ < 120)
-void f1(double da) { // expected-error {{type 'double' requires cl_khr_fp64 support}}
-  double d; // expected-error {{type 'double' requires cl_khr_fp64 support}}
-  (void) 1.0; // expected-warning {{double precision constant requires cl_khr_fp64}}
+void f1(double da) {
+#ifdef NOFP64
+// expected-error@-2 {{type 'double' requires cl_khr_fp64 support}}
+#endif
+  double d;
+#ifdef NOFP64
+// expected-error@-2 {{type 'double' requires cl_khr_fp64 support}}
+#endif
+  // FIXME: this diagnostic depends on the extension pragma in the earlier versions.
+  // There is no indication that this behavior is expected.
+  (void)1.0; // expected-warning {{double precision constant requires cl_khr_fp64}}
 }
 #endif
 
@@ -79,13 +87,11 @@
   double4 d4 = {0.0f, 2.0f, 3.0f, 1.0f};
 #ifdef NOFP64
 // expected-error@-3 {{use of type 'double' requires cl_khr_fp64 support}}
-// expected-error@-3 {{use of type 'double4' (vector of 4 'double' values) requires cl_khr_fp64 support}}
 #endif
 
-

[PATCH] D100907: [lsan][docs] Clarify supported platforms

2021-04-21 Thread Fangrui Song via Phabricator via cfe-commits

This revision was automatically updated to reflect the committed changes.
Closed by commit rG4cbe4881882e: [lsan][docs] Clarify supported platforms 
(authored by MaskRay).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100907

Files:
  clang/docs/LeakSanitizer.rst


Index: clang/docs/LeakSanitizer.rst
===
--- clang/docs/LeakSanitizer.rst
+++ clang/docs/LeakSanitizer.rst
@@ -17,8 +17,8 @@
 Usage
 =
 
-LeakSanitizer is supported on x86\_64 Linux and macOS. In order to use it,
-simply build your program with :doc:`AddressSanitizer`:
+:doc:`AddressSanitizer`: integrates LeakSanitizer and enables it by default on
+supported platforms.
 
 .. code-block:: console
 
@@ -43,6 +43,15 @@
 link step, so that it would link in proper LeakSanitizer run-time library
 into the final executable.
 
+Supported Platforms
+===
+
+* Android aarch64/i386/x86_64
+* Fuchsia aarch64/x86_64
+* Linux arm/aarch64/mips64/ppc64/ppc64le/riscv64/s390x/i386/x86\_64
+* macOS aarch64/i386/x86\_64
+* NetBSD i386/x86_64
+
 More Information
 
 


Index: clang/docs/LeakSanitizer.rst
===
--- clang/docs/LeakSanitizer.rst
+++ clang/docs/LeakSanitizer.rst
@@ -17,8 +17,8 @@
 Usage
 =
 
-LeakSanitizer is supported on x86\_64 Linux and macOS. In order to use it,
-simply build your program with :doc:`AddressSanitizer`:
+:doc:`AddressSanitizer`: integrates LeakSanitizer and enables it by default on
+supported platforms.
 
 .. code-block:: console
 
@@ -43,6 +43,15 @@
 link step, so that it would link in proper LeakSanitizer run-time library
 into the final executable.
 
+Supported Platforms
+===
+
+* Android aarch64/i386/x86_64
+* Fuchsia aarch64/x86_64
+* Linux arm/aarch64/mips64/ppc64/ppc64le/riscv64/s390x/i386/x86\_64
+* macOS aarch64/i386/x86\_64
+* NetBSD i386/x86_64
+
 More Information
 
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] 4cbe488 - [lsan][docs] Clarify supported platforms

2021-04-21 Thread Fangrui Song via cfe-commits


Author: Fangrui Song
Date: 2021-04-21T10:27:55-07:00
New Revision: 4cbe4881882edd64a7ff53da52970c4b6333de1c

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

LOG: [lsan][docs] Clarify supported platforms

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

Added: 


Modified: 
clang/docs/LeakSanitizer.rst

Removed: 




diff  --git a/clang/docs/LeakSanitizer.rst b/clang/docs/LeakSanitizer.rst
index 53a3ee15055c8..6858f32957ebe 100644
--- a/clang/docs/LeakSanitizer.rst
+++ b/clang/docs/LeakSanitizer.rst
@@ -17,8 +17,8 @@ detection phase.
 Usage
 =
 
-LeakSanitizer is supported on x86\_64 Linux and macOS. In order to use it,
-simply build your program with :doc:`AddressSanitizer`:
+:doc:`AddressSanitizer`: integrates LeakSanitizer and enables it by default on
+supported platforms.
 
 .. code-block:: console
 
@@ -43,6 +43,15 @@ To use LeakSanitizer in stand-alone mode, link your program 
with
 link step, so that it would link in proper LeakSanitizer run-time library
 into the final executable.
 
+Supported Platforms
+===
+
+* Android aarch64/i386/x86_64
+* Fuchsia aarch64/x86_64
+* Linux arm/aarch64/mips64/ppc64/ppc64le/riscv64/s390x/i386/x86\_64
+* macOS aarch64/i386/x86\_64
+* NetBSD i386/x86_64
+
 More Information
 
 



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

[PATCH] D100581: [Clang] -Wunused-but-set-parameter and -Wunused-but-set-variable

2021-04-21 Thread Dávid Bolvanský via Phabricator via cfe-commits

xbolva00 added a comment.

Thanks, looks really good.

Meanwhile I collected some interesting testcases from gcc bugzilla (reported as 
false positives), please try:
https://godbolt.org/z/747ndKEvd - No "unused-but-set" warnings expected.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100581

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

[PATCH] D100976: [OpenCL] Simplify use of C11 atomic types

2021-04-21 Thread Anastasia Stulova via Phabricator via cfe-commits

Anastasia created this revision.
Anastasia added reviewers: svenvh, azabaznov.
Herald added subscribers: ebevhan, jfb, yaxunl.
Anastasia requested review of this revision.

Clang's implementation of the extension pragma is broken because it doesn't 
respect the following requirement from OpenCL Extension spec s1.2:

https://www.khronos.org/registry/OpenCL/specs/3.0-unified/html/OpenCL_Ext.html#extensions-overview

> **disable**  Behave (including issuing errors and warnings) as if the 
> extension extension_name is not part of the language definition.

This means that extension functionality should not be exposed by default and if 
extension identifiers are not reserved they should not be recognized by the 
compiler. This is for example the case for some of the atomic types (i.e. 64 
bit types) from extensions.

As fixing the implementation of extension pragma is not feasible and it will 
affect backward compatibility and require significant rework in the parser this 
patch simplifies the implementation of pragma by making the behavior as 
consistent and intuitive as possible.

This change removes the requirement on pragma when atomic types from the 
extensions are supported because the behavior is not conformant. With this 
change, the developers can use atomic types from the extensions if they are 
supported without enabling the pragma because disabling the pragma doesn't do 
anything useful but only prevents the use of already available identifiers for 
types and issues extra diagnostics. This makes semantics consistent with the 
atomic functions that are also available when the extension is supported 
without any need for the pragma.

This patch does not break backward compatibility since the extension pragma is 
still supported and it makes the behavior of the compiler less strict by 
accepting code without extra pragma statements.

Note that there is an ongoing thread to alter the behavior in the spec
https://github.com/KhronosGroup/OpenCL-Docs/issues/82
however this change is orthogonal as it simplifies the current implementation 
that is not conformant.
Any new functionality can be added later if the behavior in the spec is fixed.


https://reviews.llvm.org/D100976

Files:
  clang/lib/Sema/Sema.cpp
  clang/test/Parser/opencl-atomics-cl20.cl

Index: clang/test/Parser/opencl-atomics-cl20.cl
===
--- clang/test/Parser/opencl-atomics-cl20.cl
+++ clang/test/Parser/opencl-atomics-cl20.cl
@@ -1,67 +1,76 @@
 // RUN: %clang_cc1 %s -triple spir-unknown-unknown -verify -pedantic -fsyntax-only
-// RUN: %clang_cc1 %s -triple spir-unknown-unknown -verify -fsyntax-only -cl-std=CL2.0 -DCL20
-// RUN: %clang_cc1 %s -triple spir64-unknown-unknown -verify -fsyntax-only -cl-std=CL2.0 -DCL20
-// RUN: %clang_cc1 %s -triple spir-unknown-unknown -verify -fsyntax-only -cl-std=CL2.0 -DCL20 -DEXT -Wpedantic-core-features
+// RUN: %clang_cc1 %s -triple spir-unknown-unknown -verify -fsyntax-only -cl-std=CL2.0 -cl-ext=-cl_khr_int64_base_atomics
+// RUN: %clang_cc1 %s -triple spir64-unknown-unknown -verify -fsyntax-only -cl-std=CL2.0
+// RUN: %clang_cc1 %s -triple spir64-unknown-unknown -verify -fsyntax-only -cl-std=CLC++
+// RUN: %clang_cc1 %s -triple spir64-unknown-unknown -verify -fsyntax-only -cl-std=CL2.0 -cl-ext=-cl_khr_int64_base_atomics
 
-#ifdef EXT
-#pragma OPENCL EXTENSION cl_khr_int64_base_atomics:enable
-#pragma OPENCL EXTENSION cl_khr_int64_extended_atomics:enable
-#pragma OPENCL EXTENSION cl_khr_fp64:enable
-#if __OPENCL_C_VERSION__ >= CL_VERSION_1_2
-// expected-warning@-2{{OpenCL extension 'cl_khr_fp64' is core feature or supported optional core feature - ignoring}}
-#endif
+#if defined(__OPENCL_CPP_VERSION__) || __OPENCL_C_VERSION__ >= CL_VERSION_1_2
+#define LANG_VER_OK
 #endif
 
 void atomic_types_test() {
-// OpenCL v2.0 s6.13.11.6 defines supported atomic types.
+  // OpenCL v2.0 s6.13.11.6 defines supported atomic types.
+
+  // Non-optional types
   atomic_int i;
   atomic_uint ui;
+  atomic_float f;
+  atomic_flag fl;
+#if !defined(LANG_VER_OK)
+// expected-error@-5 {{use of undeclared identifier 'atomic_int'}}
+// expected-error@-5 {{use of undeclared identifier 'atomic_uint'}}
+// expected-error@-5 {{use of undeclared identifier 'atomic_float'}}
+// expected-error@-5 {{use of undeclared identifier 'atomic_flag'}}
+#endif
+
+  // Optional types
   atomic_long l;
   atomic_ulong ul;
-  atomic_float f;
   atomic_double d;
-  atomic_flag fl;
+  atomic_size_t s;
   atomic_intptr_t ip;
   atomic_uintptr_t uip;
-  atomic_size_t s;
   atomic_ptrdiff_t pd;
-// OpenCL v2.0 s6.13.11.8, _Atomic type specifier and _Atomic type qualifier
-// are not supported by OpenCL.
-  _Atomic int i; // expected-error {{use of undeclared identifier '_Atomic'}}
-}
-#ifndef CL20
-// expected-error@-16 {{use of undeclared identifier 'atomic_int'}}
-// expected-error@-16 {{use of undeclared identifier 'atomic_uint'}}
-// expected-error@-16 {{use of undeclared identifier

[PATCH] D100276: [clang] p1099 using enum part 1

2021-04-21 Thread Nathan Sidwell via Phabricator via cfe-commits

urnathan updated this revision to Diff 339293.
urnathan added a comment.

Updated to fix formatting etc (pretty sure I got clang-format to work this 
time).  I changed the pre-c++20 behaviour to be a warning along the lines you 
suggested.  Trying to move the qualifier checking until after generating the 
shadow decls died horribly -- the shadow generation presumes the context is 
sane :(

As mentioned, I intend updating docs and feature macro once the second half is 
done.


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

https://reviews.llvm.org/D100276

Files:
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Sema/Sema.h
  clang/lib/Sema/SemaDeclCXX.cpp
  clang/lib/Sema/SemaTemplateInstantiateDecl.cpp
  clang/test/CXX/dcl.dcl/basic.namespace/namespace.udecl/p3.cpp
  clang/test/CXX/dcl.dcl/basic.namespace/namespace.udecl/p7-cxx20.cpp
  clang/test/CXX/dcl.dcl/basic.namespace/namespace.udecl/p7.cpp
  clang/test/SemaCXX/enum-scoped.cpp

Index: clang/test/SemaCXX/enum-scoped.cpp
===
--- clang/test/SemaCXX/enum-scoped.cpp
+++ clang/test/SemaCXX/enum-scoped.cpp
@@ -301,8 +301,8 @@
   int E::*p; // expected-error {{does not point into a class}}
   using E::f; // expected-error {{no member named 'f'}}
 
-  using E::a; // expected-error {{using declaration cannot refer to a scoped enumerator}}
-  E b = a; // expected-error {{undeclared}}
+  using E::a; // expected-warning {{using declaration naming a scoped enumerator is a C++20 extension}}
+  E b = a;
 }
 
 namespace test11 {
Index: clang/test/CXX/dcl.dcl/basic.namespace/namespace.udecl/p7.cpp
===
--- clang/test/CXX/dcl.dcl/basic.namespace/namespace.udecl/p7.cpp
+++ clang/test/CXX/dcl.dcl/basic.namespace/namespace.udecl/p7.cpp
@@ -1,4 +1,11 @@
 // RUN: %clang_cc1 -std=c++11 -verify %s
+// RUN: %clang_cc1 -std=c++17 -verify %s
+// RUN: %clang_cc1 -std=c++20 -verify %s
 
 enum class EC { ec };
-using EC::ec; // expected-error {{using declaration cannot refer to a scoped enumerator}}
+using EC::ec;
+#if __cplusplus < 202002
+// expected-warning@-2 {{using declaration naming a scoped enumerator is a C++20 extension}}
+#else
+// expected-no-diagnostics
+#endif
Index: clang/test/CXX/dcl.dcl/basic.namespace/namespace.udecl/p7-cxx20.cpp
===
--- /dev/null
+++ clang/test/CXX/dcl.dcl/basic.namespace/namespace.udecl/p7-cxx20.cpp
@@ -0,0 +1,149 @@
+// RUN: %clang_cc1 -fsyntax-only -std=c++17 -verify %s
+// RUN: %clang_cc1 -fsyntax-only -std=c++20 -verify %s
+
+// p1099 'using SCOPEDENUM::MEMBER;'
+
+namespace Bob {
+enum class Kevin {
+  Stuart,
+  AlsoStuart
+#if __cplusplus >= 202002L
+// expected-note@-3{{target of using declaration}}
+// expected-note@-3{{target of using declaration}}
+#endif
+};
+} // namespace Bob
+
+using Bob::Kevin::Stuart;
+#if __cplusplus < 202002L
+// expected-warning@-2{{using declaration naming a scoped enumerator is a C++20 extension}}
+#else
+using Bob::Kevin::Stuart;
+
+auto b = Stuart;
+
+namespace Foo {
+int Stuart;   // expected-note{{conflicting declaration}}
+using Bob::Kevin::Stuart; // expected-error{{target of using declaration conflicts}}
+
+using Bob::Kevin::AlsoStuart; // expected-note{{using declaration}}
+int AlsoStuart;   // expected-error{{declaration conflicts with target}}
+} // namespace Foo
+#endif
+
+namespace One {
+
+// derived from [namespace.udecl]/3
+enum class button { up,
+down };
+struct S {
+  using button::up;
+#if __cplusplus < 202002L
+  // expected-error@-2{{using declaration in class}}
+#else
+  button b = up;
+#endif
+};
+
+#if __cplusplus >= 202002L
+// some more
+struct T : S {
+  button c = up;
+};
+#endif
+enum E2 { e2 };
+} // namespace One
+
+namespace Two {
+enum class E1 { e1 };
+
+struct S {
+  using One::e2;
+#if __cplusplus < 202002L
+  // expected-error@-2{{using declaration in class}}
+#else
+  One::E2 c = e2;
+#endif
+};
+
+} // namespace Two
+
+namespace Three {
+
+enum E3 { e3 };
+struct e3;
+
+struct S {
+  using Three::e3; // expected-error{{using declaration in class}}
+
+  enum class E4 { e4 };
+  enum E5 { e5 };
+};
+
+using S::e5;
+using S::E4::e4;
+#if __cplusplus < 202002L
+// expected-error@-3{{using declaration cannot refer to class member}}
+// expected-note@-4{{use a constexpr variable instead}}
+// expected-warning@-4{{using declaration naming a scoped enumerator is a C++20 extension}}
+#else
+auto a = e4;
+auto b = e5;
+#endif
+} // namespace Three
+
+namespace Four {
+
+template 
+struct TPL {
+  enum class E1 { e1 };
+  struct IN {
+enum class E2 { e2 };
+  };
+
+protected:
+  enum class E3 { e3 }; // expected-note{{declared protected here}}
+};
+
+using TPL::E1::e1;
+#if __cplusplus < 202002L
+// expected-warning@-2{{using declaration naming a scoped enumerator is a C++20 extension}}
+#else
+using

[PATCH] D45639: [Driver] Support default libc++ library location on Darwin

2021-04-21 Thread Louis Dionne via Phabricator via cfe-commits

ldionne added a comment.

In D45639#2703913 , @JDevlieghere 
wrote:

> This breaks `TestAppleSimulatorOSType.py ` on GreenDragon. First failed 
> build: http://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/31346/
> [...]
>
> Based on your description above, shouldn't it prefer the libc++ form the 
> sysroot?

Actually, it's the other way around. In the discussion above, we say it's the 
toolchain path first, then anything provided with `-L`, and then the sysroot. 
Here you have a dylib in the toolchain root (assuming that's what 
`jenkins/workspace/lldb-cmake/lldb-build` is), so it's using that. It seems 
that the library built in the toolchain root is built for x68_64 (probably your 
host), whereas you'd need it to be built for the target (i386 simulator).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D45639

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

[PATCH] D100955: [-Wcalled-once] Do not run analysis on Obj-C++

2021-04-21 Thread Artem Dergachev via Phabricator via cfe-commits

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

Ok then!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100955

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

[PATCH] D100972: [clang-tidy] cppcoreguidelines-avoid-non-const-global-variables: add fixes to checks

2021-04-21 Thread Marco Gartmann via Phabricator via cfe-commits

mgartmann created this revision.
mgartmann added reviewers: aaron.ballman, njames93, alexfh.
mgartmann added a project: clang-tools-extra.
Herald added subscribers: shchenz, kbarton, xazax.hun, nemanjai.
mgartmann requested review of this revision.

I added fixes to the existing checks of 
`cppcoreguidelines-avoid-non-const-global-variables`.

To fix the `non-const_variable` case, it utilizes QualType::addConst 

 to make the non-const type constant.

For the `indirection_to_non-const` case, for the sake of simplicity of this 
check, the `const` keyword is simply inserted at the variable declaration's 
beginning. If someone knows a more elegant solution to this, I am happy to 
adapt it.

Thanks in advance for any feedback!


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D100972

Files:
  
clang-tools-extra/clang-tidy/cppcoreguidelines/AvoidNonConstGlobalVariablesCheck.cpp
  
clang-tools-extra/clang-tidy/cppcoreguidelines/AvoidNonConstGlobalVariablesCheck.h
  clang-tools-extra/docs/ReleaseNotes.rst
  
clang-tools-extra/docs/clang-tidy/checks/cppcoreguidelines-avoid-non-const-global-variables.rst
  
clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines-avoid-non-const-global-variables.cpp

Index: clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines-avoid-non-const-global-variables.cpp
===
--- clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines-avoid-non-const-global-variables.cpp
+++ clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines-avoid-non-const-global-variables.cpp
@@ -2,20 +2,25 @@
 
 int nonConstInt = 0;
 // CHECK-MESSAGES: :[[@LINE-1]]:5: warning: variable 'nonConstInt' is non-const and globally accessible, consider making it const [cppcoreguidelines-avoid-non-const-global-variables]
+// CHECK-FIXES: const int nonConstInt = 0;
 
 int  = nonConstInt;
 // CHECK-MESSAGES: :[[@LINE-1]]:6: warning: variable 'nonConstIntReference' provides global access to a non-const object; consider making the referenced data 'const' [cppcoreguidelines-avoid-non-const-global-variables]
+// CHECK-FIXES: const int  = nonConstInt;
 
 int *pointerToNonConstInt = 
 // CHECK-MESSAGES: :[[@LINE-1]]:6: warning: variable 'pointerToNonConstInt' is non-const and globally accessible, consider making it const [cppcoreguidelines-avoid-non-const-global-variables]
 // CHECK-MESSAGES: :[[@LINE-2]]:6: warning: variable 'pointerToNonConstInt' provides global access to a non-const object; consider making the pointed-to data 'const' [cppcoreguidelines-avoid-non-const-global-variables]
+// CHECK-FIXES: const int *const pointerToNonConstInt = 
 
 int *const constPointerToNonConstInt = 
 // CHECK-MESSAGES: :[[@LINE-1]]:12: warning: variable 'constPointerToNonConstInt' provides global access to a non-const object; consider making the pointed-to data 'const' [cppcoreguidelines-avoid-non-const-global-variables]
+// CHECK-FIXES: const int *const constPointerToNonConstInt = 
 
 namespace namespace_name {
 int nonConstNamespaceInt = 0;
 // CHECK-MESSAGES: :[[@LINE-1]]:5: warning: variable 'nonConstNamespaceInt' is non-const and globally accessible, consider making it const [cppcoreguidelines-avoid-non-const-global-variables]
+// CHECK-FIXES: const int nonConstNamespaceInt = 0;
 
 const int constNamespaceInt = 0;
 } // namespace namespace_name
@@ -24,6 +29,7 @@
 
 const int *pointerToConstInt = 
 // CHECK-MESSAGES: :[[@LINE-1]]:12: warning: variable 'pointerToConstInt' is non-const and globally accessible, consider making it const [cppcoreguidelines-avoid-non-const-global-variables]
+// CHECK-FIXES: const int *const pointerToConstInt = 
 
 const int *const constPointerToConstInt = 
 
@@ -39,6 +45,7 @@
 namespace {
 int nonConstAnonymousNamespaceInt = 0;
 // CHECK-MESSAGES: :[[@LINE-1]]:5: warning: variable 'nonConstAnonymousNamespaceInt' is non-const and globally accessible, consider making it const [cppcoreguidelines-avoid-non-const-global-variables]
+// CHECK-FIXES: const int nonConstAnonymousNamespaceInt = 0;
 } // namespace
 
 class DummyClass {
@@ -53,27 +60,35 @@
 
 DummyClass nonConstClassInstance;
 // CHECK-MESSAGES: :[[@LINE-1]]:12: warning: variable 'nonConstClassInstance' is non-const and globally accessible, consider making it const [cppcoreguidelines-avoid-non-const-global-variables]
+// CHECK-FIXES: const DummyClass nonConstClassInstance;
 
 DummyClass *pointerToNonConstDummyClass = 
 // CHECK-MESSAGES: :[[@LINE-1]]:13: warning: variable 'pointerToNonConstDummyClass' is non-const and globally accessible, consider making it const [cppcoreguidelines-avoid-non-const-global-variables]
 // CHECK-MESSAGES: :[[@LINE-2]]:13: warning: variable 'pointerToNonConstDummyClass' provides global access to a non-const object; consider making the pointed-to data 'const' [cppcoreguidelines-avoid-non-const-global-variables]
+// CHECK-FIXES: const

[PATCH] D100968: Update shebang for clang-format-diff script to python3.

2021-04-21 Thread Paula Toth via Phabricator via cfe-commits

PaulkaToast added a comment.

In D100968#2705598 , @MaskRay wrote:

>> On newer Linux distributions
>
> Different distributions have different strategies migrating the 
> /usr/bin/python symlink. Debian and its derivatives provide python-is-python2 
> and python-is-python3. If neither is installed, the user gets no 
> `/usr/bin/python`.
>
> LG with this clarified.

Thank you, added to the change description for more context. (:


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100968

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

[PATCH] D100968: Update shebang for clang-format-diff script to python3.

2021-04-21 Thread Fangrui Song via Phabricator via cfe-commits

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

> On newer Linux distributions

Different distributions have different strategies migrating the /usr/bin/python 
symlink. Debian and its derivatives provide python-is-python2 and 
python-is-python3. If neither is installed, the user gets no `/usr/bin/python`.

LG with this clarified.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100968

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

[PATCH] D100874: [OpenMP] Use irbuilder as default for masked and master construct

2021-04-21 Thread Chi Chun Chen via Phabricator via cfe-commits

cchen added a comment.

> what assertion?



  $ ":" "RUN: at line 1"
  $ "/mnt/disks/ssd0/agent/llvm-project/build/./bin/clang" "-fopenmp" 
"-pthread" "-fno-experimental-isel" "-I" 
"/mnt/disks/ssd0/agent/llvm-project/openmp/runtime/test" "-I" 
"/mnt/disks/ssd0/agent/llvm-project/build/projects/openmp/runtime/src" "-L" 
"/mnt/disks/ssd0/agent/llvm-project/build/lib" "-I" 
"/mnt/disks/ssd0/agent/llvm-project/openmp/runtime/test/ompt" 
"/mnt/disks/ssd0/agent/llvm-project/openmp/runtime/test/tasking/kmp_detach_tasks_t1.c"
 "-o" 
"/mnt/disks/ssd0/agent/llvm-project/build/projects/openmp/runtime/test/tasking/Output/kmp_detach_tasks_t1.c.tmp"
 "-lm" "-latomic"
  # command stderr:
  clang-13: 
/mnt/disks/ssd0/agent/llvm-project/llvm/lib/Frontend/OpenMP/OMPIRBuilder.cpp:135:
 llvm::Function 
*llvm::OpenMPIRBuilder::getOrCreateRuntimeFunctionPtr(llvm::omp::RuntimeFunction):
 Assertion `Fn && "Failed to create OpenMP runtime function pointer"' failed.
  PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash 
backtrace, preprocessed source, and associated run script.
  Stack dump:
  0.Program arguments: 
/mnt/disks/ssd0/agent/llvm-project/build/bin/clang-13 -cc1 -triple 
x86_64-unknown-linux-gnu -emit-obj -mrelax-all --mrelax-relocations 
-disable-free -main-file-name kmp_detach_tasks_t1.c -mrelocation-model static 
-mframe-pointer=all -fmath-errno -fno-rounding-math -mconstructor-aliases 
-munwind-tables -target-cpu x86-64 -tune-cpu generic -debugger-tuning=gdb 
-fcoverage-compilation-dir=/mnt/disks/ssd0/agent/llvm-project/build/projects/openmp/runtime/test/tasking
 -resource-dir /mnt/disks/ssd0/agent/llvm-project/build/lib/clang/13.0.0 -I 
/mnt/disks/ssd0/agent/llvm-project/openmp/runtime/test -I 
/mnt/disks/ssd0/agent/llvm-project/build/projects/openmp/runtime/src -I 
/mnt/disks/ssd0/agent/llvm-project/openmp/runtime/test/ompt -internal-isystem 
/mnt/disks/ssd0/agent/llvm-project/build/lib/clang/13.0.0/include 
-internal-isystem /usr/local/include -internal-isystem 
/usr/lib/gcc/x86_64-linux-gnu/10/../../../../x86_64-linux-gnu/include 
-internal-externc-isystem /usr/include/x86_64-linux-gnu 
-internal-externc-isystem /include -internal-externc-isystem /usr/include 
-fdebug-compilation-dir=/mnt/disks/ssd0/agent/llvm-project/build/projects/openmp/runtime/test/tasking
 -ferror-limit 19 -fopenmp -fopenmp-cuda-parallel-target-regions -pthread 
-fgnuc-version=4.2.1 -mllvm -global-isel=0 -faddrsig 
-D__GCC_HAVE_DWARF2_CFI_ASM=1 -o /tmp/kmp_detach_tasks_t1-bbb4b6.o -x c 
/mnt/disks/ssd0/agent/llvm-project/openmp/runtime/test/tasking/kmp_detach_tasks_t1.c
  1. parser at end of file
  2.Per-file LLVM IR generation
  3.
/mnt/disks/ssd0/agent/llvm-project/openmp/runtime/test/tasking/kmp_detach_tasks_t1.c:76:5:
 Generating code for declaration 'main'
  4.
/mnt/disks/ssd0/agent/llvm-project/openmp/runtime/test/tasking/kmp_detach_tasks_t1.c:84:3:
 LLVM IR generation of compound statement ('{}')
   #0 0x05899d83 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) 
/mnt/disks/ssd0/agent/llvm-project/llvm/lib/Support/Unix/Signals.inc:565:13
   #1 0x05897ace llvm::sys::RunSignalHandlers() 
/mnt/disks/ssd0/agent/llvm-project/llvm/lib/Support/Signals.cpp:77:18
   #2 0x0589a24f SignalHandler(int) 
/mnt/disks/ssd0/agent/llvm-project/llvm/lib/Support/Unix/Signals.inc:407:1
   #3 0x7fe786916140 __restore_rt 
(/lib/x86_64-linux-gnu/libpthread.so.0+0x14140)
   #4 0x7fe7863eedb1 raise (/lib/x86_64-linux-gnu/libc.so.6+0x3bdb1)
   #5 0x7fe7863d8537 abort (/lib/x86_64-linux-gnu/libc.so.6+0x25537)
   #6 0x7fe7863d840f (/lib/x86_64-linux-gnu/libc.so.6+0x2540f)
   #7 0x7fe7863e75b2 (/lib/x86_64-linux-gnu/libc.so.6+0x345b2)
   #8 0x080dcc3e doit 
/mnt/disks/ssd0/agent/llvm-project/llvm/include/llvm/Support/Casting.h:104:5
   #9 0x080dcc3e doit 
/mnt/disks/ssd0/agent/llvm-project/llvm/include/llvm/Support/Casting.h:131:12
  #10 0x080dcc3e doit 
/mnt/disks/ssd0/agent/llvm-project/llvm/include/llvm/Support/Casting.h:121:12
  #11 0x080dcc3e isa 
/mnt/disks/ssd0/agent/llvm-project/llvm/include/llvm/Support/Casting.h:142:10
  #12 0x080dcc3e cast 
/mnt/disks/ssd0/agent/llvm-project/llvm/include/llvm/Support/Casting.h:269:3
  #13 0x080dcc3e getFunctionType 
/mnt/disks/ssd0/agent/llvm-project/llvm/include/llvm/IR/Function.h:166:12
  #14 0x080dcc3e FunctionCallee 
/mnt/disks/ssd0/agent/llvm-project/llvm/include/llvm/IR/DerivedTypes.h:170:23
  #15 0x080dcc3e 
llvm::OpenMPIRBuilder::getOrCreateThreadID(llvm::Value*) 
/mnt/disks/ssd0/agent/llvm-project/llvm/lib/Frontend/OpenMP/OMPIRBuilder.cpp:330:7
  #16 0x080e0002 
llvm::OpenMPIRBuilder::createMaster(llvm::OpenMPIRBuilder::LocationDescription 
const&, llvm::function_ref, std::function) 
/mnt/disks/ssd0/agent/llvm-project/llvm/lib/Frontend/OpenMP/OMPIRBuilder.cpp:892:19
  #17 0x05d64ab8 isSet

[PATCH] D100756: [llvm-rc] [4/4] Add a GNU windres-like frontend to llvm-rc

2021-04-21 Thread Alexandre Ganea via Phabricator via cfe-commits

aganea added inline comments.



Comment at: llvm/tools/llvm-rc/llvm-rc.cpp:300
+
+std::string unescape(StringRef S) {
+  std::string Out;

mstorsjo wrote:
> aganea wrote:
> > I would also need this function in D43002 (see unescapeSlashes), do you 
> > think we can move it to `sys::path` or any other "support" lib?
> This does things differently than your function - this converts `\\\"` into 
> `\"` while your version leaves `\\"` if I read it correctly.
> 
> (I'm also considering a different, platform specific unescaping strategy - 
> that'd be closer to how GNU windres behaves, but makes for a more 
> inconsistent tool. Keeping the logic here makes it easier to tweak if needed.)
I think `unescapeSlashes` in D43002 was only a quick hack to allow copy-pasting 
a command-line file name from LIT outputs into the VS debugger options dialog. 
If the file name contains double quotes I would expect it to be converted as 
you do, but double quotes cannot happen in file names on Windows. In theory one 
could use the `S_OBJNAME` and `LF_BUILDINFO` records to repro a clang-cl build 
command on Linux, but that seems improbable? (since the feature is meant to be 
used on Windows)



Comment at: llvm/tools/llvm-rc/llvm-rc.cpp:567
+  if (InputArgs.hasArg(OPT_lang_id)) {
+if (InputArgs.getLastArgValue(OPT_lang_id).getAsInteger(16, Opts.LangId))
+  fatalError("Invalid language id: " +

mstorsjo wrote:
> aganea wrote:
> > There was a latent issue here - unrelated to the moving of code around - I 
> > don't know if you want to fix it now or after? That is, `s/16/0/`.
> Hmm, as far as I can see, both rc.exe and GNU windres interpret values as 
> hexadecimal - if I run e.g. `rc.exe -l 40 test.rc`, where `40` is ambiguous, 
> I get language id 64.
Ok, we only have stuff like `rc.exe /l 0x0409` in our build scripts, the 0x in 
front isn't consumed, I though it was mandatory.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100756

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

[PATCH] D100968: Update shebang for clang-format-diff script to python3.

2021-04-21 Thread Paula Toth via Phabricator via cfe-commits

PaulkaToast created this revision.
PaulkaToast added reviewers: MaskRay, DavidSpickett.
PaulkaToast requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

On newer Linux distributions that don't have python2, the clang-format-diff 
script and consequently `arc diff` is failing with python not found error.  
Since we require python greater than 3.6 as part of llvm prerequisites 
(https://llvm.org/docs/GettingStarted.html#software), let's go ahead and update 
this shebang.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D100968

Files:
  clang/tools/clang-format/clang-format-diff.py


Index: clang/tools/clang-format/clang-format-diff.py
===
--- clang/tools/clang-format/clang-format-diff.py
+++ clang/tools/clang-format/clang-format-diff.py
@@ -1,4 +1,4 @@
-#!/usr/bin/env python
+#!/usr/bin/env python3
 #
 #===- clang-format-diff.py - ClangFormat Diff Reformatter *- python 
-*--===#
 #


Index: clang/tools/clang-format/clang-format-diff.py
===
--- clang/tools/clang-format/clang-format-diff.py
+++ clang/tools/clang-format/clang-format-diff.py
@@ -1,4 +1,4 @@
-#!/usr/bin/env python
+#!/usr/bin/env python3
 #
 #===- clang-format-diff.py - ClangFormat Diff Reformatter *- python -*--===#
 #
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D100581: [Clang] -Wunused-but-set-parameter and -Wunused-but-set-variable

2021-04-21 Thread Michael Benfield via Phabricator via cfe-commits

mbenfield added a comment.

In D100581#2700083 , @xbolva00 wrote:

> So I think we should put UnusedButSetParameter under -Wextra
>
> So I would just put UnusedButSetVariable under -Wunused (and -Wunused is part 
> of -Wall):
>
> WDYT?

Sounds good; I've done this now.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100581

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

[PATCH] D100581: [Clang] -Wunused-but-set-parameter and -Wunused-but-set-variable

2021-04-21 Thread Michael Benfield via Phabricator via cfe-commits

mbenfield updated this revision to Diff 339275.
mbenfield added a comment.
Herald added subscribers: frasercrmck, luismarques, apazos, sameer.abuasal, 
pengfei, s.egerton, Jim, jocewei, PkmX, the_o, brucehoult, MartinMosbeck, 
rogfer01, edward-jones, zzheng, jrtc27, niosHD, sabuasal, simoncook, johnrusso, 
rbar, asb.

Response to review comments.

- Diagnostic groups: UnusedButSetVariable into Unused and UnusedButSetParameter 
into Extra

- Early exit from VisitBinaryOperator

- Idiomatic `if (Decl *D = ...)`

- Add `-Wno-unused-but-set-parameter` and `-Wno-unused-but-set-variable` to 
many tests (necessary since these were added to diagnostic groups)

- Don't flag for const or constexpr variables

- Test case for const and constexpr variables

- Move C++ test cases to SemaCXX


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100581

Files:
  clang/include/clang/Basic/DiagnosticGroups.td
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Sema/Sema.h
  clang/lib/Sema/SemaDecl.cpp
  clang/lib/Sema/SemaExpr.cpp
  clang/lib/Sema/SemaStmt.cpp
  clang/test/CodeGen/X86/x86_32-xsave.c
  clang/test/CodeGen/X86/x86_64-xsave.c
  clang/test/CodeGen/builtins-arm.c
  clang/test/CodeGen/builtins-riscv.c
  clang/test/FixIt/fixit.cpp
  clang/test/Misc/warning-wall.c
  clang/test/Sema/shift.c
  clang/test/Sema/vector-gcc-compat.c
  clang/test/Sema/warn-unused-but-set-parameters.c
  clang/test/Sema/warn-unused-but-set-variables.c
  clang/test/SemaCXX/goto.cpp
  clang/test/SemaCXX/shift.cpp
  clang/test/SemaCXX/sizeless-1.cpp
  clang/test/SemaCXX/warn-unused-but-set-parameters-cpp.cpp
  clang/test/SemaCXX/warn-unused-but-set-variables-cpp.cpp
  clang/test/SemaObjC/foreach.m

Index: clang/test/SemaObjC/foreach.m
===
--- clang/test/SemaObjC/foreach.m
+++ clang/test/SemaObjC/foreach.m
@@ -1,4 +1,4 @@
-/* RUN: %clang_cc1 -Wall -fsyntax-only -verify -std=c89 -pedantic %s
+/* RUN: %clang_cc1 -Wall -Wno-unused-but-set-parameter -Wno-unused-but-set-variable -fsyntax-only -verify -std=c89 -pedantic %s
  */
 
 @class NSArray;
Index: clang/test/SemaCXX/warn-unused-but-set-variables-cpp.cpp
===
--- /dev/null
+++ clang/test/SemaCXX/warn-unused-but-set-variables-cpp.cpp
@@ -0,0 +1,41 @@
+// RUN: %clang_cc1 -fblocks -fsyntax-only -Wunused-but-set-variable -verify %s
+
+struct S {
+  int i;
+};
+
+int f0() {
+  int y; // expected-warning{{variable 'y' set but not used}}
+  y = 0;
+
+  int z __attribute__((unused));
+  z = 0;
+
+  // In C++, don't warn for structs. (following gcc's behavior)
+  struct S s;
+  struct S t;
+  s = t;
+
+  int x;
+  x = 0;
+  return x + 5;
+}
+
+void f1(void) {
+  (void)^() {
+int y; // expected-warning{{variable 'y' set but not used}}
+y = 0;
+
+int x;
+x = 0;
+return x;
+  };
+}
+
+void f2() {
+  // Don't warn for either of these cases.
+  constexpr int x = 2;
+  const int y = 1;
+  char a[x];
+  char b[y];
+}
Index: clang/test/SemaCXX/warn-unused-but-set-parameters-cpp.cpp
===
--- /dev/null
+++ clang/test/SemaCXX/warn-unused-but-set-parameters-cpp.cpp
@@ -0,0 +1,33 @@
+// RUN: %clang_cc1 -fblocks -fsyntax-only -Wunused-but-set-parameter -verify %s
+
+int f0(int x,
+   int y, // expected-warning{{parameter 'y' set but not used}}
+   int z __attribute__((unused))) {
+  y = 0;
+  return x;
+}
+
+void f1(void) {
+  (void)^(int x,
+  int y, // expected-warning{{parameter 'y' set but not used}}
+  int z __attribute__((unused))) {
+y = 0;
+return x;
+  };
+}
+
+struct S {
+  int i;
+};
+
+// In C++, don't warn for a struct (following gcc).
+void f3(struct S s) {
+  struct S t;
+  s = t;
+}
+
+// Make sure this doesn't warn.
+struct A {
+  int i;
+  A(int j) : i(j) {}
+};
Index: clang/test/SemaCXX/sizeless-1.cpp
===
--- clang/test/SemaCXX/sizeless-1.cpp
+++ clang/test/SemaCXX/sizeless-1.cpp
@@ -1,7 +1,7 @@
-// RUN: %clang_cc1 -fcxx-exceptions -fsyntax-only -verify -W -Wall -Wrange-loop-analysis -triple arm64-linux-gnu -target-feature +sve -std=c++98 %s
-// RUN: %clang_cc1 -fcxx-exceptions -fsyntax-only -verify -W -Wall -Wrange-loop-analysis -triple arm64-linux-gnu -target-feature +sve -std=c++11 %s
-// RUN: %clang_cc1 -fcxx-exceptions -fsyntax-only -verify -W -Wall -Wrange-loop-analysis -triple arm64-linux-gnu -target-feature +sve -std=c++17 %s
-// RUN: %clang_cc1 -fcxx-exceptions -fsyntax-only -verify -W -Wall -Wrange-loop-analysis -triple arm64-linux-gnu -target-feature +sve -std=gnu++17 %s
+// RUN: %clang_cc1 -fcxx-exceptions -fsyntax-only -verify -W -Wall -Wno-unused-but-set-parameter -Wno-unused-but-set-variable -Wrange-loop-analysis -triple arm64-linux-gnu -target-feature +sve -std=c++98 %s
+// RUN:

[PATCH] D95976: [OpenMP] Simplify offloading parallel call codegen

2021-04-21 Thread Giorgis Georgakoudis via Phabricator via cfe-commits

ggeorgakoudis updated this revision to Diff 339265.
ggeorgakoudis added a comment.

Add tests, reduce microtask cases to avoid stack problems


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D95976

Files:
  clang/lib/CodeGen/CGOpenMPRuntimeGPU.cpp
  clang/test/OpenMP/nvptx_allocate_codegen.cpp
  clang/test/OpenMP/nvptx_data_sharing.cpp
  clang/test/OpenMP/nvptx_distribute_parallel_generic_mode_codegen.cpp
  clang/test/OpenMP/nvptx_lambda_capturing.cpp
  clang/test/OpenMP/nvptx_multi_target_parallel_codegen.cpp
  clang/test/OpenMP/nvptx_nested_parallel_codegen.cpp
  clang/test/OpenMP/nvptx_parallel_codegen.cpp
  clang/test/OpenMP/nvptx_parallel_for_codegen.cpp
  clang/test/OpenMP/nvptx_target_codegen.cpp
  clang/test/OpenMP/nvptx_target_parallel_codegen.cpp
  clang/test/OpenMP/nvptx_target_parallel_num_threads_codegen.cpp
  clang/test/OpenMP/nvptx_target_teams_codegen.cpp
  clang/test/OpenMP/nvptx_target_teams_distribute_codegen.cpp
  clang/test/OpenMP/nvptx_target_teams_distribute_parallel_for_codegen.cpp
  
clang/test/OpenMP/nvptx_target_teams_distribute_parallel_for_generic_mode_codegen.cpp
  clang/test/OpenMP/nvptx_target_teams_distribute_parallel_for_simd_codegen.cpp
  clang/test/OpenMP/nvptx_teams_reduction_codegen.cpp
  clang/test/OpenMP/remarks_parallel_in_multiple_target_state_machines.c
  clang/test/OpenMP/remarks_parallel_in_target_state_machine.c
  clang/test/OpenMP/target_parallel_debug_codegen.cpp
  clang/test/OpenMP/target_parallel_for_debug_codegen.cpp
  llvm/include/llvm/Frontend/OpenMP/OMPKinds.def
  llvm/lib/Transforms/IPO/OpenMPOpt.cpp
  llvm/test/Transforms/OpenMP/gpu_state_machine_function_ptr_replacement.ll
  openmp/libomptarget/deviceRTLs/common/generated_microtask_cases.gen
  openmp/libomptarget/deviceRTLs/common/src/omptarget.cu
  openmp/libomptarget/deviceRTLs/common/src/parallel.cu
  openmp/libomptarget/deviceRTLs/common/src/support.cu
  openmp/libomptarget/deviceRTLs/common/support.h
  openmp/libomptarget/deviceRTLs/interface.h
  openmp/libomptarget/test/offloading/bug49779.cpp
  openmp/libomptarget/utils/generate_microtask_cases.py

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

[PATCH] D100819: [RISCV] Implement the vneg.v builtin.

2021-04-21 Thread Craig Topper via Phabricator via cfe-commits

craig.topper added inline comments.



Comment at: clang/utils/TableGen/RISCVVEmitter.cpp:1048
+   return Cmp < 0;
+ // Some mask intrinsics use the same IRName as unmasked.
+ // Sort the unmasked intrinsics first.

frasercrmck wrote:
> Does this only affect `vneg` or are there other changes to the tablegenned 
> code as a consequence?
Is this needed for fneg? When we implemented this change downstream, I thought 
it was for compares due to how vmsge.vx was handled.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100819

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

[PATCH] D100756: [llvm-rc] [4/4] Add a GNU windres-like frontend to llvm-rc

2021-04-21 Thread Martin Storsjö via Phabricator via cfe-commits

mstorsjo updated this revision to Diff 339263.
mstorsjo added a comment.

Updated the capitalization of one variable


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100756

Files:
  clang/test/CMakeLists.txt
  clang/test/Preprocessor/Inputs/llvm-windres.h
  clang/test/Preprocessor/llvm-windres.rc
  llvm/test/CMakeLists.txt
  llvm/test/lit.cfg.py
  llvm/test/tools/llvm-rc/codepage.test
  llvm/test/tools/llvm-rc/language.test
  llvm/test/tools/llvm-rc/windres-format.test
  llvm/test/tools/llvm-rc/windres-prefix.test
  llvm/test/tools/llvm-rc/windres-preproc.test
  llvm/test/tools/llvm-rc/windres-target.test
  llvm/test/tools/llvm-rc/windres-version.test
  llvm/tools/llvm-rc/CMakeLists.txt
  llvm/tools/llvm-rc/WindresOpts.td
  llvm/tools/llvm-rc/llvm-rc.cpp

Index: llvm/tools/llvm-rc/llvm-rc.cpp
===
--- llvm/tools/llvm-rc/llvm-rc.cpp
+++ llvm/tools/llvm-rc/llvm-rc.cpp
@@ -18,8 +18,10 @@
 #include "ResourceScriptToken.h"
 
 #include "llvm/ADT/Triple.h"
+#include "llvm/Object/WindowsResource.h"
 #include "llvm/Option/Arg.h"
 #include "llvm/Option/ArgList.h"
+#include "llvm/Support/CommandLine.h"
 #include "llvm/Support/Error.h"
 #include "llvm/Support/FileSystem.h"
 #include "llvm/Support/FileUtilities.h"
@@ -75,8 +77,39 @@
   RcOptTable() : OptTable(InfoTable, /* IgnoreCase = */ true) {}
 };
 
+enum Windres_ID {
+  WINDRES_INVALID = 0, // This is not a correct option ID.
+#define OPTION(PREFIX, NAME, ID, KIND, GROUP, ALIAS, ALIASARGS, FLAGS, PARAM,  \
+   HELPTEXT, METAVAR, VALUES)  \
+  WINDRES_##ID,
+#include "WindresOpts.inc"
+#undef OPTION
+};
+
+#define PREFIX(NAME, VALUE) const char *const WINDRES_##NAME[] = VALUE;
+#include "WindresOpts.inc"
+#undef PREFIX
+
+static const opt::OptTable::Info WindresInfoTable[] = {
+#define OPTION(PREFIX, NAME, ID, KIND, GROUP, ALIAS, ALIASARGS, FLAGS, PARAM,  \
+   HELPTEXT, METAVAR, VALUES)  \
+  {\
+  WINDRES_##PREFIX, NAME, HELPTEXT,\
+  METAVAR,  WINDRES_##ID, opt::Option::KIND##Class,\
+  PARAM,FLAGS,WINDRES_##GROUP, \
+  WINDRES_##ALIAS,  ALIASARGS,VALUES},
+#include "WindresOpts.inc"
+#undef OPTION
+};
+
+class WindresOptTable : public opt::OptTable {
+public:
+  WindresOptTable() : OptTable(WindresInfoTable, /* IgnoreCase = */ false) {}
+};
+
 static ExitOnError ExitOnErr;
 static FileRemover TempPreprocFile;
+static FileRemover TempResFile;
 
 LLVM_ATTRIBUTE_NORETURN static void fatalError(const Twine ) {
   errs() << Message << "\n";
@@ -112,9 +145,8 @@
   return Path;
 }
 
-std::string getClangClTriple() {
-  Triple T(sys::getDefaultTargetTriple());
-  switch (T.getArch()) {
+Triple::ArchType getDefaultArch(Triple::ArchType Arch) {
+  switch (Arch) {
   case Triple::x86:
   case Triple::x86_64:
   case Triple::arm:
@@ -122,13 +154,17 @@
   case Triple::aarch64:
 // These work properly with the clang driver, setting the expected
 // defines such as _WIN32 etc.
-break;
+return Arch;
   default:
 // Other archs aren't set up for use with windows as target OS, (clang
 // doesn't define e.g. _WIN32 etc), so set a reasonable default arch.
-T.setArch(Triple::x86_64);
-break;
+return Triple::x86_64;
   }
+}
+
+std::string getClangClTriple() {
+  Triple T(sys::getDefaultTargetTriple());
+  T.setArch(getDefaultArch(T.getArch()));
   T.setOS(Triple::Win32);
   T.setVendor(Triple::PC);
   T.setEnvironment(Triple::MSVC);
@@ -136,10 +172,44 @@
   return T.str();
 }
 
-bool preprocess(StringRef Src, StringRef Dst, opt::InputArgList ,
+std::string getMingwTriple() {
+  Triple T(sys::getDefaultTargetTriple());
+  T.setArch(getDefaultArch(T.getArch()));
+  if (T.isWindowsGNUEnvironment())
+return T.str();
+  // Write out the literal form of the vendor/env here, instead of
+  // constructing them with enum values (which end up with them in
+  // normalized form). The literal form of the triple can matter for
+  // finding include files.
+  return (Twine(T.getArchName()) + "-w64-mingw32").str();
+}
+
+enum Format { Rc, Res, Coff, Unknown };
+
+struct RcOptions {
+  bool Preprocess = true;
+  bool PrintCmdAndExit = false;
+  std::string Triple;
+  std::vector PreprocessCmd;
+  std::vector PreprocessArgs;
+
+  std::string InputFile;
+  Format InputFormat = Rc;
+  std::string OutputFile;
+  Format OutputFormat = Res;
+
+  bool BeVerbose = false;
+  WriterParams Params;
+  bool AppendNull = false;
+  bool IsDryRun = false;
+  // Set the default language; choose en-US arbitrarily.
+  unsigned LangId = (/*PrimaryLangId*/ 0x09) | (/*SubLangId*/ 0x01 << 10);
+};
+
+bool preprocess(StringRef Src, StringRef

[PATCH] D100942: [clang][deps] Include "-cc1" in the arguments

2021-04-21 Thread Michael Spencer via Phabricator via cfe-commits

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

lgtm.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100942

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

[PATCH] D69498: IR: Invert convergent attribute handling

2021-04-21 Thread Sameer Sahasrabuddhe via Phabricator via cfe-commits

sameerds added a comment.

I realize now that what @foad says above puts the idea in a clearer context. 
Essentially, any check for isConvergent() isn't happening in a vacuum. It is 
relevant only in the presence of divergent control flow, which in turn is 
relevant only when the target has divergence. Any standalone check for 
isConvergent() is merely making a pessimistic assumption that all the control 
flow incident on it is divergent. This has two consequences:

1. The meaning of the `convergent` attribute has always been target-dependent.
2. Dependence on TTI is not a real cost at all. We may eventually update every 
use of isConvergent() to depend on a check for divergence. The check for TTI is 
only the first step towards that.

I would propose refining the definition of the `noconvergent` attribute as 
follows:

> noconvergent:
>
> Some targets with a parallel execution model provide cross-thread operations 
> whose outcome is affected by the presence of divergent control flow. We call 
> such operations convergent. Optimizations that change control flow may affect 
> the correctness of a program that uses convergent operations. In the presence 
> of divergent control flow, such optimizations conservatively treat every 
> call/invoke instruction as convergent by default. The noconvergent attribute 
> relaxes this constraint as follows:
>
> - The noconvergent attribute can be added to a call/invoke to indicate that 
> it is not affected by changes to the control flow that reaches it.
> - The noconvergent attribute can be added to a function to indicate that it 
> does not execute any convergent operations. A call/invoke automatically 
> inherits the noconvergent attribute if it is set on the callee.


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

https://reviews.llvm.org/D69498

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

[PATCH] D100756: [llvm-rc] [4/4] Add a GNU windres-like frontend to llvm-rc

2021-04-21 Thread Martin Storsjö via Phabricator via cfe-commits

mstorsjo added inline comments.



Comment at: llvm/tools/llvm-rc/llvm-rc.cpp:259
 
-} // anonymous namespace
+static bool consume_back_lower(StringRef , const char *str) {
+  if (!S.endswith_lower(str))

aganea wrote:
> `s/str/Str/`
Thanks, will fix.



Comment at: llvm/tools/llvm-rc/llvm-rc.cpp:300
+
+std::string unescape(StringRef S) {
+  std::string Out;

aganea wrote:
> I would also need this function in D43002 (see unescapeSlashes), do you think 
> we can move it to `sys::path` or any other "support" lib?
This does things differently than your function - this converts `\\\"` into 
`\"` while your version leaves `\\"` if I read it correctly.

(I'm also considering a different, platform specific unescaping strategy - 
that'd be closer to how GNU windres behaves, but makes for a more inconsistent 
tool. Keeping the logic here makes it easier to tweak if needed.)



Comment at: llvm/tools/llvm-rc/llvm-rc.cpp:567
+  if (InputArgs.hasArg(OPT_lang_id)) {
+if (InputArgs.getLastArgValue(OPT_lang_id).getAsInteger(16, Opts.LangId))
+  fatalError("Invalid language id: " +

aganea wrote:
> There was a latent issue here - unrelated to the moving of code around - I 
> don't know if you want to fix it now or after? That is, `s/16/0/`.
Hmm, as far as I can see, both rc.exe and GNU windres interpret values as 
hexadecimal - if I run e.g. `rc.exe -l 40 test.rc`, where `40` is ambiguous, I 
get language id 64.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100756

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

1 2 3 >

1 - 100 of 216 matches

Mail list logo