[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

[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

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

[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

[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

[Bug sanitizer/102984] New: strange alignment issues with std::vector::emplace/push_back and overaligned type

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

[Bug sanitizer/101576] New: -fsaniitize=undefined silences clear nullptr dereference warning at compile time

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

[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|

[Bug sanitizer/100878] New: enabling UBSAN leads to false positive `'this' pointer is null` when casting lambda to function pointer

: 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

[Bug analyzer/100705] New: warn about dead store

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

[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):

[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

[Bug c++/99386] New: std::variant overhead much larger compared to clang

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

[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)

!= (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: do

[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

[Bug sanitizer/97229] New: pointer-compare sanitizer is very slow due to __asan::IsAddressNearGlobal

: 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

[Bug debug/91929] missing inline subroutine information in build using sin/cos

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91929 --- Comment #9 from Milian Wolff --- > And I'm not sure that the original behavior which for > this particular case would simply say sin() was called from foo() This would indeed be the best, but that didn't happen originally when `foo` itself

[Bug debug/91929] missing inline subroutine information in build using sin/cos

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91929 --- Comment #7 from Milian Wolff --- to me, that backtrace looks quite nice and usable - a huge improvement, thanks! what you are saying is that if the same file would be calling sin/cos somewhere else, only one of those inline locations would

[Bug debug/91929] missing inline subroutine information in build using sin/cos

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91929 --- Comment #5 from Milian Wolff --- > Note the line number program should have picked up a location from the surrounding code, at least the surrounding function, so the ?? in the backtraces look like a consumer (perf) issue to me. All major

[Bug debug/91929] missing inline subroutine information in static build using sin/cos

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91929 --- Comment #2 from Milian Wolff --- the binary exceeds the 1mb size threshold, but I hope it's easy enough to reproduce directly from the source code

[Bug debug/91929] missing inline subroutine information in static build using sin/cos

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91929 --- Comment #1 from Milian Wolff --- Created attachment 46972 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46972=edit code to reproduce the issue

[Bug debug/91929] New: missing inline subroutine information in static build using sin/cos

Priority: P3 Component: debug Assignee: unassigned at gcc dot gnu.org Reporter: mail at milianw dot de Target Milestone: --- Hey there, take the attached C++ code sample and compile it with `g++ -O2 -g -static` to produce the attached binary. Sampling

[Bug c++/88475] -E -fdirectives-only clashes with raw strings

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88475 Milian Wolff changed: What|Removed |Added CC||mail at milianw dot de --- Comment #4

[Bug sanitizer/89215] New: UBSAN leaks memory

: 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: --- ``` Direct leak of 8 byte(s

[Bug c++/85802] false-positive -Wmemset-elt-size when compiling C++ code

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85802 --- Comment #2 from Milian Wolff --- Oh, awesome - it actually detected a bug :) It should have been "char buf", not "char* buf". Thanks for opening my eyes here, I stared at this for a while and couldn't spot the issue. The fact that it wasn't

[Bug c++/85802] New: false-positive -Wmemset-elt-size when compiling C++ code

Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: mail at milianw dot de Target Milestone: --- $ cat test.c #include int main() { const size_t MAX_SIZE = 1024; char* buf[MAX_SIZE]; memset(buf, 0, MAX_SIZE); return 0; } $ gcc

[Bug c++/71463] [6/7 regression] unexpected warning: ignoring function return attributes on template argument

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71463 --- Comment #16 from Milian Wolff --- So how can I silence the warning then for the case I pasted in the first comment: ~~~+ #include template struct foo {}; foo emit_unexpected_warning; int main() { return

[Bug c++/71463] [6/7 regression] unexpected warning: ignoring function return attributes on template argument

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71463 --- Comment #8 from Milian Wolff --- As an interested bystander, may I ask: If the attribute is part of the type, shouldn't it then be transferred via decltype() and then also used in the template to trigger the warning there? To me, the example

[Bug c++/71463] "ignoring attributes on template argument" in -O1 and above

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71463 --- Comment #2 from Milian Wolff --- Indeed, there is a difference between malloc in the two levels: -O0: extern void *malloc (size_t __size) throw () __attribute__ ((__malloc__)) ; -O1: extern void

[Bug c++/71463] New: "ignoring attributes on template argument" in -O1 and above

ty: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: mail at milianw dot de Target Milestone: --- I've seen this error with gcc (GCC) 6.1.1 20160501 and code like this: ~~ #include template struct foo {}; foo<declt