[Bug target/117008] -march=native pessimization of 25% with bitset [] and 20% with bool array []

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117008 --- Comment #15 from Matt Bentley --- Created attachment 59356 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59356&action=edit .ii file for bool[array] causing same issue

[Bug target/117008] -march=native pessimization of 25% with bitset [] and 20% with bool array []

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117008 --- Comment #14 from Matt Bentley --- Created attachment 59355 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59355&action=edit .ii file for vector code causing same issue

[Bug target/117008] -march=native pessimization of 25% with bitset [] and 20% with bool array []

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117008 --- Comment #13 from Matt Bentley --- Bool C-arrays also display the same problem, but only if a warm-up loop is present before the main loop (to 'warm up' the cache). I discovered this by accident the other day. char arrays and int arrays did n

[Bug target/117008] -march=native pessimization of 25% with bitset []

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117008 --- Comment #10 from Matt Bentley --- Created attachment 59293 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59293&action=edit -v build output for -o2;-march=native for second "if" variant

[Bug target/117008] -march=native pessimization of 25% with bitset []

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117008 --- Comment #9 from Matt Bentley --- (In reply to Jonathan Wakely from comment #7) > I'm certain it won't be, because (apart from vector) they access > memory locations that are at least one byte, not repeating very similar > bitwise ops for ev

[Bug target/117008] -march=native pessimization of 25% with bitset []

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117008 --- Comment #11 from Matt Bentley --- Created attachment 59294 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59294&action=edit -v build output for -o2 only in second "if" variant As requested

[Bug target/117008] -march=native pessimization of 25% with bitset popcount

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117008 --- Comment #5 from Matt Bentley --- (In reply to Andrew Pinski from comment #1) > Can you provide the output of invoking g++ with -march=native and when > compiling? The .ii files were identical, so did you you mean .o files?

[Bug target/117008] -march=native pessimization of 25% with bitset popcount

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117008 --- Comment #4 from Matt Bentley --- Yeah, I know, I mentioned that in the report. It's not a bad benchmark, it's benchmarking access of individual consecutive bits, not summing. The counting is merely for preventing the compiler from optimizin

[Bug c++/117008] New: -march=native pessimization of 25% with bitset

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117008 Bug ID: 117008 Summary: -march=native pessimization of 25% with bitset Product: gcc Version: 13.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component:

[Bug c++/116931] False "duplicate 'const'" errors when typedefs used on pointer types in function definitions

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116931 --- Comment #5 from Matt Bentley --- Nevermind, I realised my mistake.

[Bug c++/116931] False "duplicate 'const'" errors when typedefs used on pointer types in function definitions

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116931 --- Comment #4 from Matt Bentley --- Okay, so that's a language defect, because const int * const isn't invalid, so neither should a typedef of the same.

[Bug c++/116931] False "duplicate 'const'" errors when typedefs used on pointer types in function definitions

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116931 --- Comment #2 from Matt Bentley --- Enlighten me here, how is this invalid C++ code? Because a typedef should mean that int_pointer is int *, so it should work, right? If it's invalid merely because it's typedef'd instead of verbatim, it's a l

[Bug c++/116931] New: False "duplicate 'const'" errors when typedefs used on pointer types in function definitions

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116931 Bug ID: 116931 Summary: False "duplicate 'const'" errors when typedefs used on pointer types in function definitions Product: gcc Version: 13.2.0 Status: UNCONFIRMED

[Bug c++/100956] Unused variable warnings ignore "if constexpr" blocks where variables are conditionally used

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100956 --- Comment #2 from Matt Bentley --- Thank you - I'm aware GCC might optimize it out (and failed to test with GCC10), at least in O2 mode, but other compilers might not, hence the code.

[Bug c++/100956] New: Unused variable warnings ignore "if constexpr" blocks where variables are conditionally used

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100956 Bug ID: 100956 Summary: Unused variable warnings ignore "if constexpr" blocks where variables are conditionally used Product: gcc Version: 9.2.0 Status: UNCONFIRMED

[Bug middle-end/96750] 10-12% performance decrease in benchmark going from GCC8 to GCC9/GCC10

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96750 --- Comment #6 from Matt Bentley --- Created attachment 49278 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49278&action=edit Demonstration of code which doesn't trigger the performance anomaly. plf_colony_fast.h does not trigger the prob

[Bug middle-end/96750] 10-12% performance decrease in benchmark going from GCC8 to GCC9/GCC10

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96750 --- Comment #5 from Matt Bentley --- If anyone out there is interested in working on this, I found the smallest change possible to create the same performance as GCC8- it is literally eliminating one branch possibility in one function (move-ins