[Bug c/50913] New: ICE: compiling libgfortran for i686-w64-mingw32

[Bug c/50913] New: ICE: compiling libgfortran for i686-w64-mingw32

[vanboxem.ruben at gmail dot com]

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

             Bug #: 50913
           Summary: ICE: compiling libgfortran for i686-w64-mingw32
    Classification: Unclassified
           Product: gcc
           Version: 4.7.0
            Status: UNCONFIRMED
          Severity: critical
          Priority: P3
         Component: c
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: vanboxem.ruben@gmail.com


Created attachment 25662
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25662
Preprocessed source for file causing ICE

I get an ICE compiling this:

/home/ruben/mingw-w64/toolchain/linux64mingw32/gcc/./gcc/xgcc
-B/home/ruben/mingw-w64/toolchain/linux64mingw32/gcc/./gcc/
-L/home/ruben/mingw-w64/toolchain/linux64mingw32/mingw32/i686-w64-mingw32/lib
-L/home/ruben/mingw-w64/toolchain/linux64mingw32/mingw32/mingw/lib -isystem
/home/ruben/mingw-w64/toolchain/linux64mingw32/mingw32/i686-w64-mingw32/include
-isystem /home/ruben/mingw-w64/toolchain/linux64mingw32/mingw32/mingw/include
-B/home/ruben/mingw-w64/toolchain/linux64mingw32/mingw32/i686-w64-mingw32/bin/
-B/home/ruben/mingw-w64/toolchain/linux64mingw32/mingw32/i686-w64-mingw32/lib/
-isystem
/home/ruben/mingw-w64/toolchain/linux64mingw32/mingw32/i686-w64-mingw32/include
-isystem
/home/ruben/mingw-w64/toolchain/linux64mingw32/mingw32/i686-w64-mingw32/sys-include
-DHAVE_CONFIG_H -I. -I/home/ruben/mingw-w64/toolchain/src/gcc/libgfortran
-iquote/home/ruben/mingw-w64/toolchain/src/gcc/libgfortran/io
-I/home/ruben/mingw-w64/toolchain/src/gcc/libgfortran/../gcc
-I/home/ruben/mingw-w64/toolchain/src/gcc/libgfortran/../gcc/config
-I/home/ruben/mingw-w64/toolchain/src/gcc/libgfortran/../libquadmath
-I../.././gcc -std=gnu99 -Wall -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition -Wextra -Wwrite-strings -fcx-fortran-rules
-ffunction-sections -fdata-sections -g -O2 -mtune=core2 -fomit-frame-pointer
-momit-leaf-frame-pointer -fgraphite-identity -floop-interchange -floop-block
-floop-parallelize-all -MT spread_i2.lo -MD -MP -MF .deps/spread_i2.Tpo -c
/home/ruben/mingw-w64/toolchain/src/gcc/libgfortran/generated/spread_i2.c 
-DDLL_EXPORT -DPIC -o ./libs/spread_i2.o

xgcc -v output:
Using built-in specs.
COLLECT_GCC=/home/ruben/mingw-w64/toolchain/linux64mingw32/gcc/./gcc/xgcc
Target: i686-w64-mingw32
Configured with: /home/ruben/mingw-w64/toolchain/src/gcc/configure
--host=x86_64-linux-gnu --build=x86_64-linux-gnu --target=i686-w64-mingw32
--with-sysroot=/home/ruben/mingw-w64/toolchain/linux64mingw32/mingw32
--prefix=/home/ruben/mingw-w64/toolchain/linux64mingw32/mingw32
--with-libiconv-prefix=/home/ruben/mingw-w64/toolchain/linux64mingw32/prereq_install
--with-gmp=/home/ruben/mingw-w64/toolchain/linux64mingw32/prereq_install
--with-mpfr=/home/ruben/mingw-w64/toolchain/linux64mingw32/prereq_install
--with-mpc=/home/ruben/mingw-w64/toolchain/linux64mingw32/prereq_install
--with-ppl=/home/ruben/mingw-w64/toolchain/linux64mingw32/prereq_install
--with-cloog=/home/ruben/mingw-w64/toolchain/linux64mingw32/prereq_install
--enable-cloog-backend=isl --with-host-libstdcxx='-lstdc++ -lsupc++ -lm
-lgcc_eh' --enable-shared --enable-static --enable-threads=posix
--disable-multilib --enable-languages=c,lto,c++,fortran,objc,obj-c++,java
--enable-libgomp --enable-sjlj-exceptions --enable-fully-dynamic-string
--disable-nls --disable-werror --enable-checking=release CFLAGS='-O2
-mtune=core2 -fomit-frame-pointer -momit-leaf-frame-pointer -fgraphite-identity
-floop-interchange -floop-block -floop-parallelize-all' LDFLAGS=
Thread model: posix
gcc version 4.7.0 20111029 (experimental) (GCC)

Preprocessed source attached. Same thing happens for spread_i1.c.

[Bug middle-end/50913] ICE: compiling libgfortran for i686-w64-mingw32

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

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

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> 2011-10-29 22:35:55 UTC ---
What was the ICE?

[Bug middle-end/50913] ICE: compiling libgfortran for i686-w64-mingw32

[vanboxem.ruben at gmail dot com]

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

--- Comment #2 from Ruben Van Boxem <vanboxem.ruben at gmail dot com> 2011-10-30 15:20:43 UTC ---
(In reply to comment #1)
> What was the ICE?

Sorry about that:
/home/ruben/mingw-w64/toolchain/src/gcc/libgfortran/generated/spread_i1.c: In
function 'spread_i1':
/home/ruben/mingw-w64/toolchain/src/gcc/libgfortran/generated/spread_i1.c:36:1:
internal compiler error: in scan_tree_for_params_right_scev, at
graphite-sese-to-poly.c:633

[Bug middle-end/50913] [4.7 Regression] ICE in scan_tree_for_params_right_scev, at graphite-sese-to-poly.c:633 compiling libgfortran with -floop-interchange -m32

[belyshev at depni dot sinp.msu.ru]

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

Serge Belyshev <belyshev at depni dot sinp.msu.ru> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|                            |i686-*-* x86_64-*-*
             Status|UNCONFIRMED                 |NEW
           Keywords|                            |ice-on-valid-code
   Last reconfirmed|                            |2011-11-07
                 CC|                            |belyshev at depni dot
                   |                            |sinp.msu.ru
     Ever Confirmed|0                           |1
            Summary|ICE: compiling libgfortran  |[4.7 Regression] ICE in
                   |for i686-w64-mingw32        |scan_tree_for_params_right_
                   |                            |scev, at
                   |                            |graphite-sese-to-poly.c:633
                   |                            |compiling libgfortran with
                   |                            |-floop-interchange -m32
           Severity|critical                    |normal

--- Comment #3 from Serge Belyshev <belyshev at depni dot sinp.msu.ru> 2011-11-07 11:43:48 UTC ---
Reduced testcase, fails on mainline with -O2 -floop-interchange -m32:

void spread_i1 (int *rptr, int *sptr, int ncopies, int *extent, int rdelta, int
m)
{
  int *dest;
  int n;

  while (m--)
    {
      dest = rptr;
      for (n = 0; n < ncopies; n ++)
        {
          *dest = *sptr;
      dest += rdelta;
        }
      if (extent [n])
    if (n)
          rptr ++;
    }
}

[Bug middle-end/50913] [4.7 Regression] ICE in scan_tree_for_params_right_scev, at graphite-sese-to-poly.c:633 compiling libgfortran with -floop-interchange -m32

[belyshev at depni dot sinp.msu.ru]

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

Serge Belyshev <belyshev at depni dot sinp.msu.ru> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rguenth at gcc dot gnu.org

--- Comment #4 from Serge Belyshev <belyshev at depni dot sinp.msu.ru> 2011-11-07 12:51:01 UTC ---
Fails since the fix for bug 50067, r178028:

2011-08-24  Richard Guenther  <rguenther@suse.de>

    PR tree-optimization/50067
    * tree-data-ref.c (dr_analyze_indices): Do not add an access
    function for a MEM_REF base that has no evolution in the loop
    nest or that is not analyzable.
    ...

[Bug middle-end/50913] [4.7 Regression] ICE in scan_tree_for_params_right_scev, at graphite-sese-to-poly.c:633 compiling libgfortran with -floop-interchange -m32

[rguenth at gcc dot gnu.org]

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

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |4.7.0

--- Comment #5 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-11-07 13:07:53 UTC ---
Looks like a genuine graphite bug though

718       switch (TREE_CODE (e))
719         {
720         case POLYNOMIAL_CHREC:
721           scan_tree_for_params_right_scev (s, CHREC_RIGHT (e),
722                                            CHREC_VARIABLE (e), c);
(gdb) call debug_generic_expr (e)
{0B, +, (sizetype) pretmp.6_31}_2

632           |   a [i * p] = ...   */
633           gcc_assert (TREE_CODE (e) == INTEGER_CST);

where e here is CHREC_RIGHT (e).  Looks like sth assumes this form
of a SCEV does not happen.

#(Data Ref: 
#  bb: 4 
#  stmt: *dest_35 = D.2240_13;
#  ref: *dest_35;
#  base_object: *rptr_1;
#  Access function 0: {0B, +, (sizetype) pretmp.6_31}_2
#)

Note that data-ref analysis fails with

failed: evolution of base is not affine

but graphite still forces access functions to be generated.

[Bug middle-end/50913] [4.7 Regression] ICE in scan_tree_for_params_right_scev, at graphite-sese-to-poly.c:633 compiling libgfortran with -floop-interchange -m32

[rguenth at gcc dot gnu.org]

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

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P1

[Bug middle-end/50913] [4.7 Regression] ICE in scan_tree_for_params_right_scev, at graphite-sese-to-poly.c:633 compiling libgfortran with -floop-interchange -m32

[matt at use dot net]

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

Matt Hargett <matt at use dot net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |matt at use dot net

--- Comment #6 from Matt Hargett <matt at use dot net> 2011-12-10 03:23:51 UTC ---
I ran into this as well when compiling scummvm with "-O2 -floop-block". I can't
tell, but it may be a regression of PR42930. I filed a new bug as PR51943. If
this bug turns out to be a duplicate of PR51943, let me know and I'll add the
relevant info to this bug.

One way to tell is if you see this approximate valgrind output when reproducing
your testcase:

==21219== Conditional jump or move depends on uninitialised value(s)
==21219==    at 0xD02445: refs_may_alias_p_1(ao_ref_s*, ao_ref_s*, bool)
(tree-ssa-alias.c:1027)
==21219==    by 0xA92139: stmt_may_clobber_ref_p_1(gimple_statement_d*,
ao_ref_s*) (tree-ssa-alias.c:1762)
==21219==    by 0xA92210:
_ZL20walk_aliased_vdefs_1P8ao_ref_sP9tree_nodePFbS0_S2_PvES3_PP15bitmap_head_defj.955263.constprop.2845.16875
(tree-ssa-alias.c:2158)
==21219==    by 0xA9238D: walk_aliased_vdefs(ao_ref_s*, tree_node*, bool
(*)(ao_ref_s*, tree_node*, void*), void*, bitmap_head_def**)
(tree-ssa-alias.c:2178)
==21219==    by 0xA9335E:
_ZL20detect_type_change_1P9tree_nodeS0_S0_P18gimple_statement_dP13ipa_jump_funcl.498561.15992
(ipa-prop.c:460)
==21219==    by 0xA9634B: ipa_analyze_node(cgraph_node*) (ipa-prop.c:1505)
==21219==    by 0xA96F88: _ZL21ipcp_generate_summaryv.1445752 (ipa-cp.c:2490)
==21219==    by 0xE3AF25: execute_ipa_summary_passes(ipa_opt_pass_d*)
(passes.c:1888)
==21219==    by 0x9912C6: cgraph_optimize() (cgraphunit.c:2059)
==21219==    by 0x991559: cgraph_finalize_compilation_unit()
(cgraphunit.c:1327)
==21219==    by 0xCE3EBA: cp_write_global_declarations() (decl2.c:4050)
==21219==    by 0xC8DA2F: toplev_main(int, char**) (toplev.c:573)
==21219==  Uninitialised value was created by a stack allocation
==21219==    at 0xA934ED:
_ZL22detect_type_change_ssaP9tree_nodeP18gimple_statement_dP13ipa_jump_func.498569.15987
(ipa-prop.c:511)

[Bug middle-end/50913] [4.7 Regression] ICE in scan_tree_for_params_right_scev, at graphite-sese-to-poly.c:633 compiling libgfortran with -floop-interchange -m32

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-12-12 10:16:31 UTC ---
*** Bug 51493 has been marked as a duplicate of this bug. ***

[Bug middle-end/50913] [4.7 Regression] ICE in scan_tree_for_params_right_scev, at graphite-sese-to-poly.c:633 compiling libgfortran with -floop-interchange -m32

[rguenth at gcc dot gnu.org]

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

--- Comment #8 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-01-09 15:14:30 UTC ---
There is a disconnect on how we analyze data-references during SCOP detection
(outermost_loop is the root of the loop tree) and during SESE-to-poly where
outermost is determined by outermost_loop_in_sese_1 ().  That influences
the SCEV result and thus we do not break the SCOP at a stmt we have to break
it.

The following patch fixes this using a sledgehammer - require the
data-ref to be representable if analyzed with respect to all loops
it can nest in.

Index: graphite-scop-detection.c
===================================================================
--- graphite-scop-detection.c   (revision 183013)
+++ graphite-scop-detection.c   (working copy)
@@ -258,25 +258,33 @@ graphite_can_represent_expr (basic_block
    Graphite.  */

 static bool
-stmt_has_simple_data_refs_p (loop_p outermost_loop, gimple stmt)
+stmt_has_simple_data_refs_p (loop_p outermost_loop ATTRIBUTE_UNUSED,
+                            gimple stmt)
 {
   data_reference_p dr;
   unsigned i;
   int j;
   bool res = true;
-  VEC (data_reference_p, heap) *drs = VEC_alloc (data_reference_p, heap, 5);
+  VEC (data_reference_p, heap) *drs = NULL;
+  loop_p outer;

-  graphite_find_data_references_in_stmt (outermost_loop,
-                                        loop_containing_stmt (stmt),
-                                        stmt, &drs);
+  for (outer = loop_containing_stmt (stmt); outer; outer = loop_outer (outer))
+    {
+      graphite_find_data_references_in_stmt (outer,
+                                            loop_containing_stmt (stmt),
+                                            stmt, &drs);

-  FOR_EACH_VEC_ELT (data_reference_p, drs, j, dr)
-    for (i = 0; i < DR_NUM_DIMENSIONS (dr); i++)
-      if (!graphite_can_represent_scev (DR_ACCESS_FN (dr, i)))
-       {
-         res = false;
-         goto done;
-       }
+      FOR_EACH_VEC_ELT (data_reference_p, drs, j, dr)
+         for (i = 0; i < DR_NUM_DIMENSIONS (dr); i++)
+           if (!graphite_can_represent_scev (DR_ACCESS_FN (dr, i)))
+             {
+               res = false;
+               goto done;
+             }
+
+      free_data_refs (drs);
+      drs = NULL;
+    }

  done:
   free_data_refs (drs);

[Bug tree-optimization/50913] [4.7 Regression] ICE in scan_tree_for_params_right_scev, at graphite-sese-to-poly.c:633 compiling libgfortran with -floop-interchange -m32

[rguenth at gcc dot gnu.org]

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

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
          Component|middle-end                  |tree-optimization
         AssignedTo|unassigned at gcc dot       |rguenth at gcc dot gnu.org
                   |gnu.org                     |

[Bug tree-optimization/50913] [4.7 Regression] ICE in scan_tree_for_params_right_scev, at graphite-sese-to-poly.c:633 compiling libgfortran with -floop-interchange -m32

[rguenth at gcc dot gnu.org]

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

Richard Guenther <rguenth at gcc dot gnu.org> changed:

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

--- Comment #10 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-01-10 09:15:11 UTC ---
Fixed.

[Bug tree-optimization/50913] [4.7 Regression] ICE in scan_tree_for_params_right_scev, at graphite-sese-to-poly.c:633 compiling libgfortran with -floop-interchange -m32

[rguenth at gcc dot gnu.org]

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

--- Comment #9 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-01-10 09:14:57 UTC ---
Author: rguenth
Date: Tue Jan 10 09:14:51 2012
New Revision: 183055

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183055
Log:
2012-01-10  Richard Guenther  <rguenther@suse.de>

    PR tree-optimization/50913
    * graphite-scop-detection.c (stmt_has_simple_data_refs_p):
    Require data-refs to be representable by Graphite with respect
    to any loop nest.

    * gcc.dg/graphite/interchange-16.c: New testcase.
    * gcc.dg/graphite/scop-20.c: XFAIL.
    * gfortran.dg/graphite/interchange-1.f: Likewise.
    * gfortran.dg/graphite/block-1.f90: Likewise.
    * gfortran.dg/graphite/block-2.f: Likewise.

Added:
    trunk/gcc/testsuite/gcc.dg/graphite/interchange-16.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/graphite-scop-detection.c
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/testsuite/gcc.dg/graphite/scop-20.c
    trunk/gcc/testsuite/gfortran.dg/graphite/block-1.f90
    trunk/gcc/testsuite/gfortran.dg/graphite/block-2.f
    trunk/gcc/testsuite/gfortran.dg/graphite/interchange-1.f

[Bug tree-optimization/50913] [4.7 Regression] ICE in scan_tree_for_params_right_scev, at graphite-sese-to-poly.c:633 compiling libgfortran with -floop-interchange -m32

[spop at gcc dot gnu.org]

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

Sebastian Pop <spop at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
                 CC|                            |spop at gcc dot gnu.org
         Resolution|FIXED                       |---

--- Comment #11 from Sebastian Pop <spop at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #8)
> There is a disconnect on how we analyze data-references during SCOP detection
> (outermost_loop is the root of the loop tree) and during SESE-to-poly where
> outermost is determined by outermost_loop_in_sese_1 ().  That influences
> the SCEV result and thus we do not break the SCOP at a stmt we have to break
> it.
> 
> The following patch fixes this using a sledgehammer - require the
> data-ref to be representable if analyzed with respect to all loops
> it can nest in.

This is an effective shortcut to disable graphite on a lot of loops...
see bug 14741.

Let me see if I can find a better solution is for this bug.

[Bug tree-optimization/50913] [4.7 Regression] ICE in scan_tree_for_params_right_scev, at graphite-sese-to-poly.c:633 compiling libgfortran with -floop-interchange -m32

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

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

--- Comment #12 from Richard Biener <rguenth at gcc dot gnu.org> ---
Please open a new bug for this.