[llvm-branch-commits] [openmp] release/18.x: [OpenMP][OMPT] Fix hsa include when building amdgpu/src/rtl.cpp (PR #95484)

[Joseph Huber via llvm-branch-commits]

https://github.com/jhuber6 commented:

We made a change recently that made the dynamic_hsa version the default. The 
error you're seeing is from an old HSA, so if you're overriding the default to 
use an old library that's probably not worth working around.

https://github.com/llvm/llvm-project/pull/95484
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [openmp] release/18.x: [OpenMP][OMPT] Fix hsa include when building amdgpu/src/rtl.cpp (PR #95484)

[Joseph Huber via llvm-branch-commits]

https://github.com/jhuber6 edited 
https://github.com/llvm/llvm-project/pull/95484
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [openmp] release/18.x: [OpenMP][OMPT] Fix hsa include when building amdgpu/src/rtl.cpp (PR #95484)

[Joseph Huber via llvm-branch-commits]

jhuber6 wrote:

> The `openmp/libomptarget/plugins-nextgen/amdgpu/src/rtl.cpp` file requires 
> the `HSA_AMD_AGENT_INFO_TIMESTAMP_FREQUENCY` symbol.
> 
> This symbol is expected to be provided by 
> `openmp/libomptarget/plugins-nextgen/amdgpu/dynamic_hsa/hsa_ext_amd.h`, not 
> by third-party external `/opt/rocm/include/hsa/hsa_ext_amd.h`.

This was introduced in ROCm-5.3, see 
https://github.com/ROCm/ROCR-Runtime/blob/rocm-5.3.x/src/inc/hsa_ext_amd.h#L333.
 The `dynamic_hsa/` version is a copy of this header for use when the system 
version is not provided. If the system fails to find HSA, then it will use the 
dynamic version. The problem here is that you _have_ HSA, but it's too old. I 
don't know how much backward compatibility we really provide here, 
unfortunately the HSA headers really don't give you much versioning to work 
with, so we can't do `ifdef` on this stuff. 

https://github.com/llvm/llvm-project/pull/95484
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [openmp] release/18.x: [OpenMP][OMPT] Fix hsa include when building amdgpu/src/rtl.cpp (PR #95484)

[Joseph Huber via llvm-branch-commits]

jhuber6 wrote:

> This doesn't make sense, the ROCm packages may be just badly made by AMD.
> 
> When I temporarily remove `/usr/include/hsa` without uninstalling 
> `libhsa-runtime-dev` **AND** while using 
> `-DLIBOMPTARGET_FORCE_DLOPEN_LIBHSA=ON`, I can build LLVM18 without patch.
> 
> With `-DLIBOMPTARGET_FORCE_DLOPEN_LIBHSA=OFF` CMake complains that 
> `/usr/include/hsa` is missing.
> 
> So it looks like I'm tracking a ROCm packaging bug from AMD side.

I don't think AMD handles the actual packaging, that's on the maintainers for 
your distribution. I'm guessing that the HSA runtime is a separate package from 
ROCm and gets put somewhere else for whatever reason. I don't have any issues 
like that with my distribution.

> But I still don't get why LLVM doesn't use its own HSA by default and doesn't 
> use its own headers for enum values used in its own code.

It does in the main branch, but I think you're right that the logic causes it 
to look at the system one first since `hsa/hsa.h` is higher up the search list. 
Should probably do something about that.

https://github.com/llvm/llvm-project/pull/95484
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [openmp] release/18.x: [OpenMP][OMPT] Fix hsa include when building amdgpu/src/rtl.cpp (PR #95484)

[Joseph Huber via llvm-branch-commits]

jhuber6 wrote:

Made https://github.com/llvm/llvm-project/pull/95769, don't know if the window 
for the 18.x window is still open for a back port.

https://github.com/llvm/llvm-project/pull/95484
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [openmp] release/18.x: [OpenMP][OMPT] Fix hsa include when building amdgpu/src/rtl.cpp (PR #95484)

[Joseph Huber via llvm-branch-commits]

jhuber6 wrote:

I merged my patch, I think the window to backport to 18.x is passed so you'll 
need to use the main branch for now. Thanks for bringing this to my attention.

https://github.com/llvm/llvm-project/pull/95484
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [openmp] release/18.x: [OpenMP][OMPT] Fix hsa include when building amdgpu/src/rtl.cpp (PR #95484)

[Joseph Huber via llvm-branch-commits]

https://github.com/jhuber6 closed 
https://github.com/llvm/llvm-project/pull/95484
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [libc] [llvm] release/19.x: [NVPTX] Fix internal indirect call prototypes not obeying the ABI (#100131) (PR #100174)

[Joseph Huber via llvm-branch-commits]

jhuber6 wrote:

This should be merged

https://github.com/llvm/llvm-project/pull/100174
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [clang] release/19.x: [Clang] Correctly forward `--cuda-path` to the nvlink wrapper (#100170) (PR #100216)

[Joseph Huber via llvm-branch-commits]

@@ -1,9 +1,5 @@
 // Check various clang-linker-wrapper pass options after -offload-opt.
 

jhuber6 wrote:

```suggestion
// REQUIRES: llvm-plugins, llvm-examples
// REQUIRES: x86-registered-target
// REQUIRES: amdgpu-registered-target
```

https://github.com/llvm/llvm-project/pull/100216
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [clang] release/19.x: [Clang] Correctly forward `--cuda-path` to the nvlink wrapper (#100170) (PR #100216)

[Joseph Huber via llvm-branch-commits]

https://github.com/jhuber6 edited 
https://github.com/llvm/llvm-project/pull/100216
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [clang] release/19.x: [Clang] Correctly forward `--cuda-path` to the nvlink wrapper (#100170) (PR #100216)

[Joseph Huber via llvm-branch-commits]

https://github.com/jhuber6 updated 
https://github.com/llvm/llvm-project/pull/100216

>From d7f99606094fc1feb41b50de0b0eb6d07460 Mon Sep 17 00:00:00 2001
From: Joseph Huber 
Date: Tue, 23 Jul 2024 14:41:57 -0500
Subject: [PATCH 1/2] [Clang] Correctly forward `--cuda-path` to the nvlink
 wrapper (#100170)

Summary:
This was not forwarded properly as it would try to pass it to `nvlink`.

Fixes https://github.com/llvm/llvm-project/issues/100168

(cherry picked from commit 7e1fcf5dd657d465c3fc846f56c6f9d3a4560b43)
---
 clang/lib/Driver/ToolChains/Cuda.cpp   |  4 
 clang/test/Driver/linker-wrapper-passes.c  | 10 +++---
 clang/test/Driver/nvlink-wrapper.c |  7 +++
 clang/tools/clang-nvlink-wrapper/NVLinkOpts.td |  4 ++--
 4 files changed, 16 insertions(+), 9 deletions(-)

diff --git a/clang/lib/Driver/ToolChains/Cuda.cpp 
b/clang/lib/Driver/ToolChains/Cuda.cpp
index 59453c484ae4f..61d12b10dfb62 100644
--- a/clang/lib/Driver/ToolChains/Cuda.cpp
+++ b/clang/lib/Driver/ToolChains/Cuda.cpp
@@ -609,6 +609,10 @@ void NVPTX::Linker::ConstructJob(Compilation &C, const 
JobAction &JA,
 CmdArgs.push_back(Args.MakeArgString(
 "--pxtas-path=" + Args.getLastArgValue(options::OPT_ptxas_path_EQ)));
 
+  if (Args.hasArg(options::OPT_cuda_path_EQ))
+CmdArgs.push_back(Args.MakeArgString(
+"--cuda-path=" + Args.getLastArgValue(options::OPT_cuda_path_EQ)));
+
   // Add paths specified in LIBRARY_PATH environment variable as -L options.
   addDirectoryList(Args, CmdArgs, "-L", "LIBRARY_PATH");
 
diff --git a/clang/test/Driver/linker-wrapper-passes.c 
b/clang/test/Driver/linker-wrapper-passes.c
index aadcf472e9b63..8c337ff906d17 100644
--- a/clang/test/Driver/linker-wrapper-passes.c
+++ b/clang/test/Driver/linker-wrapper-passes.c
@@ -1,9 +1,5 @@
 // Check various clang-linker-wrapper pass options after -offload-opt.
 
-// REQUIRES: llvm-plugins, llvm-examples
-// REQUIRES: x86-registered-target
-// REQUIRES: amdgpu-registered-target
-
 // Setup.
 // RUN: mkdir -p %t
 // RUN: %clang -cc1 -emit-llvm-bc -o %t/host-x86_64-unknown-linux-gnu.bc \
@@ -23,14 +19,14 @@
 // RUN: %t/host-x86_64-unknown-linux-gnu.s
 
 // Check plugin, -passes, and no remarks.
-// RUN: clang-linker-wrapper -o a.out --embed-bitcode \
+// RUN: clang-linker-wrapper -o a.out --embed-bitcode --dry-run \
 // RUN: --linker-path=/usr/bin/true %t/host-x86_64-unknown-linux-gnu.o \
 // RUN: %offload-opt-loadbye --offload-opt=-wave-goodbye \
 // RUN: --offload-opt=-passes="function(goodbye),module(inline)" 2>&1 | \
 // RUN:   FileCheck -match-full-lines -check-prefixes=OUT %s
 
 // Check plugin, -p, and remarks.
-// RUN: clang-linker-wrapper -o a.out --embed-bitcode \
+// RUN: clang-linker-wrapper -o a.out --embed-bitcode --dry-run \
 // RUN: --linker-path=/usr/bin/true %t/host-x86_64-unknown-linux-gnu.o \
 // RUN: %offload-opt-loadbye --offload-opt=-wave-goodbye \
 // RUN: --offload-opt=-p="function(goodbye),module(inline)" \
@@ -43,7 +39,7 @@
 // RUN: -check-prefixes=YML %s
 
 // Check handling of bad plugin.
-// RUN: not clang-linker-wrapper \
+// RUN: not clang-linker-wrapper --dry-run \
 // RUN: --offload-opt=-load-pass-plugin=%t/nonexistent.so 2>&1 | \
 // RUN:   FileCheck -match-full-lines -check-prefixes=BAD-PLUGIN %s
 
diff --git a/clang/test/Driver/nvlink-wrapper.c 
b/clang/test/Driver/nvlink-wrapper.c
index fdda93f1f9cdc..318315ddaca34 100644
--- a/clang/test/Driver/nvlink-wrapper.c
+++ b/clang/test/Driver/nvlink-wrapper.c
@@ -63,3 +63,10 @@ int baz() { return y + x; }
 // RUN:   -arch sm_52 -o a.out 2>&1 | FileCheck %s --check-prefix=LTO
 // LTO: ptxas{{.*}} -m64 -c [[PTX:.+]].s -O3 -arch sm_52 -o [[CUBIN:.+]].cubin
 // LTO: nvlink{{.*}} -arch sm_52 -o a.out [[CUBIN]].cubin 
{{.*}}-u-{{.*}}.cubin {{.*}}-y-{{.*}}.cubin
+
+//
+// Check that we don't forward some arguments.
+//
+// RUN: clang-nvlink-wrapper --dry-run %t.o %t-u.o %t-y.a \
+// RUN:   -arch sm_52 --cuda-path/opt/cuda -o a.out 2>&1 | FileCheck %s 
--check-prefix=PATH
+// PATH-NOT: --cuda-path=/opt/cuda
diff --git a/clang/tools/clang-nvlink-wrapper/NVLinkOpts.td 
b/clang/tools/clang-nvlink-wrapper/NVLinkOpts.td
index e84b530f2787d..8c80a51b12a44 100644
--- a/clang/tools/clang-nvlink-wrapper/NVLinkOpts.td
+++ b/clang/tools/clang-nvlink-wrapper/NVLinkOpts.td
@@ -12,9 +12,9 @@ def verbose : Flag<["-"], "v">, HelpText<"Print verbose 
information">;
 def version : Flag<["--"], "version">,
   HelpText<"Display the version number and exit">;
 
-def cuda_path_EQ : Joined<["--"], "cuda-path=">,
+def cuda_path_EQ : Joined<["--"], "cuda-path=">, Flags<[WrapperOnlyOption]>,
   MetaVarName<"">, HelpText<"Set the system CUDA path">;
-def ptxas_path_EQ : Joined<["--"], "ptxas-path=">,
+def ptxas_path_EQ : Joined<["--"], "ptxas-path=">, Flags<[WrapperOnlyOption]>,
   MetaVarName<"">, HelpText<"Set the 'ptxas' path">;
 
 def o : JoinedOrSeparate<["-"], "o">, MetaVarName<"">,

>From e9ac0f0e5916236cb091179cfa7befd081b01355

[llvm-branch-commits] [clang] release/19.x: [Clang] Correctly forward `--cuda-path` to the nvlink wrapper (#100170) (PR #100216)

[Joseph Huber via llvm-branch-commits]

@@ -23,14 +22,14 @@
 // RUN: %t/host-x86_64-unknown-linux-gnu.s
 
 // Check plugin, -passes, and no remarks.
-// RUN: clang-linker-wrapper -o a.out --embed-bitcode \
+// RUN: clang-linker-wrapper -o a.out --embed-bitcode --dry-run \
 // RUN: --linker-path=/usr/bin/true %t/host-x86_64-unknown-linux-gnu.o \
 // RUN: %offload-opt-loadbye --offload-opt=-wave-goodbye \
 // RUN: --offload-opt=-passes="function(goodbye),module(inline)" 2>&1 | \
 // RUN:   FileCheck -match-full-lines -check-prefixes=OUT %s
 
 // Check plugin, -p, and remarks.
-// RUN: clang-linker-wrapper -o a.out --embed-bitcode \
+// RUN: clang-linker-wrapper -o a.out --embed-bitcode --dry-run \

jhuber6 wrote:

```suggestion
// RUN: clang-linker-wrapper -o a.out --embed-bitcode \
```

https://github.com/llvm/llvm-project/pull/100216
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [clang] release/19.x: [Clang] Correctly forward `--cuda-path` to the nvlink wrapper (#100170) (PR #100216)

[Joseph Huber via llvm-branch-commits]

@@ -23,14 +22,14 @@
 // RUN: %t/host-x86_64-unknown-linux-gnu.s
 
 // Check plugin, -passes, and no remarks.
-// RUN: clang-linker-wrapper -o a.out --embed-bitcode \
+// RUN: clang-linker-wrapper -o a.out --embed-bitcode --dry-run \

jhuber6 wrote:

```suggestion
// RUN: clang-linker-wrapper -o a.out --embed-bitcode \
```

https://github.com/llvm/llvm-project/pull/100216
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [clang] release/19.x: [Clang] Correctly forward `--cuda-path` to the nvlink wrapper (#100170) (PR #100216)

[Joseph Huber via llvm-branch-commits]

@@ -43,7 +42,7 @@
 // RUN: -check-prefixes=YML %s
 
 // Check handling of bad plugin.
-// RUN: not clang-linker-wrapper \
+// RUN: not clang-linker-wrapper --dry-run \

jhuber6 wrote:

```suggestion
// RUN: not clang-linker-wrapper \
```

https://github.com/llvm/llvm-project/pull/100216
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [clang] release/19.x: [Clang] Correctly forward `--cuda-path` to the nvlink wrapper (#100170) (PR #100216)

[Joseph Huber via llvm-branch-commits]

https://github.com/jhuber6 updated 
https://github.com/llvm/llvm-project/pull/100216

>From d7f99606094fc1feb41b50de0b0eb6d07460 Mon Sep 17 00:00:00 2001
From: Joseph Huber 
Date: Tue, 23 Jul 2024 14:41:57 -0500
Subject: [PATCH 1/3] [Clang] Correctly forward `--cuda-path` to the nvlink
 wrapper (#100170)

Summary:
This was not forwarded properly as it would try to pass it to `nvlink`.

Fixes https://github.com/llvm/llvm-project/issues/100168

(cherry picked from commit 7e1fcf5dd657d465c3fc846f56c6f9d3a4560b43)
---
 clang/lib/Driver/ToolChains/Cuda.cpp   |  4 
 clang/test/Driver/linker-wrapper-passes.c  | 10 +++---
 clang/test/Driver/nvlink-wrapper.c |  7 +++
 clang/tools/clang-nvlink-wrapper/NVLinkOpts.td |  4 ++--
 4 files changed, 16 insertions(+), 9 deletions(-)

diff --git a/clang/lib/Driver/ToolChains/Cuda.cpp 
b/clang/lib/Driver/ToolChains/Cuda.cpp
index 59453c484ae4f..61d12b10dfb62 100644
--- a/clang/lib/Driver/ToolChains/Cuda.cpp
+++ b/clang/lib/Driver/ToolChains/Cuda.cpp
@@ -609,6 +609,10 @@ void NVPTX::Linker::ConstructJob(Compilation &C, const 
JobAction &JA,
 CmdArgs.push_back(Args.MakeArgString(
 "--pxtas-path=" + Args.getLastArgValue(options::OPT_ptxas_path_EQ)));
 
+  if (Args.hasArg(options::OPT_cuda_path_EQ))
+CmdArgs.push_back(Args.MakeArgString(
+"--cuda-path=" + Args.getLastArgValue(options::OPT_cuda_path_EQ)));
+
   // Add paths specified in LIBRARY_PATH environment variable as -L options.
   addDirectoryList(Args, CmdArgs, "-L", "LIBRARY_PATH");
 
diff --git a/clang/test/Driver/linker-wrapper-passes.c 
b/clang/test/Driver/linker-wrapper-passes.c
index aadcf472e9b63..8c337ff906d17 100644
--- a/clang/test/Driver/linker-wrapper-passes.c
+++ b/clang/test/Driver/linker-wrapper-passes.c
@@ -1,9 +1,5 @@
 // Check various clang-linker-wrapper pass options after -offload-opt.
 
-// REQUIRES: llvm-plugins, llvm-examples
-// REQUIRES: x86-registered-target
-// REQUIRES: amdgpu-registered-target
-
 // Setup.
 // RUN: mkdir -p %t
 // RUN: %clang -cc1 -emit-llvm-bc -o %t/host-x86_64-unknown-linux-gnu.bc \
@@ -23,14 +19,14 @@
 // RUN: %t/host-x86_64-unknown-linux-gnu.s
 
 // Check plugin, -passes, and no remarks.
-// RUN: clang-linker-wrapper -o a.out --embed-bitcode \
+// RUN: clang-linker-wrapper -o a.out --embed-bitcode --dry-run \
 // RUN: --linker-path=/usr/bin/true %t/host-x86_64-unknown-linux-gnu.o \
 // RUN: %offload-opt-loadbye --offload-opt=-wave-goodbye \
 // RUN: --offload-opt=-passes="function(goodbye),module(inline)" 2>&1 | \
 // RUN:   FileCheck -match-full-lines -check-prefixes=OUT %s
 
 // Check plugin, -p, and remarks.
-// RUN: clang-linker-wrapper -o a.out --embed-bitcode \
+// RUN: clang-linker-wrapper -o a.out --embed-bitcode --dry-run \
 // RUN: --linker-path=/usr/bin/true %t/host-x86_64-unknown-linux-gnu.o \
 // RUN: %offload-opt-loadbye --offload-opt=-wave-goodbye \
 // RUN: --offload-opt=-p="function(goodbye),module(inline)" \
@@ -43,7 +39,7 @@
 // RUN: -check-prefixes=YML %s
 
 // Check handling of bad plugin.
-// RUN: not clang-linker-wrapper \
+// RUN: not clang-linker-wrapper --dry-run \
 // RUN: --offload-opt=-load-pass-plugin=%t/nonexistent.so 2>&1 | \
 // RUN:   FileCheck -match-full-lines -check-prefixes=BAD-PLUGIN %s
 
diff --git a/clang/test/Driver/nvlink-wrapper.c 
b/clang/test/Driver/nvlink-wrapper.c
index fdda93f1f9cdc..318315ddaca34 100644
--- a/clang/test/Driver/nvlink-wrapper.c
+++ b/clang/test/Driver/nvlink-wrapper.c
@@ -63,3 +63,10 @@ int baz() { return y + x; }
 // RUN:   -arch sm_52 -o a.out 2>&1 | FileCheck %s --check-prefix=LTO
 // LTO: ptxas{{.*}} -m64 -c [[PTX:.+]].s -O3 -arch sm_52 -o [[CUBIN:.+]].cubin
 // LTO: nvlink{{.*}} -arch sm_52 -o a.out [[CUBIN]].cubin 
{{.*}}-u-{{.*}}.cubin {{.*}}-y-{{.*}}.cubin
+
+//
+// Check that we don't forward some arguments.
+//
+// RUN: clang-nvlink-wrapper --dry-run %t.o %t-u.o %t-y.a \
+// RUN:   -arch sm_52 --cuda-path/opt/cuda -o a.out 2>&1 | FileCheck %s 
--check-prefix=PATH
+// PATH-NOT: --cuda-path=/opt/cuda
diff --git a/clang/tools/clang-nvlink-wrapper/NVLinkOpts.td 
b/clang/tools/clang-nvlink-wrapper/NVLinkOpts.td
index e84b530f2787d..8c80a51b12a44 100644
--- a/clang/tools/clang-nvlink-wrapper/NVLinkOpts.td
+++ b/clang/tools/clang-nvlink-wrapper/NVLinkOpts.td
@@ -12,9 +12,9 @@ def verbose : Flag<["-"], "v">, HelpText<"Print verbose 
information">;
 def version : Flag<["--"], "version">,
   HelpText<"Display the version number and exit">;
 
-def cuda_path_EQ : Joined<["--"], "cuda-path=">,
+def cuda_path_EQ : Joined<["--"], "cuda-path=">, Flags<[WrapperOnlyOption]>,
   MetaVarName<"">, HelpText<"Set the system CUDA path">;
-def ptxas_path_EQ : Joined<["--"], "ptxas-path=">,
+def ptxas_path_EQ : Joined<["--"], "ptxas-path=">, Flags<[WrapperOnlyOption]>,
   MetaVarName<"">, HelpText<"Set the 'ptxas' path">;
 
 def o : JoinedOrSeparate<["-"], "o">, MetaVarName<"">,

>From e9ac0f0e5916236cb091179cfa7befd081b01355

[llvm-branch-commits] [clang] release/19.x: [Clang] Correctly forward `--cuda-path` to the nvlink wrapper (#100170) (PR #100216)

[Joseph Huber via llvm-branch-commits]

https://github.com/jhuber6 updated 
https://github.com/llvm/llvm-project/pull/100216

>From d7f99606094fc1feb41b50de0b0eb6d07460 Mon Sep 17 00:00:00 2001
From: Joseph Huber 
Date: Tue, 23 Jul 2024 14:41:57 -0500
Subject: [PATCH 1/4] [Clang] Correctly forward `--cuda-path` to the nvlink
 wrapper (#100170)

Summary:
This was not forwarded properly as it would try to pass it to `nvlink`.

Fixes https://github.com/llvm/llvm-project/issues/100168

(cherry picked from commit 7e1fcf5dd657d465c3fc846f56c6f9d3a4560b43)
---
 clang/lib/Driver/ToolChains/Cuda.cpp   |  4 
 clang/test/Driver/linker-wrapper-passes.c  | 10 +++---
 clang/test/Driver/nvlink-wrapper.c |  7 +++
 clang/tools/clang-nvlink-wrapper/NVLinkOpts.td |  4 ++--
 4 files changed, 16 insertions(+), 9 deletions(-)

diff --git a/clang/lib/Driver/ToolChains/Cuda.cpp 
b/clang/lib/Driver/ToolChains/Cuda.cpp
index 59453c484ae4f..61d12b10dfb62 100644
--- a/clang/lib/Driver/ToolChains/Cuda.cpp
+++ b/clang/lib/Driver/ToolChains/Cuda.cpp
@@ -609,6 +609,10 @@ void NVPTX::Linker::ConstructJob(Compilation &C, const 
JobAction &JA,
 CmdArgs.push_back(Args.MakeArgString(
 "--pxtas-path=" + Args.getLastArgValue(options::OPT_ptxas_path_EQ)));
 
+  if (Args.hasArg(options::OPT_cuda_path_EQ))
+CmdArgs.push_back(Args.MakeArgString(
+"--cuda-path=" + Args.getLastArgValue(options::OPT_cuda_path_EQ)));
+
   // Add paths specified in LIBRARY_PATH environment variable as -L options.
   addDirectoryList(Args, CmdArgs, "-L", "LIBRARY_PATH");
 
diff --git a/clang/test/Driver/linker-wrapper-passes.c 
b/clang/test/Driver/linker-wrapper-passes.c
index aadcf472e9b63..8c337ff906d17 100644
--- a/clang/test/Driver/linker-wrapper-passes.c
+++ b/clang/test/Driver/linker-wrapper-passes.c
@@ -1,9 +1,5 @@
 // Check various clang-linker-wrapper pass options after -offload-opt.
 
-// REQUIRES: llvm-plugins, llvm-examples
-// REQUIRES: x86-registered-target
-// REQUIRES: amdgpu-registered-target
-
 // Setup.
 // RUN: mkdir -p %t
 // RUN: %clang -cc1 -emit-llvm-bc -o %t/host-x86_64-unknown-linux-gnu.bc \
@@ -23,14 +19,14 @@
 // RUN: %t/host-x86_64-unknown-linux-gnu.s
 
 // Check plugin, -passes, and no remarks.
-// RUN: clang-linker-wrapper -o a.out --embed-bitcode \
+// RUN: clang-linker-wrapper -o a.out --embed-bitcode --dry-run \
 // RUN: --linker-path=/usr/bin/true %t/host-x86_64-unknown-linux-gnu.o \
 // RUN: %offload-opt-loadbye --offload-opt=-wave-goodbye \
 // RUN: --offload-opt=-passes="function(goodbye),module(inline)" 2>&1 | \
 // RUN:   FileCheck -match-full-lines -check-prefixes=OUT %s
 
 // Check plugin, -p, and remarks.
-// RUN: clang-linker-wrapper -o a.out --embed-bitcode \
+// RUN: clang-linker-wrapper -o a.out --embed-bitcode --dry-run \
 // RUN: --linker-path=/usr/bin/true %t/host-x86_64-unknown-linux-gnu.o \
 // RUN: %offload-opt-loadbye --offload-opt=-wave-goodbye \
 // RUN: --offload-opt=-p="function(goodbye),module(inline)" \
@@ -43,7 +39,7 @@
 // RUN: -check-prefixes=YML %s
 
 // Check handling of bad plugin.
-// RUN: not clang-linker-wrapper \
+// RUN: not clang-linker-wrapper --dry-run \
 // RUN: --offload-opt=-load-pass-plugin=%t/nonexistent.so 2>&1 | \
 // RUN:   FileCheck -match-full-lines -check-prefixes=BAD-PLUGIN %s
 
diff --git a/clang/test/Driver/nvlink-wrapper.c 
b/clang/test/Driver/nvlink-wrapper.c
index fdda93f1f9cdc..318315ddaca34 100644
--- a/clang/test/Driver/nvlink-wrapper.c
+++ b/clang/test/Driver/nvlink-wrapper.c
@@ -63,3 +63,10 @@ int baz() { return y + x; }
 // RUN:   -arch sm_52 -o a.out 2>&1 | FileCheck %s --check-prefix=LTO
 // LTO: ptxas{{.*}} -m64 -c [[PTX:.+]].s -O3 -arch sm_52 -o [[CUBIN:.+]].cubin
 // LTO: nvlink{{.*}} -arch sm_52 -o a.out [[CUBIN]].cubin 
{{.*}}-u-{{.*}}.cubin {{.*}}-y-{{.*}}.cubin
+
+//
+// Check that we don't forward some arguments.
+//
+// RUN: clang-nvlink-wrapper --dry-run %t.o %t-u.o %t-y.a \
+// RUN:   -arch sm_52 --cuda-path/opt/cuda -o a.out 2>&1 | FileCheck %s 
--check-prefix=PATH
+// PATH-NOT: --cuda-path=/opt/cuda
diff --git a/clang/tools/clang-nvlink-wrapper/NVLinkOpts.td 
b/clang/tools/clang-nvlink-wrapper/NVLinkOpts.td
index e84b530f2787d..8c80a51b12a44 100644
--- a/clang/tools/clang-nvlink-wrapper/NVLinkOpts.td
+++ b/clang/tools/clang-nvlink-wrapper/NVLinkOpts.td
@@ -12,9 +12,9 @@ def verbose : Flag<["-"], "v">, HelpText<"Print verbose 
information">;
 def version : Flag<["--"], "version">,
   HelpText<"Display the version number and exit">;
 
-def cuda_path_EQ : Joined<["--"], "cuda-path=">,
+def cuda_path_EQ : Joined<["--"], "cuda-path=">, Flags<[WrapperOnlyOption]>,
   MetaVarName<"">, HelpText<"Set the system CUDA path">;
-def ptxas_path_EQ : Joined<["--"], "ptxas-path=">,
+def ptxas_path_EQ : Joined<["--"], "ptxas-path=">, Flags<[WrapperOnlyOption]>,
   MetaVarName<"">, HelpText<"Set the 'ptxas' path">;
 
 def o : JoinedOrSeparate<["-"], "o">, MetaVarName<"">,

>From e9ac0f0e5916236cb091179cfa7befd081b01355

[llvm-branch-commits] [clang] release/19.x: [Clang] Correctly forward `--cuda-path` to the nvlink wrapper (#100170) (PR #100216)

[Joseph Huber via llvm-branch-commits]

https://github.com/jhuber6 updated 
https://github.com/llvm/llvm-project/pull/100216

>From d7f99606094fc1feb41b50de0b0eb6d07460 Mon Sep 17 00:00:00 2001
From: Joseph Huber 
Date: Tue, 23 Jul 2024 14:41:57 -0500
Subject: [PATCH 1/5] [Clang] Correctly forward `--cuda-path` to the nvlink
 wrapper (#100170)

Summary:
This was not forwarded properly as it would try to pass it to `nvlink`.

Fixes https://github.com/llvm/llvm-project/issues/100168

(cherry picked from commit 7e1fcf5dd657d465c3fc846f56c6f9d3a4560b43)
---
 clang/lib/Driver/ToolChains/Cuda.cpp   |  4 
 clang/test/Driver/linker-wrapper-passes.c  | 10 +++---
 clang/test/Driver/nvlink-wrapper.c |  7 +++
 clang/tools/clang-nvlink-wrapper/NVLinkOpts.td |  4 ++--
 4 files changed, 16 insertions(+), 9 deletions(-)

diff --git a/clang/lib/Driver/ToolChains/Cuda.cpp 
b/clang/lib/Driver/ToolChains/Cuda.cpp
index 59453c484ae4f..61d12b10dfb62 100644
--- a/clang/lib/Driver/ToolChains/Cuda.cpp
+++ b/clang/lib/Driver/ToolChains/Cuda.cpp
@@ -609,6 +609,10 @@ void NVPTX::Linker::ConstructJob(Compilation &C, const 
JobAction &JA,
 CmdArgs.push_back(Args.MakeArgString(
 "--pxtas-path=" + Args.getLastArgValue(options::OPT_ptxas_path_EQ)));
 
+  if (Args.hasArg(options::OPT_cuda_path_EQ))
+CmdArgs.push_back(Args.MakeArgString(
+"--cuda-path=" + Args.getLastArgValue(options::OPT_cuda_path_EQ)));
+
   // Add paths specified in LIBRARY_PATH environment variable as -L options.
   addDirectoryList(Args, CmdArgs, "-L", "LIBRARY_PATH");
 
diff --git a/clang/test/Driver/linker-wrapper-passes.c 
b/clang/test/Driver/linker-wrapper-passes.c
index aadcf472e9b63..8c337ff906d17 100644
--- a/clang/test/Driver/linker-wrapper-passes.c
+++ b/clang/test/Driver/linker-wrapper-passes.c
@@ -1,9 +1,5 @@
 // Check various clang-linker-wrapper pass options after -offload-opt.
 
-// REQUIRES: llvm-plugins, llvm-examples
-// REQUIRES: x86-registered-target
-// REQUIRES: amdgpu-registered-target
-
 // Setup.
 // RUN: mkdir -p %t
 // RUN: %clang -cc1 -emit-llvm-bc -o %t/host-x86_64-unknown-linux-gnu.bc \
@@ -23,14 +19,14 @@
 // RUN: %t/host-x86_64-unknown-linux-gnu.s
 
 // Check plugin, -passes, and no remarks.
-// RUN: clang-linker-wrapper -o a.out --embed-bitcode \
+// RUN: clang-linker-wrapper -o a.out --embed-bitcode --dry-run \
 // RUN: --linker-path=/usr/bin/true %t/host-x86_64-unknown-linux-gnu.o \
 // RUN: %offload-opt-loadbye --offload-opt=-wave-goodbye \
 // RUN: --offload-opt=-passes="function(goodbye),module(inline)" 2>&1 | \
 // RUN:   FileCheck -match-full-lines -check-prefixes=OUT %s
 
 // Check plugin, -p, and remarks.
-// RUN: clang-linker-wrapper -o a.out --embed-bitcode \
+// RUN: clang-linker-wrapper -o a.out --embed-bitcode --dry-run \
 // RUN: --linker-path=/usr/bin/true %t/host-x86_64-unknown-linux-gnu.o \
 // RUN: %offload-opt-loadbye --offload-opt=-wave-goodbye \
 // RUN: --offload-opt=-p="function(goodbye),module(inline)" \
@@ -43,7 +39,7 @@
 // RUN: -check-prefixes=YML %s
 
 // Check handling of bad plugin.
-// RUN: not clang-linker-wrapper \
+// RUN: not clang-linker-wrapper --dry-run \
 // RUN: --offload-opt=-load-pass-plugin=%t/nonexistent.so 2>&1 | \
 // RUN:   FileCheck -match-full-lines -check-prefixes=BAD-PLUGIN %s
 
diff --git a/clang/test/Driver/nvlink-wrapper.c 
b/clang/test/Driver/nvlink-wrapper.c
index fdda93f1f9cdc..318315ddaca34 100644
--- a/clang/test/Driver/nvlink-wrapper.c
+++ b/clang/test/Driver/nvlink-wrapper.c
@@ -63,3 +63,10 @@ int baz() { return y + x; }
 // RUN:   -arch sm_52 -o a.out 2>&1 | FileCheck %s --check-prefix=LTO
 // LTO: ptxas{{.*}} -m64 -c [[PTX:.+]].s -O3 -arch sm_52 -o [[CUBIN:.+]].cubin
 // LTO: nvlink{{.*}} -arch sm_52 -o a.out [[CUBIN]].cubin 
{{.*}}-u-{{.*}}.cubin {{.*}}-y-{{.*}}.cubin
+
+//
+// Check that we don't forward some arguments.
+//
+// RUN: clang-nvlink-wrapper --dry-run %t.o %t-u.o %t-y.a \
+// RUN:   -arch sm_52 --cuda-path/opt/cuda -o a.out 2>&1 | FileCheck %s 
--check-prefix=PATH
+// PATH-NOT: --cuda-path=/opt/cuda
diff --git a/clang/tools/clang-nvlink-wrapper/NVLinkOpts.td 
b/clang/tools/clang-nvlink-wrapper/NVLinkOpts.td
index e84b530f2787d..8c80a51b12a44 100644
--- a/clang/tools/clang-nvlink-wrapper/NVLinkOpts.td
+++ b/clang/tools/clang-nvlink-wrapper/NVLinkOpts.td
@@ -12,9 +12,9 @@ def verbose : Flag<["-"], "v">, HelpText<"Print verbose 
information">;
 def version : Flag<["--"], "version">,
   HelpText<"Display the version number and exit">;
 
-def cuda_path_EQ : Joined<["--"], "cuda-path=">,
+def cuda_path_EQ : Joined<["--"], "cuda-path=">, Flags<[WrapperOnlyOption]>,
   MetaVarName<"">, HelpText<"Set the system CUDA path">;
-def ptxas_path_EQ : Joined<["--"], "ptxas-path=">,
+def ptxas_path_EQ : Joined<["--"], "ptxas-path=">, Flags<[WrapperOnlyOption]>,
   MetaVarName<"">, HelpText<"Set the 'ptxas' path">;
 
 def o : JoinedOrSeparate<["-"], "o">, MetaVarName<"">,

>From e9ac0f0e5916236cb091179cfa7befd081b01355

[llvm-branch-commits] [libc] release/19.x: [libc] Fix leftover debug commandline argument (PR #100291)

[Joseph Huber via llvm-branch-commits]

@@ -29,7 +29,7 @@ to learn about the defaults for your platform and target.
 - ``LIBC_CONF_ENABLE_STRONG_STACK_PROTECTOR``: Enable 
-fstack-protector-strong to defend against stack smashing attack.
 - ``LIBC_CONF_KEEP_FRAME_POINTER``: Keep frame pointer in functions for 
better debugging experience.
 * **"errno" options**
-- ``LIBC_CONF_ERRNO_MODE``: The implementation used for errno, acceptable 
values are LIBC_ERRNO_MODE_UNDEFINED, LIBC_ERRNO_MODE_THREAD_LOCAL, 
LIBC_ERRNO_MODE_SHARED, LIBC_ERRNO_MODE_EXTERNAL, and LIBC_ERRNO_MODE_SYSTEM.
+- ``LIBC_CONF_ERRNO_MODE``: The implementation used for errno, acceptable 
values are LIBC_ERRNO_MODE_DEFAULT, LIBC_ERRNO_MODE_UNDEFINED, 
LIBC_ERRNO_MODE_THREAD_LOCAL, LIBC_ERRNO_MODE_SHARED, LIBC_ERRNO_MODE_EXTERNAL, 
and LIBC_ERRNO_MODE_SYSTEM.

jhuber6 wrote:

```suggestion
- ``LIBC_CONF_ERRNO_MODE``: The implementation used for errno, acceptable 
values are LIBC_ERRNO_MODE_UNDEFINED, LIBC_ERRNO_MODE_THREAD_LOCAL, 
LIBC_ERRNO_MODE_SHARED, LIBC_ERRNO_MODE_EXTERNAL, and LIBC_ERRNO_MODE_SYSTEM.
```

https://github.com/llvm/llvm-project/pull/100291
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [libc] release/19.x: [libc] Fix leftover debug commandline argument (PR #100291)

[Joseph Huber via llvm-branch-commits]

https://github.com/jhuber6 updated 
https://github.com/llvm/llvm-project/pull/100291

>From c3dfd23fd6bb167eb6be49a24aef14a0f5621d8d Mon Sep 17 00:00:00 2001
From: Joseph Huber 
Date: Tue, 23 Jul 2024 21:35:09 -0500
Subject: [PATCH 1/2] [libc] Fix leftover debug commandline argument

Summary:
Fixes https://github.com/llvm/llvm-project/issues/100289

(cherry picked from commit 0420d2f97eac49af5e816b0e3f2a9135d1673168)
---
 libc/cmake/modules/LLVMLibCTestRules.cmake | 1 -
 libc/docs/configure.rst| 2 +-
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/libc/cmake/modules/LLVMLibCTestRules.cmake 
b/libc/cmake/modules/LLVMLibCTestRules.cmake
index 18adbee0bc7ad..96eb065c4a672 100644
--- a/libc/cmake/modules/LLVMLibCTestRules.cmake
+++ b/libc/cmake/modules/LLVMLibCTestRules.cmake
@@ -651,7 +651,6 @@ function(add_libc_hermetic test_name)
 target_link_options(${fq_build_target_name} PRIVATE
   ${LIBC_COMPILE_OPTIONS_DEFAULT} -Wno-multi-gpu
   -mcpu=${LIBC_GPU_TARGET_ARCHITECTURE} -flto
-  "-Wl,-asdfasdfasdf"
   "-Wl,-mllvm,-amdgpu-lower-global-ctor-dtor=0" -nostdlib -static
   "-Wl,-mllvm,-amdhsa-code-object-version=${LIBC_GPU_CODE_OBJECT_VERSION}")
   elseif(LIBC_TARGET_ARCHITECTURE_IS_NVPTX)
diff --git a/libc/docs/configure.rst b/libc/docs/configure.rst
index 5c55e4ab0f181..b81922367d8b7 100644
--- a/libc/docs/configure.rst
+++ b/libc/docs/configure.rst
@@ -29,7 +29,7 @@ to learn about the defaults for your platform and target.
 - ``LIBC_CONF_ENABLE_STRONG_STACK_PROTECTOR``: Enable 
-fstack-protector-strong to defend against stack smashing attack.
 - ``LIBC_CONF_KEEP_FRAME_POINTER``: Keep frame pointer in functions for 
better debugging experience.
 * **"errno" options**
-- ``LIBC_CONF_ERRNO_MODE``: The implementation used for errno, acceptable 
values are LIBC_ERRNO_MODE_UNDEFINED, LIBC_ERRNO_MODE_THREAD_LOCAL, 
LIBC_ERRNO_MODE_SHARED, LIBC_ERRNO_MODE_EXTERNAL, and LIBC_ERRNO_MODE_SYSTEM.
+- ``LIBC_CONF_ERRNO_MODE``: The implementation used for errno, acceptable 
values are LIBC_ERRNO_MODE_DEFAULT, LIBC_ERRNO_MODE_UNDEFINED, 
LIBC_ERRNO_MODE_THREAD_LOCAL, LIBC_ERRNO_MODE_SHARED, LIBC_ERRNO_MODE_EXTERNAL, 
and LIBC_ERRNO_MODE_SYSTEM.
 * **"malloc" options**
 - ``LIBC_CONF_FREELIST_MALLOC_BUFFER_SIZE``: Default size for the 
constinit freelist buffer used for the freelist malloc implementation (default 
1o 1GB).
 * **"math" options**

>From 5cc1df8e0c418ab3b7af212804f2fddf3371b71c Mon Sep 17 00:00:00 2001
From: Joseph Huber 
Date: Tue, 23 Jul 2024 22:04:47 -0500
Subject: [PATCH 2/2] Update libc/docs/configure.rst

---
 libc/docs/configure.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libc/docs/configure.rst b/libc/docs/configure.rst
index b81922367d8b7..5c55e4ab0f181 100644
--- a/libc/docs/configure.rst
+++ b/libc/docs/configure.rst
@@ -29,7 +29,7 @@ to learn about the defaults for your platform and target.
 - ``LIBC_CONF_ENABLE_STRONG_STACK_PROTECTOR``: Enable 
-fstack-protector-strong to defend against stack smashing attack.
 - ``LIBC_CONF_KEEP_FRAME_POINTER``: Keep frame pointer in functions for 
better debugging experience.
 * **"errno" options**
-- ``LIBC_CONF_ERRNO_MODE``: The implementation used for errno, acceptable 
values are LIBC_ERRNO_MODE_DEFAULT, LIBC_ERRNO_MODE_UNDEFINED, 
LIBC_ERRNO_MODE_THREAD_LOCAL, LIBC_ERRNO_MODE_SHARED, LIBC_ERRNO_MODE_EXTERNAL, 
and LIBC_ERRNO_MODE_SYSTEM.
+- ``LIBC_CONF_ERRNO_MODE``: The implementation used for errno, acceptable 
values are LIBC_ERRNO_MODE_UNDEFINED, LIBC_ERRNO_MODE_THREAD_LOCAL, 
LIBC_ERRNO_MODE_SHARED, LIBC_ERRNO_MODE_EXTERNAL, and LIBC_ERRNO_MODE_SYSTEM.
 * **"malloc" options**
 - ``LIBC_CONF_FREELIST_MALLOC_BUFFER_SIZE``: Default size for the 
constinit freelist buffer used for the freelist malloc implementation (default 
1o 1GB).
 * **"math" options**

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

[llvm-branch-commits] [libc] release/19.x: [libc] Fix leftover debug commandline argument (PR #100291)

[Joseph Huber via llvm-branch-commits]

https://github.com/jhuber6 updated 
https://github.com/llvm/llvm-project/pull/100291

>From c3dfd23fd6bb167eb6be49a24aef14a0f5621d8d Mon Sep 17 00:00:00 2001
From: Joseph Huber 
Date: Tue, 23 Jul 2024 21:35:09 -0500
Subject: [PATCH 1/2] [libc] Fix leftover debug commandline argument

Summary:
Fixes https://github.com/llvm/llvm-project/issues/100289

(cherry picked from commit 0420d2f97eac49af5e816b0e3f2a9135d1673168)
---
 libc/cmake/modules/LLVMLibCTestRules.cmake | 1 -
 libc/docs/configure.rst| 2 +-
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/libc/cmake/modules/LLVMLibCTestRules.cmake 
b/libc/cmake/modules/LLVMLibCTestRules.cmake
index 18adbee0bc7ad..96eb065c4a672 100644
--- a/libc/cmake/modules/LLVMLibCTestRules.cmake
+++ b/libc/cmake/modules/LLVMLibCTestRules.cmake
@@ -651,7 +651,6 @@ function(add_libc_hermetic test_name)
 target_link_options(${fq_build_target_name} PRIVATE
   ${LIBC_COMPILE_OPTIONS_DEFAULT} -Wno-multi-gpu
   -mcpu=${LIBC_GPU_TARGET_ARCHITECTURE} -flto
-  "-Wl,-asdfasdfasdf"
   "-Wl,-mllvm,-amdgpu-lower-global-ctor-dtor=0" -nostdlib -static
   "-Wl,-mllvm,-amdhsa-code-object-version=${LIBC_GPU_CODE_OBJECT_VERSION}")
   elseif(LIBC_TARGET_ARCHITECTURE_IS_NVPTX)
diff --git a/libc/docs/configure.rst b/libc/docs/configure.rst
index 5c55e4ab0f181..b81922367d8b7 100644
--- a/libc/docs/configure.rst
+++ b/libc/docs/configure.rst
@@ -29,7 +29,7 @@ to learn about the defaults for your platform and target.
 - ``LIBC_CONF_ENABLE_STRONG_STACK_PROTECTOR``: Enable 
-fstack-protector-strong to defend against stack smashing attack.
 - ``LIBC_CONF_KEEP_FRAME_POINTER``: Keep frame pointer in functions for 
better debugging experience.
 * **"errno" options**
-- ``LIBC_CONF_ERRNO_MODE``: The implementation used for errno, acceptable 
values are LIBC_ERRNO_MODE_UNDEFINED, LIBC_ERRNO_MODE_THREAD_LOCAL, 
LIBC_ERRNO_MODE_SHARED, LIBC_ERRNO_MODE_EXTERNAL, and LIBC_ERRNO_MODE_SYSTEM.
+- ``LIBC_CONF_ERRNO_MODE``: The implementation used for errno, acceptable 
values are LIBC_ERRNO_MODE_DEFAULT, LIBC_ERRNO_MODE_UNDEFINED, 
LIBC_ERRNO_MODE_THREAD_LOCAL, LIBC_ERRNO_MODE_SHARED, LIBC_ERRNO_MODE_EXTERNAL, 
and LIBC_ERRNO_MODE_SYSTEM.
 * **"malloc" options**
 - ``LIBC_CONF_FREELIST_MALLOC_BUFFER_SIZE``: Default size for the 
constinit freelist buffer used for the freelist malloc implementation (default 
1o 1GB).
 * **"math" options**

>From 5cc1df8e0c418ab3b7af212804f2fddf3371b71c Mon Sep 17 00:00:00 2001
From: Joseph Huber 
Date: Tue, 23 Jul 2024 22:04:47 -0500
Subject: [PATCH 2/2] Update libc/docs/configure.rst

---
 libc/docs/configure.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libc/docs/configure.rst b/libc/docs/configure.rst
index b81922367d8b7..5c55e4ab0f181 100644
--- a/libc/docs/configure.rst
+++ b/libc/docs/configure.rst
@@ -29,7 +29,7 @@ to learn about the defaults for your platform and target.
 - ``LIBC_CONF_ENABLE_STRONG_STACK_PROTECTOR``: Enable 
-fstack-protector-strong to defend against stack smashing attack.
 - ``LIBC_CONF_KEEP_FRAME_POINTER``: Keep frame pointer in functions for 
better debugging experience.
 * **"errno" options**
-- ``LIBC_CONF_ERRNO_MODE``: The implementation used for errno, acceptable 
values are LIBC_ERRNO_MODE_DEFAULT, LIBC_ERRNO_MODE_UNDEFINED, 
LIBC_ERRNO_MODE_THREAD_LOCAL, LIBC_ERRNO_MODE_SHARED, LIBC_ERRNO_MODE_EXTERNAL, 
and LIBC_ERRNO_MODE_SYSTEM.
+- ``LIBC_CONF_ERRNO_MODE``: The implementation used for errno, acceptable 
values are LIBC_ERRNO_MODE_UNDEFINED, LIBC_ERRNO_MODE_THREAD_LOCAL, 
LIBC_ERRNO_MODE_SHARED, LIBC_ERRNO_MODE_EXTERNAL, and LIBC_ERRNO_MODE_SYSTEM.
 * **"malloc" options**
 - ``LIBC_CONF_FREELIST_MALLOC_BUFFER_SIZE``: Default size for the 
constinit freelist buffer used for the freelist malloc implementation (default 
1o 1GB).
 * **"math" options**

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

[llvm-branch-commits] [libc] release/19.x: [libc] Fix leftover debug commandline argument (PR #100291)

[Joseph Huber via llvm-branch-commits]

https://github.com/jhuber6 approved this pull request.


https://github.com/llvm/llvm-project/pull/100291
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [llvm] release/19.x: InferAddressSpaces: Fix mishandling stores of pointers to themselves (#101877) (PR #101887)

[Joseph Huber via llvm-branch-commits]

https://github.com/jhuber6 approved this pull request.


https://github.com/llvm/llvm-project/pull/101887
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [llvm] release/19.x: Revert "[LLVM] Silence compiler-rt warning in runtimes build (#99525)" (PR #102475)

[Joseph Huber via llvm-branch-commits]

jhuber6 wrote:

Do you any clue why this is broken? `LLVM_CMAKE_DIR` should be innocuous 
enough, so if it's causing failures then there's probably a separate issue.

https://github.com/llvm/llvm-project/pull/102475
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [llvm] release/19.x: Revert "[LLVM] Silence compiler-rt warning in runtimes build (#99525)" (PR #102475)

[Joseph Huber via llvm-branch-commits]

jhuber6 wrote:

> 
> It appears that in the bad case, `LLVM_CMAKE_DIR` during the `find_package` 
> is set to `/home/ubuntu/llvm-project/llvm/cmake/modules`. In the good case, 
> it's set to `/home/ubuntu/bld`.

The latter is what it's supposed to do, I would think? When doing a runtimes 
build it's supposed to bootstrap off of the current LLVM build. Maybe someone 
more familiar with the builtins build process could expand on this.

https://github.com/llvm/llvm-project/pull/102475
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [llvm] release/19.x: Revert "[LLVM] Silence compiler-rt warning in runtimes build (#99525)" (PR #102475)

[Joseph Huber via llvm-branch-commits]

jhuber6 wrote:

> For reasons I don't understand, cmake (version 3.22.1, default on Ubuntu 
> 22.04.4) is not producing debug output for the find_package call for LLVM if 
> I use `cmake --debug-find`. It does produce output for other packages.
> 
> Resorting to strace -efile:
> 
> Good:
> 
> ```
> /home/ubuntu/llvm-project/compiler-rt/cmake/Modules/CompilerRTUtils.cmake(312):
>   find_package(LLVM HINTS /home/ubuntu/bld4 )
> access("/home/ubuntu/bld4/lib/cmake/llvm/LLVMConfig.cmake", R_OK) = 0
> ```
> 
> Bad:
> 
> ```
> /home/ubuntu/llvm-project/compiler-rt/cmake/Modules/CompilerRTUtils.cmake(312):
>   find_package(LLVM HINTS /home/ubuntu/llvm-project/llvm/cmake/modules )
> access("/usr/lib/llvm-14/cmake/LLVMConfig.cmake", R_OK) = 0
> ```
> 
> Not sure why cmake is ignoring the hint. It doesn't appear to test any other 
> directories.

Do you know what `LLVM_CONFIG_PATH` is set to in this case? The old handling 
was to get the config path based off of that, so i'd be surprised if it were 
fundamentally different. The runtimes build should not be using a config that 
exists out-of-tree as far as I'm aware.

https://github.com/llvm/llvm-project/pull/102475
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [llvm] release/19.x: Revert "[LLVM] Silence compiler-rt warning in runtimes build (#99525)" (PR #102475)

[Joseph Huber via llvm-branch-commits]

jhuber6 wrote:

So, in the "bad" case, it's finding the LLVMConfig.cmake I would expect. The 
"good" case is picking up the wrong one, but it somehow works? In both cases it 
reports that LLVM was found, but the one in-tree doesn't work for some reason. 
Sorry for all the questions, I'm not able to reproduce this.

https://github.com/llvm/llvm-project/pull/102475
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [clang] release/19.x: [Clang] Correctly forward `--cuda-path` to the nvlink wrapper (#100170) (PR #100216)

[Joseph Huber via llvm-branch-commits]

https://github.com/jhuber6 approved this pull request.


https://github.com/llvm/llvm-project/pull/100216
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [openmp] release/18.x: [OpenMP] [cmake] Don't use -fno-semantic-interposition on Windows (#81113) (PR #81332)

[Joseph Huber via llvm-branch-commits]

jhuber6 wrote:

Sure, LG

https://github.com/llvm/llvm-project/pull/81332
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [llvm] [RISCV] Support llvm.readsteadycounter intrinsic (PR #82322)

[Joseph Huber via llvm-branch-commits]

https://github.com/jhuber6 approved this pull request.


https://github.com/llvm/llvm-project/pull/82322
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [openmp] release/18.x: [OpenMP] Fix child processes to use affinity_none (#91391) (PR #91479)

[Joseph Huber via llvm-branch-commits]

jhuber6 wrote:

> @jhuber6 What do you think about merging this PR to the release branch?

This PR should be merged.

> @jhuber6 , Sorry, I'm not used to backporting. Are you the right person for 
> this?

AFAIK the bot asking is automated and then a human pushes the button.

https://github.com/llvm/llvm-project/pull/91479
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [libc] [libcxx] [libcxxabi] [libunwind] [llvm] [pstl] Revise IDE folder structure (PR #89755)

[Joseph Huber via llvm-branch-commits]

@@ -9,6 +9,7 @@ include(${LLVM_COMMON_CMAKE_UTILS}/Modules/CMakePolicy.cmake
 include(${LLVM_COMMON_CMAKE_UTILS}/Modules/LLVMVersion.cmake)
 
 project(Runtimes C CXX ASM)
+set(LLVM_SUBPROJECT_TITLE "Runtimes")

jhuber6 wrote:

Is this needed? My understanding is that the runtimes CMake here is the root 
that includes all the other projects, so this doesn't actually contain any 
"projects'>

https://github.com/llvm/llvm-project/pull/89755
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [libc] [libcxx] [libcxxabi] [libunwind] [llvm] [pstl] Revise IDE folder structure (PR #89755)

[Joseph Huber via llvm-branch-commits]

https://github.com/jhuber6 approved this pull request.


https://github.com/llvm/llvm-project/pull/89755
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [openmp] PR for llvm/llvm-project#80117 (PR #80291)

[Joseph Huber via llvm-branch-commits]

jhuber6 wrote:

Merge

https://github.com/llvm/llvm-project/pull/80291
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [clang] Revert "[LinkerWrapper] Extend with usual pass options (#96704)" (#102226) (PR #106439)

[Joseph Huber via llvm-branch-commits]

https://github.com/jhuber6 approved this pull request.

Thanks

https://github.com/llvm/llvm-project/pull/106439
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [openmp] a957634 - [OpenMP] Add documentation for error messages and release notes

[Joseph Huber via llvm-branch-commits]

Author: Joseph Huber
Date: 2021-01-13T11:00:41-05:00
New Revision: a957634942a48c963a8ed99b1bb90f7b985a3602

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

LOG: [OpenMP] Add documentation for error messages and release notes

Add extra information to the runtime page describing the error messages and add 
information to the release notes for clang 12.0

Reviewed By: jdoerfert

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

Added: 


Modified: 
openmp/docs/ReleaseNotes.rst
openmp/docs/design/Runtimes.rst

Removed: 




diff  --git a/openmp/docs/ReleaseNotes.rst b/openmp/docs/ReleaseNotes.rst
index de0f2018032c..7f40d3c81510 100644
--- a/openmp/docs/ReleaseNotes.rst
+++ b/openmp/docs/ReleaseNotes.rst
@@ -13,11 +13,34 @@ Introduction
 
 
 This document contains the release notes for the OpenMP runtime, release 
12.0.0.
-Here we describe the status of openmp, including major improvements
-from the previous release. All openmp releases may be downloaded
+Here we describe the status of OpenMP, including major improvements
+from the previous release. All OpenMP releases may be downloaded
 from the `LLVM releases web site `_.
 
 Non-comprehensive list of changes in this release
 =
 
+- Extended the ``libomptarget`` API functions to include source location
+  information and OpenMP target mapper support. This allows ``libomptarget`` to
+  know the source location of the OpenMP region it is executing, as well as the
+  name and declarations of all the variables used inside the region. Each
+  function generated now uses its ``mapper`` variant. The old API calls now 
call
+  into the new API functions with ``nullptr`` arguments for backwards
+  compatibility with old binaries. Source location information for
+  ``libomptarget`` is now generated by Clang at any level of debugging
+  information.
 
+- Added improved error messages for ``libomptarget`` and ``CUDA`` plugins. 
Error
+  messages are now presented without requiring a debug build of
+  ``libomptarget``. The newly added source location information can also be 
used
+  to identify which OpenMP target region the failure occurred in. More
+  information can be found :ref:`here `.
+
+- Added additional environment variables to control output from the
+  ``libomptarget`` runtime library. ``LIBOMPTARGET_PROFILE`` to
+  generate time profile output similar to Clang's ``-ftime-trace`` option.
+  ``LIBOMPTARGET_MEMORY_MANAGER_THRESHOLD`` sets the threshold size for which
+  the ``libomptarget`` memory manager will handle the allocation.
+  ``LIBOMPTARGET_INFO`` allows the user to request certain information from the
+  ``libomptarget`` runtime using a 32-bit field. A full description of each
+  environment variable is described :ref:`here 
`.

diff  --git a/openmp/docs/design/Runtimes.rst b/openmp/docs/design/Runtimes.rst
index 1d52b6b8378c..85031c66f442 100644
--- a/openmp/docs/design/Runtimes.rst
+++ b/openmp/docs/design/Runtimes.rst
@@ -16,6 +16,8 @@ the LLVM/OpenMP host runtime, aka.  `libomp.so`, is available 
as a `pdf
 LLVM/OpenMP Target Host Runtime (``libomptarget``)
 --
 
+.. _libopenmptarget_environment_vars:
+
 Environment Variables
 ^
 
@@ -171,6 +173,95 @@ shows that ``D`` will be copied back from the device once 
the OpenMP device
 kernel region ends even though it isn't written to. Finally, at the end of the
 OpenMP data region the entries for ``X`` and ``Y`` are removed from the table.
 
+.. _libopenmptarget_errors:
+
+Errors:
+^^^
+
+``libomptarget`` provides error messages when the program fails inside the
+OpenMP target region. Common causes of failure could be an invalid pointer
+access, running out of device memory, or trying to offload when the device is
+busy. If the application was built with debugging symbols the error messages
+will additionally provide the source location of the OpenMP target region.
+
+For example, consider the following code that implements a simple parallel
+reduction on the GPU. This code has a bug that causes it to fail in the
+offloading region.
+
+.. code-block:: c++
+
+#include 
+
+double sum(double *A, std::size_t N) {
+  double sum = 0.0;
+#pragma omp target teams distribute parallel for reduction(+:sum)
+  for (int i = 0; i < N; ++i)
+sum += A[i];
+
+  return sum;
+}
+
+int main() {
+  const int N = 1024;
+  double A[N];
+  sum(A, N);
+}
+
+If this code is compiled and run, there will be an error message indicating 
what is
+going wrong.
+
+.. code-block:: console
+
+$ clang++ -fopenmp -fopenmp-targets=nvptx64 -O3 -gline-tables-only sum.cpp 
-o s

[llvm-branch-commits] [openmp] abb174b - [OpenMP] Add example in Libomptarget Information docs

[Joseph Huber via llvm-branch-commits]

Author: Joseph Huber
Date: 2021-01-07T15:00:51-05:00
New Revision: abb174bbc100437556fd386d920a9939723e0647

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

LOG: [OpenMP] Add example in Libomptarget Information docs

Add an example to the OpenMP Documentation on the LIBOMPTARGET_INFO environment 
variable

Reviewed By: jdoerfert

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

Added: 


Modified: 
openmp/docs/design/Runtimes.rst

Removed: 




diff  --git a/openmp/docs/design/Runtimes.rst b/openmp/docs/design/Runtimes.rst
index c9f3a55c0067..1d52b6b8378c 100644
--- a/openmp/docs/design/Runtimes.rst
+++ b/openmp/docs/design/Runtimes.rst
@@ -98,6 +98,85 @@ Or, to enable every flag run with every bit set.
 
$ env LIBOMPTARGET_INFO=-1 ./your-application
 
+For example, given a small application implementing the ``ZAXPY`` BLAS routine,
+``Libomptarget`` can provide useful information about data mappings and thread
+usages.
+
+.. code-block:: c++
+
+#include 
+
+using complex = std::complex;
+
+void zaxpy(complex *X, complex *Y, complex D, std::size_t N) {
+#pragma omp target teams distribute parallel for
+  for (std::size_t i = 0; i < N; ++i)
+Y[i] = D * X[i] + Y[i];
+}
+
+int main() {
+  const std::size_t N = 1024;
+  complex X[N], Y[N], D;
+#pragma omp target data map(to:X[0 : N]) map(tofrom:Y[0 : N])
+  zaxpy(X, Y, D, N);
+}
+
+Compiling this code targeting ``nvptx64`` with all information enabled will
+provide the following output from the runtime library.
+
+.. code-block:: console
+
+$ clang++ -fopenmp -fopenmp-targets=nvptx64 -O3 -gline-tables-only 
zaxpy.cpp -o zaxpy
+$ env LIBOMPTARGET_INFO=-1 ./zaxpy
+
+.. code-block:: text
+
+Info: Device supports up to 65536 CUDA blocks and 1024 threads with a warp 
size of 32
+Info: Entering OpenMP data region at zaxpy.cpp:14:1 with 2 arguments:
+Info: to(X[0:N])[16384] 
+Info: tofrom(Y[0:N])[16384] 
+Info: OpenMP Host-Device pointer mappings after block at zaxpy.cpp:14:1:
+Info: Host Ptr   Target Ptr Size (B) RefCount Declaration
+Info: 0x7fff963f4000 0x7fd225004000 163841Y[0:N] at 
zaxpy.cpp:13:17
+Info: 0x7fff963f8000 0x7fd22500 163841X[0:N] at 
zaxpy.cpp:13:11
+Info: Entering OpenMP kernel at zaxpy.cpp:6:1 with 4 arguments:
+Info: firstprivate(N)[8] (implicit)
+Info: use_address(Y)[0] (implicit)
+Info: tofrom(D)[16] (implicit)
+Info: use_address(X)[0] (implicit)
+Info: Mapping exists (implicit) with HstPtrBegin=0x7ffe37d8be80, 
+  TgtPtrBegin=0x7f90ff004000, Size=0, updated RefCount=2, Name=Y
+Info: Mapping exists (implicit) with HstPtrBegin=0x7ffe37d8fe80, 
+  TgtPtrBegin=0x7f90ff00, Size=0, updated RefCount=2, Name=X
+Info: Launching kernel 
__omp_offloading_fd02_c2c4ac1a__Z5daxpyPNSt3__17complexIdEES2_S1_m_l6
+  with 8 blocks and 128 threads in SPMD mode
+Info: OpenMP Host-Device pointer mappings after block at zaxpy.cpp:6:1:
+Info: Host Ptr   Target Ptr Size (B) RefCount Declaration
+Info: 0x7fff963f4000 0x7fd225004000 163841Y[0:N] at 
zaxpy.cpp:13:17
+Info: 0x7fff963f8000 0x7fd22500 163841X[0:N] at 
zaxpy.cpp:13:11
+Info: Exiting OpenMP data region at zaxpy.cpp:14:1 with 2 arguments:
+Info: to(X[0:N])[16384] 
+Info: tofrom(Y[0:N])[16384] 
+
+From this information, we can see the OpenMP kernel being launched on the CUDA
+device with enough threads and blocks for all ``1024`` iterations of the loop 
in
+simplified :doc:`SPMD Mode `. The information from the OpenMP data
+region shows the two arrays ``X`` and ``Y`` being copied from the host to the
+device. This creates an entry in the host-device mapping table associating the
+host pointers to the newly created device data. The data mappings in the OpenMP
+device kernel show the default mappings being used for all the variables used
+implicitly on the device. Because ``X`` and ``Y`` are already mapped in the
+device's table, no new entries are created. Additionally, the default mapping
+shows that ``D`` will be copied back from the device once the OpenMP device
+kernel region ends even though it isn't written to. Finally, at the end of the
+OpenMP data region the entries for ``X`` and ``Y`` are removed from the table.
+
+.. toctree::
+   :hidden:
+   :maxdepth: 1
+
+   Offloading
+
 LLVM/OpenMP Target Host Runtime Plugins (``libomptarget.rtl.``)
 ---
 



___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://li

[llvm-branch-commits] [openmp] 1c19804 - [OpenMP] Add OpenMP Documentation for Libomptarget environment variables

[Joseph Huber via llvm-branch-commits]

Author: Joseph Huber
Date: 2020-12-22T17:41:27-05:00
New Revision: 1c19804ebf4c97666a5c7de86ca7432c6b020205

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

LOG: [OpenMP] Add OpenMP Documentation for Libomptarget environment variables

Add support to the OpenMP web pages for environment variables supported
by Libomptarget and their usage.

Reviewed By: jdoerfert

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

Added: 


Modified: 
openmp/docs/design/Runtimes.rst

Removed: 




diff  --git a/openmp/docs/design/Runtimes.rst b/openmp/docs/design/Runtimes.rst
index 61491060ea04..39ed256c4856 100644
--- a/openmp/docs/design/Runtimes.rst
+++ b/openmp/docs/design/Runtimes.rst
@@ -16,6 +16,88 @@ the LLVM/OpenMP host runtime, aka.  `libomp.so`, is 
available as a `pdf
 LLVM/OpenMP Target Host Runtime (``libomptarget``)
 --
 
+Environment Variables
+^
+
+``libomptarget`` uses environment variables to control 
diff erent features of the
+library at runtime. This allows the user to obtain useful runtime information 
as
+well as enable or disable certain features. A full list of supported 
environment
+variables is defined below.
+
+* ``LIBOMPTARGET_DEBUG=``
+* ``LIBOMPTARGET_PROFILE=``
+* ``LIBOMPTARGET_MEMORY_MANAGER_THRESHOLD=``
+* ``LIBOMPTARGET_INFO=``
+
+LIBOMPTARGET_DEBUG
+""
+
+``LIBOMPTARGET_DEBUG`` controls whether or not debugging information will be
+displayed. This feature is only availible if ``libomptarget`` was built with
+``-DOMPTARGET_DEBUG``. The debugging output provided is intended for use by
+``libomptarget`` developers. More user-friendly output is presented when using
+``LIBOMPTARGET_INFO``.
+
+LIBOMPTARGET_PROFILE
+
+``LIBOMPTARGET_PROFILE`` allows ``libomptarget`` to generate time profile 
output
+similar to Clang's ``-ftime-trace`` option. This generates a JSON file based on
+`Chrome Tracing`_ that can be viewed with ``chrome://tracing`` or the
+`Speedscope App`_. Building this feature depends on the `LLVM Support Library`_
+for time trace output. Using this library is enabled by default when building
+using the CMake option ``OPENMP_ENABLE_LIBOMPTARGET_PROFILING``. The output 
will
+be saved to the filename specified by the environment variable.
+
+.. _`Chrome Tracing`: 
https://www.chromium.org/developers/how-tos/trace-event-profiling-tool
+
+.. _`Speedscope App`: https://www.speedscope.app/
+
+.. _`LLVM Support Library`: https://llvm.org/docs/SupportLibrary.html
+
+LIBOMPTARGET_MEMORY_MANAGER_THRESHOLD
+"
+
+``LIBOMPTARGET_MEMORY_MANAGER_THRESHOLD`` sets the threshold size for which the
+``libomptarget`` memory manager will handle the allocation. Any allocations
+larger than this threshold will not use the memory manager and be freed after
+the device kernel exits The default threshold value is ``8Kb``. If
+``LIBOMPTARGET_MEMORY_MANAGER_THRESHOLD`` is set to ``0`` the memory manager
+will be completely disabled.
+
+LIBOMPTARGET_INFO
+"
+
+``LIBOMPTARGET_INFO`` allows the user to request 
diff erent types runtime
+information from ``libomptarget``. ``LIBOMPTARGET_INFO`` uses a 32-bit field to
+enable or disable 
diff erent types of information. This includes information
+about data-mappings and kernel execution. It is recommended to build your
+application with debugging information enabled, this will enable filenames and
+variable declarations in the information messages. OpenMP Debugging information
+is enabled at any level of debugging so a full debug runtime is not required.
+For minimal debugging information compile with `-gline-tables-only`, or compile
+with `-g` for full debug information. A full list of flags supported by
+``LIBOMPTARGET_INFO`` is given below. 
+
+* Print all data arguments upon entering an OpenMP device kernel: ``0x01``
+* Indicate when a mapped address already exists in the device mapping 
table:
+  ``0x02``
+* Dump the contents of the device pointer map at kernel exit: ``0x04``
+* Print OpenMP kernel information from device plugins: ``0x10``
+
+Any combination of these flags can be used by setting the appropriate bits. For
+example, to enable printing all data active in an OpenMP target region along
+with ``CUDA`` information, run the following ``bash`` command.
+
+.. code-block:: console
+
+   $ env LIBOMPTARGET_INFO=$((1 << 0x1 | 1 << 0x10)) ./your-application
+
+Or, to enable every flag run with every bit set.
+
+.. code-block:: console
+
+   $ env LIBOMPTARGET_INFO=-1 ./your-application
+
 LLVM/OpenMP Target Host Runtime Plugins (``libomptarget.rtl.``)
 ---
 


 

[llvm-branch-commits] [openmp] 6e60346 - [OpenMP] Fixing Typo in Documentation

[Joseph Huber via llvm-branch-commits]

Author: Joseph Huber
Date: 2020-12-23T09:17:51-05:00
New Revision: 6e603464959d43e0e430d0f8ac5522b073d68ba1

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

LOG: [OpenMP] Fixing Typo in Documentation

Added: 


Modified: 
openmp/docs/design/Runtimes.rst

Removed: 




diff  --git a/openmp/docs/design/Runtimes.rst b/openmp/docs/design/Runtimes.rst
index 39ed256c4856..2e5f2bfe0384 100644
--- a/openmp/docs/design/Runtimes.rst
+++ b/openmp/docs/design/Runtimes.rst
@@ -67,7 +67,7 @@ will be completely disabled.
 LIBOMPTARGET_INFO
 "
 
-``LIBOMPTARGET_INFO`` allows the user to request 
diff erent types runtime
+``LIBOMPTARGET_INFO`` allows the user to request 
diff erent types of runtime
 information from ``libomptarget``. ``LIBOMPTARGET_INFO`` uses a 32-bit field to
 enable or disable 
diff erent types of information. This includes information
 about data-mappings and kernel execution. It is recommended to build your



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

[llvm-branch-commits] [openmp] 631501b - [OpenMP] Fixing typo on memory size in Documenation

[Joseph Huber via llvm-branch-commits]

Author: Joseph Huber
Date: 2020-12-23T11:46:26-05:00
New Revision: 631501b1f90e8a90faeadbd535a557633a5af71b

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

LOG: [OpenMP] Fixing typo on memory size in Documenation

Added: 


Modified: 
openmp/docs/design/Runtimes.rst

Removed: 




diff  --git a/openmp/docs/design/Runtimes.rst b/openmp/docs/design/Runtimes.rst
index 2e5f2bfe0384..c9f3a55c0067 100644
--- a/openmp/docs/design/Runtimes.rst
+++ b/openmp/docs/design/Runtimes.rst
@@ -60,7 +60,7 @@ LIBOMPTARGET_MEMORY_MANAGER_THRESHOLD
 ``LIBOMPTARGET_MEMORY_MANAGER_THRESHOLD`` sets the threshold size for which the
 ``libomptarget`` memory manager will handle the allocation. Any allocations
 larger than this threshold will not use the memory manager and be freed after
-the device kernel exits The default threshold value is ``8Kb``. If
+the device kernel exits. The default threshold value is ``8KB``. If
 ``LIBOMPTARGET_MEMORY_MANAGER_THRESHOLD`` is set to ``0`` the memory manager
 will be completely disabled.
 



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

[llvm-branch-commits] [llvm] AMDGPU: Add instruction flags when lowering ctor/dtor (PR #111652)

[Joseph Huber via llvm-branch-commits]

https://github.com/jhuber6 approved this pull request.


https://github.com/llvm/llvm-project/pull/111652
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [clang] clang/AMDGPU: Emit grid size builtins with range metadata (PR #113038)

[Joseph Huber via llvm-branch-commits]

https://github.com/jhuber6 approved this pull request.


https://github.com/llvm/llvm-project/pull/113038
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [llvm] AMDGPU: Fix producing invalid IR on vector typed getelementptr (PR #114113)

[Joseph Huber via llvm-branch-commits]

https://github.com/jhuber6 approved this pull request.

Makes sense, thanks again.

https://github.com/llvm/llvm-project/pull/114113
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [clang] [flang] [lld] [llvm] [Flang] LLVM_ENABLE_RUNTIMES=flang-rt (PR #110217)

[Joseph Huber via llvm-branch-commits]

https://github.com/jhuber6 commented:

Does anyone know why this patch keeps failing the libc++ tests? Seems related 
to something in `libc` for some reason. If we could get the CI green I'd be 
happy to say it's good enough for now.

https://github.com/llvm/llvm-project/pull/110217
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [clang] [flang] [lld] [llvm] [Flang] LLVM_ENABLE_RUNTIMES=flang-rt (PR #110217)

[Joseph Huber via llvm-branch-commits]

jhuber6 wrote:

This patch doesn't apply cleanly for me

https://github.com/llvm/llvm-project/pull/110217
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [clang] [flang] [lld] [llvm] [Flang] LLVM_ENABLE_RUNTIMES=flang-rt (PR #110217)

[Joseph Huber via llvm-branch-commits]

jhuber6 wrote:

> > This patch doesn't apply cleanly for me
> 
> That's because it's a series of patches (see OP), so you have to apply them 
> all in order (or simply check out the branch that represents this PR)

I thought that's what happens by default when you use 
https://patch-diff.githubusercontent.com/raw/llvm/llvm-project/pull/110217.diff

https://github.com/llvm/llvm-project/pull/110217
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [clang] [flang] [lld] [llvm] [Flang] LLVM_ENABLE_RUNTIMES=flang-rt (PR #110217)

[Joseph Huber via llvm-branch-commits]

jhuber6 wrote:

> > Overall I think the patch is fine pending some naming nits, my one concern 
> > is the `-U__GLIBCXX` stuff, because undefining internal vars seems really 
> > sketchy. Do we use `-nostdlib++` to make sure we don't link the C++ library?
> 
> There is a 
> [test](https://github.com/llvm/llvm-project/blob/main/flang/test/Runtime/no-cpp-dep.c)
>  that uses a C-compiler to link the runtime. This more portable than 
> `-nostdlib++`.
> 
> [`_GLIBCXX_ASSERTIONS`](https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_macros.html)
>  and 
> [`_LIBCPP_ENABLE_ASSERTIONS`](https://releases.llvm.org/17.0.1/projects/libcxx/docs/UsingLibcxx.html)
>  are used as described by their respective libraries and how it is done 
> before this PR. For libstdc++ defining 

We should do `check_cxx_compiler_flag(-nostdlib++ FLANG_RT_HAS_NOSTDLIBPP)`, 
it's a lot more obvious when your program doesn't link than when a test fails 
(but the test is still good).

> `_GLIBCXX_NO_ASSERTIONS=1` might be better than undefining something. For 
> libc++ `_LIBCPP_ENABLE_ASSERTIONS` has been 
> [deprecated](https://reviews.llvm.org/D154997) in favor of 
> [`_LIBCPP_HARDENING_MODE`](https://libcxx.llvm.org/Hardening.html). Changing 
> that would be a different concern than addressed by this PR.

Yeah it's just copying what's already there so it's not a blocker. I agree that 
defining them explicitly is way better, because then if someone redefines them 
you'll get a warning.

https://github.com/llvm/llvm-project/pull/110217
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [clang] [flang] [lld] [llvm] [Flang] LLVM_ENABLE_RUNTIMES=flang-rt (PR #110217)

[Joseph Huber via llvm-branch-commits]

@@ -171,145 +76,88 @@ set(sources
   unit-map.cpp
   unit.cpp
   utf.cpp
-  ${FORTRAN_MODULE_OBJECTS}
 )
 
-include(AddFlangOffloadRuntime)
-
-# List of files that are buildable for all devices.
-set(supported_files
-  ISO_Fortran_binding.cpp
-  allocatable.cpp
-  allocator-registry.cpp
-  array-constructor.cpp
-  assign.cpp
-  buffer.cpp
-  character.cpp
-  connection.cpp
-  copy.cpp
-  derived-api.cpp
-  derived.cpp
-  descriptor.cpp
-  descriptor-io.cpp
-  dot-product.cpp
-  edit-input.cpp
-  edit-output.cpp
-  environment.cpp
-  extrema.cpp
-  external-unit.cpp
-  file.cpp
-  findloc.cpp
-  format.cpp
-  inquiry.cpp
-  internal-unit.cpp
-  io-api.cpp
-  io-api-minimal.cpp
-  io-error.cpp
-  io-stmt.cpp
-  iostat.cpp
-  matmul-transpose.cpp
-  matmul.cpp
-  memory.cpp
-  misc-intrinsic.cpp
-  namelist.cpp
-  non-tbp-dio.cpp
-  numeric.cpp
-  pointer.cpp
-  product.cpp
-  pseudo-unit.cpp
-  ragged.cpp
-  stat.cpp
-  sum.cpp
-  support.cpp
-  terminator.cpp
-  tools.cpp
-  transformational.cpp
-  type-code.cpp
-  type-info.cpp
-  unit.cpp
-  utf.cpp
+set(public_headers "")
+file(GLOB_RECURSE public_headers
+  "${FLANGRUNTIME_SOURCE_DIR}/include/flang/Runtime/*.h"
+  "${FLANGRUNTIME_SOURCE_DIR}/include/flang/Common/*.h"
   )
 
-enable_cuda_compilation(FortranRuntime "${supported_files}")
-enable_omp_offload_compilation("${supported_files}")

jhuber6 wrote:

Is that going to be supported upstream? `clang` is a CUDA compiler so `flang` 
can be as well, but since offloading in `flang` is already using my driver code 
(AFAIK) it might be easier to just make it common.

https://github.com/llvm/llvm-project/pull/110217
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [clang] [flang] [lld] [llvm] [Flang] LLVM_ENABLE_RUNTIMES=FortranRuntime (PR #110217)

[Joseph Huber via llvm-branch-commits]

@@ -0,0 +1,165 @@
+#===-- CMakeLists.txt 
--===#
+#
+# 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
+#
+#======#
+#
+# Build instructions for the flang-rt library. This is file is intended to be
+# included using the LLVM_ENABLE_RUNTIMES mechanism.
+#
+#======#
+
+set(LLVM_SUBPROJECT_TITLE "Fortran Runtime")
+set(FLANGRT_SOURCE_DIR "${CMAKE_CURRENT_SOURCE_DIR}")
+set(FLANGRT_BINARY_DIR "${CMAKE_CURRENT_BINARY_DIR}")
+set(FLANG_SOURCE_DIR "${CMAKE_CURRENT_SOURCE_DIR}/../flang")
+
+enable_language(Fortran)
+
+list(APPEND CMAKE_MODULE_PATH
+"${FLANGRT_SOURCE_DIR}/cmake/modules"
+"${FLANG_SOURCE_DIR}/cmake/modules"
+  )
+include(AddFlangRT)
+include(FlangCommon)
+
+
+
+# Build Mode Introspection #
+
+
+# Setting these variables from an LLVM build is sufficient that flang-rt can
+# construct the output paths, so it can behave as if it were in-tree here.
+set(LLVM_TREE_AVAILABLE OFF)
+if (LLVM_LIBRARY_OUTPUT_INTDIR AND LLVM_RUNTIME_OUTPUT_INTDIR AND 
PACKAGE_VERSION)
+  # This is a bootstap build
+  set(LLVM_TREE_AVAILABLE ON)
+endif()
+
+if (LLVM_TREE_AVAILABLE)
+  # Despite Clang in the name, get_clang_resource_dir does not depend on Clang 
being added to the build
+  # flang-new uses the same resource dir as clang.
+  include(GetClangResourceDir)
+  get_clang_resource_dir(FLANGRT_BUILD_LIB_DIR PREFIX 
"${LLVM_LIBRARY_OUTPUT_INTDIR}/.." SUBDIR "lib${LLVM_LIBDIR_SUFFIX}")
+  get_clang_resource_dir(FLANGRT_INSTALL_LIB_DIR SUBDIR 
"lib${LLVM_LIBDIR_SUFFIX}") # No prefix, CMake's install command find the 
install prefix itself
+else ()
+  set(FLANGRT_BUILD_LIB_DIR "${LLVM_LIBRARY_OUTPUT_INTDIR}")
+  set(FLANGRT_INSTALL_LIB_DIR "lib${LLVM_LIBDIR_SUFFIX}")
+endif ()
+
+if (DEFINED WIN32)
+  set(FLANGRT_BUILD_LIB_DIR "${FLANGRT_BUILD_LIB_DIR}/windows")
+  set(FLANGRT_INSTALL_LIB_DIR "${FLANGRT_INSTALL_LIB_DIR}/windows")
+elseif (LLVM_ENABLE_PER_TARGET_RUNTIME_DIR)
+  set(FLANGRT_BUILD_LIB_DIR "${FLANGRT_BUILD_LIB_DIR}/${LLVM_TARGET_TRIPLE}")
+  set(FLANGRT_INSTALL_LIB_DIR 
"${FLANGRT_INSTALL_LIB_DIR}/${LLVM_TARGET_TRIPLE}")
+endif ()
+
+
+#
+# Build Options #
+#
+
+# Important: flang-rt user options must be prefixed with "FLANG_RT_". Variables
+# with this prefix will be forwarded in bootstrap builds.
+
+option(FLANG_RT_INCLUDE_TESTS "Generate build targets for the flang-rt unit 
and regression-tests." "${LLVM_INCLUDE_TESTS}")
+
+set(FLANG_RT_EXPERIMENTAL_OFFLOAD_SUPPORT "" CACHE STRING "Compile flang-rt 
with GPU support (CUDA or OpenMP)")
+set_property(CACHE FLANG_RT_EXPERIMENTAL_OFFLOAD_SUPPORT PROPERTY STRINGS
+""
+CUDA
+OpenMP
+  )
+if (NOT FLANG_RT_EXPERIMENTAL_OFFLOAD_SUPPORT)
+elseif (FLANG_RT_EXPERIMENTAL_OFFLOAD_SUPPORT STREQUAL "CUDA")
+  set(FLANG_RT_LIBCUDACXX_PATH "" CACHE PATH "Path to libcu++ package 
installation")
+  option(FLANG_RT_CUDA_RUNTIME_PTX_WITHOUT_GLOBAL_VARS "Do not compile global 
variables' definitions when producing PTX library" OFF)
+elseif (FLANG_RT_EXPERIMENTAL_OFFLOAD_SUPPORT STREQUAL "OpenMP")
+set(FLANG_RT_DEVICE_ARCHITECTURES "all" CACHE STRING
+  "List of OpenMP device architectures to be used to compile the Fortran 
runtime (e.g. 'gfx1103;sm_90')")
+else ()
+  message(FATAL_ERROR "Invalid value 
'${FLANG_RT_EXPERIMENTAL_OFFLOAD_SUPPORT}' for 
FLANG_RT_EXPERIMENTAL_OFFLOAD_SUPPORT; must be empty, 'CUDA', or 'OpenMP'")
+endif ()
+
+option(FLANG_RT_ENABLE_CUF "Compile CUDA Fortran runtime sources" OFF)
+if (FLANG_RT_ENABLE_CUF)
+  find_package(CUDAToolkit REQUIRED)
+endif()
+
+
+
+# System Introspection #
+
+
+include(CheckCXXSymbolExists)
+include(CheckCXXSourceCompiles)
+check_cxx_symbol_exists(strerror_r string.h HAVE_STRERROR_R)
+# Can't use symbol exists here as the function is overloaded in C++
+check_cxx_source_compiles(
+  "#include 
+   int main() {
+ char buf[4096];
+ return strerror_s(buf, 4096, 0);
+   }
+  "
+  HAVE_DECL_STRERROR_S)
+
+
+# Search for clang_rt.builtins library.
+if (WIN32)
+  execute_process(
+  COMMAND "${CMAKE_CXX_COMPILER}" "-print-libgcc-file-name" 
"-rtlib=compiler-rt"
+  RESULT_VARIABLE CXX_COMPILER_PRINT_LIBGCC_PATH_FAILURE
+  OUTPUT_VARIABLE CXX_COMPILER_PRINT_LIBGCC_PATH_RESULT
+  ERROR_QUIET
+)
+  if (NOT CXX_COMPILER_PRINT_LIBGCC_PATH_FAILURE AND 
CXX_COMPILER_PRINT_LIBGCC_PATH_RESULT)
+string(STRIP "${CXX_COMPILER_PRINT_LIBGCC_PATH_RESULT}" FLANGRT_LIBCALL)
+  else ()
+set(FLANGRT_LIBCALL "")
+  endif ()
+endif ()
+
+
+#
+# Build Preparation #
+#
+
+if

[llvm-branch-commits] [clang] [flang] [lld] [llvm] [Flang] LLVM_ENABLE_RUNTIMES=FortranRuntime (PR #110217)

[Joseph Huber via llvm-branch-commits]

@@ -221,6 +230,9 @@ function(llvm_ExternalProject_Add name source_dir)
   
-DCMAKE_ASM_COMPILER=${LLVM_RUNTIME_OUTPUT_INTDIR}/clang${CMAKE_EXECUTABLE_SUFFIX})
   endif()
 endif()
+if(FLANG_IN_TOOLCHAIN)
+  list(APPEND compiler_args 
-DCMAKE_Fortran_COMPILER=${LLVM_RUNTIME_OUTPUT_INTDIR}/flang-new${CMAKE_EXECUTABLE_SUFFIX})

jhuber6 wrote:

This will just be `flang` soon, right?

https://github.com/llvm/llvm-project/pull/110217
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [clang] [flang] [lld] [llvm] [Flang] LLVM_ENABLE_RUNTIMES=FortranRuntime (PR #110217)

[Joseph Huber via llvm-branch-commits]

@@ -270,13 +271,15 @@ function(runtime_default_target)
   -DLLVM_BUILD_TOOLS=${LLVM_BUILD_TOOLS}
   -DCMAKE_C_COMPILER_WORKS=ON
   -DCMAKE_CXX_COMPILER_WORKS=ON
+  -DCMAKE_Fortran_COMPILER_WORKS=ON
   -DCMAKE_ASM_COMPILER_WORKS=ON
   ${COMMON_CMAKE_ARGS}
   ${RUNTIMES_CMAKE_ARGS}
   ${ARG_CMAKE_ARGS}
PASSTHROUGH_PREFIXES LLVM_ENABLE_RUNTIMES
 LLVM_USE_LINKER
-CUDA # For runtimes that may 
look for the CUDA SDK (libc, offload)
+CUDA # For runtimes that may 
look for the CUDA SDK (libc, offload, flang-rt)
+FLANG_RUNTIME # Shared between 
Flang and Flang-RT

jhuber6 wrote:

We intentionally restrict the global prefixes, I think we check for the 
projects and then add the prefix instead of just doing it for everyone.

https://github.com/llvm/llvm-project/pull/110217
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [clang] [flang] [lld] [llvm] [Flang] LLVM_ENABLE_RUNTIMES=flang-rt (PR #110217)

[Joseph Huber via llvm-branch-commits]

https://github.com/jhuber6 edited 
https://github.com/llvm/llvm-project/pull/110217
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [clang] [flang] [lld] [llvm] [Flang] LLVM_ENABLE_RUNTIMES=FortranRuntime (PR #110217)

[Joseph Huber via llvm-branch-commits]

@@ -0,0 +1,165 @@
+#===-- CMakeLists.txt 
--===#
+#
+# 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
+#
+#======#
+#
+# Build instructions for the flang-rt library. This is file is intended to be
+# included using the LLVM_ENABLE_RUNTIMES mechanism.
+#
+#======#
+
+set(LLVM_SUBPROJECT_TITLE "Fortran Runtime")
+set(FLANGRT_SOURCE_DIR "${CMAKE_CURRENT_SOURCE_DIR}")
+set(FLANGRT_BINARY_DIR "${CMAKE_CURRENT_BINARY_DIR}")
+set(FLANG_SOURCE_DIR "${CMAKE_CURRENT_SOURCE_DIR}/../flang")
+
+enable_language(Fortran)
+
+list(APPEND CMAKE_MODULE_PATH
+"${FLANGRT_SOURCE_DIR}/cmake/modules"
+"${FLANG_SOURCE_DIR}/cmake/modules"
+  )
+include(AddFlangRT)
+include(FlangCommon)
+
+
+
+# Build Mode Introspection #
+
+
+# Setting these variables from an LLVM build is sufficient that flang-rt can
+# construct the output paths, so it can behave as if it were in-tree here.
+set(LLVM_TREE_AVAILABLE OFF)
+if (LLVM_LIBRARY_OUTPUT_INTDIR AND LLVM_RUNTIME_OUTPUT_INTDIR AND 
PACKAGE_VERSION)
+  # This is a bootstap build
+  set(LLVM_TREE_AVAILABLE ON)
+endif()
+
+if (LLVM_TREE_AVAILABLE)
+  # Despite Clang in the name, get_clang_resource_dir does not depend on Clang 
being added to the build
+  # flang-new uses the same resource dir as clang.
+  include(GetClangResourceDir)
+  get_clang_resource_dir(FLANGRT_BUILD_LIB_DIR PREFIX 
"${LLVM_LIBRARY_OUTPUT_INTDIR}/.." SUBDIR "lib${LLVM_LIBDIR_SUFFIX}")
+  get_clang_resource_dir(FLANGRT_INSTALL_LIB_DIR SUBDIR 
"lib${LLVM_LIBDIR_SUFFIX}") # No prefix, CMake's install command find the 
install prefix itself
+else ()
+  set(FLANGRT_BUILD_LIB_DIR "${LLVM_LIBRARY_OUTPUT_INTDIR}")
+  set(FLANGRT_INSTALL_LIB_DIR "lib${LLVM_LIBDIR_SUFFIX}")
+endif ()
+
+if (DEFINED WIN32)
+  set(FLANGRT_BUILD_LIB_DIR "${FLANGRT_BUILD_LIB_DIR}/windows")

jhuber6 wrote:

Nit, I feel like this and everything else should be `FLANG_RT` just for 
consistency with `CLANG_RT`.

https://github.com/llvm/llvm-project/pull/110217
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [clang] [flang] [lld] [llvm] [Flang] LLVM_ENABLE_RUNTIMES=flang-rt (PR #110217)

[Joseph Huber via llvm-branch-commits]

jhuber6 wrote:

Overall I think the patch is fine pending some naming nits, my one concern is 
the `-U__GLIBCXX` stuff, because undefining internal vars seems really sketchy. 
Do we use `-nostdlib++` to make sure we don't link the C++ library?

https://github.com/llvm/llvm-project/pull/110217
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [clang] [flang] [lld] [llvm] [Flang] LLVM_ENABLE_RUNTIMES=flang-rt (PR #110217)

[Joseph Huber via llvm-branch-commits]

@@ -0,0 +1,165 @@
+#===-- CMakeLists.txt 
--===#
+#
+# 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
+#
+#======#
+#
+# Build instructions for the flang-rt library. This is file is intended to be
+# included using the LLVM_ENABLE_RUNTIMES mechanism.
+#
+#======#
+
+set(LLVM_SUBPROJECT_TITLE "Fortran Runtime")
+set(FLANGRT_SOURCE_DIR "${CMAKE_CURRENT_SOURCE_DIR}")
+set(FLANGRT_BINARY_DIR "${CMAKE_CURRENT_BINARY_DIR}")
+set(FLANG_SOURCE_DIR "${CMAKE_CURRENT_SOURCE_DIR}/../flang")
+
+enable_language(Fortran)
+
+list(APPEND CMAKE_MODULE_PATH
+"${FLANGRT_SOURCE_DIR}/cmake/modules"
+"${FLANG_SOURCE_DIR}/cmake/modules"
+  )
+include(AddFlangRT)
+include(FlangCommon)
+
+
+
+# Build Mode Introspection #
+
+
+# Setting these variables from an LLVM build is sufficient that flang-rt can
+# construct the output paths, so it can behave as if it were in-tree here.
+set(LLVM_TREE_AVAILABLE OFF)
+if (LLVM_LIBRARY_OUTPUT_INTDIR AND LLVM_RUNTIME_OUTPUT_INTDIR AND 
PACKAGE_VERSION)
+  # This is a bootstap build
+  set(LLVM_TREE_AVAILABLE ON)
+endif()
+
+if (LLVM_TREE_AVAILABLE)
+  # Despite Clang in the name, get_clang_resource_dir does not depend on Clang 
being added to the build
+  # flang-new uses the same resource dir as clang.
+  include(GetClangResourceDir)
+  get_clang_resource_dir(FLANGRT_BUILD_LIB_DIR PREFIX 
"${LLVM_LIBRARY_OUTPUT_INTDIR}/.." SUBDIR "lib${LLVM_LIBDIR_SUFFIX}")
+  get_clang_resource_dir(FLANGRT_INSTALL_LIB_DIR SUBDIR 
"lib${LLVM_LIBDIR_SUFFIX}") # No prefix, CMake's install command find the 
install prefix itself
+else ()
+  set(FLANGRT_BUILD_LIB_DIR "${LLVM_LIBRARY_OUTPUT_INTDIR}")
+  set(FLANGRT_INSTALL_LIB_DIR "lib${LLVM_LIBDIR_SUFFIX}")
+endif ()
+
+if (DEFINED WIN32)
+  set(FLANGRT_BUILD_LIB_DIR "${FLANGRT_BUILD_LIB_DIR}/windows")

jhuber6 wrote:

I meant `COMPILER_RT`, thanks. I'd say it's best to be consistent here and use 
`FLANG_RT` everywhere.

https://github.com/llvm/llvm-project/pull/110217
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [clang] [flang] [lld] [llvm] [Flang] LLVM_ENABLE_RUNTIMES=flang-rt (PR #110217)

[Joseph Huber via llvm-branch-commits]

@@ -171,145 +76,88 @@ set(sources
   unit-map.cpp
   unit.cpp
   utf.cpp
-  ${FORTRAN_MODULE_OBJECTS}
 )
 
-include(AddFlangOffloadRuntime)
-
-# List of files that are buildable for all devices.
-set(supported_files
-  ISO_Fortran_binding.cpp
-  allocatable.cpp
-  allocator-registry.cpp
-  array-constructor.cpp
-  assign.cpp
-  buffer.cpp
-  character.cpp
-  connection.cpp
-  copy.cpp
-  derived-api.cpp
-  derived.cpp
-  descriptor.cpp
-  descriptor-io.cpp
-  dot-product.cpp
-  edit-input.cpp
-  edit-output.cpp
-  environment.cpp
-  extrema.cpp
-  external-unit.cpp
-  file.cpp
-  findloc.cpp
-  format.cpp
-  inquiry.cpp
-  internal-unit.cpp
-  io-api.cpp
-  io-api-minimal.cpp
-  io-error.cpp
-  io-stmt.cpp
-  iostat.cpp
-  matmul-transpose.cpp
-  matmul.cpp
-  memory.cpp
-  misc-intrinsic.cpp
-  namelist.cpp
-  non-tbp-dio.cpp
-  numeric.cpp
-  pointer.cpp
-  product.cpp
-  pseudo-unit.cpp
-  ragged.cpp
-  stat.cpp
-  sum.cpp
-  support.cpp
-  terminator.cpp
-  tools.cpp
-  transformational.cpp
-  type-code.cpp
-  type-info.cpp
-  unit.cpp
-  utf.cpp
+set(public_headers "")
+file(GLOB_RECURSE public_headers
+  "${FLANGRUNTIME_SOURCE_DIR}/include/flang/Runtime/*.h"
+  "${FLANGRUNTIME_SOURCE_DIR}/include/flang/Common/*.h"
   )
 
-enable_cuda_compilation(FortranRuntime "${supported_files}")
-enable_omp_offload_compilation("${supported_files}")

jhuber6 wrote:

Where is this CUDA build actually used? I'm interested in removing it if 
possible and just building this on top of my other GPU libraries.

https://github.com/llvm/llvm-project/pull/110217
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [clang] [flang] [lld] [llvm] [Flang] LLVM_ENABLE_RUNTIMES=flang-rt (PR #110217)

[Joseph Huber via llvm-branch-commits]

@@ -171,145 +76,88 @@ set(sources
   unit-map.cpp
   unit.cpp
   utf.cpp
-  ${FORTRAN_MODULE_OBJECTS}
 )
 
-include(AddFlangOffloadRuntime)
-
-# List of files that are buildable for all devices.
-set(supported_files
-  ISO_Fortran_binding.cpp
-  allocatable.cpp
-  allocator-registry.cpp
-  array-constructor.cpp
-  assign.cpp
-  buffer.cpp
-  character.cpp
-  connection.cpp
-  copy.cpp
-  derived-api.cpp
-  derived.cpp
-  descriptor.cpp
-  descriptor-io.cpp
-  dot-product.cpp
-  edit-input.cpp
-  edit-output.cpp
-  environment.cpp
-  extrema.cpp
-  external-unit.cpp
-  file.cpp
-  findloc.cpp
-  format.cpp
-  inquiry.cpp
-  internal-unit.cpp
-  io-api.cpp
-  io-api-minimal.cpp
-  io-error.cpp
-  io-stmt.cpp
-  iostat.cpp
-  matmul-transpose.cpp
-  matmul.cpp
-  memory.cpp
-  misc-intrinsic.cpp
-  namelist.cpp
-  non-tbp-dio.cpp
-  numeric.cpp
-  pointer.cpp
-  product.cpp
-  pseudo-unit.cpp
-  ragged.cpp
-  stat.cpp
-  sum.cpp
-  support.cpp
-  terminator.cpp
-  tools.cpp
-  transformational.cpp
-  type-code.cpp
-  type-info.cpp
-  unit.cpp
-  utf.cpp
+set(public_headers "")
+file(GLOB_RECURSE public_headers
+  "${FLANGRUNTIME_SOURCE_DIR}/include/flang/Runtime/*.h"
+  "${FLANGRUNTIME_SOURCE_DIR}/include/flang/Common/*.h"
   )
 
-enable_cuda_compilation(FortranRuntime "${supported_files}")
-enable_omp_offload_compilation("${supported_files}")

jhuber6 wrote:

Alright, any changes I make probably won't impact this since it'll be a 
separate build. But I would greatly prefer if we stop having many different 
ways of doing things in the LLVM offloading space.

https://github.com/llvm/llvm-project/pull/110217
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [clang] [flang] [lld] [llvm] [Flang] LLVM_ENABLE_RUNTIMES=flang-rt (PR #110217)

[Joseph Huber via llvm-branch-commits]

@@ -150,12 +150,18 @@ if ("flang" IN_LIST LLVM_ENABLE_PROJECTS)
   endif()
 endif()
 
+if ("flang-rt" IN_LIST LLVM_ENABLE_RUNTIMES)
+  if (NOT "flang" IN_LIST LLVM_ENABLE_PROJECTS)
+message(FATAL_ERROR "Flang is not enabled, but is required for the 
Flang-RT runtime")
+  endif ()
+endif ()

jhuber6 wrote:

Why do we even need `flang`? I don't see any Fortran files, but maybe I'm 
missing something.

https://github.com/llvm/llvm-project/pull/110217
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [llvm] [19.x] Backport standalone build fixes for offload (PR #118643)

[Joseph Huber via llvm-branch-commits]

=?utf-8?q?Micha=C5=82_G=C3=B3rny?= ,
=?utf-8?q?Micha=C5=82_G=C3=B3rny?= ,
=?utf-8?q?Micha=C5=82_G=C3=B3rny?= ,
=?utf-8?q?Micha=C5=82_G=C3=B3rny?= ,
=?utf-8?q?Micha=C5=82_G=C3=B3rny?= 
Message-ID:
In-Reply-To: 


https://github.com/jhuber6 approved this pull request.


https://github.com/llvm/llvm-project/pull/118643
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [mlir] [mlir][rocdl] Add AMDGPU-specific `cf.assert` lowering (PR #121067)

[Joseph Huber via llvm-branch-commits]

jhuber6 wrote:

> 1. Approved
> 
> 2. Wrt OpenCL ... I hope legalization didn't get broken, but in the 
> OpenCL flow, pryntf should lower to ... `printf()`, which the compiler will 
> handle. Or at least that's my recollection of how that goes from staring at 
> the AMDGPU backend ~a year ago

It's complicated, there's like two different flows that either lower `printf` 
to AMD's hostcall version or to a ring buffer type affair, then if you suppress 
the transform you just get `printf` symbols which is what my implementation 
uses.

https://github.com/llvm/llvm-project/pull/121067
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [llvm] release/20.x: [offload] [test] Use test compiler ID rather than host (#124408) (PR #125498)

[Joseph Huber via llvm-branch-commits]

=?utf-8?q?Micha=C5=82_G=C3=B3rny?= 
Message-ID:
In-Reply-To: 


https://github.com/jhuber6 approved this pull request.


https://github.com/llvm/llvm-project/pull/125498
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [clang] [libc] release/20.x: [Clang] Fix test after new argument was added (PR #125912)

[Joseph Huber via llvm-branch-commits]

jhuber6 wrote:

Should just be the two commits, it just unfortunately took the name of the 
latest one. I would've squashed them if I knew how.

https://github.com/llvm/llvm-project/pull/125912
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [libc] fix: removes invalid token from LLVM_VERSION_SUFFIX in LIBC namespace (PR #126193)

[Joseph Huber via llvm-branch-commits]

https://github.com/jhuber6 commented:

Is this a backport? I don't see one for the `main` branch. Normally you land it 
on main and follow 
https://llvm.org/docs/GitHub.html#backporting-fixes-to-the-release-branches for 
the backport.

https://github.com/llvm/llvm-project/pull/126193
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [libc] fix: removes invalid token from LLVM_VERSION_SUFFIX in LIBC namespace (PR #126193)

[Joseph Huber via llvm-branch-commits]

@@ -51,7 +51,8 @@ set(LIBC_KERNEL_HEADERS "/usr/include" CACHE STRING "Path to 
Linux kernel header
 # Defining a global namespace to enclose all libc functions.
 set(default_namespace "__llvm_libc")
 if(LLVM_VERSION_MAJOR)
-  set(default_namespace 
"__llvm_libc_${LLVM_VERSION_MAJOR}_${LLVM_VERSION_MINOR}_${LLVM_VERSION_PATCH}_${LLVM_VERSION_SUFFIX}")
+  string(REPLACE "-" "" NS_LLVM_VERSION_SUFFIX ${LLVM_VERSION_SUFFIX})

jhuber6 wrote:

Do we even need the version suffix? If figured the patch is sufficient for that 
level of control.
```suggestion
  string(REPLACE "-" "_" NS_LLVM_VERSION_SUFFIX ${LLVM_VERSION_SUFFIX})
```

https://github.com/llvm/llvm-project/pull/126193
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [libc] fix: removes invalid token from LLVM_VERSION_SUFFIX in LIBC namespace (PR #126193)

[Joseph Huber via llvm-branch-commits]

https://github.com/jhuber6 edited 
https://github.com/llvm/llvm-project/pull/126193
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [clang] [libc] release/20.x: [Clang] Fix test after new argument was added (PR #125912)

[Joseph Huber via llvm-branch-commits]

jhuber6 wrote:

> @jhuber6 Can you take a look at these test failures.

Looks green now.

https://github.com/llvm/llvm-project/pull/125912
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [clang] [AMDGPU][clang] Replace gfx940 and gfx941 with gfx942 in clang (PR #126762)

[Joseph Huber via llvm-branch-commits]

@@ -106,8 +106,6 @@ enum class OffloadArch {
   GFX90a,
   GFX90c,
   GFX9_4_GENERIC,
-  GFX940,
-  GFX941,

jhuber6 wrote:

Seems bizarre to just fully remove support when we still accept things like 
`gfx600` to this day. As far as I understand, these are basically just being 
replaced by `gfx942`. Would it be at all possible to do `GFX940 = GFX942`?

https://github.com/llvm/llvm-project/pull/126762
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [clang] [AMDGPU][clang] Replace gfx940 and gfx941 with gfx942 in clang (PR #126762)

[Joseph Huber via llvm-branch-commits]

https://github.com/jhuber6 approved this pull request.

Okay, so I guess we can delete these because the cards that corresponded to 
these were never fully released as I understand it.

https://github.com/llvm/llvm-project/pull/126762
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [clang] [AMDGPU][clang] Replace gfx940 and gfx941 with gfx942 in clang (PR #126762)

[Joseph Huber via llvm-branch-commits]

https://github.com/jhuber6 edited 
https://github.com/llvm/llvm-project/pull/126762
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [clang] [AMDGPU][clang] Replace gfx940 and gfx941 with gfx942 in clang (PR #126762)

[Joseph Huber via llvm-branch-commits]

@@ -106,8 +106,6 @@ enum class OffloadArch {
   GFX90a,
   GFX90c,
   GFX9_4_GENERIC,
-  GFX940,
-  GFX941,

jhuber6 wrote:

So `--offload-arch=gfx940` will be a hard error after working at least since 
clang 16? That sounds very silly.

https://github.com/llvm/llvm-project/pull/126762
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [clang] [flang] [lld] [llvm] [Flang] LLVM_ENABLE_RUNTIMES=flang-rt (PR #110217)

[Joseph Huber via llvm-branch-commits]

jhuber6 wrote:

> > Also, I noticed that both linux and windows builds fail to generate some 
> > subcommands apparently (but this doesn't seem to cause an explicit error):
> > ```
> > [70/72] Generating $PREFIX/compile_commands.json
> > Failed to parse {json_file}: {e}
> > ```
> > 
> > 
> > 
> >   
> > 
> > 
> >   
> > 
> > 
> > 
> >   
> > ```
> > [140/142] Generating %LIBRARY_PREFIX%/compile_commands.json
> > Failed to parse {json_file}: {e}
> > ```
> 
> This is a problem with a 
> [hack](https://github.com/llvm/llvm-project/blob/main/runtimes/CMakeLists.txt#L358-L364)
>  in the runtimes in that tries to merge LLVM's compile_commands.json with the 
> runtime's compile_commands.json. One of the problems is that the command 
> depends on its output. Someone also forgot the `f` to get a proper error 
> message.
> 
> The problem you are seeing might be because you are running `ninja clean` 
> which removes `compile_commands.json` such that running `merge-json.py` then 
> fails. Run `cmake .` to re-generate the `compile_commands.json`,
> 
> IMHO this cannot work correctly. I would remove it, but it's not topic of 
> this PR.

Honestly that running is not required, I was just going to make it silently 
fail but @shiltian wanted a warning message.  It's pure convenience and not 
required at all.

https://github.com/llvm/llvm-project/pull/110217
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [llvm] AMDGPU: Use isWave[32|64] instead of comparing size value (PR #117411)

[Joseph Huber via llvm-branch-commits]

https://github.com/jhuber6 approved this pull request.

LG

https://github.com/llvm/llvm-project/pull/117411
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [llvm] AMDGPU: Move default wavesize hack for disassembler (PR #117422)

[Joseph Huber via llvm-branch-commits]

https://github.com/jhuber6 approved this pull request.


https://github.com/llvm/llvm-project/pull/117422
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [clang] [flang] [lld] [llvm] [Flang] LLVM_ENABLE_RUNTIMES=flang-rt (PR #110217)

[Joseph Huber via llvm-branch-commits]

@@ -0,0 +1,232 @@
+#===-- CMakeLists.txt 
--===#
+#
+# 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
+#
+#======#
+#
+# Build instructions for the flang-rt library. This is file is intended to be
+# included using the LLVM_ENABLE_RUNTIMES mechanism.
+#
+#======#
+
+if (NOT LLVM_RUNTIMES_BUILD)
+  message(FATAL_ERROR "Use this CMakeLists.txt from LLVM's runtimes build 
system.
+  Example:
+cmake /runtimes -DLLVM_ENABLE_RUNTIMES=flang-rt
+")
+endif ()
+
+set(LLVM_SUBPROJECT_TITLE "Flang-RT")
+set(FLANG_RT_SOURCE_DIR "${CMAKE_CURRENT_SOURCE_DIR}")
+set(FLANG_RT_BINARY_DIR "${CMAKE_CURRENT_BINARY_DIR}")
+set(FLANG_SOURCE_DIR "${CMAKE_CURRENT_SOURCE_DIR}/../flang")
+
+
+# CMake 3.24 is the first version of CMake that directly recognizes Flang.
+# LLVM's requirement is only CMake 3.20, teach CMake 3.20-3.23 how to use 
Flang.
+if (CMAKE_VERSION VERSION_LESS "3.24")
+  cmake_path(GET CMAKE_Fortran_COMPILER STEM _Fortran_COMPILER_STEM)
+  if (_Fortran_COMPILER_STEM STREQUAL "flang-new" OR _Fortran_COMPILER_STEM 
STREQUAL "flang")
+include(CMakeForceCompiler)
+CMAKE_FORCE_Fortran_COMPILER("${CMAKE_Fortran_COMPILER}" "LLVMFlang")
+
+set(CMAKE_Fortran_COMPILER_ID "LLVMFlang")
+set(CMAKE_Fortran_COMPILER_VERSION 
"${LLVM_VERSION_MAJOR}.${LLVM_VERSION_MINOR}")
+
+set(CMAKE_Fortran_SUBMODULE_SEP "-")
+set(CMAKE_Fortran_SUBMODULE_EXT ".mod")
+
+set(CMAKE_Fortran_PREPROCESS_SOURCE
+  " -cpp-E  
> ")
+
+set(CMAKE_Fortran_FORMAT_FIXED_FLAG "-ffixed-form")
+set(CMAKE_Fortran_FORMAT_FREE_FLAG "-ffree-form")
+
+set(CMAKE_Fortran_MODDIR_FLAG "-module-dir")
+
+set(CMAKE_Fortran_COMPILE_OPTIONS_PREPROCESS_ON "-cpp")
+set(CMAKE_Fortran_COMPILE_OPTIONS_PREPROCESS_OFF "-nocpp")
+set(CMAKE_Fortran_POSTPROCESS_FLAG "-ffixed-line-length-72")
+
+set(CMAKE_Fortran_COMPILE_OPTIONS_TARGET "--target=")
+
+set(CMAKE_Fortran_LINKER_WRAPPER_FLAG "-Wl,")
+set(CMAKE_Fortran_LINKER_WRAPPER_FLAG_SEP ",")
+  endif ()
+endif ()
+enable_language(Fortran)
+
+
+list(APPEND CMAKE_MODULE_PATH
+"${FLANG_RT_SOURCE_DIR}/cmake/modules"
+"${FLANG_SOURCE_DIR}/cmake/modules"
+  )
+include(AddFlangRT)
+include(GetToolchainDirs)
+include(FlangCommon)
+include(HandleCompilerRT)
+include(ExtendPath)
+include(GNUInstallDirs)
+
+
+
+# Build Mode Introspection #
+
+
+# Determine whether we are in the runtimes/runtimes-bins directory of a
+# bootstrap build.
+set(LLVM_TREE_AVAILABLE OFF)
+if (LLVM_LIBRARY_OUTPUT_INTDIR AND LLVM_RUNTIME_OUTPUT_INTDIR AND 
PACKAGE_VERSION)
+  set(LLVM_TREE_AVAILABLE ON)
+endif()
+
+# Path to LLVM development tools (FileCheck, llvm-lit, not, ...)
+set(LLVM_TOOLS_DIR "${LLVM_BINARY_DIR}/bin")
+
+# Determine build and install paths.
+# The build path is absolute, but the install dir is relative, CMake's install
+# command has to apply CMAKE_INSTALL_PREFIX itself.
+if (LLVM_TREE_AVAILABLE)
+  # In a bootstrap build emit the libraries into a default search path in the
+  # build directory of the just-built compiler. This allows using the
+  # just-built compiler without specifying paths to runtime libraries.
+  #
+  # Despite Clang in the name, get_clang_resource_dir does not depend on Clang
+  # being added to the build. Flang uses the same resource dir as clang.
+  include(GetClangResourceDir)
+  get_clang_resource_dir(FLANG_RT_OUTPUT_RESOURCE_DIR PREFIX 
"${LLVM_LIBRARY_OUTPUT_INTDIR}/..")

jhuber6 wrote:

The `lib64/` thing seems weird. Is anything else installed there? 
`-DLLVM_ENABLE_PER_TARGET_RUNTIME_DIR=ON` is the default for Linux and what 
should lead to having `x86_64-unknown-linux-gnu` there, but I've never seen 
`lib64/` be qualified there as well.

https://github.com/llvm/llvm-project/pull/110217
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [clang] [flang] [lld] [llvm] [Flang] Rename libFortranRuntime.a to libflang_rt.a (PR #122341)

[Joseph Huber via llvm-branch-commits]

https://github.com/jhuber6 approved this pull request.

Straightforward renaming and more consistent with the clang runtimes.

https://github.com/llvm/llvm-project/pull/122341
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [flang] [Flang] Promote FortranEvaluateTesting library (PR #124417)

[Joseph Huber via llvm-branch-commits]

https://github.com/jhuber6 approved this pull request.


https://github.com/llvm/llvm-project/pull/124417
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [clang] [llvm] [OffloadBundler] Rework the ctor of `OffloadTargetInfo` to support AMDGPU's generic target (PR #122629)

[Joseph Huber via llvm-branch-commits]

jhuber6 wrote:

Somewhere for the linker wrapper I just checked if the triple was recognized, 
you could probably just take strings after the `-` until it stops working.

https://github.com/llvm/llvm-project/pull/122629
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [flang] [Flang] Introduce FortranSupport (PR #122069)

[Joseph Huber via llvm-branch-commits]

https://github.com/jhuber6 approved this pull request.

Seems reasonable to me

https://github.com/llvm/llvm-project/pull/122069
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [flang] [Flang] Promote FortranEvaluateTesting library (PR #122334)

[Joseph Huber via llvm-branch-commits]

@@ -1,47 +1,34 @@
 set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR})
-add_library(FortranEvaluateTesting

jhuber6 wrote:

Does anyone use the omp offload build? I'm hoping to make that unnecessary once 
we have the flang-rt build working.

https://github.com/llvm/llvm-project/pull/122334
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [clang] [flang] [lld] [llvm] [Flang] LLVM_ENABLE_RUNTIMES=flang-rt (PR #110217)

[Joseph Huber via llvm-branch-commits]

https://github.com/jhuber6 approved this pull request.


https://github.com/llvm/llvm-project/pull/110217
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [clang] clang/AMDGPU: Stop looking for oclc_daz_opt_* control libraries (PR #134805)

[Joseph Huber via llvm-branch-commits]

https://github.com/jhuber6 approved this pull request.

Nice to see fewer of these used. We should be able to get rid of the 
wavefrontsize ones if we use the builtin, and if Alex's WIP lands we can 
replace the ISA checks with that.

https://github.com/llvm/llvm-project/pull/134805
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [llvm] release/20.x: AMDGPU: Stop emitting an error on illegal addrspacecasts (#127487) (PR #127496)

[Joseph Huber via llvm-branch-commits]

https://github.com/jhuber6 approved this pull request.


https://github.com/llvm/llvm-project/pull/127496
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [clang] [libc] release/20.x: [Clang] Add handlers for 'match_any' and 'match_all' to `gpuintrin.h` (#127504) (PR #127704)

[Joseph Huber via llvm-branch-commits]

https://github.com/jhuber6 approved this pull request.

Approving my own patch feels like a conflict of interest.

https://github.com/llvm/llvm-project/pull/127704
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [libc] release/20.x: libc/cmake: don't fail if LLVM_VERSION_SUFFIX isn't defined (#126359) (PR #127099)

[Joseph Huber via llvm-branch-commits]

https://github.com/jhuber6 approved this pull request.


https://github.com/llvm/llvm-project/pull/127099
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [clang] [libc] release/20.x: [Clang] Add handlers for 'match_any' and 'match_all' to `gpuintrin.h` (#127504) (PR #127704)

[Joseph Huber via llvm-branch-commits]

jhuber6 wrote:

> @jhuber6 Why do you want to back port this and what's the impact if we don't?

Sorry, https://github.com/llvm/llvm-project/pull/127703 is the actually 
important one and I forget to cherry pick it, fixes a test and incorrect 
behavior. Figured if I was backporting that I could merge this as well, but if 
that's too much then it's not a big deal.

https://github.com/llvm/llvm-project/pull/127704
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [libcxx] release/20.x: [libc++] Guard include of with __has_include (#127691) (PR #127842)

[Joseph Huber via llvm-branch-commits]

https://github.com/jhuber6 approved this pull request.


https://github.com/llvm/llvm-project/pull/127842
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [llvm] release/20.x: [OpenMP] Fix misspelled symbol name (#126120) (PR #126121)

[Joseph Huber via llvm-branch-commits]

jhuber6 wrote:

It is very important that this gets backported.

https://github.com/llvm/llvm-project/pull/126121
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [llvm] Triple: Record default exception handling type (PR #147225)

[Joseph Huber via llvm-branch-commits]

https://github.com/jhuber6 approved this pull request.


https://github.com/llvm/llvm-project/pull/147225
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [llvm] [Offload] Allow "tagging" device info entries with offload keys (PR #147317)

[Joseph Huber via llvm-branch-commits]

@@ -133,17 +139,21 @@ struct InfoTreeNode {
   // * The same key can appear multiple times
   std::unique_ptr> Children;
 
+  std::map DeviceInfoMap;

jhuber6 wrote:

Do these need to be sorted? Otherwise a dense map is more efficient.

https://github.com/llvm/llvm-project/pull/147317
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [llvm] [Offload] Allow "tagging" device info entries with offload keys (PR #147317)

[Joseph Huber via llvm-branch-commits]

@@ -171,6 +186,12 @@ struct InfoTreeNode {
 return It;
   }
 
+  std::optional get(DeviceInfo Info) {
+if (DeviceInfoMap.count(Info))
+  return &(*Children)[DeviceInfoMap[Info]];
+return std::nullopt;

jhuber6 wrote:

```suggestion
return !DeviceInfoMap.count(Info) std::nullopt : 
&(*Children)[DeviceInfoMap[Info]];
```

https://github.com/llvm/llvm-project/pull/147317
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [llvm] [Offload] Add `olGetSymbolInfo[Size]` (PR #147962)

[Joseph Huber via llvm-branch-commits]

https://github.com/jhuber6 commented:

What do we use the `Size` variant for exactly? I figured that would just be 
part of the query, most documentation will state how big the output variable 
needs  to be when using some of these enums.

https://github.com/llvm/llvm-project/pull/147962
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [llvm] [Offload] Add `olGetSymbolInfo[Size]` (PR #147962)

[Joseph Huber via llvm-branch-commits]

https://github.com/jhuber6 commented:

I would prefer that we do this like HSA does and have 
`HSA_EXECUTABLE_SYMBOL_INFO_NAME_LENGTH` as a separate info that you can query 
first and then use as a pointer for `HSA_EXECUTABLE_SYMBOL_INFO_NAME`.

https://github.com/llvm/llvm-project/pull/147962
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [llvm] [Offload] Add `olGetSymbolInfo[Size]` (PR #147962)

[Joseph Huber via llvm-branch-commits]

jhuber6 wrote:

> @jhuber6 Some queries (such as name and vendor) return strings, binary data 
> or arrays. This entry point allows the implementation to pre-allocate storage 
> for them.
> 
> It's also useful for offload users that want to create a generic "readInfo" 
> function that allocates and returns a void * to some memory for callers to 
> cast to the appropriate type.

I assumed those would just return a pointer to some memory the plugin manages, 
likely the assumption is that a symbol is valid only as long as its associated 
image is alive... Guess this is another case where the runtime *really* should 
be managing the memory of the image by copying it in. I really need to make 
that change.

https://github.com/llvm/llvm-project/pull/147962
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [llvm] [Offload] Add global variable address/size queries (PR #147972)

[Joseph Huber via llvm-branch-commits]

https://github.com/jhuber6 approved this pull request.

I'm wondering if we could just make it `getSymbol` instead of `getKernel`. We 
need to disambiguate for the underlying runtime calls (AMDGPU needs `.kd` and 
CUDA uses a different one) but that should be easily doable with a quick lookup 
in the ELF to see if the symbol is a function or variable.

https://github.com/llvm/llvm-project/pull/147972
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [llvm] [Offload] Add `olGetGlobalVariable` (PR #147944)

[Joseph Huber via llvm-branch-commits]

https://github.com/jhuber6 commented:

Debating whether or not we should just have `olGetSymbol` and let the user 
assume whether or not it's a kernel and let them use the info to verify if 
they're unsure.

https://github.com/llvm/llvm-project/pull/147944
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [llvm] [Offload] Add `olGetSymbolInfo[Size]` (PR #147962)

[Joseph Huber via llvm-branch-commits]

jhuber6 wrote:

> @jhuber6 Given that this interface matches the interface of other handles, 
> any change to how it fundamentally works should probably involve updating all 
> other getInfo queries. If we do decide to replace the Size variants, I think 
> that should be done as a separate task that touches everything.
> 
> For now, I think it makes sense to match other handle points, and leave any 
> refactors for device info as a separate change that touches everything.

Sure, we can get in and then rework all the get info's to just have a separate 
query for the size. I think that's much cleaner and keeps the number of API 
functions more clear. I'll accept this for now but we should definitely do that 
later.

https://github.com/llvm/llvm-project/pull/147962
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [llvm] [Offload] Add `olGetSymbolInfo[Size]` (PR #147962)

[Joseph Huber via llvm-branch-commits]

https://github.com/jhuber6 approved this pull request.


https://github.com/llvm/llvm-project/pull/147962
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [llvm] [Offload] Add `olLinkProgram` (PR #148648)

[Joseph Huber via llvm-branch-commits]

https://github.com/jhuber6 commented:

I'm kind of iffy here, I'm not sure if it's the runtime's job to be a linker. 
The `createProgram` interface already should handle 'JIT' compilation by 
detecting magics bits for LLVM-IR, ELF, PTX, or SPIR-V or whatever, but it's 
expected that the user provides a 'program' to run. What's the use-case for 
having the offloading runtime doing the compiler's job?

https://github.com/llvm/llvm-project/pull/148648
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [llvm] [Offload] Add `olLinkProgram` (PR #148648)

[Joseph Huber via llvm-branch-commits]

jhuber6 wrote:

This seems like something we should discuss at one of the weekly meetings, 
since it has pretty large implications for what this library is supposed to do.

https://github.com/llvm/llvm-project/pull/148648
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [llvm] [Offload] Add `olLinkProgram` (PR #148648)

[Joseph Huber via llvm-branch-commits]

jhuber6 wrote:

> @jhuber6 I'm looking at implementing a version of 
> [urProgramLink](https://oneapi-src.github.io/unified-runtime/core/api.html#urprogramlink)
>  for liboffload, which is used by SYCL.
> 
> More generally though, linking is very backend dependant, and liboffload 
> already has logic for invoking the appropriate tool (lld/ptxas/etc.). I think 
> it's worthwhile exposing this interface to offload consumers so they don't 
> have to fiddle around with implementing their own wrappers around the linker. 
> In theory, liboffload could even set optimisation flags that it knows it can 
> consume as well. Implementers can also dynamically compute what kernels they 
> want to use at runtime and link those into a single module rather than 
> unconditionally loading a huge image to the device.
> 
> If users do want to compile offline though, why not just have the 
> hypothetical `offload-lld` be a simple wrapper around `olLinkProgram` and 
> save having to implement linking in two places?

My gut reaction is that if people need a compiler they could just invoke 
`clang` themselves. That's basically what the linker wrapper does, it just 
invokes `clang --target=amdgcn-amd-amdhsa` or whatever and expects a 
functioning executable to come out from the input. It just seems a little out 
of scope to be compiling and linking entire applications beyond simple JIT.

https://github.com/llvm/llvm-project/pull/148648
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits