[Bug c++/37146] New: ICE - Compiler segfaults

[Bug c++/37146] New: ICE - Compiler segfaults

[springl-gcc at bfw-online dot de]

g++ from snapshot gcc-4.4-20080815.tar.bz2 gives

v.cc: In member function 'kostenbezug_e
verteilung_c::bezug_ausrechnen(kostenbezug_e) const':
v.cc:12: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.

on this program:
-------------------------------------------------------------------------
enum kostenbezug_e
{ kostenbezug_keiner = 0,
  kostenbezug_einheitlich = 'E',
};

struct verteilung_c
{ kostenbezug_e bezug: 8;
  enum kostenbezug_e bezug_ausrechnen (kostenbezug_e) const;
};

kostenbezug_e
verteilung_c::bezug_ausrechnen (kostenbezug_e b) const
{ return bezug && bezug != kostenbezug_einheitlich? bezug: b;
}
-------------------------------------------------------------------------
when called as
  g++ -O2 -c -o v.o v.cc

This is running on Linux version 2.6.26.2, glibc 2.6.1.
gcc was configured using:
  configure --prefix=/scratch/gcc/4.4-2008-08-08 --enable-shared \
    --enable-languages=all --with-sysroot=/usr/i686-pc-linux-gnulibc2


-- 
           Summary: ICE - Compiler segfaults
           Product: gcc
           Version: 4.4.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: springl-gcc at bfw-online dot de
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


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

[Bug c++/37146] [4.4 Regression] Invalid types with COND_EXPR

[rguenth at gcc dot gnu dot org]

------- Comment #1 from rguenth at gcc dot gnu dot org  2008-08-18 12:16 -------
confirmed.

#0  0x0000000000bca7e9 in bitmap_insert_into_set_1 (set=0x0, expr=0x1621e58, 
    allow_constants=0 '\0')
    at /space/rguenther/src/svn/trunk/gcc/tree-ssa-pre.c:640
#1  0x0000000000bca82d in bitmap_insert_into_set (set=0x0, expr=0x1621e58)
    at /space/rguenther/src/svn/trunk/gcc/tree-ssa-pre.c:650
#2  0x0000000000bcb036 in bitmap_value_replace_in_set (set=0x0, expr=0x1621e58)
    at /space/rguenther/src/svn/trunk/gcc/tree-ssa-pre.c:846
#3  0x0000000000bd1162 in create_expression_by_pieces (block=0x7ffff7597b40, 
    expr=0x1621d18, stmts=0x7fffffffd7d8, domstmt=0x7ffff7eb7f50, 
    type=0x7ffff758f540)
    at /space/rguenther/src/svn/trunk/gcc/tree-ssa-pre.c:2820
#4  0x0000000000bd0c5f in find_or_generate_expression (block=0x7ffff7597b40, 
    expr=0x1621dd8, stmts=0x7fffffffd7d8, domstmt=0x7ffff7eb7f50)
    at /space/rguenther/src/svn/trunk/gcc/tree-ssa-pre.c:2682
#5  0x0000000000bd0f78 in create_expression_by_pieces (block=0x7ffff7597b40, 
    expr=0x1621e38, stmts=0x7fffffffd7d8, domstmt=0x7ffff7eb7f50, type=0x0)
    at /space/rguenther/src/svn/trunk/gcc/tree-ssa-pre.c:2777
#6  0x0000000000bd4409 in do_SCCVN_insertion (stmt=0x7ffff7eb7f50, 
    ssa_vn=0x7ffff759bb60)
    at /space/rguenther/src/svn/trunk/gcc/tree-ssa-pre.c:3761
#7  0x0000000000bd4816 in eliminate ()
    at /space/rguenther/src/svn/trunk/gcc/tree-ssa-pre.c:3853
#8  0x0000000000bd5c0a in execute_pre (do_fre=1 '\001')

3848                      tree val = VN_INFO (lhs)->valnum;
3849                      if (val != VN_TOP
3850                          && TREE_CODE (val) == SSA_NAME
3851                          && VN_INFO (val)->needs_insertion
3852                          && can_PRE_operation (vn_get_expr_for (val)))
3853                        sprime = do_SCCVN_insertion (stmt, val);
3854                    }
3855                  if (sprime
3856                      && sprime != lhs
3857                      && (rhs == NULL_TREE
(gdb) call VN_INFO (val)
$1 = (struct vn_ssa_aux *) 0x1604aa0
(gdb) print *$1
$2 = {valnum = 0x7ffff759bb60, expr = 0x7ffff7599f00, value_id = 10, 
  dfsnum = 0, low = 0, visited = 0, on_sccstack = 0, has_constants = 0, 
  use_processed = 0, needs_insertion = 1}
(gdb) call debug_generic_expr (0x7ffff7599f00)
VIEW_CONVERT_EXPR<const unsigned char>(b_8)

b_8 is an enum of precision 32 (and thus not folded to a NOP_EXPR by fold).

But it looks like we miss a conversion and thus have an IL with invalid types
here from the start.

((const struct verteilung_c *) this)->bezug != 0 && ((const struct verteilung_c
*) this)->bezug != 69 ? ((const struct verteilung_c *) this)->bezug : b

 <cond_expr 0x7ffff7ec1780
    type <enumeral_type 0x7ffff758f540 kostenbezug_e unsigned SI
...
    arg 0 <truth_and_expr 0x7ffff75993c0
        type <boolean_type 0x7ffff7ebbb40 bool public unsigned QI
...
    arg 1 <component_ref 0x7ffff7ec1730
        type <integer_type 0x7ffff758fe40 unsigned char readonly public
unsigned string-flag QI size <integer_cst 0x7ffff7eb97b0 8> unit size
<integer_cst 0x7ffff7eb97e0 1>
...
    arg 2 <parm_decl 0x7ffff7ec2bd0 b type <enumeral_type 0x7ffff758f540
kostenbezug_e>
...

with

 <enumeral_type 0x7ffff758f540 kostenbezug_e unsigned SI
    size <integer_cst 0x7ffff7eb9a50 type <integer_type 0x7ffff7ebb240
bit_size_type> constant 32>


which leads to invalid types after gimplification already.  4.3 is not
affected by the ICE.

The type-verifier is basically disabled on the trunk ... :/


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
           Keywords|                            |ice-on-valid-code, wrong-
                   |                            |code
      Known to work|                            |4.3.2
   Last reconfirmed|0000-00-00 00:00:00         |2008-08-18 12:16:21
               date|                            |
            Summary|ICE - Compiler segfaults    |[4.4 Regression] Invalid
                   |                            |types with COND_EXPR
   Target Milestone|---                         |4.4.0


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

[Bug c++/37146] [4.4 Regression] Invalid types with COND_EXPR

[rguenth at gcc dot gnu dot org]

------- Comment #2 from rguenth at gcc dot gnu dot org  2008-08-18 12:16 -------
Fixing it yields

t.i: In member function 'kostenbezug_e
verteilung_c::bezug_ausrechnen(kostenbezug_e) const':
t.i:12: error: non-trivial conversion at assignment
iftmp.0
this->bezug
iftmp.0 = this->bezug;

t.i:12: internal compiler error: verify_gimple failed
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.


-- 


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

[Bug c++/37146] [4.4 Regression] Invalid types with COND_EXPR

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P1


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

[Bug c++/37146] [4.4 Regression] Invalid types with COND_EXPR

[jakub at gcc dot gnu dot org]

------- Comment #3 from jakub at gcc dot gnu dot org  2008-09-01 12:40 -------
This is a C++ FE bug.  Shorter testcase:
enum E { E0 = 0, E1 = 'E' };

struct S
{
  E s0 : 8;
  enum E foo (bool, E);
};

E S::foo (bool a, E b)
{
  return a ? s0 : b;
}

The bug is IMHO in build_conditional_expr.  One of:
  arg2_type = unlowered_expr_type (arg2);
  arg3_type = unlowered_expr_type (arg3);
calls returns a different type from TREE_TYPE (argX), as that's bitfield
COMPONENT_REF.  Neither of the types are void and neither is class type, so
nothing is converted first and we reach:
  /* [expr.cond]

     If the second and third operands are lvalues and have the same
     type, the result is of that type and is an lvalue.  */
  if (real_lvalue_p (arg2)
      && real_lvalue_p (arg3)
      && same_type_p (arg2_type, arg3_type))
    {
      result_type = arg2_type;
      goto valid_operands;
    }
where arg2_type is the same as arg3_type, but TREE_TYPE (arg2) != TREE_TYPE
(arg3), not even useless type conversion, and at valid_operands we build it
right away as COND_EXPR.  Can x ? bitfield : val be even considered as valid
lvalue by C++ standard (I mean e.g. bitfield can have different number of bits
from val)?  If we don't shortcut here, force_rvalue is called on both arguments
and that will call the needed convert_bitfield_to_declared_type somewhere.
E.g.:
--- call.c.jj2008-08-29 18:23:10.000000000 +0200
+++ call.c2008-09-01 14:27:24.000000000 +0200
@@ -3596,7 +3596,9 @@ build_conditional_expr (tree arg1, tree 
      type, the result is of that type and is an lvalue.  */
   if (real_lvalue_p (arg2)
       && real_lvalue_p (arg3)
-      && same_type_p (arg2_type, arg3_type))
+      && same_type_p (arg2_type, arg3_type)
+      && is_bitfield_expr_with_lowered_type (arg2) == NULL_TREE
+      && is_bitfield_expr_with_lowered_type (arg3) == NULL_TREE)
     {
       result_type = arg2_type;
       goto valid_operands;
cures this testcase, but I'm not sure if it is correct from C++ standard POV.


-- 

jakub at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jason at gcc dot gnu dot org


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

[Bug c++/37146] [4.4 Regression] Invalid types with COND_EXPR

[dodji at gcc dot gnu dot org]

-- 

dodji at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |dodji at gcc dot gnu dot org
                   |dot org                     |
             Status|NEW                         |ASSIGNED
   Last reconfirmed|2008-08-18 12:16:21         |2008-09-09 14:12:29
               date|                            |


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

[Bug c++/37146] [4.4 Regression] Invalid types with COND_EXPR

[dodji at gcc dot gnu dot org]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1564 bytes --]



------- Comment #4 from dodji at gcc dot gnu dot org  2008-09-10 14:50 -------
At PDF page 115, 5.16.6 (conditional operator), the standard says:

"Lvalue-to-rvalue (4.1), array-to-pointer (4.2), and function-to-pointer (4.3)
standard conversions are performed on the second and third operands. After
those conversions, one of the following shall hold:"

— The second and third operands have the same type; the result is of that type.

— The second and third operands have arithmetic or enumeration type; the usual
arithmetic conversions are performed to bring them to a common type, and the
result is of that type.

[...]
"

We should actualy fall into the case of "the second and third operands have
arithmetic or enumeration type ...", but we are not. And that is the bug, I
think.

Instead, we are considering earlier that arg2 and arg3 have the same type --
which I believe is not true. We are considering that because the condition
if (real_lvalue_p (arg2)                                                     
      && real_lvalue_p (arg3)                                                  
      && same_type_p (arg2_type, arg3_type))                                   
    {
[...]
is true.

We are considering that arg2 and arg3 have the same type because we think
same_type_p (arg2_type, arg3_type) should be enough to determine their type
equality. But in this particular case, it's not because arg2_type and arg3_type
lost the information about the bit-field type and size of arg2 and arg3.


-- 


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

[Bug c++/37146] [4.4 Regression] Invalid types with COND_EXPR

[dodji at gcc dot gnu dot org]

-- 

dodji at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|dodji at gcc dot gnu dot org|unassigned at gcc dot gnu
                   |                            |dot org
             Status|ASSIGNED                    |NEW


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

[Bug c++/37146] [4.4 Regression] Invalid types with COND_EXPR

[jakub at gcc dot gnu dot org]

------- Comment #5 from jakub at gcc dot gnu dot org  2008-09-10 15:10 -------
I think primarily we want to agree on what is and is not valid lvalue when
bitfields are involved.

int a;
int b;
struct A { int i:8; int j:8; int k:16; int l:32; } c;

void
foo (int x, int y)
{
  (x ? a : b) = y;
  (x ? c.i : c.j) = y;  // error with #c3 patch
  (x ? c.i : a) = y;    // error with #c3 and #c5 patch
  (x ? c.i : c.k) = y;  // error with #c3 and #c5 patch
#if __INT_MAX__ == 2147483647
  (x ? c.l : b) = y;
#endif
}

If all are supposed to be valid, then I fixing this is going to be hard.  We'll
need to create COND_EXPR with mismatching types and then fix it up immediately
once we figure out the COND_EXPR isn't used as lvalue.

The #c3 patch is above, I'll attach another patch as well which allows
bitfields
if they have the same declared type and precision.


-- 


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

[Bug c++/37146] [4.4 Regression] Invalid types with COND_EXPR

[jakub at gcc dot gnu dot org]

------- Comment #6 from jakub at gcc dot gnu dot org  2008-09-10 15:11 -------
Created an attachment (id=16286)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16286&action=view)
a different patch


-- 


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

[Bug c++/37146] [4.4 Regression] Invalid types with COND_EXPR

[jakub at gcc dot gnu dot org]

------- Comment #7 from jakub at gcc dot gnu dot org  2008-09-10 15:21 -------
If the whole testcase is supposed to be valid, we could have COND_EXPRs with
mismatching types in the FE and fix them up only during cp_genericize_r.
The ugly thing is that we'd violate:
   Operand 1 must have the same type as the entire expression, unless
   it unconditionally throws an exception, in which case it should
   have VOID_TYPE.  The same constraints apply to operand 2.  The
   condition in operand 0 must be of integral type.
constraints when in the FE.


-- 


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

[Bug c++/37146] [4.4 Regression] Invalid types with COND_EXPR

[rguenth at gcc dot gnu dot org]

------- Comment #8 from rguenth at gcc dot gnu dot org  2008-09-10 16:25 -------
These constraints are supposed to be valid when in gimple, not generic.  Maybe
the documentation in tree.def should reflect that (there is no generic type
system, if there was, it would be the much stricter that fold expects/produces)


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rguenth at gcc dot gnu dot
                   |                            |org


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

[Bug c++/37146] [4.4 Regression] Invalid types with COND_EXPR

[dodji at gcc dot gnu dot org]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1000 bytes --]



------- Comment #9 from dodji at gcc dot gnu dot org  2008-09-11 07:56 -------
@Jakub:

* I think (x ? c.i : c.j) = y; should be valid. because we then fall into the
item 4 of the spec, PDF page 115, section 5.16: Conditional operator which
reads:

"If the second and third operands are lvalues and have the same type, the
result is of that type and is an lvalue"


* (x ? c.i : a) = y; should not be valid because we fall into the item 5 that
says:
"Otherwise, the result is an rvalue".
Then we fall into item 6:

"Lvalue-to-rvalue (4.1), array-to-pointer (4.2), and function-to-pointer (4.3)
standard conversions are performed on the second and third operands. After
those conversions, one of the following shall hold:
  — The second and third operands have the same type; the result is of that
type.
"
So after this point, the result is an rvalue. So the assignation becomes
invalid.

* (x ? c.i : c.k) = y; Should be invalid as well.


-- 


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

[Bug c++/37146] [4.4 Regression] Invalid types with COND_EXPR

[dodji at gcc dot gnu dot org]

------- Comment #10 from dodji at gcc dot gnu dot org  2008-09-11 16:40 -------
Created an attachment (id=16293)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16293&action=view)
another patch that fixes the problem.

This patch proposes a fix for the problem and complies with my comment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37146#c9 .


-- 


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

[Bug c++/37146] [4.4 Regression] Invalid types with COND_EXPR

[jakub at gcc dot gnu dot org]

------- Comment #11 from jakub at gcc dot gnu dot org  2008-09-15 10:41 -------
Your #c10 patch looks good to me if the #c9 answers are right, but please also
add the #c3 testcase to the patch (as a separate testcase, because we want to
compile that one all the way through) and post it to gcc-patches.  Thanks.


-- 


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

[Bug c++/37146] [4.4 Regression] Invalid types with COND_EXPR

[dodji at gcc dot gnu dot org]

------- Comment #12 from dodji at gcc dot gnu dot org  2008-09-15 14:49 -------
Created an attachment (id=16323)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16323&action=view)
same patch with C3 testcase

@jakub: Okay, I have augmented the patch with the c3 testcase, as you
suggested.
I will send it to gcc-patches.
Thanks.


-- 

dodji at gcc dot gnu dot org changed:

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


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

[Bug c++/37146] [4.4 Regression] Invalid types with COND_EXPR

[mmitchel at gcc dot gnu dot org]

------- Comment #13 from mmitchel at gcc dot gnu dot org  2008-09-23 18:38 -------
The C++ WP draft I have (a bit old) says:

If the second and third operands are lvalues and have the same type, the result
is of that type and is an lvalue and it is a bit-field if the second or the
third operand is a bit-field, or if both are bit-fields.

So, I don't see why:

> (x ? c.i : a) = y; should not be valid 

In C++, "type" does not include the number of bits in the bit-field.  

I think think the expression "x ? c.i : a" is an lvalue bit-field of type
"int".

On that basis, I think the gimplifier (including C++-specific hooks thereto)
should handle converting down to whatever representation GENERIC requires.  

I'd expect something like:

  t = SAVE_EXPR (y), 
   x ? (c.i = (int-of-N-bits) t) : (a = t), 
   t

We could also do this in the FE proper (before GENERIC) if required; we would
fix up the conditional expression after working out whether it's being used as
an lvalue or an rvalue.


-- 

mmitchel at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mmitchel at gcc dot gnu dot
                   |                            |org


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

[Bug c++/37146] [4.4 Regression] Invalid types with COND_EXPR

[pinskia at gcc dot gnu dot org]

------- Comment #14 from pinskia at gcc dot gnu dot org  2008-09-30 16:24 -------
*** Bug 37682 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |holger dot hopp at sap dot
                   |                            |com


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

[Bug c++/37146] [4.4 Regression] Invalid types with COND_EXPR

[jakub at gcc dot gnu dot org]

------- Comment #15 from jakub at gcc dot gnu dot org  2008-10-10 08:13 -------
Testing a patch.


-- 

jakub at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |jakub at gcc dot gnu dot org
                   |dot org                     |
             Status|NEW                         |ASSIGNED
   Last reconfirmed|2008-09-09 14:12:29         |2008-10-10 08:13:21
               date|                            |


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

[Bug c++/37146] [4.4 Regression] Invalid types with COND_EXPR

[jakub at gcc dot gnu dot org]

------- Comment #16 from jakub at gcc dot gnu dot org  2008-10-10 18:23 -------
Subject: Bug 37146

Author: jakub
Date: Fri Oct 10 18:22:17 2008
New Revision: 141045

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141045
Log:
        PR c++/37146
        * cp-gimplify.c (cp_genericize_r): Fix up bitfield operands of
        COND_EXPR.

        * g++.dg/torture/pr37146-1.C: New test.
        * g++.dg/torture/pr37146-2.C: New test.
        * g++.dg/expr/bitfield10.C: New test.

Added:
    trunk/gcc/testsuite/g++.dg/expr/bitfield10.C
    trunk/gcc/testsuite/g++.dg/torture/pr37146-1.C
    trunk/gcc/testsuite/g++.dg/torture/pr37146-2.C
Modified:
    trunk/gcc/cp/ChangeLog
    trunk/gcc/cp/cp-gimplify.c
    trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug c++/37146] [4.4 Regression] Invalid types with COND_EXPR

[jakub at gcc dot gnu dot org]

------- Comment #17 from jakub at gcc dot gnu dot org  2008-10-10 19:01 -------
Fixed.


-- 

jakub at gcc dot gnu dot org changed:

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


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