[Bug c++/80827] New: False strict-aliasing warning with certain settings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80827
Bug ID: 80827
Summary: False strict-aliasing warning with certain settings
Product: gcc
Version: 7.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: s-beyer at gmx dot net
Target Milestone: ---
Hi,
$ cat foo.cc
#include
template
void foo() {
std::istringstream ss("a\nb\nc");
std::string attr;
while (std::getline(ss, attr));
}
$ g++-7 -Wall -O2 -c foo.cc # warning with -O2
foo.cc: In function ‘void foo()’:
foo.cc:7:30: warning: dereferencing type-punned pointer will break
strict-aliasing rules [-Wstrict-aliasing]
while (std::getline(ss, attr));
^
$ g++-7 -Wall -O1 -c foo.cc # works with -O1
$ g++-7 --version
g++-7 (Debian 7.1.0-5) 7.1.0
Copyright (C) 2017 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.
Interestingly, when using a function instead of a function template,
it works:
$ cat foo.cc
#include
void foo() {
std::istringstream ss("a\nb\nc");
std::string attr;
while (std::getline(ss, attr));
}
$ g++-7 -Wall -O2 -c foo.cc
Btw it works with 6.3.0
Best
Stephan
[Bug c++/78487] New: asm cpuid code and -fgcse crashes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78487 Bug ID: 78487 Summary: asm cpuid code and -fgcse crashes Product: gcc Version: 6.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: s-beyer at gmx dot net Target Milestone: --- Created attachment 40123 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40123&action=edit the C++ source
[Bug inline-asm/78487] asm cpuid code and -fgcse crashes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78487 --- Comment #2 from Stephan Beyer --- The following problem is only reproducible on one machine. I cannot reproduce it on any other machine. When compiling the attached C++ source file with g++ -O1 -fgcse, it crashes at the third cpuid call (ie, there are three output lines). When just using g++ -O1 (without -fgcse), it works well. Changing the code in main() slightly or making cpuid() inline makes it work well also with -fgcse. uname -a and g++ --version of that machine says: Linux ipc675 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt4-3 (2015-02-03) x86_64 GNU/Linux g++ (Debian 6.2.0-13) 6.2.0 20161109 If useful, I can also attach assembly output of the crashing code (with -fgcse), of the code without -fgcse and of the code with "inline" (there using -fgcse makes no difference). The code is not written by me, so I don't know if its "correct" or if the input/output asm constraints are just used wrong. (It's just the minimal example I got from code where a crash occurred.) PS: excuse the first empty bug report, it seems I am too stupid for bugzilla.
[Bug inline-asm/78487] asm cpuid code and -fgcse crashes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78487 --- Comment #5 from Stephan Beyer --- It crashes on run-time. I have absolutely no experience using extended asm syntax but I guess g++ relies on the constraints for its optimization, so I guess the constraints are wrong. I will port the code to use the macro from cpuid.h and close the issue if there are no more crashes. Thank you.
[Bug inline-asm/78487] asm cpuid code and -fgcse crashes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78487 Stephan Beyer changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #6 from Stephan Beyer --- Ok, the problem is solved using __get_cpuid(). Sorry for bothering you and thank you for the quick help.
[Bug middle-end/68336] False positive Wreturn-type warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68336
Stephan Beyer changed:
What|Removed |Added
CC||s-beyer at gmx dot net
--- Comment #3 from Stephan Beyer ---
Hi,
these false-positives still occur in g++ 6.3.0
I am mentioning this because I want to add another test case:
$ cat foo.cc
enum class Test {
first,
second
};
int return_warning(Test foo) {
switch (foo) {
case Test::first:
return 23;
case Test::second:
return 42;
}
}
$ g++-6 -std=c++11 -Wreturn-type -c foo.cc
foo.cc: In function ‘int return_warning(Test)’:
foo.cc:13:1: warning: control reaches end of non-void function [-Wreturn-type]
}
^
$ g++-6 --version
g++-6 (Debian 6.3.0-2) 6.3.0 20161229
Copyright (C) 2016 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.
This is directly related to #60725. Note the difference that an
"enum class" is used here instead of an unscoped "enum". I however do not
think that this actually makes a difference in C++. ("enum Test foo = 3"
is valid in C but not in C++, right?)
Regards
Stephan
[Bug c++/79877] New: -Wstrict-overflow false positive or misunderstanding?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79877
Bug ID: 79877
Summary: -Wstrict-overflow false positive or misunderstanding?
Product: gcc
Version: 7.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: s-beyer at gmx dot net
Target Milestone: ---
Hi,
I have the following code:
$ cat foo.cc
#include
static int strict_overflow_warning(int bitmask) {
int max = -1;
for (int i = 31; i > max; i--) {
if (bitmask & (1 << i)) {
max = i;
}
}
return max;
}
static int no_strict_overflow_warning(int bitmask) {
int max = -1;
for (int i = 31; i >= 0; i--) {
if (bitmask & (1 << i)) {
max = i;
break;
}
}
return max;
}
int main(int argc, char *argv[]) {
std::cout << strict_overflow_warning(argc) << std::endl;
std::cout << no_strict_overflow_warning(argc) << std::endl;
std::cout << strict_overflow_warning(0) << std::endl;
std::cout << no_strict_overflow_warning(0) << std::endl;
std::cout << strict_overflow_warning(-argc) << std::endl;
std::cout << no_strict_overflow_warning(-argc) << std::endl;
return 0;
}
I get the following output (depending on g++ version and -O flag):
$ g++-7 -O3 -Wstrict-overflow foo.cc && ./a.out 2 3 4 5 6 7 8
foo.cc: In function ‘int main(int, char**)’:
foo.cc:5:21: warning: assuming signed overflow does not occur when assuming
that (X - c) <= X is always true [-Wstrict-overflow]
for (int i = 31; i > max; i--) {
~~^
foo.cc:5:21: warning: assuming signed overflow does not occur when assuming
that (X - c) <= X is always true [-Wstrict-overflow]
for (int i = 31; i > max; i--) {
~~^
3
3
-1
-1
31
31
$ g++-7 -O2 -Wstrict-overflow foo.cc && ./a.out 2 3 4 5 6 7 8
3
3
-1
-1
31
31
$ g++-6 -O3 -Wstrict-overflow foo.cc && ./a.out 2 3 4 5 6 7 8
3
3
-1
-1
31
31
The two functions should be semantically equivalent (as the output
indicates). Why does the version using i > max (instead of using i >= 0
and the break) show me the strict-overflow warning?
Thank you,
Stephan
[Bug c++/79877] -Wstrict-overflow false positive or misunderstanding?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79877 --- Comment #2 from Stephan Beyer --- Hi, (In reply to Marc Glisse from comment #1) > The message seems pretty clear to me. gcc has an optimization that turns > i-1>i into false, and is telling you that it applied it (not that there is > anything wrong with your code). But it only applies it when doing some loop unrolling, doesn't it? Otherwise it would result in wrong behavior and the output wouldn't be the same. If this is the case, then the warning shouldn't be printed. > In the other code, it doesn't apply that > optimization, so the warning doesn't appear. Yes (that's why I wrote i >= 0 to see if it appears again). > Maybe we should just drop the warning if it causes more confusion than it > helps find bugs... The warning is a real problem in the case that can often be seen: when you turn on -O3 -Wall -Werror ... many people think that -Wall is so sensibly chosen by the compiler vendors that they can safely turn them into errors. However, in this case, -Wstrict-overflow is, according to you, more an information than an indication "that there is anything wrong with your code". Hence -Werror leading to an error somehow seems to be wrong behavior. On the other hand, warnings are mostly only an information about things going on implicitly, but you can usually make them explicit easily (e.g., variable assignments inside ifs by adding parentheses, implicit fallthroughs in switch/case by adding the [[fallthrough]] attribute, maybe-uninitialized warnings by initializing variables on declaration, etc.). In my example, however, the solution is to change the code into code using a break (which is considered bad style by some people) or by adding an extra bool variable (to avoid the break). And in another example, the solution may be totally different. It seems there is no "general" rule to get rid of these warnings before you experience them. Cheers Stephan
[Bug c++/80267] New: Compiling aborts when template/auto/lambda occur in some way
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80267
Bug ID: 80267
Summary: Compiling aborts when template/auto/lambda occur in
some way
Product: gcc
Version: 7.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: s-beyer at gmx dot net
Target Milestone: ---
Hi,
g++ 7.0.1 asks me for reporting a bug, so I do it.
I have the following minimal example:
$ cat gcc-bug.cpp
#include
struct Outer {
struct Inner {
void func();
};
const Inner &inner() const;
Inner &inner();
};
void run(std::function func) { func(); }
template void test() {
Outer ocm;
auto &inner = ocm.inner();
run([&]() {
inner.func();
run([&]() { inner.func(); });
});
}
int main() { test(); };
And the following happens with g++ 7.0.1
$ g++-7 --version
g++-7 (Debian 7-20170302-1) 7.0.1 20170302 (experimental) [trunk revision
245832]
Copyright (C) 2017 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.
$ g++-7 -c gcc-bug.cpp && echo GOOD
gcc-bug.cpp: In instantiation of ‘test() [with T =
bool]’:
gcc-bug.cpp:20:11: required from ‘struct test():: [with T =
bool]::’
gcc-bug.cpp:20:8: required from ‘test():: [with T = bool]’
gcc-bug.cpp:18:9: required from ‘struct test() [with T = bool]::’
gcc-bug.cpp:18:6: required from ‘void test() [with T = bool]’
gcc-bug.cpp:24:25: required from here
gcc-bug.cpp:20:17: internal compiler error: in tsubst_copy, at cp/pt.c:14589
run([&]() { inner.func(); });
^
0x5e9c2c tsubst_copy
../../src/gcc/cp/pt.c:14587
0x5ed9fe tsubst_copy
../../src/gcc/cp/pt.c:14414
0x5ed9fe tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../src/gcc/cp/pt.c:17727
0x5ed868 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../src/gcc/cp/pt.c:16665
0x5ed8e1 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../src/gcc/cp/pt.c:17507
0x5ed49e tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../src/gcc/cp/pt.c:17128
0x5e6a27 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../src/gcc/cp/pt.c:16446
0x5e5485 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../src/gcc/cp/pt.c:15711
0x5e6853 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../src/gcc/cp/pt.c:15923
0x5e6853 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../src/gcc/cp/pt.c:15923
0x5e4ef6 instantiate_decl(tree_node*, bool, bool)
../../src/gcc/cp/pt.c:22874
0x5fcfcd instantiate_class_template_1
../../src/gcc/cp/pt.c:10716
0x5fcfcd instantiate_class_template(tree_node*)
../../src/gcc/cp/pt.c:10786
0x65f9d5 complete_type(tree_node*)
../../src/gcc/cp/typeck.c:133
0x5ecaa9 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../src/gcc/cp/pt.c:17859
0x5ee406 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../src/gcc/cp/pt.c:17144
0x5e6a27 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../src/gcc/cp/pt.c:16446
0x5e5485 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../src/gcc/cp/pt.c:15711
0x5e6605 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../src/gcc/cp/pt.c:15697
0x5e6853 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../src/gcc/cp/pt.c:15923
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See for instructions.
Whereas g++ 6.3 works:
$ g++ --version
g++ (Debian 6.3.0-8) 6.3.0 20170221
Copyright (C) 2016 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.
$ g++ -c gcc-bug.cpp && echo GOOD
GOOD
Best
Stephan
[Bug c++/82552] New: No warning when using uninitialized values in initializer list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82552
Bug ID: 82552
Summary: No warning when using uninitialized values in
initializer list
Product: gcc
Version: 7.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: s-beyer at gmx dot net
Target Milestone: ---
Hi,
the following code example is pretty harmless but the underlying issue
took me quite some time to debug in real code (where the constructors
are really doing stuff):
8<
struct bar {
bar() {}
bar(bar&) {}
};
class foo {
bar first;
bar second;
public:
foo() : first(second) {}
};
>8
The interesting thing is the foo constructor.
It initializes "first" with "second", but the initializer list
is going in order of the attributes, so "first" is initialized
before "second" is.
I'd expect either an -Wreorder warning ("second" will be initialized after
"first") or an -Wuninitialized ("second" will be used uninitialized) warning
(which is what clang++ does).
I tested this with g++ 4.9.3, 5.4.1, 6.4.0, and 7.2.0. None of it raised
alarm :(
Thanks.
[Bug c++/82552] No warning when using uninitialized values in initializer list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82552 --- Comment #2 from Stephan Beyer --- I had expected this but I could not find the specific one. (I found a few related ones that were resolved as FIXED.)
