In D155049#4651572, @jdoerfert wrote:

In D155049#4651546, @fmayer wrote:

In D155049#4651545, @fmayer wrote:

In D155049#4651544, @jdoerfert wrote:

In D155049#4651543, @fmayer wrote:

In D155049#4651542, @vitalybuka wrote:

How this is going to affect sanitizers? We still want them being able to detect overflows.

more context: sanitizers use SCEV to decide to not instrument accesses where SCEV tells us that they are in range. With features like this that exploit UB in SCEV, we can no longer rely on this, because the whole point of the sanitizer is to catch UB.

SCEV (and other helpers) already refine UB, don't they? That said, you can disable the feature, right now via a command line flag. That said, we probably want a "catch all" try not to exploit UB flag.

Thanks! Yes such a catch all would be great. Just confirming I understand the CL correctly (I didn't actually read all of the code). If I take the loop from the discourse

int square(int num) {
    int A[3];
    for (int i = 0; i < num; ++i)
      A[i] = i * num;
    return A[1] + A[2];
}

SCEV would tell me that 0 <= i < 3 is true?

And also num < 3?

Yes, or at least the loop count is bound by 3. Which should be enough for the unroller to get going.

We can check for attributes, is there a helper that encapsulates all the specific attribute names?

In D155049#4651545, @fmayer wrote:

In D155049#4651544, @jdoerfert wrote:

In D155049#4651543, @fmayer wrote:

In D155049#4651542, @vitalybuka wrote:

How this is going to affect sanitizers? We still want them being able to detect overflows.

more context: sanitizers use SCEV to decide to not instrument accesses where SCEV tells us that they are in range. With features like this that exploit UB in SCEV, we can no longer rely on this, because the whole point of the sanitizer is to catch UB.

SCEV (and other helpers) already refine UB, don't they? That said, you can disable the feature, right now via a command line flag. That said, we probably want a "catch all" try not to exploit UB flag.

Thanks! Yes such a catch all would be great. Just confirming I understand the CL correctly (I didn't actually read all of the code). If I take the loop from the discourse

int square(int num) {
    int A[3];
    for (int i = 0; i < num; ++i)
      A[i] = i * num;
    return A[1] + A[2];
}

SCEV would tell me that 0 <= i < 3 is true?

In D155049#4651544, @jdoerfert wrote:

In D155049#4651543, @fmayer wrote:

In D155049#4651542, @vitalybuka wrote:

How this is going to affect sanitizers? We still want them being able to detect overflows.

more context: sanitizers use SCEV to decide to not instrument accesses where SCEV tells us that they are in range. With features like this that exploit UB in SCEV, we can no longer rely on this, because the whole point of the sanitizer is to catch UB.

SCEV (and other helpers) already refine UB, don't they? That said, you can disable the feature, right now via a command line flag. That said, we probably want a "catch all" try not to exploit UB flag.

In D155049#4651542, @vitalybuka wrote:

How this is going to affect sanitizers? We still want them being able to detect overflows.

upd

simplify

In D157102#4560976, @Chia-hungDuan wrote:

Add @fmayer to be aware of the name change

I think this might have caused https://github.com/llvm/llvm-project/issues/64730

I think this broke many of our sanitizer tests: https://lab.llvm.org/buildbot/#/builders/37/builds/24122/steps/24/logs/stdio

Also nit: typo in commit message.

remove redundant test RUN

In D156267#4533704, @vitalybuka wrote:

You may add this into llvm/docs/ReleaseNotes.rst

You probably should remove -mllvm -hwasan-use-after-scope from tests (followup patch is find, after waiting few weeks this one not reverted)

update tests

fix halt-on-error

In D152316#4404486, @fmayer wrote:

In D152316#4404455, @aeubanks wrote:

In D152316#4401551, @fmayer wrote:

I don't think we want to disable HWASan tests on Linux generally. If a test has problems on x86, we should either fix that or disable that test only.

We also have an arm64 Linux buildbot, which we definitely don't want to disable.

makes sense, but is the arm64 linux bot actually running the hwasan tests, or are they all disabled currently?

It is actually running them.

there were a lot of hwasan tests failing on linux x64 (>40), is that expected?

That is unexpected.

% ninja -C build check-hwasan
ninja: Entering directory `build'
[0/1] Running the HWAddressSanitizer tests

In D152316#4404455, @aeubanks wrote:

In D152316#4401551, @fmayer wrote:

I don't think we want to disable HWASan tests on Linux generally. If a test has problems on x86, we should either fix that or disable that test only.

We also have an arm64 Linux buildbot, which we definitely don't want to disable.

makes sense, but is the arm64 linux bot actually running the hwasan tests, or are they all disabled currently?

It is actually running them.

there were a lot of hwasan tests failing on linux x64 (>40), is that expected?

That is unexpected.

In D149162#4404271, @agozillon wrote:

I have hopefully fixed the sanitizer issue (the incorrect assert, thank you again for the catch) with the following patch: https://github.com/llvm/llvm-project/commit/309023263dba3b02bc885101faa47d110f662f99 it was a slightly more involved change than I expected, I had to rework the getTargetEntryUniqueInfo function to use a callback function to support Clang's use of a fallback filename and line number (gathered from a PresumedLoc). So I apologies for the extended time to land the change.

This triggered an MSAN error: https://lab.llvm.org/buildbot/#/builders/237/builds/3127/steps/13/logs/stdio

Seems like I made matters worse. Un-reverting this. Please fix the UBSAan error.

I think this broke sanitizer tests: https://lab.llvm.org/buildbot/#/builders/238/builds/3867/steps/13/logs/stdio

In D150298#4401580, @thakis wrote:

Could this have broken check-hwasan? http://45.33.8.238/linux/109046/step_10.txt

I don't think we want to disable HWASan tests on Linux generally. If a test has problems on x86, we should either fix that or disable that test only.

I still don't like the inconsistency between platforms, and I don't think a few bytes of repeated build id matter, but fine.

Seems like the check_memcpy.c is broken: https://lab.llvm.org/buildbot/#/builders/37/builds/22633/steps/2/logs/stdio

iwyu

fix bug around tls

In D152036#4396207, @fmayer wrote:

In D152036#4394711, @kda wrote:

This looks to be breaking HWASAN sanitizer buildbot:
https://lab.llvm.org/buildbot/#/builders/236/builds/4452

seems to be try-catch.cpp

thinks. looking, i cannot reproduce on my own phone :(