[Bug rtl-optimization/64294] New: invalid code, zero check gets optimized away

[Bug rtl-optimization/64294] New: invalid code, zero check gets optimized away

[gcc at breakpoint dot cc]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64294

            Bug ID: 64294
           Summary: invalid code, zero check gets optimized away
           Product: gcc
           Version: 4.9.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: rtl-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: gcc at breakpoint dot cc

Created attachment 34272
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34272&action=edit
the testcase

The testcase is a minimized / cut-out of some code which basically does:


if (!backsize)
     exit(11);
while(backsize--) {
     *ddst=*(ddst+backbytes);
     ddst++;
}

gcc somehow assumes that backsize can't get zero which it can. I added an 'asm
volatile("labele:");' statement so the check can be easy spotted. At -O2 gcc
produces:

0000020a <labele>:
 20a:   8b 44 24 20             mov    0x20(%esp),%eax
 20e:   66 90                   xchg   %ax,%ax
 210:   0f b6 54 0d 00          movzbl 0x0(%ebp,%ecx,1),%edx
 215:   83 c5 01                add    $0x1,%ebp
 218:   88 55 ff                mov    %dl,-0x1(%ebp)
 21b:   39 e8                   cmp    %ebp,%eax
 21d:   75 f1                   jne    210 <labele+0x6>

So it copies the first byte before checking for equal/zero.
With -O1 instead:
0000028a <labele>:
 28a:   85 f6                   test   %esi,%esi
 28c:   75 0a                   jne    298 <labele+0xe>
 28e:   83 ec 0c                sub    $0xc,%esp
 291:   6a 0b                   push   $0xb
 293:   e8 fc ff ff ff          call   294 <labele+0xa>
                        294: R_386_PC32 exit
 298:   8b 5c 24 10             mov    0x10(%esp),%ebx
 29c:   8b 54 24 2c             mov    0x2c(%esp),%edx
 2a0:   0f b6 0c 13             movzbl (%ebx,%edx,1),%ecx
 2a4:   88 0b                   mov    %cl,(%ebx)
 2a6:   83 c3 01                add    $0x1,%ebx
 2a9:   39 d8                   cmp    %ebx,%eax
 2ab:   75 f3                   jne    2a0 <labele+0x16>

There is the 0 check withint the first two opcodes including the exit(0)
statement.

[Bug rtl-optimization/64294] invalid code, zero check gets optimized away

[schwab@linux-m68k.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64294

Andreas Schwab <schwab@linux-m68k.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |INVALID

--- Comment #1 from Andreas Schwab <schwab@linux-m68k.org> ---
This condition is true if backsize == 0:
     if(!((bufsz) > 0 && (backsize) > 0 && (size_t)(backsize) <=
(size_t)(bufsz) && (ddst) >= (buf) && ((ddst) + (backsize)) <= ((buf) +
(bufsz)) && ((ddst) + (backsize)) > (buf) && (ddst) < ((buf) + (bufsz))) ||
!((bufsz) > 0 && (backsize) > 0 && (size_t)(backsize) <= (size_t)(bufsz) &&
(ddst+backbytes) >= (buf) && ((ddst+backbytes) + (backsize)) <= ((buf) +
(bufsz)) && ((ddst+backbytes) + (backsize)) > (buf) && (ddst+backbytes) <
((buf) + (bufsz)))) {

[Bug rtl-optimization/64294] invalid code, zero check gets optimized away

[gcc at breakpoint dot cc]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64294

--- Comment #2 from Sebastian Andrzej Siewior <gcc at breakpoint dot cc> ---
It seems exit(0) is dropped with -O1 -ftree-vrp.

(In reply to Andreas Schwab from comment #1)
> This condition is true if backsize == 0:

Ehm, yes. The Code is:
--
printf("bufsz: %u backsize: %d\n", bufsz, backsize);
if(!CLI_ISCONTAINED(buf, bufsz, ddst, backsize) || !CLI_ISCONTAINED(buf, bufsz,
ddst+backbytes, back size)) {
      free(usects);
      return 1;
}
asm volatile("labele:");
--
So I would expect that it leaves the function but I see a segfault in the while
loop later on and according the printf, backsize was 0.

[Bug rtl-optimization/64294] invalid code, zero check gets optimized away

[gcc at breakpoint dot cc]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64294

Sebastian Andrzej Siewior <gcc at breakpoint dot cc> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #34272|0                           |1
        is obsolete|                            |

--- Comment #3 from Sebastian Andrzej Siewior <gcc at breakpoint dot cc> ---
Created attachment 34275
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34275&action=edit
tc-macro version

[Bug rtl-optimization/64294] invalid code, zero check gets optimized away

[gcc at breakpoint dot cc]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64294

--- Comment #4 from Sebastian Andrzej Siewior <gcc at breakpoint dot cc> ---
Created attachment 34276
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34276&action=edit
tc-static function

[Bug rtl-optimization/64294] invalid code, zero check gets optimized away

[gcc at breakpoint dot cc]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64294

Sebastian Andrzej Siewior <gcc at breakpoint dot cc> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |UNCONFIRMED
         Resolution|INVALID                     |---

--- Comment #5 from Sebastian Andrzej Siewior <gcc at breakpoint dot cc> ---
I re-open it. This time I attached the whole .i twice:
- "macro" contains the second CLI_ISCONTAINED() invocation as a macro
- "static" contains the second CLI_ISCONTAINED() as a static function

The first one (macro) segfaults, the second one (static) works as a expected. 
The only obvious change I made in the static version is that the size argument
is not signed but unsigned. Changing the type of sb_size to signed int results
in the segfault again.

I saw this problem with gcc-4.8 and 4.9. gcc 4.7 seems not to miss compile it.

Comparing the disassemble between those two .i I see:

- macro
+ static
 <label>:
-       8b 44 24 44             mov    0x44(%esp),%eax
-       89 c1                   mov    %eax,%ecx
+       8b 44 24 20             mov    0x20(%esp),%eax
+       85 c0                   test   %eax,%eax
+       0f 84 8c fb ff ff       je     3f0 <petite_inflate2x_1to9+0x3f0>
+       8b 4c 24 58             mov    0x58(%esp),%ecx
+       8b 44 24 20             mov    0x20(%esp),%eax

For me as a no-compiler guy it looks like the zero check has been removed
because for 
some reason the size argument has to be != 0.

I'm not sure if this is related but #26763 fixed a problem with the same macro.

Sebastian

[Bug rtl-optimization/64294] invalid code, zero check gets optimized away

[mikpelinux at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64294

--- Comment #7 from Mikael Pettersson <mikpelinux at gmail dot com> ---
The testcases don't build due to linkage errors.  Please submit a
self-contained and preferably minimized testcase.

[Bug rtl-optimization/64294] invalid code, zero check gets optimized away

[gcc at breakpoint dot cc]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64294

--- Comment #8 from Sebastian Andrzej Siewior <gcc at breakpoint dot cc> ---
Created attachment 34305
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34305&action=edit
self-contained complete TC

[Bug rtl-optimization/64294] invalid code, zero check gets optimized away

[gcc at breakpoint dot cc]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64294

--- Comment #9 from Sebastian Andrzej Siewior <gcc at breakpoint dot cc> ---
I added the complete function including its callers.
$ gcc -g -o petite petite.c -Wall -O2
$ ./petite 
447=> 5
452=> 5
447=> 5
452=> 5
447=> 0
452=> 0
Segmentation fault
---
$ gcc -g -o petite petite.c -Wall -O1
$ ./petite
447=> -12
->1

----
As you see the value in line 447 is different in -O2 vs -O1. And with -O2 it
continues with 0 to start the loop.
I have to run now, maybe I have later some time to figure out why the value in
line 447 is different in -O2 vs -O1.

[Bug rtl-optimization/64294] invalid code, zero check gets optimized away

[mikpelinux at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64294

--- Comment #10 from Mikael Pettersson <mikpelinux at gmail dot com> ---
You're invoking undefined behaviour due to overflow in signed integer
arithmetic.

Running it after compiling with -fsanitize=undefined produces:

petite.c:391:28: runtime error: signed integer overflow: 2147483647 * 2 cannot
be represented in type 'int'

Fixing that in the following crude way:

--- petite.c    2014-12-20 16:02:59.786063515 +0100
+++ petite-fixed.c      2014-12-20 16:15:05.030889115 +0100
@@ -388,7 +388,7 @@
                                                        free(usects);
                                                        return 1;
                                                }
-                                               backbytes = backbytes*2 + oob;
+                                               backbytes = (int)((unsigned
int)backbytes*2 + (unsigned int)oob);
                                                if ( (oob = doubledl(&ssrc,
&mydl, buf, bufsz)) == -1 ) {
                                                        free(usects);
                                                        return 1;

allows the testcase to work at -O2 and -O3.

[Bug rtl-optimization/64294] invalid code, zero check gets optimized away

[gcc at breakpoint dot cc]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64294

Sebastian Andrzej Siewior <gcc at breakpoint dot cc> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |INVALID

--- Comment #11 from Sebastian Andrzej Siewior <gcc at breakpoint dot cc> ---
(In reply to Mikael Pettersson from comment #10)
> You're invoking undefined behaviour due to overflow in signed integer
> arithmetic.

Sir, you made my day. So it is undefained behaviour and showed me even how to
catch those things. Thank you.