[Bug c++/92617] Invalid loop optimization: no exit condition

2019-11-21 Thread piotr.seweryn at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92617

--- Comment #5 from Piotr Seweryn  ---
Obviously there is no return statement and warning was issued, however endless
loop isn't the expected result, don't you agree? And falling-through to the
next piece of code is even worse, coze we are falling we random arguments and
weird things may happen.

[Bug c++/92617] Invalid loop optimization: no exit condition

2019-11-21 Thread piotr.seweryn at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92617

--- Comment #3 from Piotr Seweryn  ---
Similar problem occurs when -O2 or -O3 is used, there is also an endless loop,
however different assembler code is generated. I can also provided appropriate
.ii and .s files for O2 and O3 case.

[Bug c++/92617] Invalid loop optimization: no exit condition

2019-11-21 Thread piotr.seweryn at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92617

--- Comment #2 from Piotr Seweryn  ---
Created attachment 47324
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47324=edit
Assembler file

[Bug c++/92617] Invalid loop optimization: no exit condition

2019-11-21 Thread piotr.seweryn at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92617

--- Comment #1 from Piotr Seweryn  ---
Created attachment 47323
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47323=edit
Pre-processed file

[Bug c++/92617] New: Invalid loop optimization: no exit condition

2019-11-21 Thread piotr.seweryn at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92617

Bug ID: 92617
   Summary: Invalid loop optimization: no exit condition
   Product: gcc
   Version: 8.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: piotr.seweryn at gmail dot com
  Target Milestone: ---

Created attachment 47322
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47322=edit
Compilation process stderr output

Consider the following code:
#include 
int parseList()
{
   int i;
   for (i = 0; i < 3; i++) {
   printf("DUPA: %d %d\n", i, i);
   }
}
int main(int argc, char **argv)
{
   printf("start\n");
   parseList();
}

Obviously there is no return statement in parseList function and "no return
statement in function returning non-void" warning was issued.

Command used to compile:
gcc -Wall -Wextra -v -save-temps -O1 test.cpp -otest -lstdc++ 1> log.stdout 2>
log.stderr

Expected result:
3 loop iterations, 4 messages displayed to stdout

Actual result:
endless loop

If we take a closer look at the assembler code (output of objdump -S):
0001145 <_Z9parseListv>:
1145:   48 83 ec 08 sub$0x8,%rsp
1149:   ba 00 00 00 00  mov$0x0,%edx
114e:   be 00 00 00 00  mov$0x0,%esi
1153:   48 8d 3d aa 0e 00 00lea0xeaa(%rip),%rdi# 2004
<_IO_stdin_used+0x4>
115a:   b8 00 00 00 00  mov$0x0,%eax
115f:   e8 cc fe ff ff  callq  1030 
1164:   ba 01 00 00 00  mov$0x1,%edx
1169:   be 01 00 00 00  mov$0x1,%esi
116e:   48 8d 3d 8f 0e 00 00lea0xe8f(%rip),%rdi# 2004
<_IO_stdin_used+0x4>
1175:   b8 00 00 00 00  mov$0x0,%eax
117a:   e8 b1 fe ff ff  callq  1030 
117f:   ba 02 00 00 00  mov$0x2,%edx
1184:   be 02 00 00 00  mov$0x2,%esi
1189:   48 8d 3d 74 0e 00 00lea0xe74(%rip),%rdi# 2004
<_IO_stdin_used+0x4>
1190:   b8 00 00 00 00  mov$0x0,%eax
1195:   e8 96 fe ff ff  callq  1030 

119a :
119a:   48 83 ec 08 sub$0x8,%rsp
119e:   48 8d 3d 6c 0e 00 00lea0xe6c(%rip),%rdi# 2011
<_IO_stdin_used+0x11>
11a5:   e8 96 fe ff ff  callq  1040 
11aa:   e8 96 ff ff ff  callq  1145 <_Z9parseListv>
11af:   90  nop


There is no return instruction at the end of parseList function, so we will
fall-through to main function, then we will call parseList function and
fall-through again to main and so on.

System specification:
gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/8/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 8.3.0-6'
--with-bugurl=file:///usr/share/doc/gcc-8/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr
--with-gcc-major-version-only --program-suffix=-8
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie
--with-system-zlib --with-target-system-zlib --enable-objc-gc=auto
--enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none --without-cuda-driver
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 8.3.0 (Debian 8.3.0-6) 

Debian 10.1 x86_64, updated to newest version.

Problem occurs when optimization O1 is used.