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.
>> 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:
> th
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
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
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
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.
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)
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 sig
astian
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
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?
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],
> 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] = ..."
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
> 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 s
> 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) {
> 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
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 o
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
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
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.
> + /* Increase the limit by the PHI argument number to avoid exponential
> + time and memory complexity. */
This looks good.
Thanks,
Sebastian
Awesome! Thanks Li, the patch looks good. Tobias will take care
of including it to the graphite branch.
Sebastian
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 referenc
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
(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)
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
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
> 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 "D
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
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 regio
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
> --- 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
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)
> Update
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
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.
> 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/lib
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
The patch looks good. Please test and ask for approval to
commit to trunk on [EMAIL PROTECTED]
Thanks,
Sebastian
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 re
> 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
> 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
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
The patch looks good. Please install.
I also have installed a similar patch in htdocs/gcc-4.4/changes.html
> --- 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 includ
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.
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-optimiz
> 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.
Patch http://gcc.gnu.org/ml/gcc-patches/2008-01/msg00344.html
48 matches
Mail list logo
