llvm / llvm/llvm-project

[compiler-rt][tysan][libc++] False positives with std::variant

Open
#208,647 0 comments 0 reactions 0 assignees View on GitHub
compiler-rt:tysan false-positive libc++ needs-reduction
Dominant language
LLVM
Stars
40.5k
Forks
18.7k
PR merge metrics
PR metrics pending

Description

# `std::variant`
#### Flags: `-stdlib=libc++ -fsanitize=type -O0`
#### Compiler: x86-64 clang 22.1.0
#### Link: https://godbolt.org/z/11xdacM4x
#### Code:
```.cpp
#include

int main() {
std::variant v;
v = 1;
v = 3.5;
return 0;
}
```
#### Logs:
```
==1==ERROR: TypeSanitizer: type-aliasing-violation on address 0x7ffc76b4b8d8 (pc 0x5f1c6fa72e8c bp 0x7ffc76b4b610 sp 0x7ffc76b4b5a0 tid 1)
WRITE of size 8 at 0x7ffc76b4b8d8 with type double (in std::__1::__variant_detail::__alt<1ul, double> at offset 0) accesses an existing object of type int (in std::__1::__variant_detail::__alt<0ul, int> at offset 0)
#0 0x5f1c6fa72e8b (/app/output.s+0x39e8b)
```
#### Explanation:
`v=3.5` writes a `double` over bytes still typed as the old `int`.

Contributor guide

Open the contributing guide

Research direction

Reproduce the report using the provided std::variant example, -stdlib=libc++, -fsanitize=type, and -O0, then compare the diagnostic with the linked Compiler Explorer case. Trace the type-sanitizer handling of the variant assignment; done means the valid int-to-double alternative change no longer produces a type-aliasing false positive.

Written by the indexing model from the issue text.

Assessment

Tech stack
cpp
Domain
compilers
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Quiet
Clarity
Clearly specified
Newbie friendliness
50/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.