What is the status of this patch? It fixes a blocking bug for the 12.0.1 release.

LGTM.

I think this could be simplified by using object libraries like this patch: https://reviews.llvm.org/D95727 does for libLLVM.so

In D85278#2434383, @thakis wrote:

From what I understand, linking lld as a shared library is an explicit non-goal of lld. It trusts inputs and crashes on bad inputs, since it's designed to be run as a separate process.

Can you say more about what you want this for? It seems like something we don't want to do.

D103154 seems to be making a lot of the same changes as this patch.

In D93565#2773761, @puremourning wrote:

Erm, doh. I thought I was on main, but I was using clang 12.0.0 (tag llvmorg-12.0.0 from llvm-project). We tend to only use release tagged versions.

Are you still seeing failures in the main branch? I thought I had fixed this with Revision: https://reviews.llvm.org/D96367.

In D100674#2753238, @infrandomness wrote:

In D100674#2752636, @tstellar wrote:

How long do these tests take to run?

Generally about an hour on my server

Could you add this to the list of release builders too?

I am not quite sure how to do that;

FWIW, I was originally against adding LLVM_EXTERNAL_VISIBILITY to the class, because I thought it was just working around a fundamental flaw in -fvisiblity=hidden, but based on the discussion here, I've fine with the proposed solution.

In D102193#2752595, @alanphipps wrote:

In D102193#2752558, @tstellar wrote:

I saw this fix was backported to the release/12.x branch, was there a bug for this?

I did not file an official bug for this issue -- should I have? My original commit on 12.x also needed to be fixed, but if I missed something in the process for updating release branches, let me know. Thanks!

How long do these tests take to run? Could you add this to the list of release builders too?

I was originally skeptical of this change, because of some negative feedback about these flags in the past on the Fedora development list. However, the people I've talked to more recently seem to be in favor of this change, so no objection from me.

I saw this fix was backported to the release/12.x branch, was there a bug for this?

I'm fine with the concept of having an option for generating a snapshot tarball. I understand that it may not be useful to everyone, but we already ship tarballs as part of our releases and if we were to do official snapshots for the project, we would want to generate the tarballs in the same way. I do agree with Hans that it would be nice if there was some way to uniquely identify the tarball (e.g. with the git hash) otherwise if you do multiple tarballs a day, they would all have the same name.

Does this change mean that LD_PRELOAD will no longer work? Are there any other downsides to adding these flags?

@rnk Even if we were to commit this patch, do you think we would still need to fix/remove llvm:Any?

@rnk I agree with

Adding @rnk, who reviewed the original patch for awareness...

Can you file a bug for this?

Can you file a bug for this?

In D99780#2673415, @hans wrote:

I'm not familiar with github actions so I'm just skimming the code, but it looks good as far as I can tell.

Any reason not to upload the docs also for release candidates? I think it's useful for people to be able to see the current state of release notes (usually to suggest they need improvement).

Updated patch with fixes for z3 and libffi build failures

In D99886#2669086, @tambre wrote:

@bjope Could you try without your workaround from https://reviews.llvm.org/rGd66f9c4f1e83e69abf75f97cb5f8fd1dc9422357 with this patch? I think this should fix the lack of include directory propagation that likely caused your issue.

It's helpful for the release managers to have at least have a target date for creating the release branch and also to know how much time to wait between -rc1 and -rc2. I think we should have this information at a minimum, but I agree after -rc2 the release schedule does become unpredictable. I'll try to rework this, so it is less specific.

In D95727#2667418, @bjope wrote:

I pushed my workaround for Z3 here: https://reviews.llvm.org/rGd66f9c4f1e83e69abf75f97cb5f8fd1dc9422357
Hopefully that will make our bots happy again.

I don't mind if someone wants to do a post-commit review of my workaround.

Address review comments.

@delcypher Ok, thanks. So my question for for @phosek is what if we replaced the usage of llvm-config with find_package(LLVM) would that change also enable the clean ups you are talking about? Or does relying on any kind of out-of-tree files make the build more complicated?

We still build compiler-rt in non-monorepo configuration for Fedora. Which files from the llvm directory (or other directories in the monorepo) does compiler-rt depend on?

I have this uncommitted change: D95727 which updates libLLVM.so to use object libraries, would you be able to also use object libraries to avoid adding this python script?

I've merged this.

You can go ahead and push it directly to the branch.

This seems OK to backport, can you file a bug for it?

Can you file a bug for the backport request?

In D96498#2556731, @maxim-kuvyrkov wrote:

@tstellar

Hi Tom,

OK to backport to release/12.x branch once this is merged to master? This will unblock RC builds for aarch64-windows-msvc (Windows on Arm).

I get concerned when I see us having to disable optimizations to fix bugs. Is there any kind of long-term plan to make the kernel verifier able to accept what LLVM produces or will we always be chasing after failures like this?

Is the fma.cl file mostly copied from another file that is already in the tree?

Sorry, it's too late for 11.1.0.

Can you file a bug for this and mark it as a blocker for release-12.0.0?

You can push this directly to the release/12.x branch when it's ready.

The goal here is for distributions to be able to build libc++ one way and then have it work with clang without requiring that users add additional linker flags besides -static or -stdlib=libc++. Is there a combination of CMake arguments we can use when building libc++ to make all static and shared linking with libc++ work out of the box?

LGTM.

LGTM.

Please go ahead and merge this to the release/12.x branch.

Fix typo.

Yes, go ahead and push this.

Is this something we want to try to pull into the release/12.x branch?

In D89156#2530703, @Abpostelnicu wrote:

In D89156#2530701, @JosephTremoulet wrote:

Oh, I see. I made this change in the master branch and then ported it to the release/11.x branch. It changed the signature of a virtual method, which had a couple more overrides in the release/11.x branch, and when I ported the change I didn't realize those other overrides existed. So now the release/11.x builds that include those overrides (btw, what build flags are needed to include those?) are broken. I'm not sure what the options are now that 11.0.1 has been released and 11.1.0 is at rc2 -- @tstellar, thoughts?

I have a fix for this ready, I can push it to 11.0.1.

In D95666#2530176, @serge-sans-paille wrote:

I'm 100% in favor of removing code, but can you explain why it's dead?

In D64830#2518675, @andreisfr wrote:

@brainstorm , @tonic , @tstellar , thank you very much for your help!

I support and improve Xtensa backend now, current version of the backend is rebased on release 11.0.0 https://github.com/espressif/llvm-project/tree/xtensa_release_11.0.0 .

@tstellar , so I can just update these 10 patches according to latest changes in LLVM, add myself as code owner in the first patch and send patches again to list (I will recheck outstanding issues)?

Thanks for the updates. I think this proposal is ready to send to Chris (Step 4).

@andreisfr I don't seen any major issues being raised with this backend. It would be great if there was a public official ISA document, but I don't think the lack of one is a blocker. Please make a last check of the reviews in phabricato to see if there are any outstanding issues. Then, I would recommend you take a look at the documentation @tonic posted. Specifically the 5 bullet points under the "The basic rules for a back-end to be upstreamed in experimental mode are:" header. If you think you meet those requirements, please re-send the RFC to the list, so we can discuss getting this added.

In D95114#2512315, @probinson wrote:

I think "Week number" is too ambiguous to be a guide. If January starts on the last day of the week, does that still count as week#1? What day does the week start on, anyway--much of the world starts the week on Sunday, much of the world starts the week on Monday.
"Fourth Tuesday in January/July" is unambiguous and makes everything easier to plan. Using "Start + N weeks" for the rest of the target dates is fine.

Fix shared object symlinks.

In D94941#2509829, @sylvestre.ledru wrote:

I might be wrong but if the ABI is incompatible, are we not supposed to update the SONAME itself?