--- Comment #4 from sebpop at gmail dot com 2008-11-24 17:27 ---
Subject: Re: 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
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- Comment #1 from sebpop at gmail dot com 2008-11-25 20:25 ---
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
--- Comment #6 from sebpop at gmail dot com 2008-11-26 17:42 ---
Subject: Re: -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:1
--- Comment #3 from sebpop at gmail dot com 2008-11-26 18:20 ---
Subject: Re: [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
--- Comment #7 from sebpop at gmail dot com 2008-12-05 06:34 ---
Subject: Re: [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 no
--- Comment #4 from sebpop at gmail dot com 2008-12-08 22:07 ---
Subject: Re: [graphite] ICE : in build_graphite_scops, at graphite.c:1829
On Mon, Dec 8, 2008 at 3:49 PM, grosser at gcc dot gnu dot org
<[EMAIL PROTECTED]> wrote:
> Fix
>
The patch looks good. Please apply
--- Comment #4 from sebpop at gmail dot com 2008-12-10 22:37 ---
Subject: Re: [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, hja
--- Comment #3 from sebpop at gmail dot com 2008-12-12 22:31 ---
Subject: Re: [graphite] ICE : in verify_loop_structure, at cfgloop.c:1569
> 2008-12-12 Jan Sjodin
>Harsha Jagasia
>
>PR tree-optimization/38500
>* gcc.dg/graphite
--- Comment #17 from sebpop at gmail dot com 2009-01-07 19:23 ---
Subject: Re: [graphite] several ICEs with CP2K (summary)
> I checked that current trunk (i.e. not graphite branch) still generates a
> segfaulting executable with
>
> FCFLAGS = -g -O2 -ffast-math -funroll-
--- Comment #3 from sebpop at gmail dot com 2009-01-08 16:33 ---
Subject: Re: [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 chec
--- Comment #4 from sebpop at gmail dot com 2009-01-08 17:05 ---
Subject: Re: [graphite] wrong code with -O3 -fgraphite-identity -floop-block
on polyhedron benchmarks
> I'm running the polyhedron bmk with -m32 and will report the result.
Actually I cannot run the test with -m
--- Comment #21 from sebpop at gmail dot com 2009-01-08 19:53 ---
Subject: Re: [graphite] several ICEs with CP2K (summary)
> the testcase provide runs fine (AFAICT) with current trunk. I'll run the full
> CP2K testsuite to test somewhat better.
Thanks for testing. Can yo
--- Comment #2 from sebpop at gmail dot com 2009-01-10 21:32 ---
Subject: Re: FAIL: gcc.dg/graphite/block-3.c (test for excess errors)
Does the attached patch fix the fail?
Thanks,
Sebastian
--- Comment #3 from sebpop at gmail dot com 2009-01-10 21:32 ---
Created an
--- Comment #27 from sebpop at gmail dot com 2009-01-11 13:42 ---
Subject: Re: [graphite] several ICEs with CP2K (summary)
On Sun, Jan 11, 2009 at 6:58 AM, jv244 at cam dot ac dot uk
wrote:
>> I'll see if I
>> can narrow down the problem to the single subroutine (c
--- Comment #28 from sebpop at gmail dot com 2009-01-13 19:52 ---
Subject: Re: [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
--- Comment #30 from sebpop at gmail dot com 2009-01-13 21:57 ---
Subject: Re: [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
--- Comment #33 from sebpop at gmail dot com 2009-01-14 10:20 ---
Subject: Re: [graphite] several ICEs with CP2K (summary)
Attached a fix for this PR. I will regstrap and submit for review.
Sebastian
--- Comment #34 from sebpop at gmail dot com 2009-01-14 10:20
--- Comment #8 from sebpop at gmail dot com 2009-01-14 14:45 ---
Subject: Re: 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
--- Comment #1 from sebpop at gmail dot com 2009-01-14 18:42 ---
Subject: Re: 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
--- Comment #21 from sebpop at gmail dot com 2009-01-17 15:11 ---
Subject: Re: r143152 breaks output routines in
xplor-nih
On Sat, Jan 17, 2009 at 6:29 AM, dominiq at lps dot ens dot fr
wrote:
> Somehow I got the impression that graphite is now enabled at -O2
We did enab
--- Comment #4 from sebpop at gmail dot com 2009-05-08 12:12 ---
Subject: Re: [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 a
--- Comment #8 from sebpop at gmail dot com 2009-06-09 18:17 ---
Subject: Re: CLooG header files are not -Wc++-compat
ready
On Tue, Jun 9, 2009 at 12:42, joseph at codesourcery dot
com wrote:
> I think you should allow more time for people to update after preparing a
>
--- Comment #3 from sebpop at gmail dot com 2009-08-05 04:42 ---
Subject: Re: [graphite] slow compilation
On Tue, Aug 4, 2009 at 17:44, rguenth at gcc dot gnu dot
org wrote:
> Eh - where's that exponential time complexity? ...
The code generation of Graphite can be exp
--- Comment #6 from sebpop at gmail dot com 2009-08-05 14:04 ---
Subject: Re: [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
--- Comment #2 from sebpop at gmail dot com 2008-09-02 19:48 ---
Subject: Re: 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 j
--- Comment #8 from sebpop at gmail dot com 2008-09-29 14:46 ---
Subject: Re: [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
--- Comment #2 from sebpop at gmail dot com 2008-10-02 06:18 ---
Subject: Re: 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
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37690
--- Comment #19 from sebpop at gmail dot com 2008-10-03 20:15 ---
Subject: Re: [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,
Seba
--- Comment #12 from sebpop at gmail dot com 2008-10-22 16:10 ---
Subject: Re: [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
--- Comment #1 from sebpop at gmail dot com 2008-10-22 18:04 ---
Subject: Re: New: [graphite-branch] Invalid use of single_succ_edge in
create_single_entry_edge
> Commit 141283 introduced new code in create_single_entry_edge, that breaks
> polyhedron in linpk.f90, md
--- Comment #5 from sebpop at gmail dot com 2008-10-22 21:08 ---
Subject: Re: bootstrap forever with BOOT_CFLAGS="-O2 -ftree-loop-distribution"
> Sebastian, can you please look at this?
Sorry for having missed this bug. The problem here is that we end
with two identical
--- Comment #4 from sebpop at gmail dot com 2008-10-23 01:31 ---
Subject: Re: [graphite] ICE: Segmentation fault
On Wed, Oct 22, 2008 at 7:28 PM, grosser at gcc dot gnu dot org
<[EMAIL PROTECTED]> wrote:
> Proposed fix in gloog()
>
> I added a fix for this SEGFAULT.
--- Comment #4 from sebpop at gmail dot com 2008-11-04 23:34 ---
Subject: Re: [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 hand
--- Comment #3 from sebpop at gmail dot com 2008-11-07 02:49 ---
Subject: Re: -O1/-O2/-O3 -fgraphite-identity causes ICE when compiling
induct.f90 Polyhedron 2005 benchmark
On Thu, Nov 6, 2008 at 8:41 PM, howarth at nitro dot med dot uc dot
edu <[EMAIL PROTECTED]> wrote:
> b
--- Comment #6 from sebpop at gmail dot com 2008-11-07 05:21 ---
Subject: Re: [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-
--- Comment #3 from sebpop at gmail dot com 2008-01-27 04:17 ---
Subject: Re: verify_ssa ICE with -ftree-loop-linear
Patch: http://gcc.gnu.org/ml/gcc-patches/2008-01/msg01294.html
it does not fix really the problem, just works around the problem.
See also the comments here:
http
--- Comment #2 from sebpop at gmail dot com 2008-01-29 17:40 ---
Subject: Re: [4.3 regression] ICE with -fcheck-data-deps
On 29 Jan 2008 13:34:07 -, jakub at gcc dot gnu dot org
<[EMAIL PROTECTED]> wrote:
> P4, unless you can reproduce without -fcheck-data-deps. -fcheck-
--- Comment #5 from sebpop at gmail dot com 2009-02-22 14:55 ---
Subject: Re: [miro] - Revision 144368 - Werror in
../miro/gcc/genconstants.c
I will fix this with the attached patch when approved.
--- Comment #6 from sebpop at gmail dot com 2009-02-22 14:55
--- Comment #10 from sebpop at gmail dot com 2009-02-26 20:10 ---
Subject: Re: 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
--- Comment #5 from sebpop at gmail dot com 2009-03-02 18:57 ---
Subject: Re: 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
gr
--- Comment #5 from sebpop at gmail dot com 2009-03-16 22:34 ---
Subject: Re: 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
--- Comment #6 from sebpop at gmail dot com 2009-03-16 23:18 ---
Subject: Re: 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
--- Comment #5 from sebpop at gmail dot com 2009-03-19 02:52 ---
Subject: Re: autopar fails to parallel
On Wed, Mar 18, 2009 at 20:46, nemokingdom at gmail dot com
wrote:
> I add test case for this situation.
>
Yes, indeed this is a good idea.
Thanks for the testcase,
Seb
--- Comment #6 from sebpop at gmail dot com 2009-03-19 02:53 ---
Subject: Re: autopar fails to parallel
> What |Removed |Added
>
> Component|m
--- Comment #10 from sebpop at gmail dot com 2009-03-29 02:15 ---
Subject: Re: ICE with -fcheck-data-deps
> The bug disappeared on the trunk between 2009-03-15 and 2009-03-20.
This bug might have been fixed by PR39500.
Sebastian
--
http://gcc.gnu.org/bugzilla/show_bug.cgi
--- Comment #3 from sebpop at gmail dot com 2009-03-30 20:03 ---
Subject: Re: [graphite] Remove GBB_LOOPS
Awesome! Thanks Li, the patch looks good. Tobias will take care
of including it to the graphite branch.
Sebastian
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39568
--- Comment #21 from sebpop at gmail dot com 2009-08-14 17:16 ---
Subject: Re: aermod.f90 ICEs on -O2 -fgraphite-identity
-floop-strip-mine
> Actually the error in gdb has changed with 1677_max.diff...
>
As expected: see the gcc_assert in the patch
+/* Return in R
--- Comment #4 from sebpop at gmail dot com 2009-09-19 23:31 ---
Subject: Re: -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
--- Comment #4 from sebpop at gmail dot com 2009-10-23 19:54 ---
Subject: Re: 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:
>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45146
--- Comment #3 from sebpop at gmail dot com
2010-12-22 18:36:31 UTC ---
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40979
--- Comment #16 from sebpop at gmail dot com
2011-02-01 16:59:03 UTC ---
> It's unfortunate that graphite inserts arrays of size 1 instead of scalar
> (memory) vars.
That could be easily fixed.
graphite can also use the original dat
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40979
--- Comment #18 from sebpop at gmail dot com
2011-02-01 17:22:06 UTC ---
On Tue, Feb 1, 2011 at 11:15, rguenth at gcc dot gnu.org
wrote:
> I'd suggest
>
> NEXT_PASS (pass_graphite);
> {
>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46194
--- Comment #7 from sebpop at gmail dot com
2011-02-03 18:11:09 UTC ---
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 g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46194
--- Comment #9 from sebpop at gmail dot com
2011-02-03 19:54:36 UTC ---
>> access_fn_A: {0, +, 1}_1
>> access_fn_B: {0, +, 1}_2
>>
>> (subscript
>> iterations_that_access_an_element_twice_in_A: [0 + 1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45306
--- Comment #9 from sebpop at gmail dot com
2011-02-04 07:08:30 UTC ---
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 backp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46886
--- Comment #4 from sebpop at gmail dot com
2011-02-04 20:30:46 UTC ---
On Tue, Jan 18, 2011 at 11:00, jakub at gcc dot gnu.org
wrote:
> Seems one extra incorrect iteration is added after GOMP_parallel_end:
That extra iteration is added
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50335
--- Comment #8 from sebpop at gmail dot com
2011-12-06 18:40:43 UTC ---
Hi Maxim,
Thanks for pointing me to this problem.
I would recommend that you disable the code in loop flattening by
early returning false in flatten_all_loops. I'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50335
--- Comment #10 from sebpop at gmail dot com
2011-12-08 04:08:14 UTC ---
On Wed, Dec 7, 2011 at 18:06, maxim_kuvyrkov at mentor dot com
wrote:
> Do I understand correctly that you are suggesting effectively disabling loop
> flat
--- Comment #10 from sebpop at gmail dot com 2007-06-22 10:12 ---
Subject: Re: [4.3 Regression] Complete program optimized away (i686,
-ftree-vectorize)
Grrr, I mean, I will test the patch now on amd64 ;-)
On 6/22/07, Sebastian Pop <[EMAIL PROTECTED]> wrote:
> Okay, I'
--- Comment #13 from sebpop at gmail dot com 2007-06-24 07:55 ---
Subject: Re: [4.3 Regression] Segmentation fault in
build_classic_dist_vector_1() at tree-data-ref.c:2700
On 6/24/07, Sebastian Pop <[EMAIL PROTECTED]> wrote:
> Unfortunately I haven't seen the suggestion
--- Comment #14 from sebpop at gmail dot com 2007-06-24 10:11 ---
Subject: Re: [4.3 Regression] Segmentation fault in
build_classic_dist_vector_1() at tree-data-ref.c:2700
On 6/24/07, Sebastian Pop <[EMAIL PROTECTED]> wrote:
> So this just looks like we want to improve operan
--- Comment #21 from sebpop at gmail dot com 2007-06-24 12:50 ---
Subject: Re: [4.3 Regression] Segmentation fault in
build_classic_dist_vector_1() at tree-data-ref.c:2700
On 6/24/07, Richard Guenther <[EMAIL PROTECTED]> wrote:
> If you use TREE_OPERAND (op0, 0), op1 instead
--- Comment #26 from sebpop at gmail dot com 2007-06-24 13:38 ---
Subject: Re: [4.3 Regression] Segmentation fault in
build_classic_dist_vector_1() at tree-data-ref.c:2700
On 6/24/07, Richard Guenther <[EMAIL PROTECTED]> wrote:
> An alternative is to use
>
>
--- Comment #28 from sebpop at gmail dot com 2007-06-24 19:19 ---
Subject: Re: [4.3 Regression] Segmentation fault in
build_classic_dist_vector_1() at tree-data-ref.c:2700
On 6/24/07, Sebastian Pop <[EMAIL PROTECTED]> wrote:
> On 6/24/07, Richard Guenther <[EMAIL PROTE
--- Comment #18 from sebpop at gmail dot com 2007-06-26 23:54 ---
Subject: Re: [4.3 Regression] Complete program optimized away (i686,
-ftree-vectorize)
Hi,
> I'm bootstrapping this patch on both amd64-linux and i686-linux.
The patch passed bootstrap and test on both machi
--- Comment #8 from sebpop at gmail dot com 2007-07-03 13:57 ---
Subject: Re: can't determine dependence (source/destination overlap without
more than size)
On 3 Jul 2007 12:57:33 -, irar at il dot ibm dot com
<[EMAIL PROTECTED]> wrote:
> for (i = 0; i < N; i
--- Comment #10 from sebpop at gmail dot com 2007-07-04 07:21 ---
Subject: Re: can't determine dependence (source/destination overlap without
more than size)
> > I can submit a patch for merging that part of code in trunk if you need
> > this flag to test if you
--- Comment #15 from sebpop at gmail dot com 2007-07-09 14:19 ---
Subject: Re: can't determine dependence (source/destination overlap without
more than size)
> I was going to submit the attached patch, but now the analysis fails with
> "affine-affine test failed: m
--- Comment #11 from sebpop at gmail dot com 2010-02-11 00:29 ---
Subject: Re: [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 th
--- Comment #6 from sebpop at gmail dot com 2010-03-01 18:10 ---
Subject: Re: [4.5 Regression] ICE in
try_improve_iv_set, at tree-ssa-loop-ivopts.c:5238
On Mon, Mar 1, 2010 at 12:02, changpeng dot fang at amd dot com
> I have a fix for this problem. We should not decrease
--- Comment #7 from sebpop at gmail dot com 2010-03-01 18:21 ---
Subject: Re: [4.5 Regression] ICE in
try_improve_iv_set, at tree-ssa-loop-ivopts.c:5238
> You should fuse this condition into the previous condition expression
> to avoid the inner if.
Like this:
diff -
--- Comment #3 from sebpop at gmail dot com 2010-03-18 18:33 ---
Subject: Re: 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 t
--- Comment #5 from sebpop at gmail dot com 2010-03-21 16:08 ---
Subject: Re: copy prop breaks loop closed SSA form
On Sun, Mar 21, 2010 at 04:54, steven at gcc dot gnu dot org
wrote:
> Why such a big hammer?
'cause I don't want to add more bugs,
and no I don't
--- Comment #26 from sebpop at gmail dot com 2010-03-21 16:28 ---
Subject: Re: [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 l
--- Comment #32 from sebpop at gmail dot com 2010-03-25 17:43 ---
Subject: Re: [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
--- Comment #3 from sebpop at gmail dot com 2010-04-05 17:30 ---
Subject: Re: [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 ins
--- Comment #7 from sebpop at gmail dot com 2010-04-06 05:54 ---
Subject: Re: [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=1
--- Comment #1 from sebpop at gmail dot com 2009-11-24 06:51 ---
Subject: Re: 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-paralle
--- Comment #6 from sebpop at gmail dot com 2010-01-07 17:58 ---
Subject: Re: Random code-generation differences
with GRAPHITE
After your change, there remains three users of htab_hash_pointer in graphite:
In if_region_set_false_region, there is a use of htab_hash_pointer
--- Comment #9 from sebpop at gmail dot com 2010-01-07 21:30 ---
Subject: Re: 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 h
--- Comment #11 from sebpop at gmail dot com 2010-01-08 17:55 ---
Subject: Re: [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
&g
--- Comment #10 from sebpop at gmail dot com 2010-01-13 18:15 ---
Subject: Re: [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.
--- Comment #6 from sebpop at gmail dot com 2010-02-06 19:42 ---
Subject: Re: [4.5 Regression][graphite]
miscompilation related to -floop-block
> Is
>
> IMPLICIT NONE
> INTEGER, PARAMETER :: dp=KIND(0.0D0)
> REAL(KIND=dp) :: res
>
> res=exp_rad
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48648
--- Comment #7 from sebpop at gmail dot com
2011-04-18 16:51:23 UTC ---
> (I read somewhere ppl should be replaced with isl?)
Not true: GCC still depends on PPL.
The use of cloog-ppl is deprecated: GCC will not use it in the future.
Using cl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46186
--- Comment #23 from sebpop at gmail dot com
2010-10-29 21:44:09 UTC ---
Hi,
here is a preliminary patch (not tested yet other that the PR testcase).
This patch improves chrec_apply to also handle these very uncommon
cases that some like to
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45314
--- Comment #7 from sebpop at gmail dot com
2010-11-05 16:51:22 UTC ---
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/msg0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45314
--- Comment #10 from sebpop at gmail dot com
2010-11-05 18:17:01 UTC ---
Here is the backported patch that fixes the ICE.
I will further test this and will post to gcc-patches.
Sebastian
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46928
--- Comment #4 from sebpop at gmail dot com
2010-12-13 19:05:58 UTC ---
The code that is produced looks like this just after loop
distribution, i.e., we generate memset zero only by distributing the
innermost loop:
mad_synth_mute (struct
--- Comment #4 from sebpop at gmail dot com 2010-06-25 05:32 ---
Subject: Re: [regression 4.4/4.5/4.6] ICE in
resolve_equivalence()
On Thu, Jun 24, 2010 at 23:42, kargl at gcc dot gnu dot org
wrote:
> The mangled Fortran code caught my eye. I'm actually wondering
--- Comment #5 from sebpop at gmail dot com 2010-06-25 05:49 ---
Subject: Re: [regression 4.4/4.5/4.6] ICE in
resolve_equivalence()
On Thu, Jun 24, 2010 at 23:02, kargl at gcc dot gnu dot org
wrote:
>
>
> --- Comment #1 from kargl at gcc dot gnu dot org 2010-06
--- Comment #6 from sebpop at gmail dot com 2010-06-25 06:07 ---
Subject: Re: [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 diff
--- Comment #9 from sebpop at gmail dot com 2010-06-25 06:24 ---
Subject: Re: [regression 4.4/4.5/4.6] ICE in
resolve_equivalence()
On Fri, Jun 25, 2010 at 01:14, kargl at gcc dot gnu dot org
wrote:
> ... there is a 200 line difference in the location of your
> diff
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49938
--- Comment #3 from sebpop at gmail dot com
2011-08-02 15:02:30 UTC ---
On Tue, Aug 2, 2011 at 04:49, rguenth at gcc dot gnu.org
wrote:
> What's the problem with dealing with a POLYNOMIAL_CHREC here? Why
> not simply return chre
--- Comment #6 from sebpop at gmail dot com 2007-10-30 17:59 ---
Subject: Re: not vectorized: can't determine dependence (array sections)
I would like to keep the two bugs, PR32375 and PR32378, open as we can
vectorize them without having to version the code.
--
--- Comment #16 from sebpop at gmail dot com 2007-10-31 01:13 ---
Subject: Re: can't determine dependence (source/destination overlap without
more than size)
Testing a fix.
--- Comment #17 from sebpop at gmail dot com 2007-10-31 01:13 ---
Created an attachment (id=
--- Comment #5 from sebpop at gmail dot com 2007-10-31 23:43 ---
Subject: Re: Failing to represent the stride (with array) of a dataref when it
is not a constant
> > Making us return symbolic stride would not be hard. The problem is that
> > data
> > dependence a
--- Comment #13 from sebpop at gmail dot com 2007-11-03 05:19 ---
Subject: Re: [4.3 Regression] Exponential time behavior in PRE
> Yes, the heuristics can sometimes generate a very large number of
> copies to eliminate a single redundancy.
> This is jsut the way the sta
--- Comment #14 from sebpop at gmail dot com 2007-11-03 05:26 ---
Subject: Re: [4.3 Regression] Exponential time behavior in PRE
With the patch, compile time goes down also for PR33922.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32540
--- Comment #15 from sebpop at gmail dot com 2007-11-03 05:54 ---
Subject: Re: [4.3 Regression] Exponential time behavior in PRE
And I just saw that there is already a patch for this bug attached
unfortunately to PR32575.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32540
--- Comment #1 from sebpop at gmail dot com 2007-11-03 06:31 ---
Subject: Re: New: missed optimization with dependency checker
> int
> foo (char *a, unsigned n)
> {
> int i;
> a[0] = 0;
> for (i = 16; i < n; i++)
> a[i] = a[i-16];
> }
>
1 - 100 of 111 matches
Mail list logo
