[Bug lto/42665] Internal compiler exception in with gfortran when using -fwhole-program -flto -fopenmp

2010-01-14 Thread rguenth at gcc dot gnu dot org 


--- Comment #16 from rguenth at gcc dot gnu dot org  2010-01-14 09:39 
---
Subject: Bug 42665

Author: rguenth
Date: Thu Jan 14 09:38:56 2010
New Revision: 155885

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155885
Log:
2010-01-14  Richard Guenther  rguent...@suse.de

PR lto/42665
* gimple.c (iterative_hash_gimple_type): Avoid hashing
error_mark_node.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple.c


-- 


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

[Bug lto/42665] Internal compiler exception in with gfortran when using -fwhole-program -flto -fopenmp

2010-01-14 Thread rguenth at gcc dot gnu dot org 


--- Comment #17 from rguenth at gcc dot gnu dot org  2010-01-14 09:46 
---
Fixed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.5.0


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

[Bug lto/42665] Internal compiler exception in with gfortran when using -fwhole-program -flto -fopenmp

2010-01-13 Thread rguenth at gcc dot gnu dot org 


--- Comment #13 from rguenth at gcc dot gnu dot org  2010-01-13 11:37 
---
Single-file testcase:

  subroutine loop_list(list)
integer, intent(in), dimension(:) :: list
integer :: ii
!$ integer :: chunk_size
!$ chunk_size = 4
!$OMP PARALLEL DO SCHEDULE(dynamic,chunk_size)
do ii=1,size(list)
   call do_things(list, ii)
end do

  end subroutine loop_list

  subroutine do_things(list, index)
integer, intent(in),dimension(:) :: list
integer, intent(in) :: index
print *,size(list),index
  end subroutine do_things

program list_use
  implicit none

  integer, dimension(10) :: a_list

  a_list = 1
  call loop_list(a_list)
end program list_use


It is OPEN-MP lowering that during remapping of the domain type remaps
the upper gimplified bound D.1599 to error_mark_node in omp_copy_decl.

#0  omp_copy_decl (var=0x77fcfdc0, cb=0x17a2170)
at /space/rguenther/src/svn/trunk/gcc/omp-low.c:1073
#1  0x00cefd84 in remap_decl (decl=0x77fcfdc0, id=0x17a2170)
at /space/rguenther/src/svn/trunk/gcc/tree-inline.c:283
#2  0x00cf48d2 in copy_tree_body_r (tp=0x75adcce8, 
walk_subtrees=0x7fffc640, data=0x17a2170)
at /space/rguenther/src/svn/trunk/gcc/tree-inline.c:968
#3  0x00c24389 in walk_tree_1 (tp=0x75adcce8, 
func=0xcf46af copy_tree_body_r, data=0x17a2170, pset=0x0, lh=0)
at /space/rguenther/src/svn/trunk/gcc/tree.c:9978
#4  0x00cf15c5 in remap_type_1 (type=0x77fce498, id=0x17a2170)
at /space/rguenther/src/svn/trunk/gcc/tree-inline.c:409
...
#9  0x00cf1ad3 in remap_type (type=0x77fce3f0, id=0x17a2170)
at /space/rguenther/src/svn/trunk/gcc/tree-inline.c:473
#10 0x008bbfa8 in fixup_remapped_decl (decl=0x77fc5f00, 
---Type return to continue, or q return to quit---
ctx=0x17a2170, private_debug=0 '\000')
at /space/rguenther/src/svn/trunk/gcc/omp-low.c:1019
#11 0x008bec7c in scan_sharing_clauses (clauses=0x75adaa00, 
ctx=0x17a2170) at /space/rguenther/src/svn/trunk/gcc/omp-low.c:1497
#12 0x008bfe8c in scan_omp_parallel (gsi=0x7fffd770, outer_ctx=0x0)
at /space/rguenther/src/svn/trunk/gcc/omp-low.c:1660
#13 0x008c14dd in scan_omp_1_stmt (gsi=0x7fffd770, 
handled_ops_p=0x7fffd6d7 \001, wi=0x7fffd9f0)
at /space/rguenther/src/svn/trunk/gcc/omp-low.c:1980
#14 0x0080e48f in walk_gimple_stmt (gsi=0x7fffd770, 
callback_stmt=0x8c132f scan_omp_1_stmt, 
callback_op=0x8c1204 scan_omp_1_op, wi=0x7fffd9f0)
at /space/rguenther/src/svn/trunk/gcc/gimple.c:1586


I can easily deal with error_mark_node appearing there in
iterative_hash_gimple_type but I wonder if the above is intended.

Jakub?


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu dot org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-01-13 11:37:29
   date||


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

[Bug lto/42665] Internal compiler exception in with gfortran when using -fwhole-program -flto -fopenmp

2010-01-13 Thread rguenth at gcc dot gnu dot org 


--- Comment #14 from rguenth at gcc dot gnu dot org  2010-01-13 16:21 
---
I am testing the workaround

Index: gcc/gimple.c
===
--- gcc/gimple.c(revision 155860)
+++ gcc/gimple.c(working copy)
@@ -3707,8 +3707,12 @@ iterative_hash_gimple_type (tree type, h
   /* For integer types hash the types min/max values and the string flag.  */
   if (TREE_CODE (type) == INTEGER_TYPE)
 {
-  v = iterative_hash_expr (TYPE_MIN_VALUE (type), v);
-  v = iterative_hash_expr (TYPE_MAX_VALUE (type), v);
+  /* OMP lowering can introduce error_mark_node in place of
+random local decls in types.  */
+  if (TYPE_MIN_VALUE (type) != error_mark_node)
+   v = iterative_hash_expr (TYPE_MIN_VALUE (type), v);
+  if (TYPE_MAX_VALUE (type) != error_mark_node)
+   v = iterative_hash_expr (TYPE_MAX_VALUE (type), v);
   v = iterative_hash_hashval_t (TYPE_STRING_FLAG (type), v);
 }



-- 

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|NEW |ASSIGNED
   Last reconfirmed|2010-01-13 11:37:29 |2010-01-13 16:21:45
   date||


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

[Bug lto/42665] Internal compiler exception in with gfortran when using -fwhole-program -flto -fopenmp

2010-01-13 Thread jjcogliati-r1 at yahoo dot com 


--- Comment #15 from jjcogliati-r1 at yahoo dot com  2010-01-13 23:27 
---
(In reply to comment #14)
 I am testing the workaround
 
 Index: gcc/gimple.c
 ===
 --- gcc/gimple.c(revision 155860)
 +++ gcc/gimple.c(working copy)
 @@ -3707,8 +3707,12 @@ iterative_hash_gimple_type (tree type, h
/* For integer types hash the types min/max values and the string flag.  */
if (TREE_CODE (type) == INTEGER_TYPE)
  {
 -  v = iterative_hash_expr (TYPE_MIN_VALUE (type), v);
 -  v = iterative_hash_expr (TYPE_MAX_VALUE (type), v);
 +  /* OMP lowering can introduce error_mark_node in place of
 +random local decls in types.  */
 +  if (TYPE_MIN_VALUE (type) != error_mark_node)
 +   v = iterative_hash_expr (TYPE_MIN_VALUE (type), v);
 +  if (TYPE_MAX_VALUE (type) != error_mark_node)
 +   v = iterative_hash_expr (TYPE_MAX_VALUE (type), v);
v = iterative_hash_hashval_t (TYPE_STRING_FLAG (type), v);
  }
 
 

With the above patch, my code now both compiles, and runs its testcases
correctly.  


-- 


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

[Bug lto/42665] Internal compiler exception in with gfortran when using -fwhole-program -flto -fopenmp

2010-01-12 Thread jjcogliati-r1 at yahoo dot com 


--- Comment #12 from jjcogliati-r1 at yahoo dot com  2010-01-12 21:14 
---
(In reply to comment #10)
 Subject: Re:  Internal compiler exception in with gfortran
  when using  -fwhole-program -flto -fopenmp
 
 On Mon, 11 Jan 2010, jjcogliati-r1 at yahoo dot com wrote:
 
  
  
  --- Comment #9 from jjcogliati-r1 at yahoo dot com  2010-01-11 17:15 
  ---
  My hunch, (and I could be wrong since my knowledge of gcc's tree code was 
  zero
  as of Friday morning) is that it is trying to find the array's min and max
  size, but that only the min location is available, and that the max value is
  undefined.  Since this is fortran code, there are a number of places that I 
  do
  that.  Is that plausible, and if so, how would I check this hunch?
 
 It should never be error_mark_node ...
 
  Getting permission for me to get you the full code would involve a lot of
  bureaucracy (weeks to months).  
 
 Oh, I see ...
 
 You could try putting an assert in 
 lto-streamer-out.c:lto_output_ts_type_tree_pointers so that
 the TYPE_MIN/MAXVAL are not error_mark_node.
 
 That would point you to the file and function.
 
 Richard.
 

That did the trick.  Thank you.  

Added lto-streamer-out.c:lto_output_ts_type_tree_pointers:
  else if (TREE_CODE (expr) == ARRAY_TYPE) {
+gcc_assert(TYPE_MAX_VALUE (TYPE_DOMAIN (expr) ) == NULL || 
+  TREE_CODE (TYPE_MAX_VALUE (TYPE_DOMAIN (expr) )) != ERROR_MARK
);
lto_output_tree_or_ref (ob, TYPE_DOMAIN (expr), ref_p);
  }


I can now trigger the original ice with the following valid (I think) code:
!list_use.f90
program list_use
  use list_test
  implicit none

  integer, dimension(10) :: a_list

  a_list = 1
  call loop_list(a_list)
end program list_use

!list_test.f90
module list_test
  !$ use omp_lib
  implicit none

contains

  subroutine loop_list(list)
integer, intent(in), dimension(:) :: list
integer :: ii
!$ integer :: chunk_size
!$ chunk_size = 4
!$OMP PARALLEL DO SCHEDULE(dynamic,chunk_size)
do ii=1,size(list)
   call do_things(list, ii)
end do

  end subroutine loop_list

  subroutine do_things(list, index)
integer, intent(in),dimension(:) :: list
integer, intent(in) :: index
print *,size(list),index
  end subroutine do_things

end module list_test



$ ~/gcc/old4_gcc45/bin/gfortran -Wall -o list_use -fopenmp -fwhole-program
-flto  list_test.f90 list_use.f90
lto1: internal compiler error: in iterative_hash_expr, at tree.c:6592
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
lto-wrapper: /home/jjc/gcc/old4_gcc45/bin/gfortran returned 1 exit status
collect2: lto-wrapper returned 1 exit status


-- 


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

[Bug lto/42665] Internal compiler exception in with gfortran when using -fwhole-program -flto -fopenmp

2010-01-11 Thread jjcogliati-r1 at yahoo dot com 


--- Comment #7 from jjcogliati-r1 at yahoo dot com  2010-01-11 15:50 ---
(In reply to comment #6)

 Try
 
 Index: gcc/gimple.c
 ===
 --- gcc/gimple.c(revision 155739)
 +++ gcc/gimple.c(working copy)
 @@ -3707,8 +3707,10 @@ iterative_hash_gimple_type (tree type, h
/* For integer types hash the types min/max values and the string flag.  
 */
if (TREE_CODE (type) == INTEGER_TYPE)
  {
 -  v = iterative_hash_expr (TYPE_MIN_VALUE (type), v);
 -  v = iterative_hash_expr (TYPE_MAX_VALUE (type), v);
 +  if (TYPE_MIN_VALUE (type))
 +   v = iterative_hash_expr (TYPE_MIN_VALUE (type), v);
 +  if (TYPE_MAX_VALUE (type))
 +   v = iterative_hash_expr (TYPE_MAX_VALUE (type), v);
v = iterative_hash_hashval_t (TYPE_STRING_FLAG (type), v);
  }
 
 


I tried that patch.  Still errors out with backtrace:
#0  iterative_hash_expr (t=0x71e96b70, val=154387133)
at ../../gcc-4.5-20100107/gcc/tree.c:6592
#1  0x005ee1fc in iterative_hash_gimple_type (type=0x71df3888, 
val=value optimized out, sccstack=0x7fffda38, sccstate=0x126a440, 
sccstate_obstack=0x7fffd9e0)
at ../../gcc-4.5-20100107/gcc/gimple.c:3713
#2  0x005ee843 in visit (t=0x71df3888, state=0x126b4b0, 
v=1159414094, sccstack=0x7fffda38, sccstate=0x126a440, 
sccstate_obstack=0x7fffd9e0)
at ../../gcc-4.5-20100107/gcc/gimple.c:3599
#3  0x005ee276 in iterative_hash_gimple_type (type=0x71df37e0, 
val=value optimized out, sccstack=0x7fffda38, sccstate=0x126a440, 
sccstate_obstack=0x7fffd9e0)
at ../../gcc-4.5-20100107/gcc/gimple.c:3722
#4  0x005ee843 in visit (t=0x71df37e0, state=0x126b4a0, 
v=4237831805, sccstack=0x7fffda38, sccstate=0x126a440, 
sccstate_obstack=0x7fffd9e0)
at ../../gcc-4.5-20100107/gcc/gimple.c:3599
#5  0x005ee180 in iterative_hash_gimple_type (type=0x71df3bd0, 
val=value optimized out, sccstack=0x7fffda38, sccstate=0x126a440, 
sccstate_obstack=0x7fffd9e0)
at ../../gcc-4.5-20100107/gcc/gimple.c:3703
#6  0x005ee6eb in gimple_type_hash (p=0x71df3bd0)
at ../../gcc-4.5-20100107/gcc/gimple.c:3831
#7  0x00bfb821 in htab_find_slot (htab=0x11de980, 
element=0x71df3bd0, insert=INSERT)
at ../../gcc-4.5-20100107/libiberty/hashtab.c:681
#8  0x005f76e3 in gimple_register_type (t=0x71df3bd0)
at ../../gcc-4.5-20100107/gcc/gimple.c:3873
#9  0x005f76c6 in gimple_register_type (t=0x71df3738)
at ../../gcc-4.5-20100107/gcc/gimple.c:3868
#10 0x0048cbb7 in lto_read_in_decl_state (data=value optimized out, 
state=value optimized out) at ../../gcc-4.5-20100107/gcc/lto/lto.c:174
#11 0x0048f036 in lto_read_decls (resolutions=value optimized out, 
data=value optimized out, decl_data=value optimized out)
at ../../gcc-4.5-20100107/gcc/lto/lto.c:237
#12 lto_file_read (resolutions=value optimized out, 
data=value optimized out, decl_data=value optimized out)
at ../../gcc-4.5-20100107/gcc/lto/lto.c:377
#13 read_cgraph_and_symbols (resolutions=value optimized out, 
data=value optimized out, decl_data=value optimized out)
at ../../gcc-4.5-20100107/gcc/lto/lto.c:1839
#14 lto_main (resolutions=value optimized out, data=value optimized out, 
decl_data=value optimized out)
at ../../gcc-4.5-20100107/gcc/lto/lto.c:2061
#15 0x0073fc26 in compile_file ()
at ../../gcc-4.5-20100107/gcc/toplev.c:1053
#16 do_compile () at ../../gcc-4.5-20100107/gcc/toplev.c:2405
#17 toplev_main () at ../../gcc-4.5-20100107/gcc/toplev.c:2447
#18 0x00378c01eb1d in __libc_start_main (main=value optimized out, 
argc=value optimized out, ubp_av=value optimized out, 
init=value optimized out, fini=value optimized out, 
rtld_fini=value optimized out, stack_end=value optimized out)
at libc-start.c:220

Same generally looking types as above (ERROR_MARK, INTEGER_TYPE ...)

Is there anyway for me to find out what filename and line number are being
compiled at this point?  That would help me figure out a smaller testcase.


-- 


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

[Bug lto/42665] Internal compiler exception in with gfortran when using -fwhole-program -flto -fopenmp

2010-01-11 Thread rguenther at suse dot de 


--- Comment #8 from rguenther at suse dot de  2010-01-11 15:54 ---
Subject: Re:  Internal compiler exception in with gfortran
 when using  -fwhole-program -flto -fopenmp

On Mon, 11 Jan 2010, jjcogliati-r1 at yahoo dot com wrote:

 
 
 --- Comment #7 from jjcogliati-r1 at yahoo dot com  2010-01-11 15:50 
 ---
 (In reply to comment #6)
 
  Try
  
  Index: gcc/gimple.c
  ===
  --- gcc/gimple.c(revision 155739)
  +++ gcc/gimple.c(working copy)
  @@ -3707,8 +3707,10 @@ iterative_hash_gimple_type (tree type, h
 /* For integer types hash the types min/max values and the string flag.  
  */
 if (TREE_CODE (type) == INTEGER_TYPE)
   {
  -  v = iterative_hash_expr (TYPE_MIN_VALUE (type), v);
  -  v = iterative_hash_expr (TYPE_MAX_VALUE (type), v);
  +  if (TYPE_MIN_VALUE (type))
  +   v = iterative_hash_expr (TYPE_MIN_VALUE (type), v);
  +  if (TYPE_MAX_VALUE (type))
  +   v = iterative_hash_expr (TYPE_MAX_VALUE (type), v);
 v = iterative_hash_hashval_t (TYPE_STRING_FLAG (type), v);
   }
  
  
 
 
 I tried that patch.  Still errors out with backtrace:
 #0  iterative_hash_expr (t=0x71e96b70, val=154387133)
 at ../../gcc-4.5-20100107/gcc/tree.c:6592
 #1  0x005ee1fc in iterative_hash_gimple_type (type=0x71df3888, 
 val=value optimized out, sccstack=0x7fffda38, sccstate=0x126a440, 
 sccstate_obstack=0x7fffd9e0)
 at ../../gcc-4.5-20100107/gcc/gimple.c:3713
 #2  0x005ee843 in visit (t=0x71df3888, state=0x126b4b0, 
 v=1159414094, sccstack=0x7fffda38, sccstate=0x126a440, 
 sccstate_obstack=0x7fffd9e0)
 at ../../gcc-4.5-20100107/gcc/gimple.c:3599
 #3  0x005ee276 in iterative_hash_gimple_type (type=0x71df37e0, 
 val=value optimized out, sccstack=0x7fffda38, sccstate=0x126a440, 
 sccstate_obstack=0x7fffd9e0)
 at ../../gcc-4.5-20100107/gcc/gimple.c:3722
 #4  0x005ee843 in visit (t=0x71df37e0, state=0x126b4a0, 
 v=4237831805, sccstack=0x7fffda38, sccstate=0x126a440, 
 sccstate_obstack=0x7fffd9e0)
 at ../../gcc-4.5-20100107/gcc/gimple.c:3599
 #5  0x005ee180 in iterative_hash_gimple_type (type=0x71df3bd0, 
 val=value optimized out, sccstack=0x7fffda38, sccstate=0x126a440, 
 sccstate_obstack=0x7fffd9e0)
 at ../../gcc-4.5-20100107/gcc/gimple.c:3703
 #6  0x005ee6eb in gimple_type_hash (p=0x71df3bd0)
 at ../../gcc-4.5-20100107/gcc/gimple.c:3831
 #7  0x00bfb821 in htab_find_slot (htab=0x11de980, 
 element=0x71df3bd0, insert=INSERT)
 at ../../gcc-4.5-20100107/libiberty/hashtab.c:681
 #8  0x005f76e3 in gimple_register_type (t=0x71df3bd0)
 at ../../gcc-4.5-20100107/gcc/gimple.c:3873
 #9  0x005f76c6 in gimple_register_type (t=0x71df3738)
 at ../../gcc-4.5-20100107/gcc/gimple.c:3868
 #10 0x0048cbb7 in lto_read_in_decl_state (data=value optimized out, 
 state=value optimized out) at ../../gcc-4.5-20100107/gcc/lto/lto.c:174
 #11 0x0048f036 in lto_read_decls (resolutions=value optimized out, 
 data=value optimized out, decl_data=value optimized out)
 at ../../gcc-4.5-20100107/gcc/lto/lto.c:237
 #12 lto_file_read (resolutions=value optimized out, 
 data=value optimized out, decl_data=value optimized out)
 at ../../gcc-4.5-20100107/gcc/lto/lto.c:377
 #13 read_cgraph_and_symbols (resolutions=value optimized out, 
 data=value optimized out, decl_data=value optimized out)
 at ../../gcc-4.5-20100107/gcc/lto/lto.c:1839
 #14 lto_main (resolutions=value optimized out, data=value optimized out, 
 decl_data=value optimized out)
 at ../../gcc-4.5-20100107/gcc/lto/lto.c:2061
 #15 0x0073fc26 in compile_file ()
 at ../../gcc-4.5-20100107/gcc/toplev.c:1053
 #16 do_compile () at ../../gcc-4.5-20100107/gcc/toplev.c:2405
 #17 toplev_main () at ../../gcc-4.5-20100107/gcc/toplev.c:2447
 #18 0x00378c01eb1d in __libc_start_main (main=value optimized out, 
 argc=value optimized out, ubp_av=value optimized out, 
 init=value optimized out, fini=value optimized out, 
 rtld_fini=value optimized out, stack_end=value optimized out)
 at libc-start.c:220
 
 Same generally looking types as above (ERROR_MARK, INTEGER_TYPE ...)
 
 Is there anyway for me to find out what filename and line number are being
 compiled at this point?  That would help me figure out a smaller testcase.

Not really.  A big testcase is ok - we have automated tools to reduce it.

Richard.


-- 


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

[Bug lto/42665] Internal compiler exception in with gfortran when using -fwhole-program -flto -fopenmp

2010-01-11 Thread jjcogliati-r1 at yahoo dot com 


--- Comment #9 from jjcogliati-r1 at yahoo dot com  2010-01-11 17:15 ---
My hunch, (and I could be wrong since my knowledge of gcc's tree code was zero
as of Friday morning) is that it is trying to find the array's min and max
size, but that only the min location is available, and that the max value is
undefined.  Since this is fortran code, there are a number of places that I do
that.  Is that plausible, and if so, how would I check this hunch?

Getting permission for me to get you the full code would involve a lot of
bureaucracy (weeks to months).  

(gdb) p type-base
$32 = {code = ARRAY_TYPE, side_effects_flag = 0, constant_flag = 0, 
  addressable_flag = 0, volatile_flag = 0, readonly_flag = 0, 
  unsigned_flag = 0, asm_written_flag = 0, nowarning_flag = 0, used_flag = 0, 
  nothrow_flag = 0, static_flag = 0, public_flag = 0, private_flag = 0, 
  protected_flag = 0, deprecated_flag = 0, saturating_flag = 0, 
  default_def_flag = 0, lang_flag_0 = 0, lang_flag_1 = 0, lang_flag_2 = 0, 
  lang_flag_3 = 0, lang_flag_4 = 0, lang_flag_5 = 0, lang_flag_6 = 0, 
  visited = 0, packed_flag = 0, user_align = 0, spare = 0, address_space = 0}
(gdb) list
3717  /* For array types hash their domain and the string flag.  */
3718  if (TREE_CODE (type) == ARRAY_TYPE
3719   TYPE_DOMAIN (type))
3720{
3721  v = iterative_hash_hashval_t (TYPE_STRING_FLAG (type), v);
3722  v = visit (TYPE_DOMAIN (type), state, v,
3723 sccstack, sccstate, sccstate_obstack);
3724}
3725
3726  /* Recurse for aggregates with a single element type.  */
(gdb) where
#0  iterative_hash_expr (t=0x71e96b70, val=154387133)
at ../../gcc-4.5-20100107/gcc/tree.c:6592
#1  0x005ee1fc in iterative_hash_gimple_type (type=0x71df3888, 
val=value optimized out, sccstack=0x7fffda38, sccstate=0x126a440, 
sccstate_obstack=0x7fffd9e0)
at ../../gcc-4.5-20100107/gcc/gimple.c:3713
#2  0x005ee843 in visit (t=0x71df3888, state=0x126b4b0, 
v=1159414094, sccstack=0x7fffda38, sccstate=0x126a440, 
sccstate_obstack=0x7fffd9e0)
at ../../gcc-4.5-20100107/gcc/gimple.c:3599
#3  0x005ee276 in iterative_hash_gimple_type (type=0x71df37e0, 
val=value optimized out, sccstack=0x7fffda38, sccstate=0x126a440, 
sccstate_obstack=0x7fffd9e0)
at ../../gcc-4.5-20100107/gcc/gimple.c:3722
(gdb) down
#2  0x005ee843 in visit (t=0x71df3888, state=0x126b4b0, 
v=1159414094, sccstack=0x7fffda38, sccstate=0x126a440, 
sccstate_obstack=0x7fffd9e0)
at ../../gcc-4.5-20100107/gcc/gimple.c:3599
3599  tem = iterative_hash_gimple_type (t, v,
(gdb) down
#1  0x005ee1fc in iterative_hash_gimple_type (type=0x71df3888, 
val=value optimized out, sccstack=0x7fffda38, sccstate=0x126a440, 
sccstate_obstack=0x7fffd9e0)
at ../../gcc-4.5-20100107/gcc/gimple.c:3713
3713   v = iterative_hash_expr (TYPE_MAX_VALUE (type), v);
(gdb) p type-type.minval
$33 = (tree) 0x71d995c8
(gdb) p (type-type.minval)-base
$34 = {code = INTEGER_CST, side_effects_flag = 0, constant_flag = 1, 
  addressable_flag = 0, volatile_flag = 0, readonly_flag = 0, 
  unsigned_flag = 0, asm_written_flag = 0, nowarning_flag = 0, used_flag = 0, 
  nothrow_flag = 0, static_flag = 0, public_flag = 0, private_flag = 0, 
  protected_flag = 0, deprecated_flag = 0, saturating_flag = 0, 
  default_def_flag = 0, lang_flag_0 = 0, lang_flag_1 = 0, lang_flag_2 = 0, 
  lang_flag_3 = 0, lang_flag_4 = 0, lang_flag_5 = 0, lang_flag_6 = 0, 
  visited = 0, packed_flag = 0, user_align = 0, spare = 0, address_space = 0}
(gdb) p (type-type.maxval)-base
$35 = {code = ERROR_MARK, side_effects_flag = 0, constant_flag = 0, 
  addressable_flag = 0, volatile_flag = 0, readonly_flag = 0, 
  unsigned_flag = 0, asm_written_flag = 0, nowarning_flag = 0, used_flag = 0, 
  nothrow_flag = 0, static_flag = 0, public_flag = 0, private_flag = 0, 
  protected_flag = 0, deprecated_flag = 0, saturating_flag = 0, 
  default_def_flag = 0, lang_flag_0 = 0, lang_flag_1 = 0, lang_flag_2 = 0, 
  lang_flag_3 = 0, lang_flag_4 = 0, lang_flag_5 = 0, lang_flag_6 = 0, 
  visited = 0, packed_flag = 0, user_align = 0, spare = 0, address_space = 0}


-- 


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

[Bug lto/42665] Internal compiler exception in with gfortran when using -fwhole-program -flto -fopenmp

2010-01-11 Thread rguenther at suse dot de 


--- Comment #10 from rguenther at suse dot de  2010-01-11 17:22 ---
Subject: Re:  Internal compiler exception in with gfortran
 when using  -fwhole-program -flto -fopenmp

On Mon, 11 Jan 2010, jjcogliati-r1 at yahoo dot com wrote:

 
 
 --- Comment #9 from jjcogliati-r1 at yahoo dot com  2010-01-11 17:15 
 ---
 My hunch, (and I could be wrong since my knowledge of gcc's tree code was zero
 as of Friday morning) is that it is trying to find the array's min and max
 size, but that only the min location is available, and that the max value is
 undefined.  Since this is fortran code, there are a number of places that I do
 that.  Is that plausible, and if so, how would I check this hunch?

It should never be error_mark_node ...

 Getting permission for me to get you the full code would involve a lot of
 bureaucracy (weeks to months).  

Oh, I see ...

You could try putting an assert in 
lto-streamer-out.c:lto_output_ts_type_tree_pointers so that
the TYPE_MIN/MAXVAL are not error_mark_node.

That would point you to the file and function.

Richard.

 (gdb) p type-base
 $32 = {code = ARRAY_TYPE, side_effects_flag = 0, constant_flag = 0, 
   addressable_flag = 0, volatile_flag = 0, readonly_flag = 0, 
   unsigned_flag = 0, asm_written_flag = 0, nowarning_flag = 0, used_flag = 0, 
   nothrow_flag = 0, static_flag = 0, public_flag = 0, private_flag = 0, 
   protected_flag = 0, deprecated_flag = 0, saturating_flag = 0, 
   default_def_flag = 0, lang_flag_0 = 0, lang_flag_1 = 0, lang_flag_2 = 0, 
   lang_flag_3 = 0, lang_flag_4 = 0, lang_flag_5 = 0, lang_flag_6 = 0, 
   visited = 0, packed_flag = 0, user_align = 0, spare = 0, address_space = 0}
 (gdb) list
 3717  /* For array types hash their domain and the string flag.  */
 3718  if (TREE_CODE (type) == ARRAY_TYPE
 3719   TYPE_DOMAIN (type))
 3720{
 3721  v = iterative_hash_hashval_t (TYPE_STRING_FLAG (type), v);
 3722  v = visit (TYPE_DOMAIN (type), state, v,
 3723 sccstack, sccstate, sccstate_obstack);
 3724}
 3725
 3726  /* Recurse for aggregates with a single element type.  */
 (gdb) where
 #0  iterative_hash_expr (t=0x71e96b70, val=154387133)
 at ../../gcc-4.5-20100107/gcc/tree.c:6592
 #1  0x005ee1fc in iterative_hash_gimple_type (type=0x71df3888, 
 val=value optimized out, sccstack=0x7fffda38, sccstate=0x126a440, 
 sccstate_obstack=0x7fffd9e0)
 at ../../gcc-4.5-20100107/gcc/gimple.c:3713
 #2  0x005ee843 in visit (t=0x71df3888, state=0x126b4b0, 
 v=1159414094, sccstack=0x7fffda38, sccstate=0x126a440, 
 sccstate_obstack=0x7fffd9e0)
 at ../../gcc-4.5-20100107/gcc/gimple.c:3599
 #3  0x005ee276 in iterative_hash_gimple_type (type=0x71df37e0, 
 val=value optimized out, sccstack=0x7fffda38, sccstate=0x126a440, 
 sccstate_obstack=0x7fffd9e0)
 at ../../gcc-4.5-20100107/gcc/gimple.c:3722
 (gdb) down
 #2  0x005ee843 in visit (t=0x71df3888, state=0x126b4b0, 
 v=1159414094, sccstack=0x7fffda38, sccstate=0x126a440, 
 sccstate_obstack=0x7fffd9e0)
 at ../../gcc-4.5-20100107/gcc/gimple.c:3599
 3599  tem = iterative_hash_gimple_type (t, v,
 (gdb) down
 #1  0x005ee1fc in iterative_hash_gimple_type (type=0x71df3888, 
 val=value optimized out, sccstack=0x7fffda38, sccstate=0x126a440, 
 sccstate_obstack=0x7fffd9e0)
 at ../../gcc-4.5-20100107/gcc/gimple.c:3713
 3713   v = iterative_hash_expr (TYPE_MAX_VALUE (type), v);
 (gdb) p type-type.minval
 $33 = (tree) 0x71d995c8
 (gdb) p (type-type.minval)-base
 $34 = {code = INTEGER_CST, side_effects_flag = 0, constant_flag = 1, 
   addressable_flag = 0, volatile_flag = 0, readonly_flag = 0, 
   unsigned_flag = 0, asm_written_flag = 0, nowarning_flag = 0, used_flag = 0, 
   nothrow_flag = 0, static_flag = 0, public_flag = 0, private_flag = 0, 
   protected_flag = 0, deprecated_flag = 0, saturating_flag = 0, 
   default_def_flag = 0, lang_flag_0 = 0, lang_flag_1 = 0, lang_flag_2 = 0, 
   lang_flag_3 = 0, lang_flag_4 = 0, lang_flag_5 = 0, lang_flag_6 = 0, 
   visited = 0, packed_flag = 0, user_align = 0, spare = 0, address_space = 0}
 (gdb) p (type-type.maxval)-base
 $35 = {code = ERROR_MARK, side_effects_flag = 0, constant_flag = 0, 
   addressable_flag = 0, volatile_flag = 0, readonly_flag = 0, 
   unsigned_flag = 0, asm_written_flag = 0, nowarning_flag = 0, used_flag = 0, 
   nothrow_flag = 0, static_flag = 0, public_flag = 0, private_flag = 0, 
   protected_flag = 0, deprecated_flag = 0, saturating_flag = 0, 
   default_def_flag = 0, lang_flag_0 = 0, lang_flag_1 = 0, lang_flag_2 = 0, 
   lang_flag_3 = 0, lang_flag_4 = 0, lang_flag_5 = 0, lang_flag_6 = 0, 
   visited = 0, packed_flag = 0, user_align = 0, spare = 0, address_space = 0}
 
 
 


-- 


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

[Bug lto/42665] Internal compiler exception in with gfortran when using -fwhole-program -flto -fopenmp

2010-01-11 Thread jjcogliati-r1 at yahoo dot com 


--- Comment #11 from jjcogliati-r1 at yahoo dot com  2010-01-11 18:58 
---
(In reply to comment #10)
 Subject: Re:  Internal compiler exception in with gfortran
  when using  -fwhole-program -flto -fopenmp
 
 On Mon, 11 Jan 2010, jjcogliati-r1 at yahoo dot com wrote:
 
  
  
  --- Comment #9 from jjcogliati-r1 at yahoo dot com  2010-01-11 17:15 
  ---
  My hunch, (and I could be wrong since my knowledge of gcc's tree code was 
  zero
  as of Friday morning) is that it is trying to find the array's min and max
  size, but that only the min location is available, and that the max value is
  undefined.  Since this is fortran code, there are a number of places that I 
  do
  that.  Is that plausible, and if so, how would I check this hunch?
 
 It should never be error_mark_node ...

Okay, so:
(gdb) down
#3  0x005ee276 in iterative_hash_gimple_type (type=0x71df37e0, 
val=value optimized out, sccstack=0x7fffda38, sccstate=0x126a440, 
sccstate_obstack=0x7fffd9e0)
at ../../gcc-4.5-20100107/gcc/gimple.c:3722
3722  v = visit (TYPE_DOMAIN (type), state, v,
(gdb) p type-type.values-type.maxval-base
$67 = {code = ERROR_MARK, side_effects_flag = 0, constant_flag = 0, 
  addressable_flag = 0, volatile_flag = 0, readonly_flag = 0, 
  unsigned_flag = 0, asm_written_flag = 0, nowarning_flag = 0, used_flag = 0, 
  nothrow_flag = 0, static_flag = 0, public_flag = 0, private_flag = 0, 
  protected_flag = 0, deprecated_flag = 0, saturating_flag = 0, 
  default_def_flag = 0, lang_flag_0 = 0, lang_flag_1 = 0, lang_flag_2 = 0, 
  lang_flag_3 = 0, lang_flag_4 = 0, lang_flag_5 = 0, lang_flag_6 = 0, 
  visited = 0, packed_flag = 0, user_align = 0, spare = 0, address_space = 0}

That should not have happened, since it is ERROR_MARK

I think the assert that would have triggered would need to check:
TREE_CODE (TYPE_MAX_VALUE (TYPE_DOMAIN (type) )) != ERROR_MARK
tho it would probably need to check a few of the intermediate values.


-- 


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

[Bug lto/42665] Internal compiler exception in with gfortran when using -fwhole-program -flto -fopenmp

2010-01-08 Thread rguenth at gcc dot gnu dot org 


--- Comment #1 from rguenth at gcc dot gnu dot org  2010-01-08 21:10 ---
Can you run it in a debugger and print what 'code' actually is?  Can you
check if removing -g fixes the ICE?


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu dot
   ||org
   Keywords||ice-on-valid-code, lto


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

[Bug lto/42665] Internal compiler exception in with gfortran when using -fwhole-program -flto -fopenmp

2010-01-08 Thread jjcogliati-r1 at yahoo dot com 


--- Comment #2 from jjcogliati-r1 at yahoo dot com  2010-01-08 21:27 ---
(In reply to comment #1)
 Can you run it in a debugger and print what 'code' actually is?  Can you
 check if removing -g fixes the ICE?
 

The ICE still happens when -g is removed.  I'm working on trying it in a
debugger.


-- 


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

[Bug lto/42665] Internal compiler exception in with gfortran when using -fwhole-program -flto -fopenmp

2010-01-08 Thread jjcogliati-r1 at yahoo dot com 


--- Comment #3 from jjcogliati-r1 at yahoo dot com  2010-01-08 21:38 ---
(In reply to comment #1)
 Can you run it in a debugger and print what 'code' actually is?  Can you
 check if removing -g fixes the ICE?
 

Code is: 
ERROR_MARK

(gdb) break tree.c:6592
Breakpoint 1 at 0x89a063: file ../../gcc-4.5-20100107/gcc/tree.c, line 6592.
(gdb) run
Starting program:
/home/jjc/gcc/gcc45/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/lto1 -quiet
-dumpbase program -dumpdir ./ -mtune=generic -auxbase-strip /tmp/ccxQqVMb.lto.o
-O3 -Wall -pedantic -Wline-truncation -std=f95 -version -fopenmp -fbounds-check
-fwhole-program @/tmp/cce2vBEb -o program.s
GNU GIMPLE (GCC) version 4.5.0 20100107 (experimental)
(x86_64-unknown-linux-gnu)
compiled by GNU C version 4.5.0 20100107 (experimental), GMP version
4.3.1, MPFR version 2.4.1, MPC version 0.8
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU GIMPLE (GCC) version 4.5.0 20100107 (experimental)
(x86_64-unknown-linux-gnu)
compiled by GNU C version 4.5.0 20100107 (experimental), GMP version
4.3.1, MPFR version 2.4.1, MPC version 0.8
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096

Breakpoint 1, iterative_hash_expr (t=0x71e96b70, val=154387133)
at ../../gcc-4.5-20100107/gcc/tree.c:6592
6592  gcc_assert (IS_EXPR_CODE_CLASS (tclass));
(gdb) p tclass
$1 = 0 '\000'
(gdb) p code
$2 = ERROR_MARK
(gdb) c
Continuing.
lto1: internal compiler error: in iterative_hash_expr, at tree.c:6592
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.

Program exited with code 04.


-- 


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

[Bug lto/42665] Internal compiler exception in with gfortran when using -fwhole-program -flto -fopenmp

2010-01-08 Thread rguenther at suse dot de 


--- Comment #4 from rguenther at suse dot de  2010-01-08 21:41 ---
Subject: Re:  Internal compiler exception in with gfortran
 when using  -fwhole-program -flto -fopenmp

On Fri, 8 Jan 2010, jjcogliati-r1 at yahoo dot com wrote:

 --- Comment #3 from jjcogliati-r1 at yahoo dot com  2010-01-08 21:38 
 ---
 (In reply to comment #1)
  Can you run it in a debugger and print what 'code' actually is?  Can you
  check if removing -g fixes the ICE?
  
 
 Code is: 
 ERROR_MARK

Hm, ok.  I guess we need a testcase anyway.  A tarball with all
preprocessed sources is probably enough.  You can also try reducing
the set of files required by performing incremental linking with
-r and omit files one-by-one.

Richard.


-- 


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

[Bug lto/42665] Internal compiler exception in with gfortran when using -fwhole-program -flto -fopenmp

2010-01-08 Thread jjcogliati-r1 at yahoo dot com 


--- Comment #5 from jjcogliati-r1 at yahoo dot com  2010-01-08 22:28 ---
(In reply to comment #4)
 Subject: Re:  Internal compiler exception in with gfortran
  when using  -fwhole-program -flto -fopenmp
 
 On Fri, 8 Jan 2010, jjcogliati-r1 at yahoo dot com wrote:
 
  --- Comment #3 from jjcogliati-r1 at yahoo dot com  2010-01-08 21:38 
  ---
  (In reply to comment #1)
   Can you run it in a debugger and print what 'code' actually is?  Can you
   check if removing -g fixes the ICE?
   
  
  Code is: 
  ERROR_MARK
 
 Hm, ok.  I guess we need a testcase anyway.  A tarball with all
 preprocessed sources is probably enough.  You can also try reducing
 the set of files required by performing incremental linking with
 -r and omit files one-by-one.
 
 Richard.
 

(gdb) p *t
$16 = {base = {code = ERROR_MARK, side_effects_flag = 0, constant_flag = 0, 
addressable_flag = 0, volatile_flag = 0, readonly_flag = 0, 
unsigned_flag = 0, asm_written_flag = 0, nowarning_flag = 0, 
used_flag = 0, nothrow_flag = 0, static_flag = 0, public_flag = 0, 
private_flag = 0, protected_flag = 0, deprecated_flag = 0, 
saturating_flag = 0, default_def_flag = 0, lang_flag_0 = 0, 
lang_flag_1 = 0, lang_flag_2 = 0, lang_flag_3 = 0, lang_flag_4 = 0, 
lang_flag_5 = 0, lang_flag_6 = 0, visited = 0, packed_flag = 0, 
user_align = 0, spare = 0, address_space = 0}, common = {base = {
  code = ERROR_MARK, side_effects_flag = 0, constant_flag = 0, 
  addressable_flag = 0, volatile_flag = 0, readonly_flag = 0, 
  unsigned_flag = 0, asm_written_flag = 0, nowarning_flag = 0, 
  used_flag = 0, nothrow_flag = 0, static_flag = 0, public_flag = 0, 
  private_flag = 0, protected_flag = 0, deprecated_flag = 0, 
  saturating_flag = 0, default_def_flag = 0, lang_flag_0 = 0, 
  lang_flag_1 = 0, lang_flag_2 = 0, lang_flag_3 = 0, lang_flag_4 = 0, 
  lang_flag_5 = 0, lang_flag_6 = 0, visited = 0, packed_flag = 0, 
  user_align = 0, spare = 0, address_space = 0}, chain = 0x0, 

if we go up 1 to:
(gdb) up
#1  0x005ee1cc in iterative_hash_gimple_type (type=0x71df3888, 
val=value optimized out, sccstack=0x7fffda38, sccstate=0x1269440, 
sccstate_obstack=0x7fffd9e0)
at ../../gcc-4.5-20100107/gcc/gimple.c:3711
3711  v = iterative_hash_expr (TYPE_MAX_VALUE (type), v);
(gdb) p type
$17 = (union tree_node *) 0x71df3888
(gdb) p *type
$18 = {base = {code = INTEGER_TYPE, side_effects_flag = 0, constant_flag = 0, 
addressable_flag = 0, volatile_flag = 0, readonly_flag = 0, 
unsigned_flag = 0, asm_written_flag = 0, nowarning_flag = 0, 
used_flag = 0, nothrow_flag = 0, static_flag = 0, public_flag = 0, 
private_flag = 0, protected_flag = 0, deprecated_flag = 0, 
saturating_flag = 0, default_def_flag = 0, lang_flag_0 = 0, 
lang_flag_1 = 0, lang_flag_2 = 0, lang_flag_3 = 0, lang_flag_4 = 0, 
lang_flag_5 = 0, lang_flag_6 = 0, visited = 0, packed_flag = 0, 
user_align = 0, spare = 0, address_space = 0}, common = {base = {
  code = INTEGER_TYPE, side_effects_flag = 0, constant_flag = 0, 
  addressable_flag = 0, volatile_flag = 0, readonly_flag = 0, 
  unsigned_flag = 0, asm_written_flag = 0, nowarning_flag = 0, 
  used_flag = 0, nothrow_flag = 0, static_flag = 0, public_flag = 0, 
  private_flag = 0, protected_flag = 0, deprecated_flag = 0, 
  saturating_flag = 0, default_def_flag = 0, lang_flag_0 = 0, 

Maybe that helps.  If I have inspiration over the weekend I will try to make a
test case on Monday. 


-- 


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

[Bug lto/42665] Internal compiler exception in with gfortran when using -fwhole-program -flto -fopenmp

2010-01-08 Thread rguenther at suse dot de 


--- Comment #6 from rguenther at suse dot de  2010-01-08 22:45 ---
Subject: Re:  Internal compiler exception in with gfortran
 when using  -fwhole-program -flto -fopenmp

On Fri, 8 Jan 2010, jjcogliati-r1 at yahoo dot com wrote:

 --- Comment #5 from jjcogliati-r1 at yahoo dot com  2010-01-08 22:28 
 ---
 (In reply to comment #4)
  Subject: Re:  Internal compiler exception in with gfortran
   when using  -fwhole-program -flto -fopenmp
  
  On Fri, 8 Jan 2010, jjcogliati-r1 at yahoo dot com wrote:
  
   --- Comment #3 from jjcogliati-r1 at yahoo dot com  2010-01-08 21:38 
   ---
   (In reply to comment #1)
Can you run it in a debugger and print what 'code' actually is?  Can you
check if removing -g fixes the ICE?

   
   Code is: 
   ERROR_MARK
  
  Hm, ok.  I guess we need a testcase anyway.  A tarball with all
  preprocessed sources is probably enough.  You can also try reducing
  the set of files required by performing incremental linking with
  -r and omit files one-by-one.
  
  Richard.
  
 
 (gdb) p *t
 $16 = {base = {code = ERROR_MARK, side_effects_flag = 0, constant_flag = 0, 
 addressable_flag = 0, volatile_flag = 0, readonly_flag = 0, 
 unsigned_flag = 0, asm_written_flag = 0, nowarning_flag = 0, 
 used_flag = 0, nothrow_flag = 0, static_flag = 0, public_flag = 0, 
 private_flag = 0, protected_flag = 0, deprecated_flag = 0, 
 saturating_flag = 0, default_def_flag = 0, lang_flag_0 = 0, 
 lang_flag_1 = 0, lang_flag_2 = 0, lang_flag_3 = 0, lang_flag_4 = 0, 
 lang_flag_5 = 0, lang_flag_6 = 0, visited = 0, packed_flag = 0, 
 user_align = 0, spare = 0, address_space = 0}, common = {base = {
   code = ERROR_MARK, side_effects_flag = 0, constant_flag = 0, 
   addressable_flag = 0, volatile_flag = 0, readonly_flag = 0, 
   unsigned_flag = 0, asm_written_flag = 0, nowarning_flag = 0, 
   used_flag = 0, nothrow_flag = 0, static_flag = 0, public_flag = 0, 
   private_flag = 0, protected_flag = 0, deprecated_flag = 0, 
   saturating_flag = 0, default_def_flag = 0, lang_flag_0 = 0, 
   lang_flag_1 = 0, lang_flag_2 = 0, lang_flag_3 = 0, lang_flag_4 = 0, 
   lang_flag_5 = 0, lang_flag_6 = 0, visited = 0, packed_flag = 0, 
   user_align = 0, spare = 0, address_space = 0}, chain = 0x0, 
 
 if we go up 1 to:
 (gdb) up
 #1  0x005ee1cc in iterative_hash_gimple_type (type=0x71df3888, 
 val=value optimized out, sccstack=0x7fffda38, sccstate=0x1269440, 
 sccstate_obstack=0x7fffd9e0)
 at ../../gcc-4.5-20100107/gcc/gimple.c:3711
 3711  v = iterative_hash_expr (TYPE_MAX_VALUE (type), v);
 (gdb) p type
 $17 = (union tree_node *) 0x71df3888
 (gdb) p *type
 $18 = {base = {code = INTEGER_TYPE, side_effects_flag = 0, constant_flag = 0, 
 addressable_flag = 0, volatile_flag = 0, readonly_flag = 0, 
 unsigned_flag = 0, asm_written_flag = 0, nowarning_flag = 0, 
 used_flag = 0, nothrow_flag = 0, static_flag = 0, public_flag = 0, 
 private_flag = 0, protected_flag = 0, deprecated_flag = 0, 
 saturating_flag = 0, default_def_flag = 0, lang_flag_0 = 0, 
 lang_flag_1 = 0, lang_flag_2 = 0, lang_flag_3 = 0, lang_flag_4 = 0, 
 lang_flag_5 = 0, lang_flag_6 = 0, visited = 0, packed_flag = 0, 
 user_align = 0, spare = 0, address_space = 0}, common = {base = {
   code = INTEGER_TYPE, side_effects_flag = 0, constant_flag = 0, 
   addressable_flag = 0, volatile_flag = 0, readonly_flag = 0, 
   unsigned_flag = 0, asm_written_flag = 0, nowarning_flag = 0, 
   used_flag = 0, nothrow_flag = 0, static_flag = 0, public_flag = 0, 
   private_flag = 0, protected_flag = 0, deprecated_flag = 0, 
   saturating_flag = 0, default_def_flag = 0, lang_flag_0 = 0, 
 
 Maybe that helps.  If I have inspiration over the weekend I will try to make a
 test case on Monday. 

Try

Index: gcc/gimple.c
===
--- gcc/gimple.c(revision 155739)
+++ gcc/gimple.c(working copy)
@@ -3707,8 +3707,10 @@ iterative_hash_gimple_type (tree type, h
   /* For integer types hash the types min/max values and the string flag.  
*/
   if (TREE_CODE (type) == INTEGER_TYPE)
 {
-  v = iterative_hash_expr (TYPE_MIN_VALUE (type), v);
-  v = iterative_hash_expr (TYPE_MAX_VALUE (type), v);
+  if (TYPE_MIN_VALUE (type))
+   v = iterative_hash_expr (TYPE_MIN_VALUE (type), v);
+  if (TYPE_MAX_VALUE (type))
+   v = iterative_hash_expr (TYPE_MAX_VALUE (type), v);
   v = iterative_hash_hashval_t (TYPE_STRING_FLAG (type), v);
 }



-- 


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