[Bug middle-end/20995] New: [3.4 regression] ICE in const_binop, at fold-const.c:1391

[Bug middle-end/20995] New: [3.4 regression] ICE in const_binop, at fold-const.c:1391

[bangerth at dealii dot org]

This little piece of code here
-----------------
template <int dim>
void test ()
{
  double d;
  double mu = 1;
  for (unsigned int i=0; i<dim; ++i)
    for (unsigned int j=0; j<dim; ++j)
      for (unsigned int k=0; k<dim; ++k)
        for (unsigned int l=0; l<dim; ++l)
          d = (((i==k) && (j==l) ? mu : 0) +
               ((i==j) && (k==l) ? 1 : 0));
}
template void test<3> ();
-----------------
ICEs with gcc3.4.4pre (and apparently all older versions of the 3.4.x branch I
have):

deal.II/tests> /ices/bangerth/tmp/build-gcc-3.4/gcc-install/bin/c++ -c x.cc
x.cc: In function `void test()':
x.cc:11: internal compiler error: tree check: expected real_cst, have
integer_cst in const_binop, at fold-const.c:1391
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://gcc.gnu.org/bugs.html> for instructions.

On the machine I'm on right now, I don't have a 4.x compiler, so it may even be
a regression on 4.0 branch and/or mainline. It doesn't ICE gcc3.3.x, though.

W.

-- 
           Summary: [3.4 regression] ICE in const_binop, at fold-
                    const.c:1391
           Product: gcc
           Version: 3.4.4
            Status: UNCONFIRMED
          Keywords: ice-on-valid-code
          Severity: normal
          Priority: P2
         Component: middle-end
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: bangerth at dealii dot org
                CC: gcc-bugs at gcc dot gnu dot org


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

[Bug middle-end/20995] [3.4 regression] ICE in const_binop, at fold-const.c:1391

[bangerth at dealii dot org]

------- Additional Comments From bangerth at dealii dot org  2005-04-13 15:29 -------
Note that it isn't related to PR 19899, even though the failure seems similar.

I should also note that the ICE happened with a compiler that had checking enabled.
If checking is disabled, we simply get this:

deal.II/tests> $HOME/bin/gcc-3.4/bin/c++ -c x.cc
x.cc: In function `void test()':
x.cc:11: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://gcc.gnu.org/bugs.html> for instructions.

W.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to fail|                            |3.4.2 3.4.4
      Known to work|                            |3.3.2


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

[Bug middle-end/20995] [3.4 regression] ICE in const_binop, at fold-const.c:1391

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-04-13 17:50 -------
It does not ICE with "3.4.0 20040116" but does with "3.4.0 (release)".

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|                            |1
      Known to fail|3.4.2 3.4.4                 |3.4.2 3.4.4 3.4.0
      Known to work|3.3.2                       |3.3.2 4.0.0 4.1.0
   Last reconfirmed|0000-00-00 00:00:00         |2005-04-13 17:50:06
               date|                            |
   Target Milestone|---                         |3.4.4


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

[Bug middle-end/20995] [3.4 regression] ICE in const_binop, at fold-const.c:1391

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-04-13 18:59 -------
: Search converges between 2004-01-25-trunk (#440) and 2004-01-26-trunk (#441).
: Search converges between 2004-05-20-trunk (#457) and 2004-05-23-trunk (#458).

Looking at the construct, I almost want to say this was "fixed" by:
2004-05-20  Roger Sayle  <roger@eyesopen.com>

        PR middle-end/3074
        * fold-const.c (strip_compound_expr): Delete function.
        (count_cond): Delete function.
        (fold_binary_op_with_conditional_arg): Only perform transformations
        "a + (b?c:d) -> b ? a+c : a+d" and "(b?c:d) + a -> b ? c+a : d+a"
        when a is constant.  This greatly simplifies this routine.


-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |roger at eyesopen dot com


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

[Bug middle-end/20995] [3.4 regression] ICE in const_binop, at fold-const.c:1391

[reichelt at gcc dot gnu dot org]

------- Additional Comments From reichelt at gcc dot gnu dot org  2005-04-14 08:39 -------
Shorter testcase:

======================================
template<int N> void foo()
{
    double d = (N ? 0.0 : 0) + 1;
}
======================================


-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |reichelt at gcc dot gnu dot
                   |                            |org
           Keywords|                            |monitored


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

[Bug middle-end/20995] [3.4 regression] ICE in const_binop, at fold-const.c:1391

[roger at eyesopen dot com]

------- Additional Comments From roger at eyesopen dot com  2005-04-23 16:24 -------
This is actually a C++ front-end bug.  It looks like on the 3.4 branch
ocp_convert is calling "fold" instead of "fold_if_not_in_template" (which
is what happens on mainline).  This call to "fold" triggers a chain reaction
that eventually leads to mismatched types in a COND_EXPR, but not before
over-writing memory first!

I'll try and track down and backport the mainline C++ patch which solves
this issue.


-- 


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

[Bug c++/20995] [3.4 regression] ICE in const_binop, at fold-const.c:1391

[roger at eyesopen dot com]

------- Additional Comments From roger at eyesopen dot com  2005-04-23 16:57 -------
Don't know what happened there; this should be component "c++"!

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|driver                      |c++


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

[Bug driver/20995] [3.4 regression] ICE in const_binop, at fold-const.c:1391

[roger at eyesopen dot com]

------- Additional Comments From roger at eyesopen dot com  2005-04-23 16:56 -------
Doh, fold_if_not_in_template is not on the gcc 3.4 branch.  It was introduced
to fix (workaround?) PR c++/17642, which looks too intrusive for the 3.4 branch.

Instead, the C++ mistake on the 3.4 branch, that's worked around by Mark's
fix for c++/17642 on mainline, is in build_x_conditional_expr in cp/typeck.c.
In this function, g++ calls expr = build_conditional_expr, which it assumes
will always return a tree with TREE_CODE COND_EXPR (after calling fold!).  So
when processing_template_decl, it then calls build_min_non_dep with a tree_code
that doesn't match the TREE_CODE of "expr" (which can potentially stomp memory).
More importantly, the orig_op1 and orig_op2 at this point haven't been promoted
to the correct result type, and builting a raw COND_EXPR in build_min_non_dep
with mismatched types later breaks things.

I'm not sure how to fix these lines:

  expr = build_conditional_expr (ifexp, op1, op2);
  if (processing_template_decl && expr != error_mark_node)
    return build_min_non_dep (COND_EXPR, expr,
                              orig_ifexp, orig_op1, orig_op2);

Perhaps something like:

  if (TREE_CODE (expr) != COND_EXPR)
    expr = build (COND_EXPR, TREE_TYPE (expr),
                  convert (boolean_type_node, ifexp),
                  convert (TREE_TYPE (expr), op1),
                  convert (TREE_TYPE (expr), op2));

where we recover the correct type to promote the operands to from the
type of the result.  Once again, orig_op1 = 0.0, orig_op2 = 0, and after
applying standard conversions both become 0.0, so "expr" ends up being
a REAL_CST, 0.0.  Perhaps it's possible to do better in the call to
build_min_non_dep.


-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|middle-end                  |driver


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

[Bug c++/20995] [3.4 regression] ICE in const_binop, at fold-const.c:1391

[cvs-commit at gcc dot gnu dot org]

------- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-04-25 19:59 -------
Subject: Bug 20995

CVSROOT:	/cvs/gcc
Module name:	gcc
Branch: 	gcc-3_4-branch
Changes by:	sayle@gcc.gnu.org	2005-04-25 19:58:53

Modified files:
	gcc/cp         : ChangeLog tree.c cp-tree.h call.c typeck.c 
	gcc/testsuite  : ChangeLog 
Added files:
	gcc/testsuite/g++.dg/opt: pr20995-1.C 

Log message:
	PR c++/20995
	Partial backport from mainline.
	2004-09-27  Mark Mitchell  <mark@codesourcery.com>
	* tree.c (fold_if_not_in_template): New function.
	* cp-tree.h (fold_if_not_in_template): Prototype here.
	* call.c (build_conditional_expr): Use fold_if_not_in_template.
	* typeck.c (build_binary_op): Likewise.
	
	* g++.dg/opt/pr20995-1.C: New test case.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.3892.2.212&r2=1.3892.2.213
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/tree.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.360.4.11&r2=1.360.4.12
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/cp-tree.h.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.946.4.18&r2=1.946.4.19
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/call.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.452.2.24&r2=1.452.2.25
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/typeck.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.519.2.24&r2=1.519.2.25
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.3389.2.381&r2=1.3389.2.382
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/opt/pr20995-1.C.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=NONE&r2=1.1.2.1



-- 


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

[Bug c++/20995] [3.4 regression] ICE in const_binop, at fold-const.c:1391

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-04-25 20:22 -------
Fixed.

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


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

[Bug c++/20995] [3.4 regression] ICE in const_binop, at fold-const.c:1391

[cvs-commit at gcc dot gnu dot org]

------- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-04-25 23:33 -------
Subject: Bug 20995

CVSROOT:	/cvs/gcc
Module name:	gcc
Changes by:	sayle@gcc.gnu.org	2005-04-25 23:32:56

Modified files:
	gcc/testsuite  : ChangeLog 
Added files:
	gcc/testsuite/g++.dg/opt: pr20995-1.C 

Log message:
	PR c++/20995
	* g++.dg/opt/pr20995-1.C: New test case.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.5397&r2=1.5398
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/opt/pr20995-1.C.diff?cvsroot=gcc&r1=1.1&r2=1.2



-- 


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