[Bug c/30338] New: Segmentation fault for legal code with -Os -m32

[Bug c/30338] New: Segmentation fault for legal code with -Os -m32

[dcb314 at hotmail dot com]

I just tried to compile Suse package grub-0.97-40
with the new GNU C compiler version 4.3 snapshot 20061230.

The compiler said

gcc: Internal error: Segmentation fault (program cc1)
Please submit a full bug report.
See <URL:http://gcc.gnu.org/bugs.html> for instructions.

Here is some help from valgrind

==3736== Stack overflow in thread 1: can't grow stack to 0x7FE001F04
==3736== Can't extend stack to 0x7FE0015E0 during signal delivery for thread 1:
==3736==   no stack segment
==3736==
==3736== Process terminating with default action of signal 11 (SIGSEGV)
==3736==  Access not within mapped region at address 0x7FE0015E0
==3736==    at 0x611927: fold_comparison (fold-const.c:7950)
==3736== Invalid write of size 8
==3736==    at 0x4A1E348: _vgnU_freeres (in
/usr/lib64/valgrind/amd64-linux/vgpreload_core.so)
==3736==  Address 0x7FE001E48 is on thread 1's stack
==3736== Stack overflow in thread 1: can't grow stack to 0x7FE001E48
==3736==
==3736== Process terminating with default action of signal 11 (SIGSEGV)
==3736==  Access not within mapped region at address 0x7FE001E48
==3736==    at 0x4A1E348: _vgnU_freeres (in
/usr/lib64/valgrind/amd64-linux/vgpreload_core.so)

Preprocessed source code attached. Flags -Os -m32 required.


-- 
           Summary: Segmentation fault for legal code with -Os -m32
           Product: gcc
           Version: 4.3.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: dcb314 at hotmail dot com
  GCC host triplet: x86_64-suse-linux


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30338

[Bug c/30338] Segmentation fault for legal code with -Os -m32

[dcb314 at hotmail dot com]

------- Comment #1 from dcb314 at hotmail dot com  2006-12-31 11:40 -------
Created an attachment (id=12849)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12849&action=view)
C source code


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30338

[Bug middle-end/30338] [4.3 Regression] infinite loop in maybe_canonicalize_comparison

[pinskia at gcc dot gnu dot org]

------- Comment #2 from pinskia at gcc dot gnu dot org  2006-12-31 11:51 -------
#97 0x00453a30 in maybe_canonicalize_comparison_1 (code=GE_EXPR,
type=0x42615540, arg0=0x1057ce0, arg1=0x1056de0) at ../../gcc/fold-const.c:7905
#98 0x00453ca8 in maybe_canonicalize_comparison (code=GT_EXPR, type=0x42615540,
arg0=0x1056de0, arg1=0x1057ce0) at ../../gcc/fold-const.c:7937
#99 0x00456704 in fold_comparison (code=LT_EXPR, type=0x42615540,
op0=0x1056de0, op1=0x1057ce0) at ../../gcc/fold-const.c:8068
#100 0x0048ba4c in fold_binary (code=LT_EXPR, type=0x42615540, op0=0x1056de0,
op1=0x1057ce0) at ../../gcc/fold-const.c:10990
#101 0x0049580c in fold_build2_stat (code=LT_EXPR, type=0x42615540,
op0=0x1056de0, op1=0x1057ce0) at ../../gcc/fold-const.c:12079
#102 0x00453a50 in maybe_canonicalize_comparison_1 (code=LT_EXPR,
type=0x42615540, arg0=0x1056db0, arg1=0x1057ce0) at ../../gcc/fold-const.c:7907
#103 0x00453c64 in maybe_canonicalize_comparison (code=LE_EXPR,
type=0x42615540, arg0=0x1056db0, arg1=0x1057ce0) at ../../gcc/fold-const.c:7930
#104 0x00456704 in fold_comparison (code=LE_EXPR, type=0x42615540,
op0=0x1056db0, op1=0x1057ce0) at ../../gcc/fold-const.c:8068
#105 0x0048ba4c in fold_binary (code=LE_EXPR, type=0x42615540, op0=0x1056db0,
op1=0x1057ce0) at ../../gcc/fold-const.c:10990


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |ice-on-valid-code
            Summary|Segmentation fault for legal|[4.3 Regression] infinite
                   |code with -Os -m32          |loop in
                   |                            |maybe_canonicalize_compariso
                   |                            |n
   Target Milestone|---                         |4.3.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30338

[Bug middle-end/30338] [4.3 Regression] infinite loop in maybe_canonicalize_comparison

[rguenth at gcc dot gnu dot org]

------- Comment #3 from rguenth at gcc dot gnu dot org  2006-12-31 11:57 -------
Mine.  Reducing.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |rguenth at gcc dot gnu dot
                   |dot org                     |org
             Status|UNCONFIRMED                 |ASSIGNED
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2006-12-31 11:57:01
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30338

[Bug middle-end/30338] [4.3 Regression] infinite loop in maybe_canonicalize_comparison

[rguenth at gcc dot gnu dot org]

------- Comment #4 from rguenth at gcc dot gnu dot org  2006-12-31 12:28 -------
Reduced testcase:

extern char *grub_scratch_mem;
int testload_func (char *arg, int flags)
{
  int i;
  for (i = 0; i < 0x10ac0; i++)
    if (*((unsigned char *) ((0x200000 + i) + (int) grub_scratch_mem))
        != *((unsigned char *) ((0x300000 + i) + (int) grub_scratch_mem)))
      return 0;
  return 1;
}


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30338

[Bug middle-end/30338] [4.3 Regression] infinite loop in maybe_canonicalize_comparison

[rguenth at gcc dot gnu dot org]

------- Comment #5 from rguenth at gcc dot gnu dot org  2006-12-31 12:57 -------
It starts as we try to fold

  ~(grub_scratch_mem.1_5 + 2097152) > 2147483647

from n_of_executions_at_most.  The problem is we have here already
a type-mismatch:

(gdb) call debug_tree (op0)
 <bit_not_expr 0xb7c20720
    type <integer_type 0xb7b9a2e0 unsigned int public unsigned SI
        size <integer_cst 0xb7b893f0 constant invariant 32>
        unit size <integer_cst 0xb7b89180 constant invariant 4>
        align 32 symtab 0 alias set -1 precision 32 min <integer_cst 0xb7b89468
0> max <integer_cst 0xb7b89450 4294967295>>

    arg 0 <plus_expr 0xb7b909fc
        type <integer_type 0xb7b9a284 int sizes-gimplified public SI size
<integer_cst 0xb7b893f0 32> unit size <integer_cst 0xb7b89180 4>
            align 32 symtab 0 alias set -1 precision 32 min <integer_cst
0xb7b893a8 -2147483648> max <integer_cst 0xb7b893c0 2147483647>
            pointer_to_this <pointer_type 0xb7b9ac38>>

        arg 0 <ssa_name 0xb7c237b0 type <integer_type 0xb7b9a284 int>
            visited var <var_decl 0xb7b95210 grub_scratch_mem.1> def_stmt
<gimple_modify_stmt 0xb7c27438>
            version 5>
        arg 1 <integer_cst 0xb7c27348 constant invariant 2097152>>>

(unsigned BIT_NOT_EXPR with signed argument.)

We get that from scev_probably_wraps_p () at

      tree extreme = fold_convert (unsigned_type,
                                   upper_bound_in_type (type, type));
      delta = fold_build2 (MINUS_EXPR, unsigned_type, extreme, base);
      step_abs = fold_convert (unsigned_type, step);

through fold_binary

      /* Convert -1 - A to ~A.  */
      if (INTEGRAL_TYPE_P (type)
          && integer_all_onesp (arg0))
        return fold_build1 (BIT_NOT_EXPR, type, arg1);

(that needs to read

        return fold_build1 (BIT_NOT_EXPR, type, op1);

at least, which fixes this PR)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30338

[Bug middle-end/30338] [4.3 Regression] infinite loop in maybe_canonicalize_comparison

[rguenth at gcc dot gnu dot org]

------- Comment #6 from rguenth at gcc dot gnu dot org  2006-12-31 14:05 -------
Fixed.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30338

[Bug middle-end/30338] [4.3 Regression] infinite loop in maybe_canonicalize_comparison

[pinskia at gcc dot gnu dot org]

------- Comment #7 from pinskia at gcc dot gnu dot org  2006-12-31 16:49 -------
(In reply to comment #5)
> (that needs to read
> 
>         return fold_build1 (BIT_NOT_EXPR, type, op1);

No it should read:
return fold_build1 (BIT_NOT_EXPR, type, fold_convert (type, arg1) );

There are a couple more issues like this in fold-const.c with BIT_NOT_EXPR
folding.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30338

[Bug middle-end/30338] [4.3 Regression] infinite loop in maybe_canonicalize_comparison

[bergner at gcc dot gnu dot org]

------- Comment #8 from bergner at gcc dot gnu dot org  2010-07-08 21:50 -------
The test case that was added to the testsuite (pr30338.c) ICE's on
powerpc64-linux with the following options: -Os -m64

Looking at a backtrace, we're hitting this assert in tree.c:build2_stat():

  if (code == POINTER_PLUS_EXPR && arg0 && arg1 && tt)
    gcc_assert (POINTER_TYPE_P (tt) && POINTER_TYPE_P (TREE_TYPE (arg0))
                && INTEGRAL_TYPE_P (TREE_TYPE (arg1))
                && useless_type_conversion_p (sizetype, TREE_TYPE (arg1)));

gdb shows this:

(gdb) frame 1
#1  0x000000001066de84 in build2_stat (code=POINTER_PLUS_EXPR,
tt=0x40000410000, arg0=0x400005112e8, arg1=0x400003104b0)
    at /home/bergner/gcc/gcc-mainline-r161924/gcc/tree.c:3715
3715        gcc_assert (POINTER_TYPE_P (tt) && POINTER_TYPE_P (TREE_TYPE
(arg0))
(gdb) call debug_tree(tt)
 <integer_type 0x40000410000 long unsigned int public unsigned sizetype DI
    size <integer_cst 0x40000310780 type <integer_type 0x400004100a8
bit_size_type> constant 64>
    unit size <integer_cst 0x400003107a8 type <integer_type 0x40000410000 long
unsigned int> constant 8>
    align 64 symtab 0 alias set -1 canonical type 0x40000410000 precision 64
min <integer_cst 0x400003107d0 0> max <integer_cst 0x40000310aa0 -1>>
(gdb) call debug_tree(arg0)
 <ssa_name 0x400005112e8
    type <integer_type 0x40000410000 long unsigned int public unsigned sizetype
DI
        size <integer_cst 0x40000310780 constant 64>
        unit size <integer_cst 0x400003107a8 constant 8>
        align 64 symtab 0 alias set -1 canonical type 0x40000410000 precision
64 min <integer_cst 0x400003107d0 0> max <integer_cst 0x40000310aa0 -1>>
    visited var <var_decl 0x400004f1fe0 D.2060>def_stmt D.2060_43 = ivtmp.27_37
+ D.2059_42;

    version 43>
(gdb) call debug_tree(arg1)
 <integer_cst 0x400003104b0 type <integer_type 0x40000410000 long unsigned int>
constant 1>


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30338

[Bug middle-end/30338] [4.3 Regression] infinite loop in maybe_canonicalize_comparison

[rguenther at suse dot de]

------- Comment #9 from rguenther at suse dot de  2010-07-09 08:10 -------
Subject: Re:  [4.3 Regression] infinite loop in
 maybe_canonicalize_comparison

On Thu, 8 Jul 2010, bergner at gcc dot gnu dot org wrote:

> ------- Comment #8 from bergner at gcc dot gnu dot org  2010-07-08 21:50 -------
> The test case that was added to the testsuite (pr30338.c) ICE's on
> powerpc64-linux with the following options: -Os -m64
> 
> Looking at a backtrace, we're hitting this assert in tree.c:build2_stat():
> 
>   if (code == POINTER_PLUS_EXPR && arg0 && arg1 && tt)
>     gcc_assert (POINTER_TYPE_P (tt) && POINTER_TYPE_P (TREE_TYPE (arg0))
>                 && INTEGRAL_TYPE_P (TREE_TYPE (arg1))
>                 && useless_type_conversion_p (sizetype, TREE_TYPE (arg1)));

ICEs on trunk?  If so please open a new bugreport.

Thanks,
Richard.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30338

[Bug middle-end/30338] [4.3 Regression] infinite loop in maybe_canonicalize_comparison

[bergner at gcc dot gnu dot org]

------- Comment #10 from bergner at gcc dot gnu dot org  2010-07-09 14:37 -------
Yes, it ICE's on trunk.  I just opened PR44890 for the new ICE.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30338