Bug 42772 - [4.5 Regression] ICE at fold-const.c:10033
Summary: [4.5 Regression] ICE at fold-const.c:10033
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: fortran (show other bugs)
Version: 4.5.0
: P4 normal
Target Milestone: 4.5.0
Assignee: Paul Thomas
URL:
Keywords: ice-on-valid-code
Depends on:
Blocks: 42361
  Show dependency treegraph
 
Reported: 2010-01-16 22:05 UTC by Manfred Schwarb
Modified: 2010-01-19 19:49 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2010-01-19 06:04:44


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Manfred Schwarb 2010-01-16 22:05:55 UTC
With the test case 2 of bug 
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42742
I get with

# gfortran -frecursive -fcheck=all -o writebug2 writebug2.f

writebug2.f: In function 'MAIN__':
writebug2.f:33:0: internal compiler error: in fold_binary_loc, at fold-const.c:10033
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.

This is with gfortran 4.5.0 (20100107)

A reduced test case is the most trivial fortran program:
Just the line "END"

The ICE depends on the options "-frecursive -fcheck=all"
Comment 1 Richard Biener 2010-01-16 22:16:01 UTC
I get

$ gdb --args ./f951 -quiet t.f90 -frecursive -fcheck=all
Program received signal SIGSEGV, Segmentation fault.
0x080fc354 in gfc_add_modify (pblock=0xbffff234, lhs=0x0, rhs=0xb772f6d8)
    at /home/richard/src/trunk/gcc/fortran/trans.c:164
164	  t2 = TREE_TYPE (lhs);
(gdb) up
#1  0x08125e00 in gfc_generate_function_code (ns=0x8df4100)
    at /home/richard/src/trunk/gcc/fortran/trans-decl.c:4451
4451		gfc_add_modify (&block, recurcheckvar, boolean_false_node);


with the most trivial fortran program.
Comment 2 Dominique d'Humieres 2010-01-16 23:41:06 UTC
This is a regression introduced after revision 154654 (working). Backtrace:

(gdb) run -frecursive -fcheck=all pr42772.f90
Starting program: /opt/gcc/gcc4.5w/libexec/gcc/x86_64-apple-darwin10/4.5.0/f951 -frecursive -fcheck=all pr42772.f90
Reading symbols for shared libraries .++++++++++++..... done
 MAIN__
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000010
gfc_add_modify (pblock=0x7fff5fbfeb40, lhs=0x0, rhs=0x141d213c0) at ../../work/gcc/fortran/trans.c:164
164	  t2 = TREE_TYPE (lhs);
(gdb) bt
#0  gfc_add_modify (pblock=0x7fff5fbfeb40, lhs=0x0, rhs=0x141d213c0) at ../../work/gcc/fortran/trans.c:164
#1  0x00000001000c38df in gfc_generate_function_code (ns=<value temporarily unavailable, due to optimizations>) at ../../work/gcc/fortran/trans-decl.c:4463
#2  0x000000010006936f in gfc_parse_file () at ../../work/gcc/fortran/parse.c:4242
#3  0x00000001000a153c in gfc_be_parse_file (set_yydebug=<value temporarily unavailable, due to optimizations>) at ../../work/gcc/fortran/f95-lang.c:239
#4  0x00000001006d129a in toplev_main (argc=4, argv=0x7fff5fbfed68) at ../../work/gcc/toplev.c:1053
#5  0x00000001000011e4 in start ()
Comment 3 H.J. Lu 2010-01-17 02:53:55 UTC
It is cause by revision 155606:

http://gcc.gnu.org/ml/gcc-cvs/2010-01/msg00065.html
Comment 4 Tobias Burnus 2010-01-17 08:48:39 UTC
(In reply to comment #3)
> It is cause by revision 155606:
Thus mark as regression.
Comment 5 Paul Thomas 2010-01-18 19:55:31 UTC
Index: gcc/fortran/trans-decl.c
===================================================================
*** gcc/fortran/trans-decl.c	(revision 155875)
--- gcc/fortran/trans-decl.c	(working copy)
*************** gfc_generate_function_code (gfc_namespac
*** 4256,4262 ****
    stmtblock_t block;
    stmtblock_t body;
    tree result;
!   tree recurcheckvar = NULL;
    gfc_symbol *sym;
    int rank;
    bool is_recursive;
--- 4257,4263 ----
    stmtblock_t block;
    stmtblock_t body;
    tree result;
!   tree recurcheckvar = NULL_TREE;
    gfc_symbol *sym;
    int rank;
    bool is_recursive;
*************** gfc_generate_function_code (gfc_namespac
*** 4446,4456 ****
        gfc_add_expr_to_block (&block, tmp);
        /* Reset recursion-check variable.  */
        if ((gfc_option.rtcheck & GFC_RTCHECK_RECURSION) && !is_recursive
! 	  && !gfc_option.flag_openmp)
!       {
! 	gfc_add_modify (&block, recurcheckvar, boolean_false_node);
! 	recurcheckvar = NULL;
!       }
      }
  
  
--- 4447,4457 ----
        gfc_add_expr_to_block (&block, tmp);
        /* Reset recursion-check variable.  */
        if ((gfc_option.rtcheck & GFC_RTCHECK_RECURSION) && !is_recursive
! 	  && !gfc_option.flag_openmp && recurcheckvar != NULL_TREE)
! 	{
! 	  gfc_add_modify (&block, recurcheckvar, boolean_false_node);
! 	  recurcheckvar = NULL_TREE;
! 	}
      }

Gets rid of the trivial problem reported by Richard.

Cheers

Paul
Comment 6 Paul Thomas 2010-01-19 06:04:44 UTC
Ah, I was being stupid; now I see what test case 2 actually is.  duuh, I did not think to go to comment #10!

My patch that was just posted does indeed fix this, so I'll take it on.

Thanks for the report.

Paul
Comment 7 Paul Thomas 2010-01-19 19:47:16 UTC
Subject: Bug 42772

Author: pault
Date: Tue Jan 19 19:46:59 2010
New Revision: 156046

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156046
Log:
2010-01-19  Paul Thomas  <pault@gcc.gnu.org>

	PR fortran/42783
	* trans-decl.c (add_argument_checking): Do not use the backend
	decl directly to test for the presence of an optional dummy
	argument.  Use gfc_conv_expr_present, remembering to set the
	symbol referenced.

	PR fortran/42772
	* trans-decl.c (gfc_generate_function_code): Small white space
	changes. If 'recurcheckvar' is NULL do not try to reset it.

2010-01-19  Paul Thomas  <pault@gcc.gnu.org>

	PR fortran/42783
	* gfortran.dg/bounds_check_15.f90 : New test.


Added:
    trunk/gcc/testsuite/gfortran.dg/bounds_check_15.f90
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/trans-decl.c
    trunk/gcc/testsuite/ChangeLog

Comment 8 Paul Thomas 2010-01-19 19:49:22 UTC
I believe that the commit in comment #7 fixes it.  If not, please get in touch.

Thanks for the report

Paul