mponent: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: rbd at debian dot org
The following code generates a spurious " ‘out’ may be used uninitialized in
this function" warning when built with -Og; no optimization, -O1, -O2, -O3 and
-Ofast all do not warn.
// gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58377
--- Comment #2 from Roland Dreier ---
arg, I really apologize. I copied and pasted from the wrong window and ended
up with a test case that does NOT reproduce the issue, even on my system. Here
is one I triple checked does fail (and everything i
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58377
--- Comment #3 from Roland Dreier ---
Even simpler test case for me:
$ cat x.cpp
// gcc -Og -Wall -Werror -c x.cpp
int pop ();
int pop_first_bucket;
int my_pop ()
{
int out;
while (pop_first_bucket)
if (pop_first_bucket && (ou
iority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: rbd at debian dot org
(My gcc 4.8 is new enough that it has the fix for PR middle-end/58377)
I have a case of C++ code that spuriously warns about a "may be used
uninitialized" variable. I haven
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58455
--- Comment #2 from Roland Dreier ---
Arg, I don't seem to be able to avoid breaking my test cases while minimizing
them. So for my first test case here the issue seems to be that -Og is the
only level that *correctly* warns, which is surprising
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: rbd at debian dot org
Target Milestone: ---
With gcc 5.2 I see a deque with non-is_always_equal allocator get corrupted
state when moved from. My understanding is that a moved
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: rbd at debian dot org
This is probably related to PR c++/61488 although slightly more complicated.
The following test case is accepted by gcc 4.8 (and clang) but fails on 4.9.1
and
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: rbd at debian dot org
Target Milestone: ---
My understanding of allocator aware containers (of which std::set is one) is
that moving the container should move the allocator. However the following
code shows that std
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: rbd at debian dot org
Target Milestone: ---
The example below is extracted via creduce from a large program I have. The
program runs incorrectly when build with gcc 5.4.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77316
--- Comment #2 from Roland Dreier ---
Yes, I hid that in the middle of the wall of text in my report - I only see
this with gcc 5.4. It works as expected with gcc 6 and also gcc 4.9.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77316
--- Comment #3 from Roland Dreier ---
I managed to simplify the test case a bit by hand. The significant thing seems
to be "decltype(nullptr)" - if I change that to, say, void*, then I don't get
the spurious symbol.
$ cat b.cpp
template class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77316
--- Comment #4 from Roland Dreier ---
Discovered this is due to abi-compat, I think. gcc 6 works because abi-compat
went from 2 (gcc 5.4) to 8, and the significant break is 6 -> 7:
$ g++ -Wabi=6 --std=c++11 -c b.cpp
12 matches
Mail list logo
