[Bug tree-optimization/80635] [10 regression] std::optional and bogus -Wmaybe-uninitialized warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80635 Milian Wolff changed: What|Removed |Added CC||mail at milianw dot de --- Comment #69 from Milian Wolff --- Here's another test case that still emits warnings in latest GCC trunk as available through godbolt: https://godbolt.org/z/cWaca3s5s
[Bug c++/103131] -Wpedantic doesn't warn about extra semicolons anymore
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103131 --- Comment #1 from Milian Wolff --- correction: gcc version 10 and below used to complain
[Bug c++/103131] New: -Wpedantic doesn't warn about extra semicolons anymore
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103131
Bug ID: 103131
Summary: -Wpedantic doesn't warn about extra semicolons anymore
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: mail at milianw dot de
Target Milestone: ---
Starting with GCC 11, we don't see any warnings about extra semicolons anymore:
```
struct foo{};;
```
Compile:
```
g++ -Wall -Wpedantic -Wextra test.cpp -o test.o
```
No warning is emitted with gcc version 11.0 and up. gcc 9 and below on the
other hand used to complain:
```
:1:15: warning: extra ';' [-Wpedantic]
1 | struct foo {};;
| ^
ASM generation compiler returned: 0
:1:15: warning: extra ';' [-Wpedantic]
1 | struct foo {};;
| ^
```
See also this godbolt link for a live demo:
https://godbolt.org/z/fKGqf8ExP
[Bug libstdc++/102984] strange alignment issues with std::vector::emplace/push_back and overaligned type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102984 Milian Wolff changed: What|Removed |Added Resolution|--- |FIXED Status|WAITING |RESOLVED --- Comment #8 from Milian Wolff --- Hey Jonathan, that's quite odd... Today I fail to reproduce this on my system too. Yesterday I also noticed that it worked on godbolt but forgot to mention it here - sorry about that. I also tried to reduce this issue to passing aligned temporaries in code outside of std::vector, but that didn't help either. And when I'm trying today, the issue suddenly vanished, maybe there was a system update which helped in that regard, mysterious. For the record, here's the requested information from today, which does _not_ show the broken behavior anymore. the exact version of GCC; g++ (GCC) 11.1.0 Copyright (C) 2021 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. the system type; Linux milian-workstation 5.14.14-arch1-1 #1 SMP PREEMPT Wed, 20 Oct 2021 21:35:18 + x86_64 GNU/Linux ArchLinux with all latest updates the options given when GCC was configured/built; g++ --verbose Using built-in specs. COLLECT_GCC=/usr/bin/g++ COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/ --enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++,d --with-isl --with-linker-hash-style=gnu --with-system-zlib --enable-__cxa_atexit --enable-cet=auto --enable-checking=release --enable-clocale=gnu --enable-default-pie --enable-default-ssp --enable-gnu-indirect-function --enable-gnu-unique-object --enable-install-libiberty --enable-linker-build-id --enable-lto --enable-multilib --enable-plugin --enable-shared --enable-threads=posix --disable-libssp --disable-libstdcxx-pch --disable-libunwind-exceptions --disable-werror gdc_include_dir=/usr/include/dlang/gdc Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 11.1.0 (GCC) the complete command line that triggers the bug; the compiler output (error messages, warnings, etc.); and both specified in the original message already the preprocessed file (*.i*) that triggers the bug, generated by adding -save-temps to the complete compilation command, or, in the case of a bug report for the GNAT front end, a complete set of source files (see below). I'm going to close this report and will reopen it with more details once I can reproduce this again.
[Bug sanitizer/102984] strange alignment issues with std::vector::emplace/push_back and overaligned type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102984 --- Comment #2 from Milian Wolff --- Similarly: std::vector locks(10); // works std::vector locks(10, spinlock()); // doesn't work This report here was motivated by stumbling over this report over at https://github.com/efficient/libcuckoo/issues/53. I found a workaround for that area thankfully, simply by not passing along the default value at all. @ jakub: Note that it works fine for normal situations, it's only the stack allocated default arg which triggers this issue. The way I understand https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65122 is that this should be working with C++17?
[Bug sanitizer/102984] New: strange alignment issues with std::vector::emplace/push_back and overaligned type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102984
Bug ID: 102984
Summary: strange alignment issues with
std::vector::emplace/push_back and overaligned type
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: mail at milianw dot de
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at
gcc dot gnu.org
Target Milestone: ---
I'm unsure what component to report this bug to, is it an issue with the
sanitizer, compiler or libstdc++?
test.cpp:
```
#include
struct alignas(64) spinlock { int i = 0; };
int main()
{
std::vector locks;
locks.push_back(spinlock());
return 0;
}
```
Compile with GCC 11.1.0 with ubsan and run:
```
g++ -std=c++20 -O0 -g -fsanitize=address,undefined test.cpp && ./a.out
```
Will produce this output for me:
```
test.cpp:3:20: runtime error: member access within misaligned address
0x7fe2d4898060 for type 'struct spinlock', which requires 64 byte alignment
0x7fe2d4898060: note: pointer points here
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00
^
#0 0x559ef4c5e453 in spinlock::spinlock() /tmp/test.cpp:3
#1 0x559ef4c5e166 in main /tmp/test.cpp:8
#2 0x7fe2d7d4ab24 in __libc_start_main (/usr/lib/libc.so.6+0x27b24)
#3 0x559ef4c5df9d in _start (/tmp/a.out+0x8f9d)
test.cpp:8:21: runtime error: reference binding to misaligned address
0x7fe2d4898060 for type 'struct value_type', which requires 64 byte alignment
0x7fe2d4898060: note: pointer points here
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00
^
#0 0x559ef4c5e18f in main /tmp/test.cpp:8
#1 0x7fe2d7d4ab24 in __libc_start_main (/usr/lib/libc.so.6+0x27b24)
#2 0x559ef4c5df9d in _start (/tmp/a.out+0x8f9d)
/usr/include/c++/11.1.0/bits/stl_vector.h:1204:31: runtime error: reference
binding to misaligned address 0x7fe2d4898060 for type 'struct spinlock', which
requires 64 byte alignment
0x7fe2d4898060: note: pointer points here
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00
^
#0 0x559ef4c5e8fa in std::vector
>::push_back(spinlock&&) /usr/include/c++/11.1.0/bits/stl_vector.h:1204
#1 0x559ef4c5e1a1 in main /tmp/test.cpp:8
#2 0x7fe2d7d4ab24 in __libc_start_main (/usr/lib/libc.so.6+0x27b24)
#3 0x559ef4c5df9d in _start (/tmp/a.out+0x8f9d)
/usr/include/c++/11.1.0/bits/move.h:105:74: runtime error: reference binding to
misaligned address 0x7fe2d4898060 for type 'struct type', which requires 64
byte alignment
0x7fe2d4898060: note: pointer points here
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00
^
#0 0x559ef4c5ec0e in std::remove_reference::type&&
std::move(spinlock&) /usr/include/c++/11.1.0/bits/move.h:105
#1 0x559ef4c5e906 in std::vector
>::push_back(spinlock&&) /usr/include/c++/11.1.0/bits/stl_vector.h:1204
#2 0x559ef4c5e1a1 in main /tmp/test.cpp:8
#3 0x7fe2d7d4ab24 in __libc_start_main (/usr/lib/libc.so.6+0x27b24)
#4 0x559ef4c5df9d in _start (/tmp/a.out+0x8f9d)
/usr/include/c++/11.1.0/bits/stl_vector.h:1204:21: runtime error: reference
binding to misaligned address 0x7fe2d4898060 for type 'struct spinlock', which
requires 64 byte alignment
0x7fe2d4898060: note: pointer points here
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00
^
#0 0x559ef4c5e92e in std::vector
>::push_back(spinlock&&) /usr/include/c++/11.1.0/bits/stl_vector.h:1204
#1 0x559ef4c5e1a1 in main /tmp/test.cpp:8
#2 0x7fe2d7d4ab24 in __libc_start_main (/usr/lib/libc.so.6+0x27b24)
#3 0x559ef4c5df9d in _start (/tmp/a.out+0x8f9d)
/usr/include/c++/11.1.0/bits/vector.tcc:121:21: runtime error: reference
binding to misaligned address 0x7fe2d4898060 for type 'struct type', which
requires 64 byte alignment
0x7fe2d4898060: note: pointer points here
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00
^
#0 0x559ef4c5ef70 in spinlock& std::vector >::emplace_back(spinlock&&)
/usr/include/c++/11.1.0/bits/vector.tcc:121
#1 0x559ef4c5e93d in std::vector
>::push_back(spinlock&&) /usr/include/c++/11.1.0/bits/stl_vector.h:1204
#2 0x559ef4c5e1a1 in main /tmp/test.cpp:8
#3 0x7fe2d7d4ab24 in __libc_start_main (/usr/lib/libc.so.6+0x27b24)
#4 0x559ef4c5df9d in _start (/tmp/a.out+0x8f9d)
/usr/include/c++/11.1.0/bits/move.h:78:36: runtime error: reference binding to
misaligned address 0x7fe2d4898060 for type 'struct spinlock', which requires 64
byte alignment
0x7fe2d4898060:
[Bug sanitizer/101576] New: -fsaniitize=undefined silences clear nullptr dereference warning at compile time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101576
Bug ID: 101576
Summary: -fsaniitize=undefined silences clear nullptr
dereference warning at compile time
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: mail at milianw dot de
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at
gcc dot gnu.org
Target Milestone: ---
take this code:
```
struct Foo
{
virtual ~Foo() {}
};
struct Bar : Foo
{
~Bar() override {};
int bar() { return _bar; }
int _bar = 42;
};
int doStuff(Foo *foo)
{
if (auto *bar = dynamic_cast(foo))
{
return bar->bar();
}
else
{
// this is obviously wrong, but why is there no compiler warning?!
return bar->bar();
}
}
int main()
{
Foo foo;
return doStuff();
}
```
when you compile it with `-O -Wall -Wextra -Wpedantic -Werror` you'll get...
Nothing? Why?
But now also add `-Wnull-dereference` and you'll get:
https://godbolt.org/z/EKn8q85nT
```
: In function 'int doStuff(Foo*)':
:10:24: error: null pointer dereference [-Werror=null-dereference]
10 | int bar() { return _bar; }
|^~~~
cc1plus: all warnings being treated as errors
Compiler returned: 1
```
(Side note: It's unfortunate that this is not visible with -O0...)
Now add `-fsanitize=undefined` and the compile error is gone again which is
quite unfortunate...
https://godbolt.org/z/ebeaY1vP8
[Bug sanitizer/100878] enabling UBSAN leads to false positive `'this' pointer is null` when casting lambda to function pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100878 Milian Wolff changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Known to fail||11.1.0 Known to work||12.0 Resolution|--- |FIXED --- Comment #2 from Milian Wolff --- ah great, then I guess we can mark this as fixed.
[Bug sanitizer/100878] New: enabling UBSAN leads to false positive `'this' pointer is null` when casting lambda to function pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100878
Bug ID: 100878
Summary: enabling UBSAN leads to false positive `'this' pointer
is null` when casting lambda to function pointer
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: mail at milianw dot de
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at
gcc dot gnu.org
Target Milestone: ---
```
const auto lambda = [](int i) -> int { return i + 1; };
using Callback = int (*)(int);
int run(Callback callback, int i)
{
return callback(i);
}
int main()
{
return run(lambda, 52);
}
```
compile with `-g -Og -fsanitize=undefined -Wall -Werror -Wpedantic -Wextra`
leads to:
```
: In static member function 'static constexpr
int::_FUN(int)':
:1:54: error: 'this' pointer is null [-Werror=nonnull]
1 | const auto lambda = [](int i) -> int { return i + 1; };
| ^
:1:21: note: in a call to non-static member function ''
1 | const auto lambda = [](int i) -> int { return i + 1; };
| ^
cc1plus: all warnings being treated as errors
Compiler returned: 1
```
see also: https://godbolt.org/z/jTYYWbMsz
[Bug analyzer/100705] New: warn about dead store
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100705
Bug ID: 100705
Summary: warn about dead store
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: mail at milianw dot de
Target Milestone: ---
Hey there,
in a large code base I'm working on I stumbled over code in one area that
basically did the below, but in a more elaborate manner. It would have been
quite helpful to get a warning when `-fanalyzer` is passed, because in my
opinion, this code is bogus:
```
struct Properties
{
int foo = 0;
int bar = 0;
};
Properties asdf()
{
Properties ret;
ret.foo = 42; // warning: this has no effect
ret.bar = 1;
ret.foo = 12; // b/c it's unconditionally overwritten here
return ret;
}
```
Thanks
[Bug c++/99386] std::variant overhead much larger compared to clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99386 --- Comment #4 from Milian Wolff --- Ah, but LTO only helps with the variant that contains a single type. The variant with two types remains very slow: variant with single type: ``` Performance counter stats for './variant 1' (5 runs): 264.14 msec task-clock#0.999 CPUs utilized ( +- 0.13% ) 0 context-switches #0.001 K/sec ( +-100.00% ) 0 cpu-migrations#0.000 K/sec 380 page-faults #0.001 M/sec ( +- 0.13% ) 1,182,582,454 cycles#4.477 GHz ( +- 0.06% ) (62.52%) 634,015 stalled-cycles-frontend #0.05% frontend cycles idle ( +- 3.72% ) (62.52%) 1,044,218,220 stalled-cycles-backend# 88.30% backend cycles idle ( +- 0.16% ) (62.52%) 1,187,317,899 instructions #1.00 insn per cycle #0.88 stalled cycles per insn ( +- 0.11% ) (62.52%) 132,470,519 branches # 501.512 M/sec ( +- 0.09% ) (62.53%) 2,967 branch-misses #0.00% of all branches ( +- 7.80% ) (62.47%) 788,740,131 L1-dcache-loads # 2986.044 M/sec ( +- 0.16% ) (62.47%) 16,466,669 L1-dcache-load-misses #2.09% of all L1-dcache accesses ( +- 0.16% ) (62.46%) LLC-loads LLC-load-misses 0.264412 +- 0.000379 seconds time elapsed ( +- 0.14% ) ``` The above measurements is in the same ballpark as the no-variant baseline without LTO. But check out the following for using a variant with two types: ``` Performance counter stats for './variant 2' (5 runs): 1,807.01 msec task-clock#1.000 CPUs utilized ( +- 0.04% ) 4 context-switches #0.002 K/sec ( +- 11.59% ) 0 cpu-migrations#0.000 K/sec ( +- 61.24% ) 383 page-faults #0.212 K/sec ( +- 0.27% ) 8,093,139,812 cycles#4.479 GHz ( +- 0.01% ) (62.35%) 1,393,308 stalled-cycles-frontend #0.02% frontend cycles idle ( +- 5.84% ) (62.52%) 7,257,955,665 stalled-cycles-backend# 89.68% backend cycles idle ( +- 0.08% ) (62.62%) 4,728,542,717 instructions #0.58 insn per cycle #1.53 stalled cycles per insn ( +- 0.02% ) (62.65%) 395,189,246 branches # 218.698 M/sec ( +- 0.02% ) (62.65%) 17,570 branch-misses #0.00% of all branches ( +- 12.38% ) (62.55%) 3,806,321,294 L1-dcache-loads # 2106.424 M/sec ( +- 0.02% ) (62.39%) 16,753,910 L1-dcache-load-misses #0.44% of all L1-dcache accesses ( +- 0.11% ) (62.28%) LLC-loads LLC-load-misses 1.807335 +- 0.000776 seconds time elapsed ( +- 0.04% ) ``` Again, performance suffers dramatically
[Bug c++/99386] std::variant overhead much larger compared to clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99386 --- Comment #3 from Milian Wolff --- Ah, seems like `-O2 -flto` fixes the issue for me, but how come clang can pull this off without LTO?
[Bug c++/99386] std::variant overhead much larger compared to clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99386 --- Comment #2 from Milian Wolff --- in both cases libstdc++ is being used: ``` gcc: linux-vdso.so.1 (0x7ffdc9f93000) libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x7f1449b2d000) libm.so.6 => /usr/lib/libm.so.6 (0x7f14499e8000) libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x7f14499ce000) libc.so.6 => /usr/lib/libc.so.6 (0x7f1449801000) /lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x7f1449d4) clang: linux-vdso.so.1 (0x7fff5854f000) libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x7fd9b190f000) libm.so.6 => /usr/lib/libm.so.6 (0x7fd9b17ca000) libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x7fd9b17b) libc.so.6 => /usr/lib/libc.so.6 (0x7fd9b15e3000) /lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x7fd9b1b22000) ``` I just tried setting `-O3 -finline-limit=5000`, but the performance numbers don't really change much. Is there anything else I should be trying out?
[Bug c++/99386] New: std::variant overhead much larger compared to clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99386 Bug ID: 99386 Summary: std::variant overhead much larger compared to clang Product: gcc Version: 10.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: mail at milianw dot de Target Milestone: --- I've come across some code in an application I'm working on that makes use of std::variant. The overhead imposed by std::variant compared to a raw type is extremely high (700% and more). I created a little MWE to show this behavior: https://github.com/milianw/cpp-variant-overhead To reproduce, compile two versions in different build folders with both g++ or clang++: ``` CXX=g++ cmake -DCMAKE_BUILD_TYPE=RelWithDebInfo CXX=clang++ cmake -DCMAKE_BUILD_TYPE=RelWithDebInfo ``` Then run both versions: ``` perf stat -r 5 -d ./variant 0 perf stat -r 5 -d ./variant 1 perf stat -r 5 -d ./variant 2 ``` I put the measurements on my machine into the README.md. The gist is, the relative runtime overhead is huge when compiling with g++: g++ uint64_t: 100% std::variant: 720% std::variant: 840% clang++ uint64_t: 100% std::variant: 114% std::variant: 184% The baseline for both g++/clang++ is roughly the same.
[Bug sanitizer/97416] New: pointer-compare sanitizer + use-after-return: CHECK failed: /build/gcc/src/gcc/libsanitizer/asan/asan_thread.cpp:369 "((bottom)) != (0)" (0x0, 0x0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97416
Bug ID: 97416
Summary: pointer-compare sanitizer + use-after-return: CHECK
failed:
/build/gcc/src/gcc/libsanitizer/asan/asan_thread.cpp:3
69 "((bottom)) != (0)" (0x0, 0x0)
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: mail at milianw dot de
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at
gcc dot gnu.org
Target Milestone: ---
Apparently the pointer compare sanitizer gets confused when we also try to find
use-after-return errors.
MWE:
```
$ cat test.cpp
#include
#include
#include
#include
int main()
{
std::vector> v;
for (int i = 0; i < 100; ++i) {
v.emplace_back(std::to_string(rand()), std::to_string(rand()));
}
std::sort(v.begin(), v.end());
return 0;
}
$ g++ -g -fsanitize=address,undefined,pointer-compare ./test.cpp -o test
$ export
ASAN_OPTIONS=detect_invalid_pointer_pairs=1,detect_stack_use_after_return=1
$ ./test
==35419==AddressSanitizer CHECK failed:
/build/gcc/src/gcc/libsanitizer/asan/asan_thread.cpp:369 "((bottom)) != (0)"
(0x0, 0x0)
#0 0x7efe11ff9bbb in AsanCheckFailed
/build/gcc/src/gcc/libsanitizer/asan/asan_rtl.cpp:73
#1 0x7efe1201a59e in __sanitizer::CheckFailed(char const*, int, char
const*, unsigned long long, unsigned long long)
/build/gcc/src/gcc/libsanitizer/sanitizer_common/sanitizer_termination.cpp:78
#2 0x7efe11fff9c1 in
__asan::AsanThread::GetStackVariableShadowStart(unsigned long)
/build/gcc/src/gcc/libsanitizer/asan/asan_thread.cpp:369
#3 0x7efe11ff675d in IsInvalidPointerPair
/build/gcc/src/gcc/libsanitizer/asan/asan_report.cpp:383
#4 0x7efe11ff95d9 in CheckForInvalidPointerPair
/build/gcc/src/gcc/libsanitizer/asan/asan_report.cpp:424
#5 0x7efe11ff95d9 in CheckForInvalidPointerPair
/build/gcc/src/gcc/libsanitizer/asan/asan_report.cpp:411
#6 0x7efe11ff95d9 in __sanitizer_ptr_cmp
/build/gcc/src/gcc/libsanitizer/asan/asan_report.cpp:556
#7 0x55dda3c6ed54 in bool __gnu_cxx::operator<
,
std::allocator >, std::__cxx11::basic_string, std::allocator > >*,
std::vector,
std::allocator >, std::__cxx11::basic_string, std::allocator > >,
std::allocator, std::allocator >,
std::__cxx11::basic_string, std::allocator >
> > > >(__gnu_cxx::__normal_iterator, std::allocator >,
std::__cxx11::basic_string, std::allocator >
>*, std::vector, std::allocator >,
std::__cxx11::basic_string, std::allocator >
>, std::allocator, std::allocator >,
std::__cxx11::basic_string, std::allocator >
> > > > const&,
__gnu_cxx::__normal_iterator, std::allocator >,
std::__cxx11::basic_string, std::allocator >
>*, std::vector, std::allocator >,
std::__cxx11::basic_string, std::allocator >
>, std::allocator, std::allocator >,
std::__cxx11::basic_string, std::allocator >
> > > > const&) /usr/include/c++/10.2.0/bits/stl_iterator.h:1107
#8 0x55dda3c6d7cf in
__gnu_cxx::__normal_iterator, std::allocator >,
std::__cxx11::basic_string, std::allocator >
>*, std::vector, std::allocator >,
std::__cxx11::basic_string, std::allocator >
>, std::allocator, std::allocator >,
std::__cxx11::basic_string, std::allocator >
> > > >
std::__unguarded_partition<__gnu_cxx::__normal_iterator, std::allocator >,
std::__cxx11::basic_string, std::allocator >
>*, std::vector, std::allocator >,
std::__cxx11::basic_string, std::allocator >
>, std::allocator, std::allocator >,
std::__cxx11::basic_string, std::allocator >
> > > >,
__gnu_cxx::__ops::_Iter_less_iter>(__gnu_cxx::__normal_iterator, std::allocator >,
std::__cxx11::basic_string, std::allocator >
>*, std::vector, std::allocator >,
std::__cxx11::basic_string, std::allocator >
>, std::allocator, std::allocator >,
std::__cxx11::basic_string, std::allocator >
> > > >,
__gnu_cxx::__normal_iterator, std::allocator >,
std::__cxx11::basic_string, std::allocator >
>*, std::vector, std::allocator >,
std::__cxx11::basic_string, std::allocator >
>, std::allocator, std::allocator >,
std::__cxx11::basic_string, std::allocator >
> > > >,
__gnu_cxx::__normal_iterator, std::allocator >,
std::__cxx11::basic_string, std::allocator >
>*, std::vector, std::allocator >,
std::__cxx11::basic_string, std::allocator >
>, std::allocator, std::allocator >,
std::__cxx11::basic_string, std::allocator >
> > > >, __gnu_cxx::__ops::_Iter_less_iter)
/usr/include/c++/10.2.0/bits/stl_algo.h:1909
#9 0x55dda3c6ba8b in
__gnu_cxx::__normal_iterator, std::allocator >,
std::__cxx11::basic_string, std::allocator >
>*, std::vector, std::allocator >,
std::__cxx11::basic_string, std::allocator >
>, std::allocator, std::allocator >,
std::__cxx11::basic_string, std::allocator >
> > > >
[Bug sanitizer/97229] pointer-compare sanitizer is very slow due to __asan::IsAddressNearGlobal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97229 --- Comment #2 from Milian Wolff --- As I said, >99% of the samples point to this backtrace: ``` __sanitizer_ptr_cmp __asanCheckForInvalidPointerPair __asanCheckForInvalidPointerPair __asan::IsInvalidPointerPair __asan::GetGlobalAddressInformation(unsigned long, unsigned long, ...) __asan::GetGlobalsForAddress(unsigned long, __asan_global*, ...) __asan::isAddressNearGlobal ``` if you want per-line cost attribution, I'd first have to compile the sanitizer runtime with debug symbols. If you really need the `perf report` output instead (why?) I can redo the measurement again.
[Bug sanitizer/97229] New: pointer-compare sanitizer is very slow due to __asan::IsAddressNearGlobal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97229
Bug ID: 97229
Summary: pointer-compare sanitizer is very slow due to
__asan::IsAddressNearGlobal
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: mail at milianw dot de
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at
gcc dot gnu.org
Target Milestone: ---
I am trying to use the pointer-compare sanitizer during product development. I
noticed that it is usually fine from a performance POV, but one specific code
path is getting extremely slow. Quasi 99% of the CPU samples point at this
backtrace:
```
__sanitizer_ptr_cmp
__asanCheckForInvalidPointerPair
__asanCheckForInvalidPointerPair
__asan::IsInvalidPointerPair
__asan::GetGlobalAddressInformation(unsigned long, unsigned long, ...)
__asan::GetGlobalsForAddress(unsigned long, __asan_global*, ...)
__asan::isAddressNearGlobal
```
I have tried to simulate what our code does in this simplistic example: It
copies one file to another in a stupid way via mmap. The pointer comparison is
within the copy() function below.
```
#include
#include
#include
#include
#include
static
__attribute__((noinline))
void copy(const unsigned char *source, size_t source_size,
unsigned char *target, size_t target_size)
{
if (target + source_size > target + target_size) {
fprintf(stderr, "bad offsets: %zu %zu\n", target_size, source_size);
return;
}
std::copy_n(source, source_size, target);
}
unsigned char* mapBuffer(const char *path, size_t size)
{
auto fd = open(path, O_CREAT | O_RDWR, 0600);
if (fd == -1) {
perror("failed to open file");
return nullptr;
}
if (posix_fallocate64(fd, 0, size) != 0) {
perror("failed to resize file");
close(fd);
return nullptr;
}
auto buffer = mmap(nullptr, size, PROT_READ | PROT_WRITE, MAP_SHARED, fd,
0);
close(fd);
if (!buffer) {
perror("failed to mmap file");
return nullptr;
}
return reinterpret_cast(buffer);
}
int main(int argc, char **argv)
{
if (argc != 3) {
fprintf(stderr, "USAGE: ./a.out BUFFER_SIZE COPY_SIZE\n");
return 1;
}
const auto size_i = atoi(argv[1]);
if (size_i < 0) {
fprintf(stderr, "bad size: %d\n", size_i);
return 1;
}
const auto size = static_cast(size_i);
const auto copySize_i = atoi(argv[2]);
if (copySize_i < 0 || copySize_i > size_i || (size_i % copySize_i) != 0) {
fprintf(stderr, "bad copy size: %d %d\n", copySize_i, size_i);
return 1;
}
const auto copySize = static_cast(copySize_i);
auto source = mapBuffer("/tmp/source.dat", size);
if (!source) {
return 1;
}
auto target = mapBuffer("/tmp/target.dat", size);
if (!target) {
return 1;
}
for (int i = 0; i < size; i += copySize) {
copy(source + i, copySize, target + i, copySize);
}
munmap(source, size);
munmap(target, size);
return 0;
}
```
But that demo does not show the extreme slow down. It is actually behaving
quite well, at most 10% slow down, when enabling pointer-compare with the
ASAN_OPTIONS env var.
In the real application, the slow-down is more in the order of 100x or more.
That app links in a lot of other libraries and also runs code in multiple
threads, so I suspect that the issue I'm seeing is related to the amount of
globals and potentially libraries available in the application? Any idea how I
could reproduce this to create a proper MWE?
