a5e5eb17fd9743ea39de35f2779c6dc10729cf9f doesn't really explain the rationale here. Anyway, we picked up that _ENABLE_ASSERTIONS was deprecated thanks to this warning during the RCs (https://bugs.gentoo.org/912223). This change reverting to the old behaviour wasn't in any of the RCs and have now become "experimental" again.

In D159115#4638325, @v.g.vassilev wrote:

In D159115#4638323, @mgorny wrote:

Changing the type from unsigned long long to uintptr_t fix the test for me.

Ah! Nice catch! Can you commit the fix?

Thank you!

This seems right. I'd normally prefer for Michael to take a look but I'll merge it to unbreak the build. We can revert it later if needed.

During our regular snapshot testing, we've hit this in Gentoo on 32-bit Linux x86: https://github.com/llvm/llvm-project/issues/63704#issuecomment-1631791518.

In D153729#4450489, @michaelrj wrote:

LGTM, and if there are spots where both linux and macos should be accepted then we should probably make those #if defined(__linux__) || defined(__APPLE__)

Yes, it's a transitive include which just happened to work before.

lgtm, but not a member of llvm-libc

Add some additional cases

Tweak commit message

This looks fine, thank you! I'll land it later today if nobody objects, given the bug has been open for a while and 16.x is broken as a result.

This is just a draft which I've only briefly tested so far. I'm wondering if this is the right place to put the option, as i've not had to write anything in tablegen before.

I think we've had a similar set of changes like this before but I can't find them right now...

The counterpoint would be that _we're_ adding this flag (LLVM needs it) so it makes sense for us to swallow it, i.e. it's not an arbitrary user-defined flag.

Thanks for explaining. @xry111 Are you taking a look or shall I?

I think we can get away with doing that. We already do it with plenty of other GCC args..

In D150505#4349380, @Dinistro wrote:

It seems this change lets us no longer build LLVM with GCC and then run clang-tidy on it.
In our specific case, we have a downstream project that relies on HandleLLVMOptions, and we run the built clang-tidy on our project.

Is there a possible workaround apart from using Clang to compile?

Sure & thanks.

(I even struggled to find docs for the fix we used for clang-tidy, although it obviously works.)

Phew. Thank you again both.

Reverted for now to avoid confusing other people. I'll look into this more later today if @xry111 doesn't beat me to it.

I can only reproduce it with a GCC-built LLVM.

@dyung Sure, I'll take a look now. If I can't fix it tonight, I'll revert it to keep the bots green.

Apologies - I got the attribution wrong (I forgot that arc doesn't preserve it by default) so I reverted and reapplied with the correct git author.

Thank you!

Adding to the concerns raised above, I don't think we're there yet. See https://bugs.gentoo.org/buglist.cgi?quicksearch=enum-constexpr-conversion&list_id=6843355 and keep in mind that a bunch of stuff isn't buildable with Clang 16 yet anyway so I expect a bunch more to be broken on top of that.

This loses us coverage on musl and other libcs, unfortunately. musl will be keeping crypt indefinitely, although it does "support" overriding/interposition as well w/ libxcrypt (even if it's somewhat discouraged). But I'm also not sure how we can actually prevent that, so right now, sanitizing crypt at all is dangerous (c.f. the bugs @fweimer shared).

Given glibc plans to remove its crypt() anyway, this seems fine.

Yes, please. Obviously we want to fix it properly but right now it's a known issue and it's noise when checking for regressions weekly.

Would it be possible to revert the original changes then reland them with the improvements mentioned above?

You should be able to use the mechanism from https://github.com/llvm/llvm-project/commit/fa981b541365190ae646d2dce575706cd0626cf7 instead for both the original change here and any future changes?

The atomic changes look fine.

In D133375#4214214, @tambre wrote:

I've now run into a snag with this. Having clang++.cfg with -std=c++2b makes /usr/bin/clang++ -E -dM - fail with error: invalid argument '-std=c++2b' not allowed with 'C'.
This is invoked by Meson during its configuration process and causes it to fail.

Am I doing something wrong?