Bug 30391 - [4.3 regression] ICE at -O1 with conditional expressions and GIMPLE_MODIFY_STMT
Summary: [4.3 regression] ICE at -O1 with conditional expressions and GIMPLE_MODIFY_STMT
Alias: None
Product: gcc
Classification: Unclassified
Component: middle-end (show other bugs)
Version: 4.3.0
: P3 normal
Target Milestone: 4.3.0
Assignee: Aldy Hernandez
Keywords: ice-on-valid-code
: 30412 30672 30715 30817 (view as bug list)
Depends on:
Blocks: 29975
  Show dependency treegraph
Reported: 2007-01-06 10:41 UTC by Francois-Xavier Coudert
Modified: 2007-02-16 08:31 UTC (History)
13 users (show)

See Also:
Known to work:
Known to fail:
Last reconfirmed: 2007-01-23 00:43:21


Note You need to log in before you can comment on or make changes to this bug.
Description Francois-Xavier Coudert 2007-01-06 10:41:20 UTC
The following fails with today's (rev. 120520) trunk (at -O1 on both i686-linux and x86_64-linux):

$ cat mc_coordinates.f90
SUBROUTINE check_for_overlap (cell_length)
  REAL, DIMENSION(1:3), INTENT(IN), OPTIONAL :: cell_length
  REAL, DIMENSION(1:3) :: abc, box_length

  IF (PRESENT(cell_length)) THEN
END SUBROUTINE check_for_overlap
$ gfortran -O1 -c mc_coordinates.f90
mc_coordinates.f90: In function ‘check_for_overlap’:
mc_coordinates.f90:6: internal compiler error: in operand_equal_p, at fold-const.c:2539

The bug was originaly reported in PR29975. The gdb backtrace is:

Breakpoint 1, fancy_abort (file=0xa20a04 "../../trunk/gcc/fold-const.c", 
    line=2539, function=0xa20900 "operand_equal_p")
    at ../../trunk/gcc/diagnostic.c:641
641     {
(gdb) back
#0  fancy_abort (file=0xa20a04 "../../trunk/gcc/fold-const.c", line=2539, 
    function=0xa20900 "operand_equal_p") at ../../trunk/gcc/diagnostic.c:641
#1  0x00000000005c416d in operand_equal_p (arg0=0x2a984c3e40, 
    arg1=0x2a983e3300, flags=0) at ../../trunk/gcc/fold-const.c:2539
#2  0x00000000005c7f5f in fold_ternary (code=COND_EXPR, type=0x2a983f30c0, 
    op0=0x2a983de3c0, op1=0x2a984c3e40, op2=0x2a983e3300)
    at ../../trunk/gcc/fold-const.c:11657
#3  0x00000000005c9161 in fold_build3_stat (code=COND_EXPR, type=0x2a983f30c0, 
    op0=0x2a983de3c0, op1=0x2a984c3e40, op2=0x2a983e3300)
    at ../../trunk/gcc/fold-const.c:12307
#4  0x0000000000493271 in gfc_trans_if_1 (code=0xd6af60)
    at ../../trunk/gcc/fortran/trans-stmt.c:612
#5  0x0000000000464b83 in gfc_trans_code (code=0xd73b80)
    at ../../trunk/gcc/fortran/trans.c:528
#6  0x0000000000477f64 in gfc_generate_function_code (ns=0xd6a710)
    at ../../trunk/gcc/fortran/trans-decl.c:3232
#7  0x0000000000442bfc in gfc_parse_file ()
    at ../../trunk/gcc/fortran/parse.c:3263

I don't see any suspicious change in gcc/fortran/ChangeLog, maybe it has to do with Roger's recent array copying patch (although I don't see how). What is sure is that it worked at least until 20070104, and is now failing. Roger, could you give it a look?
Comment 1 Andrew Pinski 2007-01-06 23:15:24 UTC
This is a bug exposed by Roger's memcpy patch.  This bug was originally caused by Aldy's GIMPLE_MODIFY_STMT patch.
We are trying to fold a conditional expression's whos one side is a GIMPLE_MODIFY_STMT that came from folding of memcpy.
Comment 2 Andrew Pinski 2007-01-08 23:00:22 UTC
*** Bug 30412 has been marked as a duplicate of this bug. ***
Comment 3 Francois-Xavier Coudert 2007-01-20 13:14:29 UTC
Aldy, can you comment on this bug? It's still present as of today, and it prevents mainline from building a fair number of real-life Fortran codes.
Comment 4 Aldy Hernandez 2007-01-23 00:43:21 UTC
I'll look at this.
Comment 5 Andrew Pinski 2007-02-02 00:28:34 UTC
*** Bug 30672 has been marked as a duplicate of this bug. ***
Comment 6 Joost VandeVondele 2007-02-05 20:12:24 UTC
a patch:

Comment 7 Andrew Pinski 2007-02-06 17:52:19 UTC
*** Bug 30715 has been marked as a duplicate of this bug. ***
Comment 8 Sandra Loosemore 2007-02-14 00:04:04 UTC
Testing of the CALL_EXPR representation patch turned up a related ICE in tree_ssa_useless_type_conversion() while compiling libjava/java/lang/reflect/natMethod.cc.  It was failing because the expansion of memcpy produced by fold_builtin_memory_op includes a GIMPLE_MODIFY_STMT, and expansion of builtins happens long before the gimplifier is invoked by the C++ front end.  See http://gcc.gnu.org/ml/gcc-patches/2007-02/msg01193.html for more discussion.

As a temporary solution, the CALL_EXPR patch includes a tweak to use GENERIC_TREE_TYPE in tree_ssa_useless_type_conversion().  This should be revisited as part of a general solution.
Comment 9 Aldy Hernandez 2007-02-14 18:50:14 UTC
I believe this is addressed by Roger's patch which was approved yesterday (http://gcc.gnu.org/ml/gcc-patches/2007-02/msg00353.html), though I don't think the final revision has been committed.
Comment 10 Roger Sayle 2007-02-16 03:38:35 UTC
Subject: Bug 30391

Author: sayle
Date: Fri Feb 16 03:38:22 2007
New Revision: 122030

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122030

	PR middle-end/30391
	* tree.c (expr_align): Handle MODIFY_EXPR.  GIMPLE_MODIFY_STMT
	should be unreachable.
	(build2_stat): Allow construction of MODIFY_EXPR at any time.
	For the time being redirect GIMPLE_MODIFY_STMT to the new
	(renamed) build_gimple_modify_stmt_stat.
	(build2_gimple_stat): Rename to...
	(build_gimple_modify_stmt_stat): Now longer take a CODE argument.
	Always build a GIMPLE_MODIFY_STMT node.
	* tree.h (build2_gimple, build2_gimple_stat): Delete.
	(build_gimple_modify_stmt, build_gimple_modify_stmt_stat): New

	* tree-cfg.c (factor_computed_gotos, tree_merge_blocks,
	gimplify_val): Use build_gimple_modify_stmt instead of build2_gimple.
	* tree-complex.c (set_component_ssa_name, expand_complex_move,
	expand_complex_div_wide): Likewise.
	* tree-ssa-dom.c (record_equivalences_from_stmt): Likewise.
	* tree-ssa-loop-im.c (schedule_sm): Likewise.
	* tree-ssa-loop-ivopts.c (rewrite_use_nonlinear_expr): Likewise.
	* tree-ssa-loop-manip.c (create_iv): Likewise.
	* tree-ssa-phiopt.c (conditional_replacement, minmax_replacement,
	abs_replacement): Likewise.
	* tree-ssa-pre.c (create_expression_by_pieces, poolify_modify_stmt,
	realify_fake_stores): Likewise.

	* builtins.c (std_expand_builtin_va_start): Build a MODIFY_EXPR
	node rather than a GIMPLE_MODIFY_STMT node.
	(std_gimpify_va_arg_expr, expand_builtin_va_copy,
	fold_builtin_memset, fold_builtin_memory_op, do_mpfr_sincos):
	(integer_valued_real_p): Handle MODIFY_EXPR, not GIMPLE_MODIFY_STMT.
	* expr.c (expand_expr_real_1): Handle both MODIFY_EXPR and

	* gfortran.dg/pr30391-1.f90: New test case.


Comment 11 Francois-Xavier Coudert 2007-02-16 06:54:28 UTC
*** Bug 30817 has been marked as a duplicate of this bug. ***
Comment 12 Andrew Pinski 2007-02-16 08:31:16 UTC