I don't think so. First of all, this is on another architecture; and then I tried running this test on both x86_64 and s390x with your change, and it succeeded in both cases for me.

Thanks for catching this! LGTM.

lldb-arm-ubuntu (https://lab.llvm.org/buildbot/#/builders/17/builds/9015) fails with:

llvm-clang-x86_64-expensive-checks-debian (https://lab.llvm.org/buildbot/#/builders/16/builds/13741) fails with:

• Fix style issues (seems like arc diff is linting only the top commit?).

Based on Ulrich's feedback I tested the series on RHEL7, which, in
addition to an old kernel, contains an old glibc and an old toolchain.
This uncovered a few extra issues, which are fixed here:

Regarding the openmp test failures: I tried check-openmp on a x86_64 machine, and they occur both with and without this patch series, so must be unrelated.

• Fix a local variable naming issue CheckAndProtect().

• Reserve the address space "tail" in the "[TSan] Define C/C++ address ranges for SystemZ" patch.
• Drop the "[TSan] Simulate OOM in mmap_interceptor()" patch.
• Group "[TSan] Use zeroext for function parameters" with the common code patches.

Removed an unnecessary trailing u32.

Hi, it has been a long time, but I've finally implemented the support
for the floating-point types in BTF. Here are the other pieces:

Ping.

• Fixed a typo in a comment.
• Rebased.

• Do not use FileCheck in fentry-debug-info.ll.

• Don't put FENTRY_CALL in a separate MBB.

I guess you are right - cross-bb optimizations can still mess with it they want to. Let's do just isCall here and solve other problems when/if they arise.

In D91218#2388416, @jonpa wrote:

In D91218#2388401, @iii wrote:

• Add isCall to FENTRY_CALL in Target.td.

Do you still need to create the extra basic block?

• Add isCall to FENTRY_CALL in Target.td.

In D91218#2388311, @jonpa wrote:

An alternative fix would be to modify isSchedulingBoundary() to accept FENTRY_CALL, but this would have questionable semantics.

Did you try to add the isCall flag to the instruction in Target.td? That should make it a scheduling boundary...

• D86382 works - so changing the patch to simply un-XFAIL the test.

Hm, it actually looks fairly simple as is: just a bunch of comparisons of unmodified ints from the input buffer with constants. So I would expect Mutate_AddWordFromTORC to help solving it this fairly quickly. Do you have an idea why this might not be happening? Maybe it could be worth looking into it a bit deeper.

All 3 test failures here are in unrelated areas and must be preexisting.

The failing test is libFuzzer :: cleanse.test, but I don't think this is due to my patch - it doesn't fail locally, and it didn't fail the last time. I wonder if build machines do parallel builds? If yes, then the following code might be the culprit:

• Added a test.
• Moved Alrm after Abrt in order to maintain the alphabetic order.

I've committed with HostToLE, since it matches the existing code style.

• Remove unnecessary {}
• htole -> HostToLE

@kcc Could you have another look please?

• Htole -> htole (I missed clang-tidy suggestion)
• [libFuzzer] -> [SanitizerCoverage] in the 2nd patch title

Two minor fixes:

• Remove unneeded <endian.h> include.
• Make clang-tidy happy by renaming HToLE to Htole.

• [libFuzzer] Fix endianness issue in ForEachNonZeroByte()
• [libFuzzer] Fix types of stop* and start* symbols
• [libFuzzer] Enable for SystemZ

arc which origin/master tells me that arc diff origin/master will
send all the 3 commits. Fingers crossed.

Second attempt to push all 3 commits with arcanist. Sorry for the noise
if it doesn't work out :-/

Split in three commits, removed #ifdef from ForEachNonZeroByte() body.

Ok, I'll split the patch.

Fixed Reviewers: tag.

@yonghong-song Sure, I will give it a try.

I'll close this change now. Thanks for the discussion; looking forward to the proper floating point support in BTF!

I've added the warning. On my s390 it looks like this when building
kselftests:

Thanks for the review!