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

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

[jjcogliati-r1 at yahoo dot com]

When using -fwhole-program -flto -fopenmp on a program with gcc-4.5-20100107, I
get an internal compiler exception.  If I remove the -fopenmp, the program
compiles fine.  If I remove the -flto -fwhole-program, the program compiles
fine.

I have only been able to trigger this in a multi-thousand line program
proprietary program, and have not yet figured out a small test case that causes
this.  If you have any hints as to how to create a small test case, I will try
them.  I cannot provide the full program source code.  

Approximate command line:
gfortran -march=native -std=f95 -g -Wall -pedantic -O3 -Wline-truncation
-fopenmp -fbounds-check -fwhole-program -flto -o program lots.o of.o dot.o
files.o
Error:
lto1: internal compiler error: in iterative_hash_expr, at tree.c:6592


Relevant portion of gcc/tree.c:
      /* FALL THROUGH */
    default:
      tclass = TREE_CODE_CLASS (code);

      if (tclass == tcc_declaration)
        {
          /* DECL's have a unique ID */
          val = iterative_hash_host_wide_int (DECL_UID (t), val);
        }
      else
        {
          gcc_assert (IS_EXPR_CODE_CLASS (tclass));

          val = iterative_hash_object (code, val);

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/home/jjc/gcc/gcc45/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.5-20100107/configure --prefix=/home/jjc/gcc/gcc45
--enable-languages=c,c++,fortran,lto,objc --disable-multilib
Thread model: posix
gcc version 4.5.0 20100107 (experimental) (GCC)


-- 
           Summary: Internal compiler exception in with gfortran when using
                    -fwhole-program -flto -fopenmp
           Product: gcc
           Version: 4.5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: lto
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: jjcogliati-r1 at yahoo dot com
 GCC build triplet: x86_64-unknown-linux-gnu
  GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu


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

[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

[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

[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=0x7ffff1e96b70, 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

[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

[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  0x00000000005ee1cc in iterative_hash_gimple_type (type=0x7ffff1df3888, 
    val=<value optimized out>, sccstack=0x7fffffffda38, sccstate=0x1269440, 
    sccstate_obstack=0x7fffffffd9e0)
    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 *) 0x7ffff1df3888
(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

[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  0x00000000005ee1cc in iterative_hash_gimple_type (type=0x7ffff1df3888, 
>     val=<value optimized out>, sccstack=0x7fffffffda38, sccstate=0x1269440, 
>     sccstate_obstack=0x7fffffffd9e0)
>     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 *) 0x7ffff1df3888
> (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

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

[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=0x7ffff1e96b70, val=154387133)
    at ../../gcc-4.5-20100107/gcc/tree.c:6592
#1  0x00000000005ee1fc in iterative_hash_gimple_type (type=0x7ffff1df3888, 
    val=<value optimized out>, sccstack=0x7fffffffda38, sccstate=0x126a440, 
    sccstate_obstack=0x7fffffffd9e0)
    at ../../gcc-4.5-20100107/gcc/gimple.c:3713
#2  0x00000000005ee843 in visit (t=0x7ffff1df3888, state=0x126b4b0, 
    v=1159414094, sccstack=0x7fffffffda38, sccstate=0x126a440, 
    sccstate_obstack=0x7fffffffd9e0)
    at ../../gcc-4.5-20100107/gcc/gimple.c:3599
#3  0x00000000005ee276 in iterative_hash_gimple_type (type=0x7ffff1df37e0, 
    val=<value optimized out>, sccstack=0x7fffffffda38, sccstate=0x126a440, 
    sccstate_obstack=0x7fffffffd9e0)
    at ../../gcc-4.5-20100107/gcc/gimple.c:3722
#4  0x00000000005ee843 in visit (t=0x7ffff1df37e0, state=0x126b4a0, 
    v=4237831805, sccstack=0x7fffffffda38, sccstate=0x126a440, 
    sccstate_obstack=0x7fffffffd9e0)
    at ../../gcc-4.5-20100107/gcc/gimple.c:3599
#5  0x00000000005ee180 in iterative_hash_gimple_type (type=0x7ffff1df3bd0, 
    val=<value optimized out>, sccstack=0x7fffffffda38, sccstate=0x126a440, 
    sccstate_obstack=0x7fffffffd9e0)
    at ../../gcc-4.5-20100107/gcc/gimple.c:3703
#6  0x00000000005ee6eb in gimple_type_hash (p=0x7ffff1df3bd0)
    at ../../gcc-4.5-20100107/gcc/gimple.c:3831
#7  0x0000000000bfb821 in htab_find_slot (htab=0x11de980, 
    element=0x7ffff1df3bd0, insert=INSERT)
    at ../../gcc-4.5-20100107/libiberty/hashtab.c:681
#8  0x00000000005f76e3 in gimple_register_type (t=0x7ffff1df3bd0)
    at ../../gcc-4.5-20100107/gcc/gimple.c:3873
#9  0x00000000005f76c6 in gimple_register_type (t=0x7ffff1df3738)
    at ../../gcc-4.5-20100107/gcc/gimple.c:3868
#10 0x000000000048cbb7 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 0x000000000048f036 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 0x000000000073fc26 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 0x000000378c01eb1d 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

[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=0x7ffff1e96b70, val=154387133)
>     at ../../gcc-4.5-20100107/gcc/tree.c:6592
> #1  0x00000000005ee1fc in iterative_hash_gimple_type (type=0x7ffff1df3888, 
>     val=<value optimized out>, sccstack=0x7fffffffda38, sccstate=0x126a440, 
>     sccstate_obstack=0x7fffffffd9e0)
>     at ../../gcc-4.5-20100107/gcc/gimple.c:3713
> #2  0x00000000005ee843 in visit (t=0x7ffff1df3888, state=0x126b4b0, 
>     v=1159414094, sccstack=0x7fffffffda38, sccstate=0x126a440, 
>     sccstate_obstack=0x7fffffffd9e0)
>     at ../../gcc-4.5-20100107/gcc/gimple.c:3599
> #3  0x00000000005ee276 in iterative_hash_gimple_type (type=0x7ffff1df37e0, 
>     val=<value optimized out>, sccstack=0x7fffffffda38, sccstate=0x126a440, 
>     sccstate_obstack=0x7fffffffd9e0)
>     at ../../gcc-4.5-20100107/gcc/gimple.c:3722
> #4  0x00000000005ee843 in visit (t=0x7ffff1df37e0, state=0x126b4a0, 
>     v=4237831805, sccstack=0x7fffffffda38, sccstate=0x126a440, 
>     sccstate_obstack=0x7fffffffd9e0)
>     at ../../gcc-4.5-20100107/gcc/gimple.c:3599
> #5  0x00000000005ee180 in iterative_hash_gimple_type (type=0x7ffff1df3bd0, 
>     val=<value optimized out>, sccstack=0x7fffffffda38, sccstate=0x126a440, 
>     sccstate_obstack=0x7fffffffd9e0)
>     at ../../gcc-4.5-20100107/gcc/gimple.c:3703
> #6  0x00000000005ee6eb in gimple_type_hash (p=0x7ffff1df3bd0)
>     at ../../gcc-4.5-20100107/gcc/gimple.c:3831
> #7  0x0000000000bfb821 in htab_find_slot (htab=0x11de980, 
>     element=0x7ffff1df3bd0, insert=INSERT)
>     at ../../gcc-4.5-20100107/libiberty/hashtab.c:681
> #8  0x00000000005f76e3 in gimple_register_type (t=0x7ffff1df3bd0)
>     at ../../gcc-4.5-20100107/gcc/gimple.c:3873
> #9  0x00000000005f76c6 in gimple_register_type (t=0x7ffff1df3738)
>     at ../../gcc-4.5-20100107/gcc/gimple.c:3868
> #10 0x000000000048cbb7 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 0x000000000048f036 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 0x000000000073fc26 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 0x000000378c01eb1d 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

[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=0x7ffff1e96b70, val=154387133)
    at ../../gcc-4.5-20100107/gcc/tree.c:6592
#1  0x00000000005ee1fc in iterative_hash_gimple_type (type=0x7ffff1df3888, 
    val=<value optimized out>, sccstack=0x7fffffffda38, sccstate=0x126a440, 
    sccstate_obstack=0x7fffffffd9e0)
    at ../../gcc-4.5-20100107/gcc/gimple.c:3713
#2  0x00000000005ee843 in visit (t=0x7ffff1df3888, state=0x126b4b0, 
    v=1159414094, sccstack=0x7fffffffda38, sccstate=0x126a440, 
    sccstate_obstack=0x7fffffffd9e0)
    at ../../gcc-4.5-20100107/gcc/gimple.c:3599
#3  0x00000000005ee276 in iterative_hash_gimple_type (type=0x7ffff1df37e0, 
    val=<value optimized out>, sccstack=0x7fffffffda38, sccstate=0x126a440, 
    sccstate_obstack=0x7fffffffd9e0)
    at ../../gcc-4.5-20100107/gcc/gimple.c:3722
(gdb) down
#2  0x00000000005ee843 in visit (t=0x7ffff1df3888, state=0x126b4b0, 
    v=1159414094, sccstack=0x7fffffffda38, sccstate=0x126a440, 
    sccstate_obstack=0x7fffffffd9e0)
    at ../../gcc-4.5-20100107/gcc/gimple.c:3599
3599          tem = iterative_hash_gimple_type (t, v,
(gdb) down
#1  0x00000000005ee1fc in iterative_hash_gimple_type (type=0x7ffff1df3888, 
    val=<value optimized out>, sccstack=0x7fffffffda38, sccstate=0x126a440, 
    sccstate_obstack=0x7fffffffd9e0)
    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) 0x7ffff1d995c8
(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

[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=0x7ffff1e96b70, val=154387133)
>     at ../../gcc-4.5-20100107/gcc/tree.c:6592
> #1  0x00000000005ee1fc in iterative_hash_gimple_type (type=0x7ffff1df3888, 
>     val=<value optimized out>, sccstack=0x7fffffffda38, sccstate=0x126a440, 
>     sccstate_obstack=0x7fffffffd9e0)
>     at ../../gcc-4.5-20100107/gcc/gimple.c:3713
> #2  0x00000000005ee843 in visit (t=0x7ffff1df3888, state=0x126b4b0, 
>     v=1159414094, sccstack=0x7fffffffda38, sccstate=0x126a440, 
>     sccstate_obstack=0x7fffffffd9e0)
>     at ../../gcc-4.5-20100107/gcc/gimple.c:3599
> #3  0x00000000005ee276 in iterative_hash_gimple_type (type=0x7ffff1df37e0, 
>     val=<value optimized out>, sccstack=0x7fffffffda38, sccstate=0x126a440, 
>     sccstate_obstack=0x7fffffffd9e0)
>     at ../../gcc-4.5-20100107/gcc/gimple.c:3722
> (gdb) down
> #2  0x00000000005ee843 in visit (t=0x7ffff1df3888, state=0x126b4b0, 
>     v=1159414094, sccstack=0x7fffffffda38, sccstate=0x126a440, 
>     sccstate_obstack=0x7fffffffd9e0)
>     at ../../gcc-4.5-20100107/gcc/gimple.c:3599
> 3599          tem = iterative_hash_gimple_type (t, v,
> (gdb) down
> #1  0x00000000005ee1fc in iterative_hash_gimple_type (type=0x7ffff1df3888, 
>     val=<value optimized out>, sccstack=0x7fffffffda38, sccstate=0x126a440, 
>     sccstate_obstack=0x7fffffffd9e0)
>     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) 0x7ffff1d995c8
> (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

[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  0x00000000005ee276 in iterative_hash_gimple_type (type=0x7ffff1df37e0, 
    val=<value optimized out>, sccstack=0x7fffffffda38, sccstate=0x126a440, 
    sccstate_obstack=0x7fffffffd9e0)
    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

[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

[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=0x7ffff7fcfdc0, cb=0x17a2170)
    at /space/rguenther/src/svn/trunk/gcc/omp-low.c:1073
#1  0x0000000000cefd84 in remap_decl (decl=0x7ffff7fcfdc0, id=0x17a2170)
    at /space/rguenther/src/svn/trunk/gcc/tree-inline.c:283
#2  0x0000000000cf48d2 in copy_tree_body_r (tp=0x7ffff5adcce8, 
    walk_subtrees=0x7fffffffc640, data=0x17a2170)
    at /space/rguenther/src/svn/trunk/gcc/tree-inline.c:968
#3  0x0000000000c24389 in walk_tree_1 (tp=0x7ffff5adcce8, 
    func=0xcf46af <copy_tree_body_r>, data=0x17a2170, pset=0x0, lh=0)
    at /space/rguenther/src/svn/trunk/gcc/tree.c:9978
#4  0x0000000000cf15c5 in remap_type_1 (type=0x7ffff7fce498, id=0x17a2170)
    at /space/rguenther/src/svn/trunk/gcc/tree-inline.c:409
...
#9  0x0000000000cf1ad3 in remap_type (type=0x7ffff7fce3f0, id=0x17a2170)
    at /space/rguenther/src/svn/trunk/gcc/tree-inline.c:473
#10 0x00000000008bbfa8 in fixup_remapped_decl (decl=0x7ffff7fc5f00, 
---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 0x00000000008bec7c in scan_sharing_clauses (clauses=0x7ffff5adaa00, 
    ctx=0x17a2170) at /space/rguenther/src/svn/trunk/gcc/omp-low.c:1497
#12 0x00000000008bfe8c in scan_omp_parallel (gsi=0x7fffffffd770, outer_ctx=0x0)
    at /space/rguenther/src/svn/trunk/gcc/omp-low.c:1660
#13 0x00000000008c14dd in scan_omp_1_stmt (gsi=0x7fffffffd770, 
    handled_ops_p=0x7fffffffd6d7 "\001", wi=0x7fffffffd9f0)
    at /space/rguenther/src/svn/trunk/gcc/omp-low.c:1980
#14 0x000000000080e48f in walk_gimple_stmt (gsi=0x7fffffffd770, 
    callback_stmt=0x8c132f <scan_omp_1_stmt>, 
    callback_op=0x8c1204 <scan_omp_1_op>, wi=0x7fffffffd9f0)
    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|0000-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

[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

[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

[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=gcc&view=rev&rev=155885
Log:
2010-01-14  Richard Guenther  <rguenther@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

[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