[Bug c++/97697] Segmentation fault on while (true) loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97697 --- Comment #2 from Marcin Jasinski --- Is there any workaround possible, before next 9.x release?
[Bug c++/97697] New: Segmentation fault on while (true) loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97697
Bug ID: 97697
Summary: Segmentation fault on while (true) loop
Product: gcc
Version: 9.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: marcin.jachu19 at gmail dot com
Target Milestone: ---
Created attachment 49496
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49496&action=edit
source file
May be a duplicate of 97627, but this time it seg faults, -fwrapv doesn't help
and there is only one for loop inside. It seems to not reach the end of the
while(true) loop and crashes just before. Observed on gcc 9.x and 10.x (all
versions).
GCC version (in practice any 9.x and 10.x):
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-9.2.0/configure --enable-languages=c,c++
--enable-multilib
Thread model: posix
gcc version 9.2.0 (GCC)
GNU C++17 (GCC) version 9.2.0 (x86_64-pc-linux-gnu)
compiled by GNU C version 9.2.0, GMP version 4.3.1, MPFR version 2.4.1,
MPC version 0.8, isl version none
System type (doesn't matter, any Linux, for this example used):
centos-release-7-7.1908.0.el7.centos.x86_64
GCC compilation options:
../gcc-9.2.0/configure --enable-languages=c,c++ --enable-multilib
Test compilation options:
g++ -Wall -Wextra -fPIC -O2 -std=c++17 -o test test.cpp
Compiler output:
(none)
Source files attached, the problematic part:
for (unsigned int nrn_idx = 0; nrn_idx < nrn_pass_num; ++nrn_idx)
{
bar();
}
baz();
Expected behavior:
test enters the end of the loop and prints "all OK"
Actual behavior:
Segmentation fault (core dumped)
Command line
./test
More comments:
- gcc 8.x works OK on this example
- gcc trunk works OK as well
- -fwrapv doesn't change anything, it was helping in 97627
- -O1 works fine
I hoped we can move from 8.x to 9.x using -fwrapv workaround, but it doesn't
help here. Can you please suggest any temporal workaround other than -O1 ?
[Bug c++/97627] New: loop end condition missing - endless loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97627
Bug ID: 97627
Summary: loop end condition missing - endless loop
Product: gcc
Version: 9.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: marcin.jachu19 at gmail dot com
Target Milestone: ---
Created attachment 49467
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49467&action=edit
cpp source file
It seems a loop end condition is missing in this example. Observed on gcc 9.x
and 10.x (all versions).
This example may look as not much sense, but it is extracted from bigger system
to just explore the issue.
GCC version (in practice any 9.x and 10.x):
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-9.2.0/configure --enable-languages=c,c++
--enable-multilib
Thread model: posix
gcc version 9.2.0 (GCC)
GNU C++17 (GCC) version 9.2.0 (x86_64-pc-linux-gnu)
compiled by GNU C version 9.2.0, GMP version 4.3.1, MPFR version 2.4.1,
MPC version 0.8, isl version none
System type (doesn't matter, any Linux, for this example used):
centos-release-7-7.1908.0.el7.centos.x86_64
GCC compilation options:
../gcc-9.2.0/configure --enable-languages=c,c++ --enable-multilib
Test compilation options:
g++ -Wall -Wextra -fPIC -O2 -std=c++17 -o test test.cpp
Compiler output:
(none)
Source files attached, the problematic loop:
for (int h = 0; h < num_of_repeats_h; h++)
{
for (int w = 0; w < num_of_repeats_w; w++)
{
printf("w: %d, num_of_repeats_w: %d\n", w, num_of_repeats_w);
}
}
Expected behavior:
test enters to the inter loop only once, printing counter always equal 0 like:
w: 0, num_of_repeats_w: 1
Actual behavior:
the internal loop never ends, the counter reaches high numbers like:
w: 22373, num_of_repeats_w: 1
Command line
./test
Ctrl+c
More comments:
- gcc 8.x works OK on this example
- it's worth to mention, that -fwrapv option makes it working fine, but I
believe the issue just hides.
- also the -O1 option makes the difference.
- also the -fsanitize=undefined option makes the difference like:
: runtime error: execution reached an unreachable program point
but I still believe the source code is correct and the gcc causes the issue.
