Re: [Bug middle-end/38250] ICE with -O2 -ftree-loop-distribution
The patch looks good. Please test and ask for approval to commit to trunk on [EMAIL PROTECTED] Thanks, Sebastian
Re: [Bug bootstrap/38262] New: [4.4 regression] GCC components unnecessarily link with shared gmp/mpfr
Here is a patch from Dwarak for fixing this. He will send this to review on gcc-patches@ list. Sebastian Pop -- AMD - GNU Tools --- Makefile.in 2008-10-23 10:33:51.274495000 -0500 +++ Makefile.in.fix 2008-11-19 16:11:55.80298 -0600 @@ -903,8 +903,9 @@ BUILD_LIBDEPS=3D $(BUILD_LIBIBERTY) # How to link with both our special library facilities # and the system's installed libraries. -LIBS =3D @LIBS@ $(CPPLIB) $(LIBINTL) $(LIBICONV) $(LIBIBERTY) $(LIBDECNUMBER) \ - $(GMPLIBS) $(CLOOGLIBS) $(PPLLIBS) +LIBS =3D @LIBS@ $(CPPLIB) $(LIBINTL) $(LIBICONV) $(LIBIBERTY) $(LIBDECNUMBER)=20 + +BACKENDLIBS =3D $(GMPLIBS) $(CLOOGLIBS) $(PPLLIBS) # Any system libraries needed just for GNAT. SYSLIBS =3D @GNAT_LIBEXC@ @@ -1613,7 +1614,7 @@ libbackend.a: $([EMAIL PROTECTED]@) xgcc$(exeext): $(GCC_OBJS) gccspec.o version.o intl.o prefix.o \ version.o $(LIBDEPS) $(EXTRA_GCC_OBJS) $(CC) $(ALL_CFLAGS) $(LDFLAGS) -o $@ $(GCC_OBJS) gccspec.o \ - intl.o prefix.o version.o $(EXTRA_GCC_OBJS) $(LIBS) + intl.o prefix.o version.o $(EXTRA_GCC_OBJS) $(LIBS) $(BACKENDLIBS) # cpp is to cpp0 as gcc is to cc1. # The only difference from xgcc is that it's linked with cppspec.o @@ -1621,7 +1622,7 @@ xgcc$(exeext): $(GCC_OBJS) gccspec.o ver cpp$(exeext): $(GCC_OBJS) cppspec.o version.o intl.o prefix.o \ version.o $(LIBDEPS) $(EXTRA_GCC_OBJS) $(CC) $(ALL_CFLAGS) $(LDFLAGS) -o $@ $(GCC_OBJS) cppspec.o \ - intl.o prefix.o version.o $(EXTRA_GCC_OBJS) $(LIBS) + intl.o prefix.o version.o $(EXTRA_GCC_OBJS) $(LIBS) $(BACKENDLIBS) # Dump a specs file to make -B./ read these specs over installed ones. $(SPECS): xgcc$(exeext) @@ -1638,7 +1639,7 @@ dummy-checksum.o : dummy-checksum.c cc1-dummy$(exeext): $(C_OBJS) dummy-checksum.o $(BACKEND) $(LIBDEPS) $(CC) $(ALL_CFLAGS) $(LDFLAGS) -o $@ $(C_OBJS) dummy-checksum.o \ - $(BACKEND) $(LIBS) $(GMPLIBS) + $(BACKEND) $(LIBS) $(BACKENDLIBS) cc1-checksum.c : cc1-dummy$(exeext) build/genchecksum$(build_exeext) build/genchecksum$(build_exeext) cc1-dummy$(exeext) > $@ @@ -1647,7 +1648,7 @@ cc1-checksum.o : cc1-checksum.c cc1$(exeext): $(C_OBJS) cc1-checksum.o $(BACKEND) $(LIBDEPS) $(CC) $(ALL_CFLAGS) $(LDFLAGS) -o $@ $(C_OBJS) cc1-checksum.o \ - $(BACKEND) $(LIBS) $(GMPLIBS) + $(BACKEND) $(LIBS) $(BACKENDLIBS) # # Build libgcc.a.
Re: [Bug middle-end/37951] -ftree-parallelize-loops=2 fails for MA57
> gfortran -O3 -fdump-tree-vect-details -ftree-vectorize > -ftree-parallelize-loops=2 -c ma57.f > ma57.f: In function 'ma57sd': > ma57.f:1538: internal compiler error: Segmentation fault [...] > Program received signal SIGSEGV, Segmentation fault. > 0xb7ce06f9 in free () from /lib/tls/i686/cmov/libc.so.6 > (gdb) bt > #0 0xb7ce06f9 in free () from /lib/tls/i686/cmov/libc.so.6 > #1 0xb7cdcf43 in _IO_free_backup_area () from /lib/tls/i686/cmov/libc.so.6 > #2 0xb7cdafb2 in _IO_file_overflow () from /lib/tls/i686/cmov/libc.so.6 > #3 0xb7cda51b in _IO_file_xsputn () from /lib/tls/i686/cmov/libc.so.6 > #4 0xb7cb675f in vfprintf () from /lib/tls/i686/cmov/libc.so.6 > #5 0xb7cbf2e2 in fprintf () from /lib/tls/i686/cmov/libc.so.6 > #6 0x083a634e in vect_print_dump_info (vl=REPORT_DETAILS) at This ICE is different than the one you reported first: this fails in the debug dumps function. Could you report the backtrace using the following flags: gfortran -O3 -ftree-vectorize -ftree-parallelize-loops=2 -c ma57.f Thank you, Sebastian
Re: [Bug bootstrap/38262] [4.4 regression] GCC components unnecessarily link with shared gmp/mpfr
Thanks for catching the missing parts. Here is the updated patch. Does this patch look correct? I sent this patch to test on the gccfarm and will send an email to gcc-patches after it completes regstrap. Thanks, Sebastian On Tue, Nov 25, 2008 at 5:08 PM, ghazi at gcc dot gnu dot org <[EMAIL PROTECTED]> wrote: > > > --- Comment #2 from ghazi at gcc dot gnu dot org 2008-11-25 23:08 --- > (In reply to comment #1) >> Subject: Re: New: [4.4 regression] GCC components unnecessarily link with >> shared gmp/mpfr >> Here is a patch from Dwarak for fixing this. >> He will send this to review on gcc-patches@ list. >> Sebastian Pop >> -- >> AMD - GNU Tools > > Thanks, however I don't understand why in this patch xgcc and cpp are being > linked with BACKENDLIBS. They don't linked with libbackend.a. > > Also, there are many more places where you do need to add BACKENDLIBS like > cc1plus, cc1obj, f951, jc1, etc. See here for all the places you'll need to > catch: > > http://gcc.gnu.org/ml/gcc-patches/2008-02/msg00187.html > > > -- > > ghazi at gcc dot gnu dot org changed: > > What|Removed |Added > > Status|UNCONFIRMED |NEW > Ever Confirmed|0 |1 > Last reconfirmed|-00-00 00:00:00 |2008-11-25 23:08:54 > date|| > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38262 > > Index: gcc/java/Make-lang.in === --- gcc/java/Make-lang.in (revision 142224) +++ gcc/java/Make-lang.in (working copy) @@ -101,7 +101,7 @@ jvspec.o-warn = -Wno-error jc1$(exeext): $(JAVA_OBJS) $(BACKEND) $(LIBDEPS) attribs.o rm -f $@ $(CC) $(ALL_CFLAGS) $(LDFLAGS) -o $@ \ - $(JAVA_OBJS) $(BACKEND) $(ZLIB) $(LIBICONV) $(LIBS) attribs.o $(GMPLIBS) + $(JAVA_OBJS) $(BACKEND) $(ZLIB) $(LIBICONV) $(LIBS) attribs.o $(BACKENDLIBS) jcf-dump$(exeext): $(JCFDUMP_OBJS) $(LIBDEPS) rm -f $@ Index: gcc/objc/Make-lang.in === --- gcc/objc/Make-lang.in (revision 142224) +++ gcc/objc/Make-lang.in (working copy) @@ -54,7 +54,7 @@ objc_OBJS = $(OBJC_OBJS) cc1obj-checksum cc1obj-dummy$(exeext): $(OBJC_OBJS) $(C_AND_OBJC_OBJS) dummy-checksum.o $(BACKEND) $(LIBDEPS) $(CC) $(ALL_CFLAGS) $(LDFLAGS) -o $@ \ $(OBJC_OBJS) $(C_AND_OBJC_OBJS) dummy-checksum.o \ - $(BACKEND) $(LIBS) $(GMPLIBS) + $(BACKEND) $(LIBS) $(BACKENDLIBS) cc1obj-checksum.c : cc1obj-dummy$(exeext) build/genchecksum$(build_exeext) build/genchecksum$(build_exeext) cc1obj-dummy$(exeext) > $@ @@ -64,7 +64,7 @@ cc1obj-checksum.o : cc1obj-checksum.c cc1obj$(exeext): $(OBJC_OBJS) $(C_AND_OBJC_OBJS) cc1obj-checksum.o $(BACKEND) $(LIBDEPS) $(CC) $(ALL_CFLAGS) $(LDFLAGS) -o $@ \ $(OBJC_OBJS) $(C_AND_OBJC_OBJS) cc1obj-checksum.o \ - $(BACKEND) $(LIBS) $(GMPLIBS) + $(BACKEND) $(LIBS) $(BACKENDLIBS) # Objective C language specific files. Index: gcc/objcp/Make-lang.in === --- gcc/objcp/Make-lang.in (revision 142224) +++ gcc/objcp/Make-lang.in (working copy) @@ -56,7 +56,7 @@ obj-c++_OBJS = $(OBJCXX_OBJS) cc1objplus cc1objplus-dummy$(exeext): $(OBJCXX_OBJS) dummy-checksum.o $(BACKEND) \ $(LIBDEPS) $(CC) $(ALL_CFLAGS) $(LDFLAGS) -o $@ \ - $(OBJCXX_OBJS) dummy-checksum.o $(BACKEND) $(LIBS) $(GMPLIBS) + $(OBJCXX_OBJS) dummy-checksum.o $(BACKEND) $(LIBS) $(BACKENDLIBS) cc1objplus-checksum.c : cc1objplus-dummy$(exeext) build/genchecksum$(build_exeext) build/genchecksum$(build_exeext) cc1objplus-dummy$(exeext) > $@ @@ -65,7 +65,7 @@ cc1objplus-checksum.o : cc1objplus-check cc1objplus$(exeext): $(OBJCXX_OBJS) cc1objplus-checksum.o $(BACKEND) $(LIBDEPS) $(CC) $(ALL_CFLAGS) $(LDFLAGS) -o $@ \ - $(OBJCXX_OBJS) cc1objplus-checksum.o $(BACKEND) $(LIBS) $(GMPLIBS) + $(OBJCXX_OBJS) cc1objplus-checksum.o $(BACKEND) $(LIBS) $(BACKENDLIBS) # Objective C++ language specific files. Index: gcc/cp/Make-lang.in === --- gcc/cp/Make-lang.in (revision 142224) +++ gcc/cp/Make-lang.in (working copy) @@ -93,7 +93,7 @@ cp-warn = $(STRICT_WARN) cc1plus-dummy$(exeext): $(CXX_OBJS) dummy-checksum.o $(BACKEND) $(LIBDEPS) $(CC) $(ALL_CFLAGS) $(LDFLAGS) -o $@ \ - $(CXX_OBJS) dummy-checksum.o $(BACKEND) $(LIBS) $(GMPLIBS) + $(CXX_OBJS) dummy-checksum.o $(BACKEND) $(LIBS) $(BACKENDLIBS) cc1plus-checksum.c : cc1plus-dummy$(exeext) build/genchecksum$(build_exeext) build/genchecksum$(build_exeext) cc1plus-dummy$(exeext) > $@ @@ -102,7 +102,7 @@ cc1plus-checksum.o : cc1plus-checksum.c cc1plus$(exeext):
Re: [Bug bootstrap/38262] [4.4 regression] GCC components unnecessarily link with shared gmp/mpfr
On Fri, Nov 28, 2008 at 3:38 AM, jakub at gcc dot gnu dot org <[EMAIL PROTECTED]> wrote: > The patch looks good to me (if not obvious). Sebastian, are you going to post > it to gcc-patches? I just sent it to gcc-patches. Sorry this took me so long to send: it went out of my radar. Sebastian
Re: [Bug middle-end/38446] [graphite] The def for a var exists inside one of the scops bb's but an appropriate phi is not created to allow the phi to reach the use of that def ouside the scop.
On Wed, Dec 10, 2008 at 4:34 PM, hjagasia at gcc dot gnu dot org <[EMAIL PROTECTED]> wrote: > > > --- Comment #3 from hjagasia at gcc dot gnu dot org 2008-12-10 22:34 > --- > Created an attachment (id=16880) > --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16880&action=view) > Updated patch reviewed by Sebastian This looks better thanks. Ok for graphite branch.
Re: [Bug c/38755] [graphite] wrong code with -O3 -fgraphite-identity -floop-block on polyhedron benchmarks
> --- Comment #2 from howarth at nitro dot med dot uc dot edu 2009-01-08 > 16:20 --- > What checkin fixed this? Or can't you reproduce the failure? If the latter, > what happens if you use -m32 on amd64-linux? I'm running the polyhedron bmk with -m32 and will report the result. But this should be fixed now by the patch for PR38559. Sebastian
Re: [Bug middle-end/38431] [graphite] several ICEs with CP2K (summary)
Hi, I compiled BLAS and LAPACK with the gfortran compiler of the graphite branch such that I could test the CP2K benchmark. On my laptop, that is an amd64-linux, "make test" passes with the gfortran compiler from the graphite branch. However I'm not able to run the test that you reported failing: ./cp2k.sopt canonical.inp CP2K: The specified file canonical.inp can not be opened, it does not exist. STOP 1 Could you tell me where I can find the canonical.inp file, or how to reproduce the fail? Thanks, Sebastian
Re: [Bug middle-end/38431] [graphite] several ICEs with CP2K (summary)
Thanks for the clarification, I managed to reproduce the fail. The problem comes from the fact that we do not generate code for a scalar reduction that is not detected as a scalar reduction with the variable connection$dim$1$lbound. In the attached output from debug_loops (3) I selected the region of code containing both the original loops: loop_3 and loop_4 and the code generated by graphite with -fgraphite-identity: loop_22, loop_23. In loop_22 the computation on connection$dim$1$lbound disappears. I wonder what this variable stands for: it is not used elsewhere in the debug_loops (3) output of change_bond_length function, and I suspect that this is a global variable whose value is needed elsewhere outside the change_bond_length function. The bug is in the detection of scalar reductions. Sebastian 2 Description: Binary data
Re: [Bug middle-end/38431] [graphite] several ICEs with CP2K (summary)
Attached a fix for this PR. I will regstrap and submit for review.
Sebastian
2009-01-14 Sebastian Pop
PR middle-end/38431
* graphite.c (get_vdef_before_scop, scop_adjust_vphi): New.
(scop_adjust_phis_for_liveouts): Call scop_adjust_vphi.
(gloog): Do not call cleanup_tree_cfg.
(graphite_transform_loops): Call cleanup_tree_cfg after all
scops have been code generated.
Index: graphite.c
===
--- graphite.c (revision 143346)
+++ graphite.c (working copy)
@@ -5188,6 +5188,82 @@ scop_insert_phis_for_liveouts (sese regi
update_ssa (TODO_update_ssa);
}
+/* Get the definition of NAME before the SCOP. Keep track of the
+ basic blocks that have been VISITED in a bitmap. */
+
+static tree
+get_vdef_before_scop (scop_p scop, tree name, sbitmap visited)
+{
+ unsigned i;
+ gimple def_stmt = SSA_NAME_DEF_STMT (name);
+ basic_block def_bb = gimple_bb (def_stmt);
+
+ if (!bb_in_scop_p (def_bb, scop))
+return name;
+
+ if (TEST_BIT (visited, def_bb->index))
+return NULL_TREE;
+
+ SET_BIT (visited, def_bb->index);
+
+ switch (gimple_code (def_stmt))
+{
+case GIMPLE_PHI:
+ for (i = 0; i < gimple_phi_num_args (def_stmt); i++)
+ {
+ tree arg = gimple_phi_arg_def (def_stmt, i);
+ tree res = get_vdef_before_scop (scop, arg, visited);
+ if (res)
+ return res;
+ }
+ return NULL_TREE;
+
+default:
+ return NULL_TREE;
+}
+}
+
+/* Adjust a virtual phi node PHI that is placed at the end of the
+ generated code for SCOP:
+
+ | if (1)
+ | generated code from REGION;
+ | else
+ | REGION;
+
+ The FALSE_E edge comes from the original code, TRUE_E edge comes
+ from the code generated for the SCOP. */
+
+static void
+scop_adjust_vphi (scop_p scop, gimple phi, edge true_e)
+{
+ unsigned i;
+
+ gcc_assert (gimple_phi_num_args (phi) == 2);
+
+ for (i = 0; i < gimple_phi_num_args (phi); i++)
+if (gimple_phi_arg_edge (phi, i) == true_e)
+ {
+ tree true_arg, false_arg, before_scop_arg;
+ sbitmap visited;
+
+ true_arg = gimple_phi_arg_def (phi, i);
+ if (!SSA_NAME_IS_DEFAULT_DEF (true_arg))
+ return;
+
+ false_arg = gimple_phi_arg_def (phi, i == 0 ? 1 : 0);
+ if (SSA_NAME_IS_DEFAULT_DEF (false_arg))
+ return;
+
+ visited = sbitmap_alloc (last_basic_block);
+ sbitmap_zero (visited);
+ before_scop_arg = get_vdef_before_scop (scop, false_arg, visited);
+ gcc_assert (before_scop_arg != NULL_TREE);
+ SET_PHI_ARG_DEF (phi, i, before_scop_arg);
+ sbitmap_free (visited);
+ }
+}
+
/* Adjusts the phi nodes in the block BB for variables defined in
SCOP_REGION and used outside the SCOP_REGION. The code generation
moves SCOP_REGION in the else clause of an "if (1)" and generates
@@ -5214,7 +5290,10 @@ scop_adjust_phis_for_liveouts (scop_p sc
gimple phi = gsi_stmt (si);
if (!is_gimple_reg (PHI_RESULT (phi)))
- continue;
+ {
+ scop_adjust_vphi (scop, phi, true_e);
+ continue;
+ }
for (i = 0; i < gimple_phi_num_args (phi); i++)
if (gimple_phi_arg_edge (phi, i) == false_e)
@@ -5396,9 +5475,6 @@ gloog (scop_p scop, struct clast_stmt *s
recompute_all_dominators ();
graphite_verify ();
- cleanup_tree_cfg ();
- recompute_all_dominators ();
- graphite_verify ();
}
/* Returns the number of data references in SCOP. */
@@ -6095,6 +6171,7 @@ graphite_transform_loops (void)
}
/* Cleanup. */
+ cleanup_tree_cfg ();
free_scops (current_scops);
cloog_finalize ();
free_original_copy_tables ();
Re: [Bug testsuite/38791] FAIL: gcc.dg/graphite/block-3.c (test for excess errors)
> Before closing this pr as fixed, I have a question: usually tests having
> -fdump-* in dg-options are doing some search of patterns in the dumped file,
> e.g. in gcc/testsuite/gcc.dg/pr35729.c
>
> /* { dg-options "-Os -fdump-rtl-loop2_invariant" } */
> ...
> /* { dg-final { scan-rtl-dump-times "Decided to move invariant" 0
> "loop2_invariant" } } */
>
> I noticed that gcc/testsuite/gcc.dg/graphite/block-3.c has only the cleaning
> dg-final, but no scan-* one(s). I don't see anything in
> gcc/testsuite/gcc.dg/graphite/graphite.exp that could supply it either.
> Is this the intended behavior or is there something missing in this test (and
> possibly other graphite ones)?
The test for loop blocking is missing in block-3.c. We will have to
clean up the graphite testsuite and making the tests more reliable,
but probably this will be done in GCC4.5.
Sebastian
Re: [Bug middle-end/38846] New: [Graphite] 70% slower using -floop* than without graphite (gas_dyn of Polyhedron)
Hi, Thanks for this report. Please also test with the code of graphite branch that contains a patch that schedules several scalar optimizations that can improve the quality of the code generated. Thanks, Sebastian Pop -- AMD - GNU Tools
Re: [Bug tree-optimization/40062] [4.3/4.4/4.5 Regression] high memory usage and compile time in SCEV cprop with -O3
> + /* Increase the limit by the PHI argument number to avoid exponential > + time and memory complexity. */ This looks good. Thanks, Sebastian
Re: [Bug middle-end/40965] [4.5 Regression][graphite] slow compilation
What changed from 4.4 to 4.5 is that we now get to compile larger SCoPs with Graphite. In 4.5, Graphite can deal with reductions and other unhandled constructs like the NE_EXPR that Fortran is frequently using for representing the exit condition of DO loops.
Re: [Bug objc++/37335] Boostrap failed on obj-c++ "too many arguments to function 'build_array_ref'"
On Tue, Sep 2, 2008 at 12:22 PM, 3dw4rd at verizon dot net <[EMAIL PROTECTED]> wrote: > Graphite just went it. > > I might just wait till the turbulence dies down and try again. This should be another problem: graphite has not touched the code of build_array_ref, nor the code of gcc/objc/objc-act.c Sebastian
Re: [Bug middle-end/37372] [graphite] SCoP detection splits bbs / Define SCoPs with single entry and exit edge
> --- Comment #7 from grosser at gcc dot gnu dot org 2008-09-29 13:14 > --- > Committed SVN 140746. I see that in http://gcc.gnu.org/viewcvs?view=rev&revision=140746 you forgot to include in the changelog a line like this: PR tree-optimization/37372 that would have automatically included the commit message in the bugzilla bug.
Re: [Bug tree-optimization/37690] typo in the example for -floop-strip-mine
The patch looks good. Please install. I also have installed a similar patch in htdocs/gcc-4.4/changes.html
Re: [Bug tree-optimization/37686] [4.4 Regression] Building of CPU2000's bzip2 with peak flags with -mcpu=power4 fails with an ICE.
Here is a patch that should fix this bug. Can somebody test that it fixes it?
Thanks,
Sebastian
Index: tree-loop-linear.c
===
--- tree-loop-linear.c (revision 140668)
+++ tree-loop-linear.c (working copy)
@@ -333,11 +333,16 @@ linear_transform_loops (void)
lambda_loopnest before, after;
lambda_trans_matrix trans;
struct obstack lambda_obstack;
+ struct loop *loop;
+ VEC(loop_p,heap) *nest = VEC_alloc (loop_p, heap, 3);
depth = perfect_loop_nest_depth (loop_nest);
if (depth == 0)
continue;
+ for (loop = loop_nest; loop; loop = loop->inner)
+ VEC_safe_push (loop_p, heap, nest, loop);
+
gcc_obstack_init (&lambda_obstack);
VEC_truncate (tree, oldivs, 0);
VEC_truncate (tree, invariants, 0);
@@ -350,8 +355,7 @@ linear_transform_loops (void)
goto free_and_continue;
lambda_collect_parameters (datarefs, &lambda_parameters);
- if (!lambda_compute_access_matrices (datarefs, lambda_parameters,
- loop_nest->num))
+ if (!lambda_compute_access_matrices (datarefs, lambda_parameters, nest))
goto free_and_continue;
if (dump_file && (dump_flags & TDF_DETAILS))
@@ -410,6 +414,7 @@ linear_transform_loops (void)
obstack_free (&lambda_obstack, NULL);
free_dependence_relations (dependence_relations);
free_data_refs (datarefs);
+ VEC_free (loop_p, heap, nest);
}
for (i = 0; VEC_iterate (gimple, remove_ivs, i, oldiv_stmt); i++)
Index: tree-data-ref.h
===
--- tree-data-ref.h (revision 140668)
+++ tree-data-ref.h (working copy)
@@ -128,13 +128,13 @@ typedef struct scop *scop_p;
*/
struct access_matrix
{
- int loop_nest_num;
+ VEC (loop_p, heap) *loop_nest;
int nb_induction_vars;
VEC (tree, heap) *parameters;
VEC (lambda_vector, heap) *matrix;
};
-#define AM_LOOP_NEST_NUM(M) (M)->loop_nest_num
+#define AM_LOOP_NEST(M) (M)->loop_nest
#define AM_NB_INDUCTION_VARS(M) (M)->nb_induction_vars
#define AM_PARAMETERS(M) (M)->parameters
#define AM_MATRIX(M) (M)->matrix
@@ -149,8 +149,14 @@ struct access_matrix
static inline int
am_vector_index_for_loop (struct access_matrix *access_matrix, int loop_num)
{
- gcc_assert (loop_num >= AM_LOOP_NEST_NUM (access_matrix));
- return loop_num - AM_LOOP_NEST_NUM (access_matrix);
+ int i;
+ loop_p l;
+
+ for (i = 0; VEC_iterate (loop_p, AM_LOOP_NEST (access_matrix), i, l); i++)
+if (l->num == loop_num)
+ return i;
+
+ gcc_unreachable();
}
int access_matrix_get_index_for_parameter (tree, struct access_matrix *);
@@ -581,7 +587,7 @@ bool lambda_transform_legal_p (lambda_tr
void lambda_collect_parameters (VEC (data_reference_p, heap) *,
VEC (tree, heap) **);
bool lambda_compute_access_matrices (VEC (data_reference_p, heap) *,
- VEC (tree, heap) *, int);
+ VEC (tree, heap) *, VEC (loop_p, heap) *);
/* In tree-data-ref.c */
void split_constant_offset (tree , tree *, tree *);
Index: lambda-code.c
===
--- lambda-code.c (revision 140668)
+++ lambda-code.c (working copy)
@@ -2786,17 +2786,15 @@ av_for_af (tree access_fun, lambda_vecto
static bool
build_access_matrix (data_reference_p data_reference,
- VEC (tree, heap) *parameters, int loop_nest_num)
+ VEC (tree, heap) *parameters, VEC (loop_p, heap) *nest)
{
struct access_matrix *am = GGC_NEW (struct access_matrix);
unsigned i, ndim = DR_NUM_DIMENSIONS (data_reference);
- struct loop *loop = gimple_bb (DR_STMT (data_reference))->loop_father;
- struct loop *loop_nest = get_loop (loop_nest_num);
- unsigned nivs = loop_depth (loop) - loop_depth (loop_nest) + 1;
+ unsigned nivs = VEC_length (loop_p, nest);
unsigned lambda_nb_columns;
lambda_vector_vec_p matrix;
- AM_LOOP_NEST_NUM (am) = loop_nest_num;
+ AM_LOOP_NEST (am) = nest;
AM_NB_INDUCTION_VARS (am) = nivs;
AM_PARAMETERS (am) = parameters;
@@ -2824,13 +2822,13 @@ build_access_matrix (data_reference_p da
bool
lambda_compute_access_matrices (VEC (data_reference_p, heap) *datarefs,
VEC (tree, heap) *parameters,
-int loop_nest_num)
+VEC (loop_p, heap) *nest)
{
data_reference_p dataref;
unsigned ix;
for (ix = 0; VEC_iterate (data_reference_p, datarefs, ix, dataref); ix++)
-if (!build_access_matrix (dataref, parameters, loop_nest_num))
+if (!build_access_matrix (dataref, parameters, nest))
return false;
return true;
Re: [Bug tree-optimization/37573] [4.4 Regression] gcc-4.4 regression: incorrect code generation with -O1 -ftree-vectorize
> common base. Consider &s.c[1] and &s + i, obviously the accesses can
> overlap - would you still say so if the base address of the first one
> would be &s.c[0]?
Yes, in the case &s.c[1] versus &s.c[0], we still have to consider the
arrays to potentially overlap.
> (really the base address of a non-variable access is the access
> itself, right? &s.c[1] in this case)
No, it cannot be &s.c[1] here. The base object for arrays in structs
should be the struct itself.
The base address tells you what memory object is accessed with an
offset. For structs, you are allowed to access any of their contents
using arithmetic. For instance in:
struct s {
int a[2];
int c[20];
}
you could access s.c[10] from the address of struct s with: &s.a + 12.
Re: [Bug middle-end/37883] [graphite] ICE : in scan_tree_for_params, at graphite.c:2274
> It seems PLUS_EXPR and POINTER_PLUS_EXPR can really handled identically. > So I will like to commit this patch. Yes they should be handled in the same way in this context. Please install the patch. Thanks, Sebastian
Re: [Bug middle-end/37379] [graphite] ICE compiling aermod.f90 with -ffast-math -floop-block -O2 -fgraphite
Hi,
For the first part of the bug:
> aermod.f90:14521: internal compiler error: in instantiate_scev_1, at
> tree-scalar-evolution.c:2220
the bug was introduced by an automatic rewrite arount TREE_CODE_LENGTH
http://gcc.gnu.org/viewcvs?view=rev&revision=122018
The fix avoids the gcc_assert by returning "unknown scalar evolution".
The second part of the bug was already fixed:
> aermod.f90:8312: internal compiler error: in expand_scalar_variables_expr, at
> graphite.c:3168
I will apply the patch below once it finishes regstrap.
Sebastian
Index: tree-scalar-evolution.c
===
--- tree-scalar-evolution.c (revision 141661)
+++ tree-scalar-evolution.c (working copy)
@@ -2213,7 +2213,9 @@ instantiate_scev_1 (basic_block instanti
break;
}
- gcc_assert (!VL_EXP_CLASS_P (chrec));
+ if (VL_EXP_CLASS_P (chrec))
+return chrec_dont_know;
+
switch (TREE_CODE_LENGTH (TREE_CODE (chrec)))
{
case 3:
Re: [Bug middle-end/39308] ICE when compiling with -O[s123] -floop-interchange
Hi, Can you try this patch. It should fix your problem. I will bootstrap and test the patch and send it for review. Thanks, Sebastian Pop -- AMD - GNU Tools On Thu, Feb 26, 2009 at 13:46, il dot basso dot buffo at gmail dot com wrote: > > > --- Comment #9 from il dot basso dot buffo at gmail dot com 2009-02-26 > 19:46 --- > Thanks, Sebastian. I followed your directions, except I used -O1 instead of > -O2. Here's the backtrace: > > #0 is_gimple_val (t=0x0) at ../.././gcc/gimple.c:2853 > #1 0x0055dec4 in force_gimple_operand (expr=0x0, > stmts=0x7fffdc78a538, > simple=1 '\001', var=0x0) at ../.././gcc/gimplify.c:7592 > #2 0x0097fc22 in build_scop_loop_nests (scop=0x12ce530) at > ../.././gcc/graphite.c:2387 > #3 0x00981f1a in limit_scops () at ../.././gcc/graphite.c:6081 > #4 0x00983de7 in graphite_transform_loops () at > ../.././gcc/graphite.c:6124 > #5 0x006cd137 in graphite_transforms () at > ../.././gcc/tree-ssa-loop.c:298 > #6 0x005b87ca in execute_one_pass (pass=0xe8ab60) at > ../.././gcc/passes.c:1277 > #7 0x005b89b0 in execute_pass_list (pass=0xe8ab60) at > ../.././gcc/passes.c:1326 > #8 0x005b89c5 in execute_pass_list (pass=0xe8a8c0) at > ../.././gcc/passes.c:1327 > #9 0x005b89c5 in execute_pass_list (pass=0xe89d80) at > ../.././gcc/passes.c:1327 > #10 0x00678bca in tree_rest_of_compilation (fndecl=0x7fbcd2977100) at > ../.././gcc/tree-optimize.c:420 > #11 0x00789665 in cgraph_expand_function (node=0x7fbcd2977700) at > ../.././gcc/cgraphunit.c:1047 > #12 0x0078ab00 in cgraph_optimize () at ../.././gcc/cgraphunit.c:1106 > #13 0x00413dcb in c_write_global_declarations () at > ../.././gcc/c-decl.c:8102 > #14 0x0064301e in toplev_main (argc=, argv= optimized out>) at ../.././gcc/toplev.c:981 > #15 0x7fbcd315c60d in __libc_start_main () from /lib/libc.so.6 > #16 0x00405229 in _start () > > > -- > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39308 > > Index: graphite.c === --- graphite.c (revision 144404) +++ graphite.c (working copy) @@ -2382,8 +2382,10 @@ graphite_loop_normal_form (loop_p loop) tree nit; gimple_seq stmts; edge exit = single_dom_exit (loop); + bool known_niter = number_of_iterations_exit (loop, exit, &niter, false); + + gcc_assert (known_niter); - gcc_assert (number_of_iterations_exit (loop, exit, &niter, false)); nit = force_gimple_operand (unshare_expr (niter.niter), &stmts, true, NULL_TREE); if (stmts)
Re: [Bug middle-end/39335] ICE in GCC 4.4 with -O[123] -floop-interchange
Hi,
The only thing that graphite modifies is from canonicalize_loop_ivs:
here is the diff between "1" that is the debug_loops (3) before
graphite and "2" that is after graphite.
--- 1 2009-03-02 12:20:03.0 -0600
+++ 2 2009-03-02 12:20:18.0 -0600
@@ -23,6 +23,8 @@
bb_4 (preds = {bb_3 }, succs = {bb_10 })
{
:
+D.1655_27 = (unsigned int) width_12(D);
+D.1656_25 = D.1655_27 + 4294967295;
goto ;
}
@@ -90,6 +92,8 @@
bb_11 (preds = {bb_10 }, succs = {bb_6 })
{
:
+ D.1652_24 = (unsigned int) num_comp_14(D);
+ D.1653_6 = D.1652_24 + 4294967295;
goto ;
}
@@ -98,16 +102,18 @@
bb_5 (preds = {bb_6 }, succs = {bb_6 })
{
:
+ivtmp.25_2 = ivtmp.25_4 + 1;
}
bb_6 (preds = {bb_5 bb_11 }, succs = {bb_5 bb_7 })
{
:
-# in_47 = PHI
-# out_48 = PHI
-# i_49 = PHI
# SMT.10_50 = PHI
# SMT.11_52 = PHI
+# ivtmp.25_4 = PHI
+in_47 = in_21 + ivtmp.25_4;
+out_48 = out_32 + ivtmp.25_4;
+i_49 = (int) ivtmp.25_4;
# VUSE { SMT.10 SMT.11 }
D.1617_15 = *in_47;
# SMT.10_30 = VDEF
@@ -116,7 +122,7 @@
out_16 = out_48 + 1;
in_17 = in_47 + 1;
i_18 = i_49 + 1;
-if (num_comp_14(D) > i_18)
+if (ivtmp.25_4 < D.1653_6)
goto ;
else
goto ;
The fail is in RTL expand in copy_to_mode_reg:
gcc_assert (GET_MODE (x) == mode || GET_MODE (x) == VOIDmode);
(gdb) p x->mode
$16 = SImode
(gdb) p mode
$17 = DImode
It looks like a type problem for the condition to be expanded:
(gdb) p exp
$18 = (tree) 0x7fa9967d2e00
(gdb) pgs
ivtmp.25 < D.1653;
So after figuring out that canonicalize_loop_ivs does compute the
largest precision for all the phi nodes of the loop, such that the new
induction variable can represent all the values of the old IVs, i.e:
for (psi = gsi_start_phis (loop->header);
!gsi_end_p (psi); gsi_next (&psi))
{
phi = gsi_stmt (psi);
res = PHI_RESULT (phi);
if (is_gimple_reg (res) && TYPE_PRECISION (TREE_TYPE (res)) > precision)
precision = TYPE_PRECISION (TREE_TYPE (res));
}
type = lang_hooks.types.type_for_size (precision, 1);
it does not fold_convert the number of iterations to this new type,
and thus we end up building a condition with two different precision
types: 32 for niter and 64 for the new IV.
Attached is a fix for this problem, and the diff between 1 before and
5 after graphite looks like this:
--- 1 2009-03-02 12:20:03.0 -0600
+++ 5 2009-03-02 12:54:27.0 -0600
@@ -23,6 +23,8 @@
bb_4 (preds = {bb_3 }, succs = {bb_10 })
{
:
+D.1656_25 = (unsigned int) width_12(D);
+D.1657_5 = D.1656_25 + 4294967295;
goto ;
}
@@ -90,6 +92,9 @@
bb_11 (preds = {bb_10 }, succs = {bb_6 })
{
:
+ D.1652_24 = (unsigned int) num_comp_14(D);
+ D.1653_6 = D.1652_24 + 4294967295;
+ D.1654_4 = (long unsigned int) D.1653_6;
goto ;
}
@@ -98,16 +103,18 @@
bb_5 (preds = {bb_6 }, succs = {bb_6 })
{
:
+ivtmp.25_27 = ivtmp.25_2 + 1;
}
bb_6 (preds = {bb_5 bb_11 }, succs = {bb_5 bb_7 })
{
:
-# in_47 = PHI
-# out_48 = PHI
-# i_49 = PHI
# SMT.10_50 = PHI
# SMT.11_52 = PHI
+# ivtmp.25_2 = PHI
+in_47 = in_21 + ivtmp.25_2;
+out_48 = out_32 + ivtmp.25_2;
+i_49 = (int) ivtmp.25_2;
# VUSE { SMT.10 SMT.11 }
D.1617_15 = *in_47;
# SMT.10_30 = VDEF
@@ -116,7 +123,7 @@
out_16 = out_48 + 1;
in_17 = in_47 + 1;
i_18 = i_49 + 1;
-if (num_comp_14(D) > i_18)
+if (ivtmp.25_2 < D.1654_4)
goto ;
else
goto ;
Sebastian Pop
--
AMD - GNU Tools
Index: tree-parloops.c
===
--- tree-parloops.c (revision 144544)
+++ tree-parloops.c (working copy)
@@ -1338,6 +1338,7 @@ canonicalize_loop_ivs (struct loop *loop
affine_iv iv;
edge exit = single_dom_exit (loop);
struct reduction_info *red;
+ gimple_seq stmts;
for (psi = gsi_start_phis (loop->header);
!gsi_end_p (psi); gsi_next (&psi))
@@ -1351,6 +1352,11 @@ canonicalize_loop_ivs (struct loop *loop
type = lang_hooks.types.type_for_size (precision, 1);
+ nit = fold_convert (type, nit);
+ nit = force_gimple_operand (nit, &stmts, true, NULL_TREE);
+ if (stmts)
+gsi_insert_seq_on_edge_immediate (loop_preheader_edge (loop), stmts);
+
gsi = gsi_last_bb (loop->latch);
create_iv (build_int_cst_type (type, 0), build_int_cst (type, 1), NULL_TREE,
loop, &gsi, true, &var_before, NULL);
Re: [Bug middle-end/39447] ICE in create_data_ref with -O1 -floop-interchange
Thanks for the reduced testcase, it completely went out of my radar (by now my delta script should have finished reducing it as well on the gcc-farm, but I won't even look at it). Thanks again for the reduced case. I will look at the bug now. Sebastian
Re: [Bug middle-end/39447] ICE in create_data_ref with -O1 -floop-interchange
Hi,
I don't know who coded the overly complicated exclude_component_ref.
In the graphite branch we already cleaned up all this code, but in
trunk we still have it.
Attached is a patch that fixes the problem by looking at whether the
operand contains COMPONENT_REFs before calling the data reference
analysis.
I'm testing the patch on the gcc farm, and will send it to the gcc-patches
once it finishes regstrap.
Sebastian
* graphite.c (exclude_component_ref): Renamed contains_component_ref_p.
(is_simple_operand): Call contains_component_ref_p before calling data
reference analysis that would fail on COMPONENT_REFs.
Index: graphite.c
===
--- graphite.c (revision 144893)
+++ graphite.c (working copy)
@@ -1062,27 +1062,20 @@ loop_affine_expr (basic_block scop_entry
is component_ref. */
static bool
-exclude_component_ref (tree op)
+contains_component_ref_p (tree op)
{
int i;
- int len;
- if (op)
-{
- if (TREE_CODE (op) == COMPONENT_REF)
- return false;
- else
- {
- len = TREE_OPERAND_LENGTH (op);
- for (i = 0; i < len; ++i)
- {
- if (!exclude_component_ref (TREE_OPERAND (op, i)))
- return false;
- }
- }
-}
+ if (!op)
+return false;
- return true;
+ if (TREE_CODE (op) == COMPONENT_REF)
+return true;
+
+ for (i = 0; i < TREE_OPERAND_LENGTH (op); i++)
+return contains_component_ref_p (TREE_OPERAND (op, i));
+
+ return false;
}
/* Return true if the operand OP is simple. */
@@ -1094,13 +1087,15 @@ is_simple_operand (loop_p loop, gimple s
if (DECL_P (op)
/* or a structure, */
|| AGGREGATE_TYPE_P (TREE_TYPE (op))
+ /* or a COMPONENT_REF, */
+ || contains_component_ref_p (op)
/* or a memory access that cannot be analyzed by the data
reference analysis. */
|| ((handled_component_p (op) || INDIRECT_REF_P (op))
&& !stmt_simple_memref_p (loop, stmt, op)))
return false;
- return exclude_component_ref (op);
+ return true;
}
/* Return true only when STMT is simple enough for being handled by
Re: [Bug middle-end/39568] [graphite] Remove GBB_LOOPS
Awesome! Thanks Li, the patch looks good. Tobias will take care of including it to the graphite branch. Sebastian
Re: [Bug tree-optimization/41406] -O3 conflict with -floop-strip-mine internal compiler error: in build_loop_iteration_domains, at graphite-sese-to-poly.c:1156
Could you run gdb and report the backtrace? # gdb build-gcc/gcc/cc1 (gdb) run -O3 -floop-strip-mine ... aes.i (gdb) bt Thanks, Sebastian
Re: [Bug tree-optimization/41811] graphite miscompiles 454.calculix of the SPEC 2k6
On Fri, Oct 23, 2009 at 14:46, spop at gcc dot gnu dot org
wrote:
> and the code generated by CLooG for the interchange looks like this:
>
> for (scat_1=0;scat_1<=2;scat_1++) {
> for (scat_3=0;scat_3<=2;scat_3++) {
> S4(scat_1,scat_3) ;
> for (scat_5=0;scat_5<=2;scat_5++) {
> S5(scat_1,scat_5,scat_3) ;
> }
> S7(scat_1,scat_3) ;
> S18(scat_1,scat_3) ;
> }
S7 and S18 should not be generated before S5 finishes to execute over
all the iterations of the original innermost loop (do k=1,20).
S7 and S18 contain the end of the reduction and the write in the array
xs(i,j) that is independent of the k loop.
> for (scat_3=3;scat_3<=19;scat_3++) {
> for (scat_5=0;scat_5<=2;scat_5++) {
> S5(scat_1,scat_5,scat_3) ;
> }
> }
> }
Re: [Bug bootstrap/45146] Bootstrap broken at -O3
We do bootstrap on amd64-linux the graphite branch for every commit, and that would be the equivalent of your patch. Please open a new bug for tracking this issue. Thanks, Sebastian
Re: [Bug tree-optimization/46194] [4.5/4.6 Regression] gcc.dg/graphite/block-0.c FAILs with -ftree-parallelize-loops
Here is the loop kernel from block-0.c
for (i = 0; i < N; i++)
for (j = 0; j < N; j++)
a[j] = a[i] + 1;
On Fri, Dec 31, 2010 at 06:01, jakub at gcc dot gnu.org
wrote:
> access_fn_A: {0, +, 1}_1
> access_fn_B: {0, +, 1}_2
>
> (subscript
> iterations_that_access_an_element_twice_in_A: [0 + 1 * x_1]
> last_conflict: 1000
> iterations_that_access_an_element_twice_in_B: [0 + 1 * x_1]
I think that this representation of affine functions is wrong:
the access in B should read [0 + 0 * x_1 + 1 * x_2] and that
would not lead to a wrong conclusion like the following...
> last_conflict: 1000
> (Subscript distance: 0
> )
> )
> inner loop index: 0
> loop nest: (1 2 )
> distance_vector: 0 0
> direction_vector: = =
> )
Re: [Bug tree-optimization/46194] [4.5/4.6 Regression] gcc.dg/graphite/block-0.c FAILs with -ftree-parallelize-loops
>> access_fn_A: {0, +, 1}_1
>> access_fn_B: {0, +, 1}_2
>>
>> (subscript
>> iterations_that_access_an_element_twice_in_A: [0 + 1 * x_1]
>> last_conflict: 1000
>> iterations_that_access_an_element_twice_in_B: [0 + 1 * x_1]
>
> I think that this representation of affine functions is wrong:
> the access in B should read [0 + 0 * x_1 + 1 * x_2] and that
> would not lead to a wrong conclusion like the following...
This representation is correct, as it stands for: there exists
a dependence for all x_1 from 0 to 1000, that is, there exist
a possible overlap that is represented by:
{0, +, 1}_1 ([0 + 1 * x_1]) == {0, +, 1}_2 ([0 + 1 * x_1])
>
>> last_conflict: 1000
>> (Subscript distance: 0
>> )
>> )
>> inner loop index: 0
>> loop nest: (1 2 )
>> distance_vector: 0 0
>> direction_vector: = =
>> )
>
This representation is still wrong, and so I went to see where this
was computed, and the bug seems to be in build_classic_dist_vector_1
I will submit a patch to fix this.
Re: [Bug middle-end/45306] ICE (Segmentation fault) while building PyQt with -fgraphite-identity
On Fri, Feb 4, 2011 at 00:27, dirtyepic at gentoo dot org wrote: > I'm guessing that means 4.5 will stay broken? > Depends on how difficult it would be to backport the fix. I haven't git-bisect'ed it to know which of the patches fixed it.
Re: [Bug tree-optimization/42771] [4.5 Regression][graphite] ICE: in graphite_loop_normal_form, at graphite-sese-to-poly.c (2)
On Wed, Feb 10, 2010 at 12:26, amonakov at gcc dot gnu dot org wrote: > I don't see how this patch makes simple_iv call from number_of_iterations_exit > return true for j_20. Could you please kindly explain? We used to analyze the second scop after the code generation of the first one. In that context, the scalar evolution analysis failed to analyze the code containing scalar computations stored and read from arrays with 1 element (introduced by the code generation and analysis part). We now analyze all the scops before code generating them: thus, we don't have to invalidate the scalar evolution hash tables between the analysis of two scops.
Re: [Bug tree-optimization/43423] gcc should vectorize this loop through "iteration range splitting"
> Well it could be vectorized even without range splitting. The issue is the > "sinking" of the store to a[i]. You mean that the problem is the if-conversion of the stores "a[i] = ..."
Re: [Bug middle-end/42181] [4.5 Regression][graphite] -fgraphite-identity miscompiles air.f90
On Sat, Mar 20, 2010 at 05:45, dominiq at lps dot ens dot fr wrote: > Do you understand why graphite does not detect that the loop for [scat_1+1, > T_10-2] depends on the one for [0, scat_1-1]? Graphite does know this, but it does not ask CLooG to generate [0, scat_1-1] after [scat_1+1, T_10-2], however CLooG does generate it, so I am thinking that this is a problem in CLooG. > Second question why does graphite exchange the order of the split loops? > CLooG does that.
Re: [Bug middle-end/42181] [4.5 Regression][graphite] -fgraphite-identity miscompiles air.f90
On Wed, Mar 24, 2010 at 16:35, howarth at nitro dot med dot uc dot edu wrote: >> Fixed. >> >> Please use ftp://gcc.gnu.org/pub/gcc/infrastructure/cloog-ppl-0.15.9.tar.gz >> > > Shouldn't the required cloog-ppl version in configure be bumped from 0.15.5 to > 0.15.9? > Richi what do you think?
Re: [Bug middle-end/43519] [graphite] Bootstrap with Graphite enabled fails in Java libs
On Mon, Apr 5, 2010 at 04:47, rguenth at gcc dot gnu dot org
wrote:
> You shouldn't be using type_for_size but instead use
> build_nonstandard_integer_type.
I copied this from another LNO pass, should I also update that pass?
What about this patch?
Sebastian
From 504de7abe45a6b5f663c22e1fef54964c19d7528 Mon Sep 17 00:00:00 2001
From: Sebastian Pop
Date: Mon, 5 Apr 2010 12:16:22 -0500
Subject: [PATCH] Use build_nonstandard_integer_type.
---
gcc/graphite-clast-to-gimple.c |4 ++--
gcc/tree-ssa-loop-ivopts.c |2 +-
gcc/tree-ssa-loop-manip.c |2 +-
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/gcc/graphite-clast-to-gimple.c b/gcc/graphite-clast-to-gimple.c
index 66089ae..3866eec 100644
--- a/gcc/graphite-clast-to-gimple.c
+++ b/gcc/graphite-clast-to-gimple.c
@@ -233,7 +233,7 @@ max_signed_precision_type (tree type1, tree type2)
int p1 = TYPE_PRECISION (type1);
int p2 = TYPE_PRECISION (type2);
int precision = p1 > p2 ? p1 : p2;
- tree type = lang_hooks.types.type_for_size (precision, false);
+ tree type = build_nonstandard_integer_type (precision, false);
if (!type)
{
@@ -485,7 +485,7 @@ gcc_type_for_interval (Value low, Value up, tree old_type)
prec_int = precision_for_interval (low, up);
precision = prec_up > prec_int ? prec_up : prec_int;
- type = lang_hooks.types.type_for_size (precision, unsigned_p);
+ type = build_nonstandard_integer_type (precision, unsigned_p);
if (!type)
{
gloog_error = true;
diff --git a/gcc/tree-ssa-loop-ivopts.c b/gcc/tree-ssa-loop-ivopts.c
index e6565db..486243f 100644
--- a/gcc/tree-ssa-loop-ivopts.c
+++ b/gcc/tree-ssa-loop-ivopts.c
@@ -2291,7 +2291,7 @@ static void
add_standard_iv_candidates_for_size (struct ivopts_data *data,
unsigned int size)
{
- tree type = lang_hooks.types.type_for_size (size, true);
+ tree type = build_nonstandard_integer_type (size, true);
add_candidate (data, build_int_cst (type, 0), build_int_cst (type, 1),
true, NULL);
}
diff --git a/gcc/tree-ssa-loop-manip.c b/gcc/tree-ssa-loop-manip.c
index 7818f5b..c09a2ed 100644
--- a/gcc/tree-ssa-loop-manip.c
+++ b/gcc/tree-ssa-loop-manip.c
@@ -1207,7 +1207,7 @@ canonicalize_loop_ivs (struct loop *loop, tree *nit, bool bump_in_latch)
precision = TYPE_PRECISION (TREE_TYPE (res));
}
- type = lang_hooks.types.type_for_size (precision, 1);
+ type = build_nonstandard_integer_type (precision, 1);
if (original_precision != precision)
{
--
1.6.3.3
Re: [Bug middle-end/43519] [graphite] Bootstrap with Graphite enabled fails in Java libs
On Mon, Apr 5, 2010 at 22:16, spop at gcc dot gnu dot org wrote: > URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157977 > Log: > Use build_nonstandard_integer_type. This commit seems to create problems both in chrec_convert and in the niter estimations: these use unsigned_type_for and signed_type_for that fail by returning NULL_TREE when the type is one that is returned by build_nonstandard_integer_type.
Re: [Bug testsuite/42135] New: FAIL: libgomp.graphite/force-parallel-2.c execution test
On Sat, Nov 21, 2009 at 14:57, dominiq at lps dot ens dot fr wrote: > Since revision 150792, the test libgomp.graphite/force-parallel-2.c > (introduced > in revision 150755) fails on *-apple-darwin9. AFAICT the array x[1][1] > is allocated in stack and is too big for the 64Mb hard limit on darwin. One > solution could be to replace 1 with 4000. Also the following patch works. Please update the size of arrays. Thanks, Sebastian
Re: [Bug tree-optimization/42641] Random code-generation differences with GRAPHITE
> htab_hash_pointer is fine if a hash table is never traversed, or such > traversal > can't affect code generation. E.g. graphite has some debug_* routines that > traverse such hash tables, that's fine, they aren't called at all during > compilation except for debugging sessions. Ok, thanks for the detailed explanation. The two other htabs using htab_hash_pointer ivtype_map_elt_info and clast_name_index_elt_info are safe.
Re: [Bug middle-end/42512] [4.5 Regression] integer wrong code bug with loop
> Ok, I have that fixed locally at the place of the patch but I wonder if
> initial_condition () shouldn't return for example
>
> 1ul for (unsigned long) { 1, +, 1 }_1
>
This is correct.
> and
>
> (int) i_2 for (int) { i_2, +, 1 }_1
>
> and further (for short i_2)
>
> i_2 for (short) { (int) { i_2, +, 1 }_2, +, 1 }_1
>
> ? Can the latter two happen all?
Yes, these could happen, and you are right, we should see
the initial value of a chrec through the type conversion lenses.
> Is it even correct to talk about a
> general initial condition in this case? Consider
>
> { { 1, +, 1 }_2, +, 1 }_1
>
> initial_condition will return 1 for the chrec even though that is not
> correct because the initial condition is not constant in loop 1.
If you want, there is an initial condition for the loop_1 and that would be
{1, +, 1}_2, and there is an initial condition 1 for loop nest loop_2:
loop_2
i = loop_2_phi (0, i+1) = {1, +, 1}_2
loop_1
j = loop_1_phi (i, j+1) = {{1, +, 1}_2, +, 1}_1
> I suppose I'd only see that if instantiating the chrec at the point
> where I placed the fix? So I really only see at most a single outer
> conversion around the chrec?
Yes, I think that at most you can have only one conversion around a chrec.
Re: [Bug tree-optimization/42521] [4.5 Regression] ICE: in graphite_loop_normal_form, at graphite-sese-to-poly.c:2844
> pdv_d.f:89:0: error: definition in block 40 does not dominate use in block 212 > for SSA_NAME: prephitmp.28_439 in statement: > D.2771_606 = D.2770_605 <= prephitmp.28_439; The error comes from the fact that we are not clearing the scev information anymore in between the code generation of two scops. In this particular case, we have two scops, the second scop contains a loop for which the number of iterations is a variable computed in the first scop, and because we do not update the niter/scev info we keep referring to the old SSA_NAME, prephitmp.28_439. A solution would be to rename all the scev info based on the rename_map that is computed by the translation of the first scop. I am working on a patch to do that. Sebastian
Re: [Bug tree-optimization/45314] [4.5/4.6 Regression] ICE: error: in remove_unreachable_handlers, at tree-sh.c:3294 with -O2 -floop-interchange
On Fri, Nov 5, 2010 at 11:26, hjl.tools at gmail dot com wrote: > On trunk, it was fixed by revision 163123: > > http://gcc.gnu.org/ml/gcc-cvs/2010-08/msg00334.html > Thanks HJ for reducing this. I looked at this change and it looks simple enough to backport it to 4.5.
Re: [Bug tree-optimization/45314] [4.5 Regression] ICE: error: in remove_unreachable_handlers, at tree-sh.c:3294 with -O2 -floop-interchange
Here is the backported patch that fixes the ICE.
I will further test this and will post to gcc-patches.
Sebastian
From 8f0cc975c09d2e0779f7e25a82a295f3deb9de46 Mon Sep 17 00:00:00 2001
From: Sebastian Pop
Date: Fri, 5 Nov 2010 13:15:25 -0500
Subject: [PATCH] Fix PR45314: backport revision 163123.
---
gcc/graphite-sese-to-poly.c | 56 --
1 files changed, 6 insertions(+), 50 deletions(-)
diff --git a/gcc/graphite-sese-to-poly.c b/gcc/graphite-sese-to-poly.c
index d4bb8a3..b12210b 100644
--- a/gcc/graphite-sese-to-poly.c
+++ b/gcc/graphite-sese-to-poly.c
@@ -2231,58 +2231,14 @@ rewrite_phi_out_of_ssa (gimple_stmt_iterator *psi)
for (i = 0; i < gimple_phi_num_args (phi); i++)
{
tree arg = gimple_phi_arg_def (phi, i);
+ edge e = gimple_phi_arg_edge (phi, i);
- /* Try to avoid the insertion on edges as much as possible: this
- would avoid the insertion of code on loop latch edges, making
- the pattern matching of the vectorizer happy, or it would
- avoid the insertion of useless basic blocks. Note that it is
- incorrect to insert out of SSA copies close by their
- definition when they are more than two loop levels apart:
- for example, starting from a double nested loop
-
- | a = ...
- | loop_1
- | loop_2
- |b = phi (a, c)
- |c = ...
- | end_2
- | end_1
-
- the following transform is incorrect
-
- | a = ...
- | Red[0] = a
- | loop_1
- | loop_2
- |b = Red[0]
- |c = ...
- |Red[0] = c
- | end_2
- | end_1
-
- whereas inserting the copy on the incoming edge is correct
-
- | a = ...
- | loop_1
- | Red[0] = a
- | loop_2
- |b = Red[0]
- |c = ...
- |Red[0] = c
- | end_2
- | end_1
- */
- if (TREE_CODE (arg) == SSA_NAME
- && is_gimple_reg (arg)
- && gimple_bb (SSA_NAME_DEF_STMT (arg))
- && (flow_bb_inside_loop_p (bb->loop_father,
- gimple_bb (SSA_NAME_DEF_STMT (arg)))
- || flow_bb_inside_loop_p (loop_outer (bb->loop_father),
- gimple_bb (SSA_NAME_DEF_STMT (arg)
- insert_out_of_ssa_copy (zero_dim_array, arg);
+ /* Avoid the insertion of code in the loop latch to please the
+ pattern matching of the vectorizer. */
+ if (e->src == bb->loop_father->latch)
+ insert_out_of_ssa_copy (zero_dim_array, arg);
else
- insert_out_of_ssa_copy_on_edge (gimple_phi_arg_edge (phi, i),
- zero_dim_array, arg);
+ insert_out_of_ssa_copy_on_edge (e, zero_dim_array, arg);
}
var = force_gimple_operand (zero_dim_array, &stmts, true, NULL_TREE);
--
1.7.0.4
Re: [Bug fortran/44660] [regression 4.4/4.5/4.6] ICE in resolve_equivalence()
These previous patches don't seem to solve the problem: here is another reduced case that still fails in resolve_equivalence at a different place than before. $ cat bug.f CALL TRFWTM(JKT,XX,NX,Y,NIX,NORB2,1,TOL) IF(DBUG.AND.NX.GT.0) THEN EQUIVALENCE (DBUGME, DBUGME_STR) END IF END
Re: [Bug tree-optimization/34679] [4.3 Regression] ICE: tree check: expected integer_type, have enumeral_type in host_integerp, at tree.c:4949 (predictive commoning)
Patch http://gcc.gnu.org/ml/gcc-patches/2008-01/msg00344.html
Re: [Bug tree-optimization/36287] [4.4 Regression] ICE with -O -ftree-loop-linear
> Sebastian, that was your change. http://gcc.gnu.org/viewcvs?view=rev&revision=135672 was a clean-up of the lambda framework. I'm working on a fix.
Re: [Bug tree-optimization/36287] [4.4 Regression] ICE with -O -ftree-loop-linear
Fix attached: that's a bad typo. This also fixes PR36286.
Sent to regstrap on gccfarm. I will commit it just after it passes.
Sebastian
email: [EMAIL PROTECTED]
branch:trunk
revision:HEAD
configure:
make:
check:
2008-05-21 Sebastian Pop <[EMAIL PROTECTED]>
PR tree-optimization/36286
* lambda-code.c (build_access_matrix): Do not use the loop->num
for computing the number of induction variables: use the loop depth
instead.
* testsuite/gcc.dg/tree-ssa/pr36287.c: New.
* testsuite/gfortran.dg/pr36286.f90: New.
Index: gcc/testsuite/gcc.dg/tree-ssa/pr36287.c
===
--- gcc/testsuite/gcc.dg/tree-ssa/pr36287.c (revision 0)
+++ gcc/testsuite/gcc.dg/tree-ssa/pr36287.c (revision 0)
@@ -0,0 +1,22 @@
+/* { dg-do compile } */
+/* { dg-options "-O -ftree-loop-linear" } */
+
+int tab[2][2];
+
+int foo ()
+{
+ int i, j, k;
+
+ for (i = 0; i < 2; ++i)
+for (j = 0; j < 2; ++j)
+ for (k = 0; k < 2; ++k)
+ {}
+
+ for (i = 0; i < 2; ++i)
+for (j = 0; j < 2; ++j)
+ if (i == 0)
+ tab[i][j] = 0;
+
+ return tab[0][1];
+}
+
Index: gcc/testsuite/gfortran.dg/pr36286.f90
===
--- gcc/testsuite/gfortran.dg/pr36286.f90 (revision 0)
+++ gcc/testsuite/gfortran.dg/pr36286.f90 (revision 0)
@@ -0,0 +1,14 @@
+! { dg-do compile }
+! { dg-options "-O1 -ftree-loop-linear" }
+! PR tree-optimization/36286
+
+program test_count
+integer, dimension(2,3) :: a, b
+a = reshape( (/ 1, 3, 5, 2, 4, 6 /), (/ 2, 3 /))
+b = reshape( (/ 0, 3, 5, 7, 4, 8 /), (/ 2, 3 /))
+print '(3l6)', a.ne.b
+print *, a(1,:).ne.b(1,:)
+print *, a(2,:).ne.b(2,:)
+print *, count(a.ne.b)
+end program test_count
+
Index: gcc/lambda-code.c
===
--- gcc/lambda-code.c (revision 135673)
+++ gcc/lambda-code.c (working copy)
@@ -2794,12 +2794,13 @@ build_access_matrix (data_reference_p da
struct access_matrix *am = GGC_NEW (struct access_matrix);
unsigned i, ndim = DR_NUM_DIMENSIONS (data_reference);
struct loop *loop = bb_for_stmt (DR_STMT (data_reference))->loop_father;
- unsigned nb_induction_vars = loop_depth (loop) - loop_nest_num + 1;
+ struct loop *loop_nest = get_loop (loop_nest_num);
+ unsigned nivs = loop_depth (loop) - loop_depth (loop_nest) + 1;
unsigned lambda_nb_columns;
lambda_vector_vec_p matrix;
AM_LOOP_NEST_NUM (am) = loop_nest_num;
- AM_NB_INDUCTION_VARS (am) = nb_induction_vars;
+ AM_NB_INDUCTION_VARS (am) = nivs;
AM_PARAMETERS (am) = parameters;
lambda_nb_columns = AM_NB_COLUMNS (am);
