Bug 45059 - [4.6 Regression] error: invalid operands in binary operation, leads to ICE: verify_stmts failed
Summary: [4.6 Regression] error: invalid operands in binary operation, leads to ICE: v...
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: tree-optimization (show other bugs)
Version: 4.6.0
: P3 normal
Target Milestone: 4.6.0
Assignee: Jakub Jelinek
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-07-24 18:24 UTC by John Regehr
Modified: 2010-08-25 09:50 UTC (History)
3 users (show)

See Also:
Host: x86_64-unknown-linux-gnu
Target: x86_64-unknown-linux-gnu
Build: x86_64-unknown-linux-gnu
Known to work:
Known to fail:
Last reconfirmed: 2010-07-24 19:09:14


Attachments
gcc46-pr45059.patch (756 bytes, patch)
2010-08-24 17:26 UTC, Jakub Jelinek
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description John Regehr 2010-07-24 18:24:25 UTC
[regehr@bethe tmp604]$ current-gcc -O3 small.c -c -fwhole-program
small.c: In function 'main':
small.c:42:1: error: invalid operands in binary operation
D.2852_11 = (unsigned int) D.2845_7 != 4294967295;

small.c:42:1: internal compiler error: verify_stmts failed
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.

[regehr@bethe tmp604]$ current-gcc -v

Using built-in specs.
COLLECT_GCC=current-gcc
COLLECT_LTO_WRAPPER=/uusoc/exports/scratch/regehr/z/compiler-install/gcc-r162424-inst
all/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --with-libelf=/usr/local --enable-lto --prefix=/home/re
gehr/z/compiler-install/gcc-r162424-install --program-prefix=r162424- --enable-langua
ges=c,c++
Thread model: posix
gcc version 4.6.0 20100722 (experimental) (GCC)

[regehr@bethe tmp604]$ cat small.c

typedef signed char int8_t;
typedef short int int16_t;
typedef int int32_t;
typedef unsigned char uint8_t;
typedef unsigned int uint32_t;

static uint32_t
safe_mod_func_uint32_t_u_u (uint32_t ui1, uint8_t ui2)
{
  return ui2 ? ui1 : ui1 + ui2;
}

int8_t g_2;
uint32_t g_36[7][4] = {
  -1L, -1L, -1L, 0, -1L, -1L, -1L, 0
};

uint8_t g_56;
uint8_t g_269;
int32_t func_37 (const int16_t p_38, int16_t p_39, int8_t p_40, int32_t p_41,
                 uint8_t p_42);
uint8_t
func_1 (void)
{
  uint8_t *l_298 = &g_2;
  func_20 (l_298,
           &l_298 != &l_298 == ~func_37 (func_37 (g_56, 0, 0, g_269, 0), 1, 0,
                                         -1L, 0), 0);
  return 0;
}

int32_t
func_37 (const int16_t p_38, int16_t p_39, int8_t p_40, int32_t p_41,
         uint8_t p_42)
{
  uint8_t *l_55 = &g_56;
  *l_55 |= g_2 < safe_mod_func_uint32_t_u_u (g_36[1][2], 0) | 0, ~p_39;
  return 0;
}

int
main (int argc, char *argv[])
{
  func_1 ();
}
Comment 1 Richard Biener 2010-07-24 19:09:14 UTC
Caused by tree-ssa-reassoc.c
Comment 2 Jakub Jelinek 2010-07-26 12:39:01 UTC
Simplified testcase:

typedef unsigned int T;
extern void foo (unsigned char *, int);

static signed char a;
static T b[1] = { -1 };
static unsigned char c;

static inline short int
bar (short v)
{
  c |= a < b[0];
  return 0;
}

int
main ()
{
  unsigned char *e = &a;
  foo (e, bar (bar (c)));
  return 0;
}
Comment 3 Jakub Jelinek 2010-07-26 12:58:48 UTC
Works if b[] has unsigned int type instead of T.
Sounds like a type mismatch.
The VAR_DECL b has ARRAY_TYPE with T element type and b's CONSTRUCTOR has the same type, but the values in the constructor doesn't have T type, but unsigned int:
 <constructor 0x7ffff1f2f420
    type <array_type 0x7ffff1f23498
        type <integer_type 0x7ffff1f232a0 T unsigned SI
            size <integer_cst 0x7ffff202d708 constant 32>
            unit size <integer_cst 0x7ffff202d410 constant 4>
            align 32 symtab 0 alias set -1 canonical type 0x7ffff2042540 precision 32 min <integer_cst 0x7ffff202d730 0> max <integer_cst 0x7ffff202d6e0 4294967295>
            pointer_to_this <pointer_type 0x7ffff1f23540>>
        SI size <integer_cst 0x7ffff202d708 32> unit size <integer_cst 0x7ffff202d410 4>
        align 32 symtab 0 alias set -1 canonical type 0x7ffff1f235e8
        domain <integer_type 0x7ffff2055690 type <integer_type 0x7ffff2042000 long unsigned int>
            DI
            size <integer_cst 0x7ffff202d7d0 constant 64>
            unit size <integer_cst 0x7ffff202d7f8 constant 8>
            align 64 symtab 0 alias set -1 canonical type 0x7ffff2055690 precision 64 min <integer_cst 0x7ffff202d438 0> max <integer_cst 0x7ffff202d438 0>>>
    constant static lngt 1
    idx <integer_cst 0x7ffff202db40 type <integer_type 0x7ffff20420a8 bit_size_type> constant 0>
    val <integer_cst 0x7ffff202d6e0 type <integer_type 0x7ffff2042540 unsigned int> constant 4294967295>>

When ccp propagates b[0] into the comparison, the comparison uses T on one side and unsigned int on the other side.  When b has T type, ccp doesn't optimize the ... < 4294967295 comparison into ... != 4294967295, while when b has unsigned int type, it does.
T's TYPE_MAIN_VARIANT is unsigned int.
So, it isn't clear if the middle-end is considering the two types as incompatible or what.
Comment 4 Jakub Jelinek 2010-07-26 14:15:21 UTC
The reassoc issue is caused by http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159189

BTW, the C++ FE uses T instead of unsigned type for values in the ctor and thus the testcase works there.
Comment 5 Jakub Jelinek 2010-08-24 17:26:31 UTC
Created attachment 21557 [details]
gcc46-pr45059.patch

Untested fix.
Comment 6 Jakub Jelinek 2010-08-25 09:37:02 UTC
Subject: Bug 45059

Author: jakub
Date: Wed Aug 25 09:36:35 2010
New Revision: 163539

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=163539
Log:
	PR tree-optimization/45059
	* tree-ssa-reassoc.c (eliminate_redundant_comparison): Strip useless
	type conversions from newop{1,2}.  Assert t is a comparison and
	newop{1,2} after the stripping are gimple vals.

	* gcc.c-torture/compile/pr45059.c: New test.

Added:
    trunk/gcc/testsuite/gcc.c-torture/compile/pr45059.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/tree-ssa-reassoc.c

Comment 7 Jakub Jelinek 2010-08-25 09:50:01 UTC
Fixed.