Missed tysan violation with optimization

[thesamesam]

With -O0 -fsanitize=type, we detect the violation correctly, but fail to with -O1 or greater:

#include <stdbool.h>

typedef struct k {
    int a;
    int b;
} k;

typedef struct l {
    bool a;
    bool b;
} l;

k my_k;
l my_l;

void frobnicate_the_struct(k *my_k) {
    int a = ((k*) &my_k)->a;
    __builtin_printf("got k.a=%d\n", a);
}

int main() {
    frobnicate_the_struct((k*)&my_l);
}

$ clang -O0 -fsanitize=type a.c -o a && ./a
==1==ERROR: TypeSanitizer: type-aliasing-violation on address 0x7ffcfff2a198 (pc 0x5f6739b118d1 bp 0x7ffcfff2a110 sp 0x7ffcfff2a0b8 tid 1)
READ of size 4 at 0x7ffcfff2a198 with type int (in k at offset 0) accesses an existing object of type p1 _ZTS1k
    #0 0x5f6739b118d0  (/app/output.s+0x2a8d0)

got k.a=977714280

$ clang -O1 -fsanitize=type a.c -o a && ./a
got k.a=1389137000

godbolt: https://godbolt.org/z/cYPT3vYnY

[thesamesam]

The same is true for this simpler case w/o structs:

#include <stdbool.h>

void frobnicate(int *a) {
    __builtin_printf("got a=%d\n", *a);
}

int main() {
    bool b = false;
    frobnicate((int*) &b);
}

godbolt: https://godbolt.org/z/EG3de668G

[thesamesam]

And even:

int main() {
    bool b = false;
    __builtin_printf("got b=%d\n", *(int*) &b);
}

godbolt: https://godbolt.org/z/Ksqo87fbK

[fhahn]

Looks like LLVM optimizes out the memory accesses before TySan runs (quite late at the moment). We could catch those by instrumenting earlier, although the current position makes it more likely to only catch violations that may trigger mis-compiles I think

[thesamesam]

Yeah, you can look at it two ways. On the one hand, you absolutely must act on what it finds right now. On the other hand, it means that using TySan doesn't necessarily tell you if a newer or earlier Clang version may miscompile a program (because the optimization may or may not happen there), and it also means we can't compare to e.g. GCC then. For UBSan, we try to flag things even if we're not going to optimise based on a violation.

[shafik]

On this bug it fails to catch the violations at -O2 which is exactly the case they were dealing with: #126370

see: https://godbolt.org/z/Y4o5xb816

[fhahn]

On this bug it fails to catch the violations at -O2 which is exactly the case they were dealing with: #126370

see: https://godbolt.org/z/Y4o5xb816

Yep, this is probably the same issue. It catches them with -O1

[shafik]

On this bug it fails to catch the violations at -O2 which is exactly the case they were dealing with: #126370
see: https://godbolt.org/z/Y4o5xb816

Yep, this is probably the same issue. It catches them with -O1

It is a great tool, hopefully the kinks will be worked out soon and we can retire having to use fno-strict-aliasing as a proxy for identifying strict aliasing violations.

[fhahn]

FWIW moving to much earlier in the pipeline should be pretty straight-forward, but will make running sanitized binaries even slower. Maybe we should have an option to run it early to hep with smaller programs for now?

[fhahn]

also cc @gbMattN