http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56865
--- Comment #5 from Bill Schmidt 2013-05-02
15:29:10 UTC ---
Created attachment 30001
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30001
Vectorization details dump for r196871
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56865
--- Comment #6 from Bill Schmidt 2013-05-02
15:29:51 UTC ---
Created attachment 30002
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30002
Vectorization details dump for r196872
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56864
Bill Schmidt changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
--- C
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57154
Bug #: 57154
Summary: [4.9 Regression] Bootstrap broken for
powerpc64-unknown-linux-gnu
Classification: Unclassified
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57154
--- Comment #2 from Bill Schmidt 2013-05-03
11:45:06 UTC ---
There is a powerpc64 pool machine available. I believe it's gcc110.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57154
--- Comment #13 from Bill Schmidt 2013-05-03
17:32:05 UTC ---
Teresa, thanks for the prompt fix!
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57154
Bill Schmidt changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57192
--- Comment #2 from Bill Schmidt 2013-05-07
18:23:21 UTC ---
Created attachment 30047
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30047
Proposed patch
Hi Joost,
Can you please apply the proposed patch and see if this fixes yo
||wschmidt at gcc dot gnu.org
Resolution||FIXED
--- Comment #6 from Bill Schmidt 2013-05-07
20:11:09 UTC ---
OK, thanks! Current trunk has a half-good fix that I put in this morning. The
proposed patch fixes it the right way
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57192
--- Comment #7 from Bill Schmidt 2013-05-07
20:13:10 UTC ---
Ah, and thanks for noting the compile warning. I would have expected that to
get caught in bootstrap, odd. I'll fix that.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57203
--- Comment #1 from Bill Schmidt 2013-05-08
17:52:20 UTC ---
I can't reproduce this with an x86_64 cross-compiler today, using r198713.
Could you please verify this still fails natively with at least r198709? I
hope the main SLSR bug fix has ta
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57192
--- Comment #13 from Bill Schmidt ---
(In reply to Joost VandeVondele from comment #0)
> when compiled at -O3 . Compiling with 4.8 branch, or 4.9 and -O2 doesn't
> cause this behavior.
I just want to point out that SLSR runs at -O1 and above by
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57192
--- Comment #14 from Bill Schmidt ---
Of course, there can be secondary effects that cause SLSR to kick in with
different intermediate code, but it's something to consider.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57192
--- Comment #15 from Bill Schmidt ---
I was able to download your code, and I can't reproduce the problem on
powerpc64-unknown-linux-gnu with current trunk.
||2012-08-09
CC||wschmidt at gcc dot gnu.org
AssignedTo|unassigned at gcc dot |wschmidt at gcc dot gnu.org
|gnu.org |
Target Milestone|--- |4.8.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54211
--- Comment #3 from William J. Schmidt 2012-08-09
21:06:22 UTC ---
Ah, actually we're generating a POINTER_PLUS_EXPR when a PLUS_EXPR is called
for. I see what's going on, shouldn't be hard to fix.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54211
--- Comment #4 from William J. Schmidt 2012-08-10
01:14:41 UTC ---
The following patch is tested and awaiting approval:
Index: gcc/gimple-ssa-strength-reduction.c
===
--- gcc/gimple
||wschmidt at gcc dot gnu.org
Resolution||DUPLICATE
--- Comment #2 from William J. Schmidt 2012-08-10
01:16:07 UTC ---
Correct, this is a dup. Thanks, Andrew.
*** This bug has been marked as a duplicate of bug 54211 ***
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54211
William J. Schmidt changed:
What|Removed |Added
CC||hjl.tools at gmail dot com
--- Comme
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54211
--- Comment #6 from William J. Schmidt 2012-08-10
12:16:11 UTC ---
Author: wschmidt
Date: Fri Aug 10 12:16:04 2012
New Revision: 190294
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190294
Log:
gcc:
2012-08-10 Bill Schmidt
PR mi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54211
William J. Schmidt changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54211
William J. Schmidt changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54240
--- Comment #3 from William J. Schmidt 2012-08-13
14:14:59 UTC ---
Odd, I don't know. I'll have to go back and look at the tests when I get a
moment and investigate that. Peculiar.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54240
--- Comment #5 from William J. Schmidt 2012-08-13
14:24:48 UTC ---
Well, I'm embarrassed. The tests I wrote for this functionality never got into
the test suite -- I apparently forgot to submit them with the patch -- and I
can't find them anymor
||2012-08-13
AssignedTo|unassigned at gcc dot |wschmidt at gcc dot gnu.org
|gnu.org |
Ever Confirmed|0 |1
--- Comment #6 from William J. Schmidt 2012-08-13
15:46:31 UTC ---
Mine.
||2012-08-13
AssignedTo|unassigned at gcc dot |wschmidt at gcc dot gnu.org
|gnu.org |
Ever Confirmed|0 |1
--- Comment #2 from William J. Schmidt 2012-08-13
19:29:06 UTC ---
I'll take a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54240
--- Comment #7 from William J. Schmidt 2012-08-13
20:39:59 UTC ---
Something else is broken, too, as the optab handlers for cmov on powerpc64
appear to have gone missing. I'll get one of our back-end specialists to help
me understand that.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54240
--- Comment #9 from William J. Schmidt 2012-08-14
11:44:35 UTC ---
(In reply to comment #8)
> (In reply to comment #7)
> > Something else is broken, too, as the optab handlers for cmov on powerpc64
> > appear to have gone missing. I'll get one o
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54245
--- Comment #3 from William J. Schmidt 2012-08-14
12:34:24 UTC ---
I'm putting together a for-now patch that disables the optimization when a
widening cast produces the stride. In the long run this can be re-enabled so
long as we can retain the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54240
--- Comment #11 from William J. Schmidt
2012-08-14 19:48:40 UTC ---
Well. It turns out that cmov_optab was a red herring. Apparently no ports are
generating this, and actually movcc_optab is what's being used instead. My
guess is that cmov_opt
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54240
--- Comment #12 from William J. Schmidt
2012-08-15 13:17:47 UTC ---
Author: wschmidt
Date: Wed Aug 15 13:17:42 2012
New Revision: 190411
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190411
Log:
gcc:
2012-08-15 Bill Schmidt
PR t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54240
William J. Schmidt changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54245
--- Comment #4 from William J. Schmidt 2012-08-15
13:27:38 UTC ---
Author: wschmidt
Date: Wed Aug 15 13:27:29 2012
New Revision: 190412
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190412
Log:
gcc:
2012-08-15 Bill Schmidt
PR tr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54245
William J. Schmidt changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54245
William J. Schmidt changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54492
William J. Schmidt changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54563
--- Comment #6 from William J. Schmidt 2012-09-14
18:25:52 UTC ---
I tend to agree; this isn't the only place in the middle-end this could cause
trouble. The handling of pow/powf in reassociation comes to mind as another
place where this could c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54674
--- Comment #6 from William J. Schmidt 2012-09-24
01:38:37 UTC ---
Andrew, thanks for chasing this down. I'll have a look.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54674
--- Comment #7 from William J. Schmidt 2012-09-24
18:35:41 UTC ---
I'm working on a patch to avoid introducing a multiply by a pointer type, such
as happened here.
The interesting thing is that this doesn't look like a profitable
transf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54674
--- Comment #9 from William J. Schmidt 2012-09-24
20:32:34 UTC ---
To be clear, SLSR doesn't rely on mult costs being greater than int costs -- it
simply trusts that the given costs are accurate and makes decisions based upon
them.
Don'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54674
--- Comment #11 from William J. Schmidt
2012-09-26 16:49:45 UTC ---
Author: wschmidt
Date: Wed Sep 26 16:49:32 2012
New Revision: 191765
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=191765
Log:
2012-09-26 Bill Schmidt
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54674
William J. Schmidt changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution
AssignedTo|unassigned at gcc dot |wschmidt at gcc dot gnu.org
|gnu.org |
--- Comment #3 from William J. Schmidt 2012-10-22
13:48:26 UTC ---
Mine. Just unburying myself after vacation, but will take a look as soon as I
can.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55008
--- Comment #4 from William J. Schmidt 2012-10-22
15:41:41 UTC ---
Simple enough. The statement has two interpretations and one looks like a
basis for the other. Surprised this never came up before. Adding a check to
avoid letting a sta
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55008
--- Comment #5 from William J. Schmidt 2012-10-22
22:09:29 UTC ---
Author: wschmidt
Date: Mon Oct 22 22:09:22 2012
New Revision: 192696
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=192696
Log:
gcc:
2012-10-22 Bill Schmidt
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55008
William J. Schmidt changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution
-optimization
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: wschmidt at gcc dot gnu.org
CC: bergner at vnet dot ibm.com
Host: powerpc*-*-*
Target: powerpc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57309
--- Comment #2 from Bill Schmidt ---
(In reply to Richard Biener from comment #1)
> Can you isolate a testcase for the worst loop?
Not yet. It's one of these horrible gargantuan functions (leslie3d is one big
file and fluxi, fluxj, fluxk are all
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57441
Bill Schmidt changed:
What|Removed |Added
CC||wschmidt at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57441
--- Comment #3 from Bill Schmidt ---
Pending patch available at
http://gcc.gnu.org/ml/gcc-patches/2013-05/msg01723.html.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57441
Bill Schmidt changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35308
Bill Schmidt changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
, wrong-code
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: wschmidt at gcc dot gnu.org
CC: bergner at vnet dot ibm.com, dje at gcc dot gnu.org
Host: powerpc64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57949
--- Comment #1 from Bill Schmidt ---
The front end identifies the structure as having the correct alignment. From
the 001t.tu dump:
@2846 record_type name: @2857size: @127 algn: 128
tag : struct fld
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57949
--- Comment #2 from Bill Schmidt ---
The wrong code is introduced during expand. vs.m is computed as
mem(plus(virtual-incoming-args, 72))
with the pad at offset 80, v[0..1] at offset 88, and v[2..3] at offset 96. All
are shown as having alig
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57949
--- Comment #3 from Bill Schmidt ---
The problem is target-specific, in config/rs6000/rs6000.c:
rs6000_function_arg_boundary().
static unsigned int
rs6000_function_arg_boundary (enum machine_mode mode, const_tree type)
{
if (DEFAULT_ABI == ABI_
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57949
--- Comment #4 from Bill Schmidt ---
Enabling the code used for MachO/Darwin64 when targeting ABI_AIX/linux produces
much better code:
li 9,144
addis 8,2,.LC1@toc@ha
lvx 0,1,9
ld 10,.LC1@toc@l(8)
addis 8,2,.LC2@toc@ha
ld 9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57949
Bill Schmidt changed:
What|Removed |Added
CC||joseph at codesourcery dot com
--- Comment
gcc dot gnu.org |wschmidt at gcc dot
gnu.org
--- Comment #3 from Bill Schmidt ---
Mine. I'll investigate.
To reproduce this on powerpc64-unknown-linux-gnu requires adding -fsigned-char
to the compile flags (a clue!).
Bill
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57993
--- Comment #5 from Bill Schmidt ---
Looks like the casting is confusing us into replacing PHIs not dominated by the
prospective basis. Shouldn't be too hard to fix.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57993
--- Comment #6 from Bill Schmidt ---
Here's the patch I'm currently testing, which corrects the problem for this
test case. We'll see how it does on regressions.
Index: gcc/gimple-ssa-strength-reduction.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57993
--- Comment #7 from Bill Schmidt ---
More complete fix submitted as
http://gcc.gnu.org/ml/gcc-patches/2013-07/msg01326.html.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57993
Bill Schmidt changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57949
--- Comment #7 from Bill Schmidt ---
I rewrote the test case to use the IBM vector extensions and ran it through
xlc. The generated code shows that xlc addresses the code as expected by the
ABI (and contrary to what's done by gcc). So this adds
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041
--- Comment #6 from Bill Schmidt ---
I'll investigate. It may be a day or two before I can get to it, but this is
pretty clearly my issue.
Thanks,
Bill
||2013-08-01
Assignee|unassigned at gcc dot gnu.org |wschmidt at gcc dot
gnu.org
Ever confirmed|0 |1
--- Comment #7 from Bill Schmidt ---
This shouldn't be too hard to fix. Looks like we are missing a check for
possibly unaligned
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041
--- Comment #11 from Bill Schmidt ---
Hi Martin,
Your assumptions are correct, but I'm not sure this is the best place to handle
it. It looks like what you are doing is replacing one already correct memory
reference with another, both of which w
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041
--- Comment #12 from Bill Schmidt ---
...which apparently is not quite right, since the candidates still appear in
the table. Hm. But you get the idea -- do the check earlier.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041
--- Comment #14 from Bill Schmidt ---
(In reply to Bernd Edlinger from comment #13)
> Hi,
>
> just one question, how about the -m[no-]unaligned-access option?
>
> If -munaligned-access had been given the code was almost right,
> I mean AFAIK ldr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041
--- Comment #15 from Bill Schmidt ---
Bernd, Mikael, Martin: Could you please test this on your respective targets?
Index: gcc/gimple-ssa-strength-reduction.c
===
--- gcc/gimple-ssa
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041
--- Comment #17 from Bill Schmidt ---
Excellent! Thanks for the confirmation.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58010
--- Comment #3 from Bill Schmidt ---
r189527 is probably a red herring. That just changed the cost model to be
turned on by default at -O3. Somebody who's actively working on the vectorizer
should probably have a look at this.
If you want to na
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041
--- Comment #20 from Bill Schmidt ---
After thinking it over some more, I think you are right, Martin. We should go
ahead with the optimization with the corrected alignment attached to the type.
Please go ahead with your patch. I will run a rou
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041
--- Comment #23 from Bill Schmidt ---
(In reply to Eric Botcazou from comment #22)
> We should be very wary of generating unaligned accesses during optimization
> for targets that define SLOW_UNALIGNED_ACCESS. And note that most
> architectures s
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041
--- Comment #21 from Bill Schmidt ---
My only comment on the patch would be to please add commentary indicating why
the change is being made, and referencing this PR. Something along the lines
of:
/* Ensure the memory reference carries the min
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041
--- Comment #25 from Bill Schmidt ---
Yep, that's terrific. Thanks.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041
--- Comment #26 from Bill Schmidt ---
Martin's patch bootstrapped on powerpc64-unknown-linux-gnu with no new
regressions.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57993
--- Comment #9 from Bill Schmidt ---
I missed a couple of candidate replacements in the previous fix; these are
fixed in r201466.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58041
--- Comment #41 from Bill Schmidt ---
Thanks, Martin!
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57949
Bill Schmidt changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50180
Bug #: 50180
Summary: insn does not satisfy constraints for 444.namd when
generating profile data
Classification: Unclassified
Product: gcc
Version: 4.6.2
Status: UNC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50181
Bug #: 50181
Summary: insn does not satisfy constraints for 481.wrf when
generating profile data
Classification: Unclassified
Product: gcc
Version: 4.6.2
Status: UNCO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50183
Bug #: 50183
Summary: ICE in verify_ssa for 416.gamess when optimizing using
profile data
Classification: Unclassified
Product: gcc
Version: 4.6.2
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50183
--- Comment #1 from William J. Schmidt 2011-08-24
21:32:34 UTC ---
Created attachment 25096
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25096
Profile data for grd2c.fppized.f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50183
--- Comment #3 from William J. Schmidt 2011-08-25
13:39:54 UTC ---
Thanks. -floop-interchange is required to cause the problem, and
graphite_transforms was in the stack at the time of the verify failure. I
believe there was an explicit call to
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50191
Bug #: 50191
Summary: Strange debug insn produced for TOC compiling
416.gamess with profile-generate
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50183
--- Comment #4 from William J. Schmidt 2011-08-25
21:02:02 UTC ---
Here's the backtrace from the failure.
(gdb) bt
#0 internal_error (gmsgid=0x10e73c80 "verify_ssa failed") at
/home/wschmidt/gcc/gcc-4_6-branch/gcc/diagnostic.c:838
#1 0x000
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50191
--- Comment #5 from William J. Schmidt 2011-08-29
13:45:36 UTC ---
Jakub, I don't see -fprofile-generate in your list of options. What Peter gave
you was the link command that exposed the problem, but the error occurred when
compiling chgpen.fpp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50191
--- Comment #7 from William J. Schmidt 2011-08-29
18:05:17 UTC ---
Hm, mysterious. That's the correct auto-host.h and the correct options. I
will get on one of the farm machines and see if I can reproduce with a
cross-compiler.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50191
--- Comment #8 from William J. Schmidt 2011-08-30
19:33:42 UTC ---
I built a cross-compiler on gcc10.fsffrance.org that exhibits the problem:
$ cd /home/wschmidt/src/416.gamess
$ /home/wschmidt/gcc/build/gcc-mainline-base/gcc/f951 chgpen.fppized
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50183
--- Comment #5 from William J. Schmidt 2011-08-30
21:07:03 UTC ---
Here's the relevant gimple following 103t.copyprop5:
==
:
err2 = 0.0;
err2_lsm.820_567 = err2;
:
#
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50183
--- Comment #6 from William J. Schmidt 2011-09-01
21:41:19 UTC ---
This PHI:
:
# err2.395_561 = PHI
is removed by the second call to remove_phi in
translate_scalar_reduction_to_array (graphite-sese-to-poly.c). There appears
to be an implici
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50191
--- Comment #11 from William J. Schmidt
2011-09-02 17:44:28 UTC ---
Also, when I built a new cross-compiler over on gcc10, the issue moved from
.LC7 to .LC8 -- so the exact .LC number may vary for whatever reason.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50183
--- Comment #7 from William J. Schmidt 2011-09-12
19:18:07 UTC ---
Slogging through the code, it appears to me that the code added in block 45 to
define err2.395_571:
D.6815_562 = Commutative_Associative_Reduction.822[0];
err2.395_571 = D.68
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50183
--- Comment #8 from William J. Schmidt 2011-09-12
20:15:59 UTC ---
Previous comment is incorrect. The statement:
# err2.395_571 = PHI
is the close_phi for the outer loop, while:
# err2.395_561 = PHI
is the close_phi for the inner loop.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50183
--- Comment #9 from William J. Schmidt 2011-09-13
15:24:08 UTC ---
OK, the problem appears to originate earlier, sometime during
canonicalize_loop_closed_ssa_form (). After canonicalization, we have:
:
# err2.395_571 = PHI
# err2_lsm.820_5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50183
--- Comment #10 from William J. Schmidt
2011-09-13 16:40:05 UTC ---
The problem arises during canonicalization in the presence of nested loops.
Loops are processed outward-in. When each loop is processed, its single exit
edge's destination bloc
||2011-09-13
AssignedTo|unassigned at gcc dot |wschmidt at gcc dot gnu.org
|gnu.org |
Ever Confirmed|0 |1
--- Comment #11 from William J. Schmidt
2011-09-13 17:19:56 UTC ---
Tentative fix
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50557
--- Comment #2 from William J. Schmidt 2011-09-28
12:13:50 UTC ---
The fix for 49749 is intended to remove dependencies between loop iterations.
One possibility would be to condition the changes on the presence of
-funroll-loops. Another would
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50557
--- Comment #4 from William J. Schmidt 2011-09-29
12:16:46 UTC ---
No, that's OK. I should be able to reproduce this on a pool machine.
It may be difficult to come up with a good heuristic here given that
reassociation doesn't have a good estim
101 - 200 of 1697 matches
Mail list logo
