[Bug target/115749] Non optimal assembly for integer modulo by a constant on x86-64 CPUs

2024-07-03 Thread kim.walisch at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115749 --- Comment #9 from kim.walisch at gmail dot com --- Here I am providing some benchmark results to back up my claim that switching to the integer modulo by a constant algorithm with 2 multiplication instructions (which is the default in both

[Bug target/115749] Non optimal assembly for integer modulo by a constant on x86-64 CPUs

2024-07-02 Thread kim.walisch at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115749 --- Comment #4 from kim.walisch at gmail dot com --- One possible explanation for why GCC's current integer division by a constant assembly sequence was chosen back in the day (I guess one or two decades ago) is that GCC's curren

[Bug target/115749] Non optimal assembly for integer modulo by a constant on x86-64 CPUs

2024-07-02 Thread kim.walisch at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115749 --- Comment #3 from kim.walisch at gmail dot com --- (In reply to Andrew Pinski from comment #2) > This seems like a tuning issue. In that gcc thinks the shifts and stuff is > faster than mulx. > > What happens if you do -

[Bug c++/115749] Missed BMI2 optimization on x86-64

2024-07-02 Thread kim.walisch at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115749 --- Comment #1 from kim.walisch at gmail dot com --- I played a bit more with my C/C++ code snippet and managed to further simplify it. The GCC performance issue seems to be mostly caused by GCC producing worse assembly than Clang for the

[Bug c++/115749] New: Missed BMI2 optimization on x86-64

2024-07-02 Thread kim.walisch at gmail dot com via Gcc-bugs
++ Assignee: unassigned at gcc dot gnu.org Reporter: kim.walisch at gmail dot com Target Milestone: --- Hi, I have debugged a performance issue in one of my C++ applications on x86-64 CPUs where GCC produces noticeably slower code (using all GCC versions) than Clang. I was able to

[Bug c++/107452] New: Failed to catch C++ exception thrown from multiarch-function (x64 CPUs)

2022-10-28 Thread kim.walisch at gmail dot com via Gcc-bugs
: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: kim.walisch at gmail dot com Target Milestone: --- Hi, Tested using: GCC 11.2.0, Ubuntu 22.10 x64 Tested using: GCC 9.4.0, Ubuntu 18.04 x64 I am using the GCC multiarch

[Bug c++/107287] New: -Wuninitialized false positive (in all GCC versions)

2022-10-17 Thread kim.walisch at gmail dot com via Gcc-bugs
Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: kim.walisch at gmail dot com Target Milestone: --- Hi, In my primecount C++ project I have hit a -Wuninitialized false positive with GCC. It happens basically with every g++ version >= 8 && <= 12 that

[Bug tree-optimization/101831] Spurious maybe-uninitialized warning on std::array::size

2022-01-21 Thread kim.walisch at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101831 kim.walisch at gmail dot com changed: What|Removed |Added CC||kim.walisch at gmail dot

[Bug c/92826] Impossible to silence warning: non-standard suffix on floating constant [-Wpedantic]

2019-12-05 Thread kim.walisch at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92826 --- Comment #3 from kim.walisch at gmail dot com --- > I thought the name "pedantic" made it clear that it is going to warn about > things that are just fine, and you shouldn't use it... A large number of projects (includin

[Bug c/92826] New: Impossible to silence warning: non-standard suffix on floating constant [-Wpedantic]

2019-12-05 Thread kim.walisch at gmail dot com
Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: kim.walisch at gmail dot com Target Milestone: --- Created attachment 47429 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47429&action=edit Causes warni

[Bug c/66970] Add __has_builtin() macro

2017-02-27 Thread kim.walisch at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66970 kim.walisch at gmail dot com changed: What|Removed |Added CC||kim.walisch at gmail dot

[Bug c++/53596] g++-4.7 -Wall shouldn't complain for non-virtual protected dtor

2012-06-07 Thread kim.walisch at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53596 kim.walisch at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED

[Bug c++/53596] g++-4.7 -Wall shouldn't complain for non-virtual protected dtor

2012-06-07 Thread kim.walisch at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53596 --- Comment #4 from kim.walisch at gmail dot com 2012-06-07 08:28:05 UTC --- I found another post on the web (http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20110530/042333.html) that explains the warning, it says: "If Derived

[Bug c++/53596] g++-4.7 -Wall shouldn't complain for non-virtual protected dtor

2012-06-07 Thread kim.walisch at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53596 --- Comment #3 from kim.walisch at gmail dot com 2012-06-07 07:31:41 UTC --- Hi, thanks for your answer but I still think it is a bug. Here are my reasons: 1) You mention that Clang also warns for my example but this seems to be a bug in Clang

[Bug c++/53596] New: g++-4.7 -Wall shouldn't complain for non-virtual protected dtor

2012-06-06 Thread kim.walisch at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53596 Bug #: 53596 Summary: g++-4.7 -Wall shouldn't complain for non-virtual protected dtor Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED