https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61542
--- Comment #6 from Bill Schmidt ---
Author: wschmidt
Date: Thu Jun 26 18:50:25 2014
New Revision: 212050
URL: https://gcc.gnu.org/viewcvs?rev=212050&root=gcc&view=rev
Log:
2014-06-26 Bill Schmidt
PR target/61542
* config/rs6000/vsx.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61542
Bill Schmidt changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
,
||wschmidt at gcc dot gnu.org
--- Comment #2 from Bill Schmidt ---
Reported to fail for powerpc64le-unknown-linux-gnu as well. CCing middle end
maintainer.
Assignee: unassigned at gcc dot gnu.org
Reporter: wschmidt at gcc dot gnu.org
CC: rdsandiford at googlemail dot com
Host: powerpc64le-unknown-linux-gnu
Target: powerpc64le-unknown-linux-gnu
Build: powerpc64le-unknown-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62301
Bill Schmidt changed:
What|Removed |Added
Target|powerpc64le-unknown-linux-g |powerpc64*-unknown-linux-gn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62301
--- Comment #2 from Bill Schmidt ---
Example backtrace for segv:
#0 0x4d5a28a0 in ?? ()
#1 0x10370128 in mem_loc_descriptor(rtx_def*, machine_mode,
machine_mode, var_init_status) ()
#2 0x103704f4 in mem_loc_descriptor(
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62301
--- Comment #3 from Bill Schmidt ---
Looks like a subtle logic change in the patch:
+ FOR_EACH_SUBRTX (iter, array, body, ALL)
+if (const_rtx y = *iter)
+ {
+ /* Check if a label_ref Y refers to label X. */
+ if (GET_CODE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62301
--- Comment #4 from Bill Schmidt ---
Unfortunately that was not sufficient -- same SEGVs are still occurring.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62301
--- Comment #6 from Bill Schmidt ---
Ah...I've been staring at the two versions for so long and that never leaped
out at me. :) Thanks, Richard!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62301
--- Comment #9 from Bill Schmidt ---
Thanks, Richard!
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: wschmidt at gcc dot gnu.org
CC: bergner at gcc dot gnu.org, pthaugen at gcc dot gnu.org,
segher at gcc dot gnu.org
Host: powerpc64le-unknown-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63165
Bill Schmidt changed:
What|Removed |Added
Target|powerpc64le-unknown-linux-g |powerpc64*-unknown-linux-gn
at gcc dot gnu.org |wschmidt at gcc dot
gnu.org
--- Comment #2 from Bill Schmidt ---
I see the problem. I'll work on a patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63335
--- Comment #3 from Bill Schmidt ---
Proposed patch here: https://gcc.gnu.org/ml/gcc-patches/2014-09/msg02201.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63335
--- Comment #4 from Bill Schmidt ---
Author: wschmidt
Date: Thu Sep 25 14:06:09 2014
New Revision: 215599
URL: https://gcc.gnu.org/viewcvs?rev=215599&root=gcc&view=rev
Log:
[gcc]
2014-09-25 Bill Schmidt
PR target/63335
* config/rs60
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63335
--- Comment #5 from Bill Schmidt ---
Author: wschmidt
Date: Thu Sep 25 15:12:42 2014
New Revision: 215603
URL: https://gcc.gnu.org/viewcvs?rev=215603&root=gcc&view=rev
Log:
[gcc]
2014-09-25 Bill Schmidt
PR target/63335
* config/rs60
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63335
--- Comment #6 from Bill Schmidt ---
Author: wschmidt
Date: Thu Sep 25 15:15:06 2014
New Revision: 215604
URL: https://gcc.gnu.org/viewcvs?rev=215604&root=gcc&view=rev
Log:
[gcc]
2014-09-25 Bill Schmidt
PR target/63335
* config/rs60
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63335
Bill Schmidt changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68403
--- Comment #8 from Bill Schmidt ---
Verified that the powerpc64le failures are gone as well.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68707
Bill Schmidt changed:
What|Removed |Added
CC||wschmidt at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68776
--- Comment #1 from Bill Schmidt ---
Created attachment 36947
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36947&action=edit
Vectorization dump for r226675
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: wschmidt at gcc dot gnu.org
CC: rguenth at gcc dot gnu.org
Target Milestone: ---
Host: powerpc*-*-linux
-optimization
Severity: normal
Priority: P3
Component: target
Assignee: segher at kernel dot crashing.org
Reporter: wschmidt at gcc dot gnu.org
CC: dje.gcc at gmail dot com
Target Milestone: ---
Host: powerpc64le-*-linux
Priority: P3
Component: target
Assignee: segher at gcc dot gnu.org
Reporter: wschmidt at gcc dot gnu.org
CC: dje.gcc at gmail dot com, seurer at linux dot vnet.ibm.com
Target Milestone: ---
Host: powerpc64le-*-linux*
Target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68814
Bill Schmidt changed:
What|Removed |Added
Target Milestone|--- |6.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68799
--- Comment #2 from Bill Schmidt ---
Hi Matthias,
Attempted to recreate with powerpc64le-linux-gnu running on POWER8 using latest
gcc-5-branch. I get a different failure within lto1; output shown below. This
indicates a problem streaming in a
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: wschmidt at gcc dot gnu.org
CC: dje.gcc at gmail dot com, jwakely.gcc at gmail dot com,
seurer at linux dot vnet.ibm.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68825
--- Comment #4 from Bill Schmidt ---
Thanks, Jonathan!
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: wschmidt at gcc dot gnu.org
CC: law at gcc dot gnu.org, seurer at linux dot vnet.ibm.com
Target Milestone: ---
Host: powerpc64-*-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68844
--- Comment #1 from Bill Schmidt ---
Created attachment 36987
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36987&action=edit
dom1 dump from r228306
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: wschmidt at gcc dot gnu.org
CC: dje.gcc at gmail dot com, segher at gcc dot gnu.org,
seurer at linux dot vnet.ibm.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68865
Bill Schmidt changed:
What|Removed |Added
Target Milestone|--- |6.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68865
--- Comment #2 from Bill Schmidt ---
That's very possible. No doubt r231165 just caused it to come out of the
woodwork again. However, I verified that it didn't ICE with r230600 - r231164,
so something about r231165 managed to trigger the issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68799
--- Comment #3 from Bill Schmidt ---
Created attachment 37008
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37008&action=edit
test patch to gather more information
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68799
Bill Schmidt changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68867
Bill Schmidt changed:
What|Removed |Added
CC||wschmidt at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68799
--- Comment #6 from Bill Schmidt ---
Hm, that almost worked. Can you please delete the line
dump_incr_vec ();
from that patch and try again? Sorry for the trouble. Meanwhile I'll see if
the partial data I got triggers any ideas.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68799
--- Comment #7 from Bill Schmidt ---
The most likely cause here is memory being improperly overwritten. If the data
from the next round of dumps don't turn up anything, I'll need a debuggable
version of gcc so I can try to sort out the offender.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68844
--- Comment #5 from Bill Schmidt ---
Jeff, thanks very much for the detailed analysis!
Bill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58796
Bill Schmidt changed:
What|Removed |Added
CC||wschmidt at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58796
--- Comment #10 from Bill Schmidt ---
Apologies, Jonathan, I didn't see that. I was led here from some internal
tracking and wasn't previously CC'd on the bug. Sorry for the noise.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68799
Bill Schmidt changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |wschmidt at gcc dot
gnu.org
||2015-12-15
CC||wschmidt at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #15 from Bill Schmidt ---
Obviously confirmed at this point. Vlad, do you plan to backport this to GCC
5? We should get this closed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55975
--- Comment #39 from Bill Schmidt ---
I believe this work has been completed. Peter, do you concur?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45053
Bill Schmidt changed:
What|Removed |Added
CC||wschmidt at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32429
Bill Schmidt changed:
What|Removed |Added
CC||wschmidt at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25972
Bill Schmidt changed:
What|Removed |Added
CC||wschmidt at gcc dot gnu.org
--- Comment
,
||wschmidt at gcc dot gnu.org
--- Comment #9 from Bill Schmidt ---
David, looks like you fixed this long ago -- can this be closed?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68872
Bill Schmidt changed:
What|Removed |Added
Target Milestone|--- |6.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68867
--- Comment #16 from Bill Schmidt ---
Hm, but comment #8 from PR24685 indicates that this is clearly a regression.
At that time Andrew Pinski asserted that this failure was restricted to Darwin,
and powerpc*-linux didn't fail the test.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68805
Bill Schmidt changed:
What|Removed |Added
Target Milestone|--- |6.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68770
Bill Schmidt changed:
What|Removed |Added
Target Milestone|--- |6.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68753
Bill Schmidt changed:
What|Removed |Added
Target Milestone|--- |6.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68752
Bill Schmidt changed:
What|Removed |Added
Target Milestone|--- |6.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68690
Bill Schmidt changed:
What|Removed |Added
Target Milestone|--- |6.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68685
Bill Schmidt changed:
What|Removed |Added
Target Milestone|--- |6.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68664
Bill Schmidt changed:
What|Removed |Added
Target Milestone|--- |6.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67530
Bill Schmidt changed:
What|Removed |Added
Target Milestone|--- |6.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68867
--- Comment #22 from Bill Schmidt ---
Jerry, thanks very much for investigating. Given all the discussion here I
agree with XFAILing this test for all powerpc. However, it does appear to be
one of those intermittent failures, so we'll have to p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67530
--- Comment #3 from Bill Schmidt ---
No, the same code is produced for at least GCC 5. I just happened to notice it
on trunk while looking at another problem.
I hope to get time to look at this one in the next couple of weeks if nobody
else has
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68776
--- Comment #4 from Bill Schmidt ---
Yep. I'll verify the fix and commit today if all goes well. Thanks for the
investigation!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68776
--- Comment #5 from Bill Schmidt ---
(In reply to Bill Schmidt from comment #4)
> Yep. I'll verify the fix and commit today if all goes well. Thanks for the
> investigation!
Actually, looking at check_effective_target_vect_int_mult, this won't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68961
--- Comment #1 from Bill Schmidt ---
Is this little-endian only?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61981
Bill Schmidt changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61397
--- Comment #16 from Bill Schmidt ---
Mike, did your patch go upstream, or is there more work to do here?
||wschmidt at gcc dot gnu.org
Resolution|--- |FIXED
--- Comment #5 from Bill Schmidt ---
Work completed some time ago.
||wschmidt at gcc dot gnu.org
Resolution|--- |FIXED
--- Comment #8 from Bill Schmidt ---
Work completed some time ago.
||wschmidt at gcc dot gnu.org
--- Comment #11 from Bill Schmidt ---
Martin, can this be closed?
||wschmidt at gcc dot gnu.org
Resolution|--- |FIXED
--- Comment #2 from Bill Schmidt ---
Fixed some time ago.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55598
Bill Schmidt changed:
What|Removed |Added
CC||wschmidt at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69033
Bill Schmidt changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69146
--- Comment #1 from Bill Schmidt ---
Please provide cluster.ii as an attachment. Thanks...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69146
--- Comment #2 from Bill Schmidt ---
Oh, sorry, you provided it inline. Need my coffee this morning.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69007
--- Comment #3 from Bill Schmidt ---
I just tried the experiment with swapping the two patterns, and it does indeed
solve the problem.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68803
Bill Schmidt changed:
What|Removed |Added
Summary|[6 regression] |gcc.vect/powerpc/20050603-3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68799
--- Comment #9 from Bill Schmidt ---
It appears that the stmt_cand_map, which is a hash_map from gimple*s to
candidates, must be getting overwritten. At the time things go south, we have
done a lookup on the var _1338 using base_cand_from_table.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68799
--- Comment #10 from Bill Schmidt ---
The stmt_cand_map is *not* losing its integrity. Instead, it appears that a
phi statement changes its address at some point during the SLSR pass, even
though it hasn't been modified (SFAICT).
There are two
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68799
--- Comment #11 from Bill Schmidt ---
OK, I see. Although the PHI itself is not directly modified, a new PHI is
introduced in the same block. During this process we may alter the incoming
control flow to the block (introducing a new block along
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68799
--- Comment #12 from Bill Schmidt ---
Created attachment 37348
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37348&action=edit
Proposed patch
Matthias, please apply the attached patch and see if it clears the bug for you.
Thanks!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68799
--- Comment #14 from Bill Schmidt ---
Author: wschmidt
Date: Mon Jan 18 02:43:06 2016
New Revision: 232491
URL: https://gcc.gnu.org/viewcvs?rev=232491&root=gcc&view=rev
Log:
2016-01-17 Bill Schmidt
PR tree-optimization/68799
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68799
--- Comment #15 from Bill Schmidt ---
Author: wschmidt
Date: Mon Jan 18 02:46:58 2016
New Revision: 232492
URL: https://gcc.gnu.org/viewcvs?rev=232492&root=gcc&view=rev
Log:
2016-01-17 Bill Schmidt
Backport from mainline:
201
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68799
Bill Schmidt changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68799
--- Comment #16 from Bill Schmidt ---
Author: wschmidt
Date: Mon Jan 18 03:54:48 2016
New Revision: 232494
URL: https://gcc.gnu.org/viewcvs?rev=232494&root=gcc&view=rev
Log:
2016-01-17 Bill Schmidt
Backport from mainline:
201
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67755
--- Comment #10 from Bill Schmidt ---
Hi Jeff,
I think we would appreciate having this backported to 5 so it can be fixed in
those distro releases that ship 5. This caused a significant drop in an
important benchmark for us. Thanks!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68959
--- Comment #5 from Bill Schmidt ---
Martin, did you specify -mlra and -mvsx-timode? Peter's compiler is a test one
that turns these on by default. Just want to be sure we're comparing the same
things.
at gcc dot gnu.org |wschmidt at gcc dot
gnu.org
--- Comment #4 from Bill Schmidt ---
I will take a look at this relatively soon. Probably just a testsuite issue as
Richard surmises.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65096
--- Comment #8 from Bill Schmidt ---
I would say so. OP may reopen if he can reproduce on 5.2 or later. Almost
certainly a dup.
at gcc dot gnu.org |wschmidt at gcc dot
gnu.org
--- Comment #4 from Bill Schmidt ---
I'll get this upstream on Anton's behalf.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65408
Bill Schmidt changed:
What|Removed |Added
CC||cyrilbur at gmail dot com
--- Comment #11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65096
Bill Schmidt changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63354
--- Comment #5 from Bill Schmidt ---
Author: wschmidt
Date: Thu Jan 21 17:32:28 2016
New Revision: 232684
URL: https://gcc.gnu.org/viewcvs?rev=232684&root=gcc&view=rev
Log:
[gcc]
2016-01-21 Anton Blanchard
Bill Schmidt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63354
Bill Schmidt changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68685
--- Comment #2 from Bill Schmidt ---
Hm, I can't reproduce this with current trunk. Instead I get a lot of
undefined references from /tmp/*.ltrans0.ltrans.o which seems to indicate we've
gotten beyond the point of the reported failure. Anton, c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67489
Bill Schmidt changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67489
Bill Schmidt changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67489
--- Comment #2 from Bill Schmidt ---
Author: wschmidt
Date: Fri Jan 22 03:01:27 2016
New Revision: 232717
URL: https://gcc.gnu.org/viewcvs?rev=232717&root=gcc&view=rev
Log:
2016-01-21 Bill Schmidt
PR testsuite/67489
* gcc.tar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68685
Bill Schmidt changed:
What|Removed |Added
Status|NEW |WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28366
--- Comment #2 from Bill Schmidt ---
Actually, the code you get for -mcpu=power6 looks "fine." The originally
reported problem was for use of stvewx to store single vector elements, rather
than using stvx to store entire vectors. This is now ha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28314
Bill Schmidt changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68753
Bill Schmidt changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
1301 - 1400 of 1697 matches
Mail list logo
