Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: sebpop at gmail dot com
Target Milestone: ---
On testsuite/gcc.target/i386/long-double-64-1.c, gcc produces a call to
__multf3 on arm64 and the test checks that such a call
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50335
--- Comment #10 from sebpop at gmail dot com 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
gcc-bugzi...@gcc.gnu.org wrote:
Do I understand correctly that you are suggesting
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50335
--- Comment #8 from sebpop at gmail dot com 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49938
--- Comment #3 from sebpop at gmail dot com 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
gcc-bugzi...@gcc.gnu.org wrote:
What's the problem with dealing with a POLYNOMIAL_CHREC here
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48648
--- Comment #7 from sebpop at gmail dot com 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46886
--- Comment #4 from sebpop at gmail dot com 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
gcc-bugzi...@gcc.gnu.org wrote:
Seems one extra incorrect iteration is added after
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46194
--- Comment #7 from sebpop at gmail dot com 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46194
--- Comment #9 from sebpop at gmail dot com 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 * x_1]
last_conflict
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45306
--- Comment #9 from sebpop at gmail dot com 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
gcc-bugzi...@gcc.gnu.org wrote:
I'm guessing that means 4.5 will stay broken?
Depends
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40979
--- Comment #16 from sebpop at gmail dot com 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40979
--- Comment #18 from sebpop at gmail dot com 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
gcc-bugzi...@gcc.gnu.org wrote:
I'd suggest
NEXT_PASS (pass_graphite
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45146
--- Comment #3 from sebpop at gmail dot com 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46928
--- Comment #4 from sebpop at gmail dot com 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45314
--- Comment #7 from sebpop at gmail dot com 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
gcc-bugzi...@gcc.gnu.org wrote:
On trunk, it was fixed by revision 163123:
http
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45314
--- Comment #10 from sebpop at gmail dot com 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=46186
--- Comment #23 from sebpop at gmail dot com 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
--- 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 different
--- 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
gcc-bugzi...@gcc.gnu.org wrote:
... there is a 200 line difference in the location
--- 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
gcc-bugzi...@gcc.gnu.org wrote:
The mangled Fortran code caught my eye. I'm
--- 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
gcc-bugzi...@gcc.gnu.org wrote:
--- Comment #1 from kargl at gcc dot gnu dot
--- 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
gcc-bugzi...@gcc.gnu.org wrote:
You shouldn't be using type_for_size
--- 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
gcc-bugzi...@gcc.gnu.org wrote:
URL: http://gcc.gnu.org/viewcvs?root=gccview
--- 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
gcc-bugzi...@gcc.gnu.org wrote:
Fixed.
Please use ftp
--- 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
gcc-bugzi...@gcc.gnu.org wrote:
Why such a big hammer?
'cause I don't want to add more bugs,
and no I
--- 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 loop
--- 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 to a[i].
You mean
--- 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 --git
--- 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
gcc-bugzi...@gcc.gnu.org wrote:
I don't
--- 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_radius_very_extended( 0
--- 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.28_439
--- 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
 1ul for (unsigned
--- 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 has some debug_
--- 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
gcc-bugzi...@gcc.gnu.org wrote:
Since revision 150792, the test
--- 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
gcc-bugzi...@gcc.gnu.org wrote:
and the code generated by CLooG for the interchange
--- 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 #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 RES
--- 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 #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
orggcc-bugzi...@gcc.gnu.org wrote:
Eh - where's that exponential time complexity? ...
The code generation of Graphite
--- 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
comgcc-bugzi...@gcc.gnu.org wrote:
I think you should allow more time for people to update
--- 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 and memory
--- 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 #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?id
--- 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
gcc-bugzi...@gcc.gnu.org wrote:
I add test case for this situation.
Yes, indeed this is a good idea.
Thanks
--- Comment #6 from sebpop at gmail dot com 2009-03-19 02:53 ---
Subject: Re: autopar fails to parallel
What |Removed |Added
Component|middle-end
--- 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
trunk
--- 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
graphite and 2
--- 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-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 #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
gcc-bugzi...@gcc.gnu.org wrote:
Somehow I got the impression that graphite is now enabled
--- 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 dumped file
--- 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 #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
--- 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
gcc-bugzi...@gcc.gnu.org wrote:
I'll see if I
can narrow down the problem to the single subroutine
--- 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
--- 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 checkin fixed
--- 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 -m32 on my
--- 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 you close
--- 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-loops -ftree
--- 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 jan.sjo...@amd.com
Harsha Jagasia harsha.jaga...@amd.com
PR tree-optimization/38500
* gcc.dg
--- 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, hjagasia
--- 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 to graphite
--- 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 not obvious
--- 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:1538: internal compiler error
--- 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
--- 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 #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 #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:
but no ICE
--- 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-scalar
--- 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 handled
--- 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 say so if the base
--- 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, mdbx.f90, protein.f90
--- 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 loops, as we
--- 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. But now we fail
--- 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,
Sebastian
--- 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 #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 see
--- 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 just went it.
I might just wait
--- Comment #3 from sebpop at gmail dot com 2008-05-21 16:31 ---
Subject: Re: [4.4 Regression] ICE with -O -ftree-loop-linear
Sebastian, that was your change.
http://gcc.gnu.org/viewcvs?view=revrevision=135672
was a clean-up of the lambda framework.
I'm working on a fix
--- Comment #4 from sebpop at gmail dot com 2008-05-21 18:49 ---
Subject: Re: [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
--- Comment #5
--- Comment #3 from sebpop at gmail dot com 2008-05-15 21:55 ---
Subject: Re: redundant runtime check while vectorizing
Here is a patch for this:
a first data dependence test a call to operand_equal_p on the array references
Tested with vect.exp and tree-ssa.exp.
I will send another
--- 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-data-deps
--- 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 #14 from sebpop at gmail dot com 2008-01-12 00:11 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] DOM and VRP creating harder to
optimize code
Patch: http://gcc.gnu.org/ml/gcc-patches/2008-01/msg00518.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23821
--- Comment #3 from sebpop at gmail dot com 2008-01-09 08:08 ---
Subject: Re: [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
--
http
--- Comment #9 from sebpop at gmail dot com 2007-12-28 17:56 ---
Subject: Re: [4.3 Regression] ICE in int_cst_value, at tree.c:8047 at -O3
Attached is a fix for this bug. I'll test it and then post it on gcc-patches.
Sebastian
--- Comment #10 from sebpop at gmail dot com 2007
--- Comment #5 from sebpop at gmail dot com 2007-12-16 08:31 ---
Subject: Re: gfortran.dg/ltrans-7.f90 doesn't work
On 16 Dec 2007 03:23:17 -, jvdelisle at gcc dot gnu dot org
[EMAIL PROTECTED] wrote:
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2007-12-16 03:23
--- Comment #44 from sebpop at gmail dot com 2007-11-11 05:16 ---
Subject: Re: [4.1/4.2/4.3 regression] Quadratic behavior with many sets for
the same register in VRP
IMVHO this should be closed as WONTFIX.
Steven, why isn't your patch from comment #37 not a candidate for
fixing
--- Comment #12 from sebpop at gmail dot com 2007-11-05 06:13 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] Not elimintating the PHIs which have
the same arguments
Replacing ssa names with other ssa names willy-nilly is not always a
win. We eventually ended up with heuristics
--- Comment #9 from sebpop at gmail dot com 2007-11-03 20:39 ---
Subject: Re: [4.2/4.3 regression] g++.dg/tree-ssa/pr27549.C ICE with
vectorization
I cannot reproduce the bug on i686-linux either.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33319
--- 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 standard PRE
--- 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];
}
We're failing to analyse the base
--- 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 analysis would fail anyway
--- 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.
--
http
1 - 100 of 111 matches
Mail list logo
