@bd1976llvm Can you file an issue for this: https://llvm.org/docs/GitHub.html#backporting-fixes-to-the-release-branches

I think the context got mixed up in the patch, so I have a new version here: https://reviews.llvm.org/D145996

LGTM.

Better fix for formatting.

In D145997#4191168, @dim wrote:

Is the -srcdir option no longer needed?

ping.

LGTM.

LGTM. Thanks.

In D110900#4186649, @aaronpuchert wrote:

In D110900#4160169, @tstellar wrote:

We switched to using <arch>-redhat-linux-gnu as the default triple and we patch clang to translate the triple from <arch>-redhat-linux-gnu to <arch>-redhat-linux only when searching for the gcc installation, but not for anything else.

That seems like a valid solution as well.

Switching clang/llvm to treat <arch>-redhat-linux or <arch>-suse-linux as a gnu environment would be better, but that would also cause a behavior change for anyone using those triples.

Do you mean that the triple is treated as GNU, but users might not want that, e.g. because they use a different runtime? I think users would explicitly specify if they wanted a different runtime than GNU on RedHat/SUSE.

Or do you mean a difference in terms of which GCC installation gets picked up? Though I'm wondering why you wouldn't expect the equally named GCC triple.

From what I can tell the problem is not the JIT'd code, but registering the EHFrames. Maybe the endian differences make libgcc not able to read the EHFrames since they are generated for x86. See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108994#c14

Fix PowerPC tests too.

Should we apply this patch to the release/16.x branch to create a more smooth transition since the option has been removed in main?

-fopenmp-add-rpath has been removed.

We're holding -rc4 until this is merged, so it would be great if we could merge it on Friday.

In D118493#4182583, @JonChesterfield wrote:

Duplicating a comment from the commit thread so it's easier for me to find later.

You've applied this to the release branches going back as far as 14. It's a user facing breaking change. As in people who have a working openmp toolchain and update to the point release which looks like a semantic versioning thing indicating minor bugfixes will experience immediate cessation of function. I consider that very poor user experience and do not agree with the scope of breakage.

As a result of this change, the X86 tests are being run on other hosts e.g. SystemZ. Was this intended?

In D110900#4160110, @aaronpuchert wrote:

In D110900#3044159, @aaronpuchert wrote:

Can't speak for RedHat, but on SUSE we have

> gcc -dumpmachine
x86_64-suse-linux
> clang -dumpmachine
x86_64-unknown-linux-gnu

Not anymore. I've switched the default target triple to <arch>-suse-linux some time ago (except for ARM 6 & 7, where we specify the ABI), and haven't gotten any complaints about it.

We switched to using <arch>-redhat-linux-gnu as the default triple and we patch clang to translate the triple from <arch>-redhat-linux-gnu to <arch>-redhat-linux only when searching for the gcc installation, but not for anything else. Switching clang/llvm to treat <arch>-redhat-linux or <arch>-suse-linux as a gnu environment would be better, but that would also cause a behavior change for anyone using those triples.

Address some more review comments.

@joycebrum Do you need me to commit this for you?

Add exports to LLVMExports.cmake instead of a separate file.

Would this make more sense in a config file rather than a CMake option? @MaskRay

@JonChesterfield I don't think we should be putting any Fedora specific logic into clang's build system or the driver, if that's what you are suggesting. Fedora can always patch the compiler or install a config file to change the default behavior, even though this is something we try really hard to avoid.

LGTM. I tested this here with our stable branch CI jobs: https://github.com/llvm/llvm-project-release-prs/pull/309

In D143306#4145432, @MaskRay wrote:

This is the point. Specifying a driver option to use libc++/libc++abi/libunwind doesn't magically change DT_RUNPATH. This is exactly the behavior a user wants for a system Clang.
It does make users with a non-system Clang inconvenient but that's the point that such users should specify rpath by themselves.
openmp should not diverge from libc++/libc++abi/libunwind in this regard.

Fix permissions.

In D143306#4142023, @JonChesterfield wrote:

I don't mind hugely what mechanism is used but would really like clang++ -fopenmp foo.cpp to build a program that runs. How can we preserve that 'works' feature without setting rpath on the binary?

FWIW, I'm in favor of this patch. System directory rpaths (e.g. /usr/lib64) are not allowed in Fedora Linux. The current default makes building packages with clang+openmp more difficult.

Update permissions for the action.

Put setup code into a script and make sure to always do the upload.

Addresss some review feedback and also make sure the correct ref is checked out.

This patch is from @str4d

Rebase on main.

LGTM.

LGTM, Thanks, can you open the backport request for release/16.x ?

LGTM. Thank you for doing this.

https://llvm.org/docs/GitHub.html#backporting-fixes-to-the-release-branches

In D142719#4085597, @thieta wrote:

I thought the required version is much less than 3.10? Why is this helping / failing?

In D142606#4082783, @serge-sans-paille wrote:

In D142606#4082753, @tstellar wrote:

Does this mean that clang will no longer search for the ROCM and CUDA library paths for every C compile?

That's the goal, yes.

Does this mean that clang will no longer search for the ROCM and CUDA library paths for every C compile?

LGTM. Thank you.

LGTM.

@luke You'll need to contact the bot owners so they can update machine. The workers running the publish-sphinx-docs will need to be updated too. @gkistanova should be able to help.

LGTM. I tested and this fixes the build.

In D142403#4074905, @fpetrogalli wrote:

In D142403#4074885, @tstellar wrote:

This is still the wrong change IMO. I don't know, maybe I'm not being clear, but I don't 'think you ever actually tried my suggestion in D141581 which was to leave the RISCVTargetParserTableGen Depends as is and add the pseudo targets in llvm/cmake/modules/LLVMConfig.cmake.in.

We'll get there! I think I missed the "leave the RISCVTargetParserTableGen in the DEPENDS, sorry about that.

This is still the wrong change IMO. I don't know, maybe I'm not being clear, but I don't 'think you ever actually tried my suggestion in D141581 which was to leave the RISCVTargetParserTableGen Depends as is and add the pseudo targets in llvm/cmake/modules/LLVMConfig.cmake.in.