[Bug c++/107140] Potential false positive uninitialized variable warning with -Wmaybe-uninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107140 --- Comment #3 from Kip Warner --- If you click the Save button in Godbolt's CE, you can download a compressed archive. I've attached it for you.
[Bug c++/107140] Potential false positive uninitialized variable warning with -Wmaybe-uninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107140 --- Comment #2 from Kip Warner --- Created attachment 53673 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53673=edit Minimal
[Bug c++/107140] New: Potential false positive uninitialized variable warning with -Wmaybe-uninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107140 Bug ID: 107140 Summary: Potential false positive uninitialized variable warning with -Wmaybe-uninitialized Product: gcc Version: 12.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: kip at thevertigo dot com Target Milestone: --- I am aware there have been other related issues that have already been opened. I am not sure if this adds anything new to the discussion, but I have, with some effort, managed to isolate a minimal that reproduces the issue. This code is not meant to be run, but it's merely a heavily butchered minimal to re-create a "'MaximumPriorityQueue' may be used uninitialized" warning. This originates in Test.cpp on L71. Here is the code: https://godbolt.org/z/a17Eoc3f3 This only appears to happen with >= -O2. My guess is this may be a result of a complex interaction with the optimizer and how part of the instantiated template was inlined. I note that if I reorder m_LessThanComparison with m_MinMaxHeap in Test.cpp, the warning is suppressed.
[Bug libstdc++/101228] tbb/task.h is Deprecated in newer TBB.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101228 --- Comment #3 from Kip Warner --- Thanks Andrew. I've opened an issue downstream: https://bugs.launchpad.net/gcc/+bug/1933775
[Bug libstdc++/101228] #include triggers Intel TBB warning for tbb/task.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101228 --- Comment #1 from Kip Warner --- Suggestion: Maybe a unit test that includes all the standard STL headers, does nothing with them, and that's expected to emit no warnings would mitigate problems like this occurring in the future.
[Bug libstdc++/101228] New: #include triggers Intel TBB warning for tbb/task.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101228
Bug ID: 101228
Summary: #include triggers Intel TBB warning for
tbb/task.h
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: kip at thevertigo dot com
Target Milestone: ---
I've managed to reproduce this issue on two different machines, one amd64 and
the other ppc64le. Both were using g++-11 (Ubuntu 11.1.0-1ubuntu1~21.04)
11.1.0.
Here is a minimal:
#include
#include
using namespace std;
int main()
{
vector Container(3'000'000);
iota(begin(Container), end(Container), 1);
sort(execution::par, begin(Container), end(Container));
return 0;
}
Compiling raises the following pragma in header generated warning:
$ g++-11 test.cpp -o test -Wall -Werror -std=c++17 -ltbb && ./test
In file included from /usr/include/c++/11/pstl/parallel_backend_tbb.h:26,
from /usr/include/c++/11/pstl/parallel_backend.h:20,
from /usr/include/c++/11/pstl/algorithm_impl.h:22,
from /usr/include/c++/11/pstl/glue_execution_defs.h:50,
from /usr/include/c++/11/execution:32,
from test.cpp:4:
/usr/include/tbb/task.h:21:139: note: ‘#pragma message: TBB Warning: tbb/task.h
is deprecated. For details, please see Deprecated Features appendix in the TBB
reference manual.’
21 | ("TBB Warning: tbb/task.h is deprecated. For details, please see
Deprecated Features appendix in the TBB reference manual.")
|
^
Compiling again with #define TBB_SUPPRESS_DEPRECATED_MESSAGES 1 prepended to
the beginning and the warning disappears.
This appears to have crept in some how with the 11 series. The
header is indirectly including some deprecated Intel header from the TBB
library.
[Bug libstdc++/99402] [10 Regression] std::copy creates _GLIBCXX_DEBUG false positive for attempt to subscript a dereferenceable (start-of-sequence) iterator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99402 --- Comment #11 from Kip Warner --- Thanks Jonathan. That was a constructive follow up.
[Bug libstdc++/99402] [10/11 Regression] std::copy creates _GLIBCXX_DEBUG false positive for attempt to subscript a dereferenceable (start-of-sequence) iterator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99402 --- Comment #8 from Kip Warner --- And for anyone finding this from a search engine, the temporary workaround is to use std::copy_n.
[Bug c++/99402] New: std::copy creates _GLIBCXX_DEBUG false positive for attempt to subscript a dereferenceable (start-of-sequence) iterator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99402
Bug ID: 99402
Summary: std::copy creates _GLIBCXX_DEBUG false positive for
attempt to subscript a dereferenceable
(start-of-sequence) iterator
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: kip at thevertigo dot com
Target Milestone: ---
The following is a minimal:
// Standard C++ / POSIX system headers...
#include
#include
#include
using namespace std;
int main()
{
// Container of eleven elements...
const set Source = { 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 };
// Goal is to copy the first ten elements in to here, or 0 to 9 inclusive.
// It has space for ten elements...
vector Destination(10);
// This should point to the end of the source range, or element with value
// 10 which is the first value after the range to be copied...
const auto EndIterator = next(cbegin(Source), 10);
// This results in memory corruption, or an abort with STL debugging
// enabled. copy_n(..., 10, ...) works fine...
copy(cbegin(Source), EndIterator, begin(Destination));
return 0;
}
Compile and run with the following:
$ g++-10 -D_GLIBCXX_DEBUG test.cpp -o test -g3 -std=c++17 && ./test
I see the following:
/usr/include/c++/10/bits/stl_algobase.h:566:
In function:
_OI std::copy(_II, _II, _OI) [with _II =
__gnu_debug::_Safe_iterator,
std::__debug::set, std::bidirectional_iterator_tag>; _OI =
__gnu_debug::_Safe_iterator<__gnu_cxx::__normal_iterator > >,
std::__debug::vector, std::random_access_iterator_tag>]
Error: attempt to subscript a dereferenceable (start-of-sequence) iterator
11 step from its current position, which falls outside its dereferenceable
range.
Objects involved in the operation:
iterator "__result" @ 0x0x7ffc3a448040 {
type = __gnu_cxx::__normal_iterator > > (mutable iterator);
state = dereferenceable (start-of-sequence);
references sequence with type 'std::__debug::vector >' @ 0x0x7ffc3a4480d0
}
Aborted (core dumped)
I've been advised from another who ran the same test that this works fine with
GCC 8 and 9, so it may be a regression.
[Bug libstdc++/79700] std::fabsf and std::fabsl missing from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79700 --- Comment #14 from Kip Warner --- Thanks Jonathan, but I still think you are mistaken in that you don't understand why the function exists in its various forms. Your explanation is technical and not philosophical. Whether it was originally inherited from the standard C library or was a creature of a C++ WG committee isn't material. And yes, you are being speculative. We can discuss another day the history, design choices, and rationale behind how floating point calculations have been done. In any event, we are going around in circles. But the important thing is that this is thankfully being patched.
[Bug libstdc++/79700] std::fabsf and std::fabsl missing from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79700 --- Comment #12 from Kip Warner --- I didn't say STL. I said library designers which includes the standard C runtime. And no, I don't agree with you. Separate names are helpful for greater certainty. As for std::ceilf existing just for consistency with C, that's speculative and, in my view doubtful.
[Bug libstdc++/79700] std::fabsf and std::fabsl missing from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79700 --- Comment #10 from Kip Warner --- Thanks Jonathan, but I disagree. The point is that the caller might be wrong in any number of assumptions. The library designers were in agreement, hence why there is an explicit ceilf function.
[Bug libstdc++/79700] std::fabsf and std::fabsl missing from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79700 --- Comment #7 from Kip Warner --- Not if I want any certainty at compile time that it is single precision.
[Bug libstdc++/79700] std::fabsf and std::fabsl missing from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79700 Kip Warner changed: What|Removed |Added CC||kip at thevertigo dot com --- Comment #5 from Kip Warner --- I am experiencing the same problem with GCC 10.2.0. I have included and I am attempting to rely on std::ceilf. g++(1) bails with: error: ‘ceilf’ is not a member of ‘std’; did you mean ‘ceil’ $ g++ --version g++ (Ubuntu 10.2.0-13ubuntu1) 10.2.0
[Bug c++/98368] Seg fault on template method missing required return statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98368 --- Comment #5 from Kip Warner --- *face palm* Yes, you are right! I totally forgot about the invocation at the end of the CLI! That's what happens when I don't get enough sleep.
[Bug c++/98368] Seg fault on template method missing required return statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98368 --- Comment #3 from Kip Warner --- Sorry, the _compiler_ crashing is expected behaviour?
[Bug c++/98368] New: Seg fault on template method missing required return statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98368 Bug ID: 98368 Summary: Seg fault on template method missing required return statement Product: gcc Version: 10.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: kip at thevertigo dot com Target Milestone: --- Created attachment 49792 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49792=edit Example to generate seg fault. I am experiencing a core dump when attempting to compile code that is missing a required return statement in a function that returns a non-void type. $ g++ --version g++ (Ubuntu 10.2.0-13ubuntu1) 10.2.0 Copyright (C) 2020 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. Minimal attached. $ g++ test2.cpp -o test2 -O3 -std=c++17 && ./test2 test2.cpp: In instantiation of ‘SomeTemplate::NodeOffsetType SomeTemplate::Foo(const Type3&) const [with Type3 = int; Type1 = int; Type2 = int; SomeTemplate::NodeOffsetType = long int]’: test2.cpp:25:16: required from here test2.cpp:20:1: warning: no return statement in function returning non-void [-Wreturn-type] 20 | } | ^ Segmentation fault (core dumped)
[Bug target/97329] POWER9 default cache and line sizes appear to be wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97329 --- Comment #7 from Kip Warner --- So it looks like even with GCC 11 in trunk it's still sometimes wrong on power9. Wrong L2 cache size when no -mcpu specified: $ gcc -Q --help=param | grep -i cache --param=l1-cache-line-size= 128 --param=l1-cache-size=32 --param=l2-cache-size=256 Correct when manually specifying native (power9) cpu: $ gcc -Q -mcpu=native --help=param | grep -i cache --param=l1-cache-line-size= 128 --param=l1-cache-size=32 --param=l2-cache-size=512 Correct when manually specifying power9 cpu: $ gcc -Q -mcpu=power9 --help=param | grep -i cache --param=l1-cache-line-size= 128 --param=l1-cache-size=32 --param=l2-cache-size=512 Wrong L2 cache size when powerpc64le is selected in place of power9: $ gcc -Q -mcpu=powerpc64le --help=param | grep -i cach --param=l1-cache-line-size= 128 --param=l1-cache-size=32 --param=l2-cache-size=256 Looks like this might be a clue. GCC did not identify the host/build/target as power9 automatically: $ gcc -dumpmachine powerpc64le-unknown-linux-gnu I built it from trunk last night on a power9 machine. I've attached my config.log. $ gcc --version gcc (GCC) 11.0.0 20201008 (experimental) (...)
[Bug target/97329] POWER9 default cache and line sizes appear to be wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97329 --- Comment #6 from Kip Warner --- Created attachment 49333 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49333=edit Autoconf configuration log on POWER9.
[Bug target/97329] POWER9 default cache and line sizes appear to be wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97329 --- Comment #4 from Kip Warner --- I'm going to do some more testing tonight and report back after.
[Bug target/97324] -mcpu= isn't validated on x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97324 --- Comment #9 from Kip Warner --- Yup. Agreed.
[Bug target/97324] -mcpu= isn't validated on x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97324 --- Comment #7 from Kip Warner --- I understand what you mean from a maintainer's standpoint. But from a user's standpoint, that's an inconsistency.
[Bug target/97324] -mcpu= isn't validated on x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97324 --- Comment #5 from Kip Warner --- The reason I asked is because of that inconsistency in the -mcpu usage on targets. Thanks for clarifying.
[Bug target/97324] -mcpu= isn't validated on x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97324 --- Comment #3 from Kip Warner --- Martin, is -mcpu deprecated for all architectures or just x86?
[Bug target/97329] POWER9 default cache and line sizes appear to be wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97329 --- Comment #2 from Kip Warner --- Sorry, not same issue. It appears as though this was fixed in gcc-11.
[Bug target/97329] POWER9 default cache and line sizes appear to be wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97329 Kip Warner changed: What|Removed |Added Version|10.2.0 |11.0 --- Comment #1 from Kip Warner --- Just tested with Git head (11.0.0 20201008) and same issue: $ gcc --version gcc (GCC) 11.0.0 20201008 (experimental) Copyright (C) 2020 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. $ gcc -Q -mcpu=power9 --help=param | grep -i cache --param=l1-cache-line-size= 128 --param=l1-cache-size=32 --param=l2-cache-size=512 $ getconf -a | grep CACHE LEVEL1_ICACHE_SIZE 32768 LEVEL1_ICACHE_ASSOC32 LEVEL1_ICACHE_LINESIZE 128 LEVEL1_DCACHE_SIZE 32768 LEVEL1_DCACHE_ASSOC32 LEVEL1_DCACHE_LINESIZE 128 LEVEL2_CACHE_SIZE 524288 LEVEL2_CACHE_ASSOC 2048 LEVEL2_CACHE_LINESIZE 32 LEVEL3_CACHE_SIZE 10485760 LEVEL3_CACHE_ASSOC 40960 LEVEL3_CACHE_LINESIZE 32 LEVEL4_CACHE_SIZE 0 LEVEL4_CACHE_ASSOC 0 LEVEL4_CACHE_LINESIZE 0 $ cat /proc/cpuinfo processor : 0 cpu : POWER9, altivec supported clock : 2933.00MHz revision: 2.2 (pvr 004e 1202) (...) processor : 143 cpu : POWER9, altivec supported clock : 2166.00MHz revision: 2.2 (pvr 004e 1202) timebase: 51200 platform: PowerNV model : machine : PowerNV firmware: OPAL MMU : Radix
[Bug c/97329] New: POWER9 default cache and line sizes appear to be wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97329 Bug ID: 97329 Summary: POWER9 default cache and line sizes appear to be wrong Product: gcc Version: 10.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: kip at thevertigo dot com Target Milestone: --- While investigating the memory hierarchy on my Romulus POWER9 (CPU revision 2.2) I discovered GCC's default L1 cache and line sizes on POWER9 are not correct. I think whoever specified the default cache size of 64KB may not have realized the L1 cache is banked, and not unified. On POWER9 that 64KB is split between separate instructions and data spaces. Only 32KB is actually available for data. GCC's documentation specifies that the l1-cache-size parameter is suppose to refer to data only, but not instructions. Further, the default l1-cache-line-size is wrong. It's currently set at 32 bytes. The correct value is actually four times that at 128 bytes. As things are right now, the resulting generated code may not be properly optimized because the optimizer plans around the wrong parameters. When this happens the generated program may have a higher than necessary cache miss rate. This could be a big deal since the CPU retrieving data from the L1 may only take one or two cycles, but a cache miss could mean several hundred while the block is transferred.
[Bug c/97324] New: -mcpu= isn't validated on x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97324 Bug ID: 97324 Summary: -mcpu= isn't validated on x86 Product: gcc Version: 10.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: kip at thevertigo dot com Target Milestone: --- On amd64 I see the following: $ gcc-10 -Q --help=param -mcpu=sdfdsf gcc-10: warning: ‘-mcpu=’ is deprecated; use ‘-mtune=’ or ‘-march=’ instead The following options control parameters: --param=align-loop-iterations=4 (...) On my POWER9 machine I see the following: $ gcc-10 -Q --help=param -mcpu=sdfdsf gcc-10: error: unrecognized argument in option ‘-mcpu=sdfdsf’ gcc-10: note: valid arguments to ‘-mcpu=’ are: 401 403 405 405fp 440 440fp 464 464fp 476 476fp 505 601 602 603 603e 604 604e 620 630 740 7400 7450 750 801 821 823 8540 8548 860 970 G3 G4 G5 a2 cell e300c2 e300c3 e500mc e500mc64 e5500 e6500 ec603e native power10 power3 power4 power5 power5+ power6 power6x power7 power8 power9 powerpc powerpc64 powerpc64le rs64 titan Note that on amd64 the CPU value's nonsensical value was not validated.
