[Bug c++/104616] New: -Wconversion diagnostic on operator `/` with short ints, only when -fsanitize=undefined is passed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104616
Bug ID: 104616
Summary: -Wconversion diagnostic on operator `/` with short
ints, only when -fsanitize=undefined is passed
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: oschonrock at gmail dot com
Target Milestone: ---
`-fsanitize=undefined` should not affect -Wconversion behaviour. The behaviour
without -fsanitize=undefined is correct I believe.
https://godbolt.org/z/5663eajW1
int main() {
short sum = 50;
short count = 10;
short avg1 = sum / count;
auto tmp = sum;
tmp /= count;
short avg2 = tmp;
return (avg1 + avg2) & 0xff; // prevent "unused" diagnostics
}
g++ -Wconversion
=> no diagnostics
g++ -fsanitize=undefined -Wconversion
: In function 'int main()':
:5:22: warning: conversion from 'int' to 'short int' may change value
[-Wconversion]
5 | short avg1 = sum / count;
| ^~~
:8:12: warning: conversion from 'int' to 'short int' may change value
[-Wconversion]
8 | tmp /= count;
|^
[Bug tree-optimization/94566] conversion between std::strong_ordering and int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94566
--- Comment #8 from Oliver Schönrock ---
how about:
#include
#include
#include
int conv3(std::strong_ordering s){
return std::bit_cast(s);
}
std::strong_ordering conv4(int i){
return std::bit_cast(static_cast(i));
}
conv3(std::strong_ordering):
movsbl %dil, %eax
ret
conv4(int):
movl%edi, %eax
ret
https://godbolt.org/z/szP5MGq4T
[Bug tree-optimization/94566] conversion between std::strong_ordering and int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94566 --- Comment #10 from Oliver Schönrock --- I agree the switch optimisation is better, but... shouldn't std::bit_cast prevent incorrect casting with different underlying implementaion? (ie if the size doesn't match, and the size could be deduced with TMP) and "unordered value" doesn't apply to std::strong_ordering?
[Bug c++/96830] GCC does not complain about redeclaration with inconsistent requires clause
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96830 Oliver Schönrock changed: What|Removed |Added CC||oschonrock at gmail dot com --- Comment #7 from Oliver Schönrock --- It appears gcc's failure to "complain about redeclaration with inconsistent requires clause " might be hiding a small bug in libstdc++: https://godbolt.org/z/vxsY6oohM clang-trunk reports: /opt/compiler-explorer/gcc-snapshot/lib/gcc/x86_64-linux-gnu/13.0.0/../../../../include/c++/13.0.0/ranges:6098:14: error: requires clause differs in template redeclaration requires forward_range<_Vp> ^ /opt/compiler-explorer/gcc-snapshot/lib/gcc/x86_64-linux-gnu/13.0.0/../../../../include/c++/13.0.0/ranges:5797:14: note: previous template declaration is here requires input_range<_Vp> whereas gcc silently swallows the inconsistency?
[Bug libstdc++/117276] std::sort(par_unseq ,...) leaks memory when called repeatedly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117276 --- Comment #3 from Oliver Schönrock --- Realised the link to my repo with demo code was incorrect. Here is the correct one: https://github.com/oschonrock/tbbleak
[Bug libstdc++/117276] std::sort(par_unseq ,...) leaks memory when called repeatedly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117276 --- Comment #1 from Oliver Schönrock --- Created attachment 59419 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59419&action=edit patch which solves the problem this patch applies cleanly to libstdc++ 13.2 and 14.2 and also to head I believe. It solves the problem. The code change is from here: https://github.com/oneapi-src/oneDPL/pull/1589/files By one of the people on the TBB / oneDPL team. it cannot be applied to TBB ( I did ask there) because the bug is in the "glue/interface" code between libstdc++ and TBB and managed by libstdc++
[Bug libstdc++/117276] std::sort(par_unseq ,...) leaks memory when called repeatedly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117276 --- Comment #4 from Oliver Schönrock --- Is there anything I can do to help move this forward?
[Bug libstdc++/117276] New: std::sort(par_unseq ,...) leaks memory when called repeatedly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117276 Bug ID: 117276 Summary: std::sort(par_unseq ,...) leaks memory when called repeatedly Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: oschonrock at gmail dot com Target Milestone: --- Created attachment 59418 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59418&action=edit code to reproduce problem Environment --- ubuntu 24.04 libstdc++ 13.2 from ubuntu repos but also 14.2 and judging by libstdc++ github mirror the latest head also has this problem sudo apt install libtbb-dev ## this is obviously required Problem --- when calling `std::sort(std::execution::par_unseq` repeatedly it leaks memory, and will ultimately deplete the machine and get killed by the kernel. the attached
[Bug libstdc++/117276] std::sort(par_unseq ,...) leaks memory when called repeatedly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117276 Oliver Schönrock changed: What|Removed |Added URL||https://github.com/oneapi-s ||rc/oneTBB/issues/1533 --- Comment #2 from Oliver Schönrock --- Sorry, premature submit on original report comment. continuing... The attached sort_leak.cpp (59418) shows the problem. Single threaded sort is fine, par_unseq is not. output: Single threaded sort: VM:14544 RSS:11648 (kB) VM:14616 RSS:11588 (kB) VM:14616 RSS:11588 (kB) VM:14616 RSS:11588 (kB) VM:14616 RSS:11588 (kB) par_unseq sort: VM:29372 RSS:17860 (kB) VM:33468 RSS:19652 (kB) VM:33468 RSS:21316 (kB) VM:37564 RSS:23108 (kB) VM:37564 RSS:24772 (kB) Related bug reports: Issue filed by me on oneTBB: https://github.com/oneapi-src/oneTBB/issues/1533 my repo with demo code, instructions and references should they be needed: https://github.com/oneapi-src/oneTBB/issues/1533 Pull request on oneDPL which fixes it https://github.com/oneapi-src/oneDPL/pull/1589/files (that is what my patch is based on) Solution As stated above, the attached patch (59419) fixes the issue
[Bug libstdc++/117276] std::sort(par_unseq ,...) leaks memory when called repeatedly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117276 --- Comment #7 from Oliver Schönrock --- I did some additional testing on older distributions. On debian 11, bullseye, oldstable, we have gcc version 10.2.1 20210110 (Debian 10.2.1-6) I noticed that my patch DID NOT apply and the leak is NOT present with libstc++ as is. $ ./build/gcc/release/sort_leak Single threaded sort: VM:13900 RSS:11012 (kB) VM:13968 RSS:11288 (kB) VM:13968 RSS:11288 (kB) VM:13968 RSS:11288 (kB) VM:13968 RSS:11288 (kB) par_unseq sort: VM:94268 RSS:15684 (kB) VM:94268 RSS:15684 (kB) VM:94268 RSS:15684 (kB) VM:94268 RSS:15684 (kB) VM:94268 RSS:15684 (kB)
[Bug libstdc++/117276] std::sort(par_unseq ,...) leaks memory when called repeatedly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117276 --- Comment #10 from Oliver Schönrock --- Sorry, should have made that clear.. yes, appears to be a regression between gcc-10 and gcc-12
