ping? any concerns about this change?

Changed test to use -Werror -### instead of -fdriver-only -v -Werror.

Too hasty w/the last update - forgot to remove the -###.

I misunderstood the previous suggestion about -fdriver-only -Werror -v and thought I needed to separate the test into two invocations. Combined these back into a single RUN now.

Fixed target: --target=hexagon-unknown-linux was not correct for testing this bug, it should have been --target=hexagon-unknown-linux-musl.

In D156330#4535974, @MaskRay wrote:

Tip: use %clang -fdriver-only -Werror -v to test that a command produces no warning or error and has an exit code of 0. Without it your Args.ClaimAllArgs(options::OPT_L); change is untested.

In D146366#4296151, @bcain wrote:

...

But in any case, it seems like that feature is no longer present because stdlib=llvm-libc++ can't distinguish between the one from the build toolchain and the just-built library, right? What's an appropriate/recommended way to make this sort of change?

IIRC, before this change we could use use_system_cxx_lib with LLVM_LIT_ARGS to indicate "do not test the just-built libc++, instead test the libc++ build toolchain's libc++". Perhaps this is what is meant by "back deployment"?

Can you depend on cstdio in an LLVM toolchain test case like this? clang doesn't install cstdio -- does it? This is a c or c++ library file, so I think it should be out of scope for a clang test, right? AFAICT no other clang test uses this header file.

It seems extremely unlikely that this change to target-dependent flags caused this libc++ test failure w/an error referring to partial specialization.

In rGc172726f6f1476ead975e6e731fb95c4d1393e42#1161017, @MaskRay wrote:

Does check-cfi actually work on Hexagon? If no, this change is not appropriate...

Thanks, Fangrui!

In D132480#3760209, @bcain wrote:

@ldionne do you have an idea when you plan to land this change? I'm pretty sure it won't break our usage but I'd like to test it out to be sure.

I don't see any LLVM_ENABLE_PROJECTS (beyond clang+lld) - only LLVM_ENABLE_RUNTIMES so I think we're ok.

https://github.com/quic/toolchain_for_hexagon/blob/29a926ac283a4afb9dc4d5ae4a0f2c18b6649243/build-toolchain.sh

@ldionne do you have an idea when you plan to land this change? I'm pretty sure it won't break our usage but I'd like to test it out to be sure.

In D97625#3337018, @dmgreen wrote:

Hello. I noticed this was applied to the base /test directory in the llvm repo: https://github.com/llvm/llvm-project/tree/main/test
Was it intended be in clang-tools-extra: https://github.com/llvm/llvm-project/tree/main/clang-tools-extra/test? I'm not sure it will do much where it is.

In D70631#3340840, @Mordante wrote:

Yes please provide a patch, can you supply one to libc++ and one to MSVC STL? Thanks.

This test libcxx/test/std/utilities/charconv/charconv.msvc/test.cpp fails downstream for us w/Hexagon SDK. It's a subtle nit from the compiler regarding format specifiers.

In D118391#3277519, @ldionne wrote:

This kooks sensible to me. I assume this is based on compiling for a funky target and it not working (and this is the fix).

Is this configuration (target, etc.) something we could run in our CI? Like is it possible to run this configuration in a Docker image or something? It would be awesome to have tests for it.

In D111356#3064401, @ldionne wrote:

I haven't seen a lot of discussion on this, either here or on the lists where I posted my RFC. Does this sounds reasonable to you all?

Pinging @tstellar and @bcain in particular because I think they are using standalone builds at the moment, and I want to have their blessing that this is going to work for them. Actually folks, you could move to the new "default" build right away to try it out if you wanted.

Previous upload was a stale patch, sorry!

Updated to address further PRM mismatches.

Updated to remove discrepancies with PRM.

Thanks a lot, Fangrui!

In D109340#2987464, @bcain wrote:

In D109340#2987453, @MaskRay wrote:

Sorry, lto/aarch64.ll is a better one.

I'll fix riscv64.ll

ok, will do.

In D109340#2987453, @MaskRay wrote:

Sorry, lto/aarch64.ll is a better one.

I'll fix riscv64.ll

@kparzysz any concerns?

The change LGTM, we may want to fix the error message.

Changed to suggested fix

fixed iserror()

applied clang-format-diff, s/long/u32/ for syscall funcs.

added context

reduced scope to CFI only

Line-wrap update

In D108174#2949827, @vitalybuka wrote:

please drop [PATCH *]

In D108083#2949815, @vitalybuka wrote:

We can help create a bot for hexagon-unknown-linux-musl. What's the process?

Thank you. https://llvm.org/docs/HowToAddABuilder.html

Decomposed to just the sanitizer-common portion. Now it's an 8 patch series, this is number 1.

In D108083#2947914, @vitalybuka wrote:

Do we have public bot for hexagon?

In D108083#2947907, @vitalybuka wrote:

Can you cut this into separate peaces, at least patch per sanitizer for "asan lsan ubsan scudo scudo_standalone cfi safestack"?

Suggestions from Fangrui: override the resource-dir with an explicit arg, disable for windows.

Test case updates per suggestion.

Add a test case, address failing test.

This patch is so far just for discussion, still needs tests, etc. The motivation for this patch is to be able to include the intrinsic header files installed in the resource dir.

In D105218#2867598, @MaskRay wrote:

In D105218#2854082, @MaskRay wrote:

@bcain , could you check whether this addresses the performance issue for you?

@bcain Ping?

LGTM

Removed some unavailable instructions.

Should I clang format the headers? I prefer keeping the historical formatting intact. But if the submission should conform then I suppose I'll just accept the wrapped text suggested by clang-format.

Add hexagon_types.h and additional test cases. Updated existing test case to use types defined in hexagon_types.h.

It occurs to me now that some of these are not very useful in the absence of hexagon_types.h. So I will add that one too and change the tests to use those definitions instead.