https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77346
--- Comment #11 from Bill Schmidt ---
Shall we close this for now? We can always reopen if it resurfaces.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71199
--- Comment #11 from Bill Schmidt ---
After some experiments, we've found that a better approach is to continue using
the current poor-man's overloading scheme, and do more folding of built-in
calls following gimplification. David, should we clo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78142
--- Comment #2 from Bill Schmidt ---
What's the status of this? Can it be closed?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79044
--- Comment #4 from Bill Schmidt ---
Author: wschmidt
Date: Thu Jan 12 16:01:13 2017
New Revision: 244368
URL: https://gcc.gnu.org/viewcvs?rev=244368&root=gcc&view=rev
Log:
[gcc]
2017-01-12 Bill Schmidt
PR target/79044
* con
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79044
--- Comment #5 from Bill Schmidt ---
Author: wschmidt
Date: Thu Jan 12 17:19:17 2017
New Revision: 244373
URL: https://gcc.gnu.org/viewcvs?rev=244373&root=gcc&view=rev
Log:
[gcc]
2017-01-12 Bill Schmidt
PR target/79044
* con
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79044
Bill Schmidt changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78604
Bill Schmidt changed:
What|Removed |Added
CC||meissner at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78263
--- Comment #5 from Bill Schmidt ---
There are two potential approaches:
(1) Add a warning, such as:
#if defined(__STRICT_ANSI__) && defined(__cplusplus) &&
!defined(__APPLE_ALTIVEC__)
#warning requires GNU extensions; use -std=gnu++
#endif
(
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79040
Bill Schmidt changed:
What|Removed |Added
Assignee|meissner at gcc dot gnu.org|wschmidt at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79137
--- Comment #1 from Bill Schmidt ---
vec_perm_const is one of the standard pattern names, that gets expanded from
a middle-end vector permute.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79040
--- Comment #4 from Bill Schmidt ---
Author: wschmidt
Date: Wed Jan 18 22:29:22 2017
New Revision: 244602
URL: https://gcc.gnu.org/viewcvs?rev=244602&root=gcc&view=rev
Log:
2017-01-18 Bill Schmidt
PR target/79040
* config/rs6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79040
Bill Schmidt changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78900
Bill Schmidt changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71648
--- Comment #5 from Bill Schmidt ---
This appears to be fixed on trunk -- between David and me we've tested this on
AIX 32- and 64-bit, PPC64LE on P8, and PPC64 on P7. We'll need to bisect and
see what fixed the problem and work on a backport fo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71648
--- Comment #6 from Bill Schmidt ---
This actually appears to be fixed in GCC 6 as well, so the fix must have been
backported. Konstantinos, can you please try with GCC 6.3 and confirm that the
problem goes away for you?
Thanks,
Bill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68972
--- Comment #9 from Bill Schmidt ---
The test has gone back to not failing anymore at some point:
https://gcc.gnu.org/ml/gcc-testresults/2017-01/msg01932.html
I don't know why.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79160
Bill Schmidt changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |wschmidt at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77318
--- Comment #9 from Bill Schmidt ---
Seen also on powerpc64-unknown-linux-gnu, but not on
powerpc64le-unknown-linux-gnu.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70012
Bill Schmidt changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70012
--- Comment #3 from Bill Schmidt ---
It looks to me like vect_alignment_reachable is the wrong test to be using
here. This is equivalent to vect_aligned_arrays || natural_alignment_32.
vect_aligned_array is always 0 for powerpc*-*-*. natural_a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70012
Bill Schmidt changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |wschmidt at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79218
--- Comment #2 from Bill Schmidt ---
At the moment, swap optimization doesn't attempt to handle __int128 values, for
which swaps don't deal with elements of a vector, but pieces of a cohesive
integer value. This may be overly conservative, and w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=15826
--- Comment #18 from Bill Schmidt ---
I agree with Matthew.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79160
Bill Schmidt changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79160
--- Comment #4 from Bill Schmidt ---
Resolution in r244916. Oops, forgot the PR line in the ChangeLog.
2017-01-25 Bill Schmidt
* gcc.target/powerpc/vsx-elemrev-4.c: Change expected code
generation to accept D-mode memory acc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65484
Bill Schmidt changed:
What|Removed |Added
Priority|P3 |P4
--- Comment #1 from Bill Schmidt ---
||2017-01-26
CC||meissner at gcc dot gnu.org,
||uros at gcc dot gnu.org,
||wschmidt at gcc dot gnu.org
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65482
--- Comment #4 from Bill Schmidt ---
OK, that explains how we got here. At the moment, the usage of the flag only
matters to the test suite when running on older hardware. On P8, the test
suite uses -mpower8-vector rather than -mvsx -mno-allow-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65484
--- Comment #2 from Bill Schmidt ---
Author: wschmidt
Date: Fri Jan 27 15:59:02 2017
New Revision: 244985
URL: https://gcc.gnu.org/viewcvs?rev=244985&root=gcc&view=rev
Log:
2017-01-27 Bill Schmidt
PR target/65484
* g++.dg/vec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65484
Bill Schmidt changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |wschmidt at gcc dot
gnu.org
Assignee: unassigned at gcc dot gnu.org
Reporter: wschmidt at gcc dot gnu.org
Target Milestone: ---
Use of the vec_xxpermdi built-in appears to work incorrectly on little endian;
it seems to be using big-endian semantics. This may be working as designed
(direct access to the
-code
Severity: major
Priority: P3
Component: target
Assignee: wschmidt at gcc dot gnu.org
Reporter: wschmidt at gcc dot gnu.org
CC: segher at gcc dot gnu.org
Target Milestone: ---
Target: powerpc64*-*-*
I had a thinko
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79268
Bill Schmidt changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79268
--- Comment #1 from Bill Schmidt ---
Author: wschmidt
Date: Mon Jan 30 03:32:59 2017
New Revision: 245021
URL: https://gcc.gnu.org/viewcvs?rev=245021&root=gcc&view=rev
Log:
[gcc]
2017-01-29 Bill Schmidt
PR target/79268
* con
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70012
--- Comment #6 from Bill Schmidt ---
(In reply to Iain Sandoe from comment #5)
> (In reply to Bill Schmidt from comment #4)
> > Created attachment 40568 [details]
> > Proposed patch
> >
> > Attaching proposed patch. Iain, would you be able to t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79268
--- Comment #2 from Bill Schmidt ---
Author: wschmidt
Date: Tue Jan 31 22:57:55 2017
New Revision: 245075
URL: https://gcc.gnu.org/viewcvs?rev=245075&root=gcc&view=rev
Log:
[gcc]
2017-01-31 Bill Schmidt
Backport from mainline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79268
Bill Schmidt changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70012
--- Comment #7 from Bill Schmidt ---
Author: wschmidt
Date: Wed Feb 1 22:11:57 2017
New Revision: 245108
URL: https://gcc.gnu.org/viewcvs?rev=245108&root=gcc&view=rev
Log:
2017-02-01 Bill Schmidt
PR target/70012
* gcc.dg/vec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70012
Bill Schmidt changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79197
--- Comment #16 from Bill Schmidt ---
(In reply to Jakub Jelinek from comment #15)
> I see SIGILL on
>0x3fffb7e722e8 : xscvuxdsp vs32,vs33
> => 0x3fffb7e722ec : stxssp v0,0(r31)
>0x3fffb7e722f0 : add r31,r31,r27
> T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65484
--- Comment #4 from Bill Schmidt ---
Author: wschmidt
Date: Fri Feb 3 19:06:58 2017
New Revision: 245164
URL: https://gcc.gnu.org/viewcvs?rev=245164&root=gcc&view=rev
Log:
2017-02-03 Bill Schmidt
Backport from mainline
2017-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65484
--- Comment #5 from Bill Schmidt ---
Author: wschmidt
Date: Fri Feb 3 19:08:10 2017
New Revision: 245165
URL: https://gcc.gnu.org/viewcvs?rev=245165&root=gcc&view=rev
Log:
2017-02-03 Bill Schmidt
Backport from mainline
2017-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65484
Bill Schmidt changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79544
Bill Schmidt changed:
What|Removed |Added
Keywords||wrong-code
Version|unknown
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79544
--- Comment #1 from Bill Schmidt ---
Note that this is indeed wrong because the semantics of vec_sra are to
duplicate the sign bit even for unsigned inputs.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79545
Bill Schmidt changed:
What|Removed |Added
Keywords||wrong-code
Target|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79261
--- Comment #1 from Bill Schmidt ---
Author: wschmidt
Date: Fri Feb 17 19:11:06 2017
New Revision: 245545
URL: https://gcc.gnu.org/viewcvs?rev=245545&root=gcc&view=rev
Log:
[gcc]
2017-02-17 Bill Schmidt
PR target/79261
* con
||2017-02-17
Assignee|unassigned at gcc dot gnu.org |wschmidt at gcc dot
gnu.org
Target Milestone|--- |7.0
Ever confirmed|0 |1
--- Comment #2 from Bill Schmidt ---
Fixed in trunk so far. Backports needed for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79545
Bill Schmidt changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79140
--- Comment #3 from Bill Schmidt ---
This can be closed, I think?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68644
Bill Schmidt changed:
What|Removed |Added
Target|hppa*-*-* (32-bit) |hppa*-*-* (32-bit)
|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68644
--- Comment #10 from Bill Schmidt ---
Created attachment 40785
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40785&action=edit
ivopts-details-scev dump
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68644
Bill Schmidt changed:
What|Removed |Added
CC||amker at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68644
--- Comment #13 from Bill Schmidt ---
So for POWER, at least, the IV for i is not eliminated.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68644
--- Comment #14 from Bill Schmidt ---
Also, there's an introduced ivtmp, rather than using p as an ivar.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68644
--- Comment #16 from Bill Schmidt ---
OK, thanks, that helps. We'll evaluate the cost model here and figure out
what's best.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68644
--- Comment #17 from Bill Schmidt ---
The current code generation is quite tight using the existing cost modeling:
.L2:
stwu 10,4(3)
bdnz .L2
Thus we will plan to skip this test for POWER.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68644
--- Comment #18 from Bill Schmidt ---
Author: wschmidt
Date: Wed Feb 22 18:00:21 2017
New Revision: 245656
URL: https://gcc.gnu.org/viewcvs?rev=245656&root=gcc&view=rev
Log:
2017-02-22 Bill Schmidt
PR tree-optimization/68644
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68644
Bill Schmidt changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79261
--- Comment #4 from Bill Schmidt ---
Author: wschmidt
Date: Wed Feb 22 22:54:56 2017
New Revision: 245664
URL: https://gcc.gnu.org/viewcvs?rev=245664&root=gcc&view=rev
Log:
[gcc]
2017-02-22 Bill Schmidt
Backport from mainline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79261
Bill Schmidt changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79261
--- Comment #3 from Bill Schmidt ---
Author: wschmidt
Date: Wed Feb 22 22:52:36 2017
New Revision: 245663
URL: https://gcc.gnu.org/viewcvs?rev=245663&root=gcc&view=rev
Log:
[gcc]
2017-02-22 Bill Schmidt
Backport from mainline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79427
Bill Schmidt changed:
What|Removed |Added
Target|powerpc64-unknown-linux-gnu |powerpc64-unknown-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79455
--- Comment #2 from Bill Schmidt ---
I think the most relevant issue here is that we are usually generating a call
to memset here, but apparently on rare occasions we do not. That kind of
inconsistency is troubling, to say the least.
As Segher
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79268
--- Comment #4 from Bill Schmidt ---
Author: wschmidt
Date: Thu Feb 23 19:29:40 2017
New Revision: 245687
URL: https://gcc.gnu.org/viewcvs?rev=245687&root=gcc&view=rev
Log:
2017-02-23 Bill Schmidt
PR target/79268
* gcc.target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79395
--- Comment #2 from Bill Schmidt ---
(In reply to acsawdey from comment #1)
> * possibly the tests like 3d-01.c should move to gcc.dg/powerpc because
> arguably for -mcpu=power9 we are not testing them fully because of -mno-vsx.
Please leave the
-optimization
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: wschmidt at gcc dot gnu.org
CC: anton at samba dot org, rguenth at gcc dot gnu.org
Target Milestone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79941
Bill Schmidt changed:
What|Removed |Added
CC||willschm at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79908
Bill Schmidt changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79908
Bill Schmidt changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |wschmidt at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79905
--- Comment #3 from Bill Schmidt ---
So, is the desired behavior that the front end produce an error message
instead? Or is the front end supposed to unify these two types and accept the
code?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79908
--- Comment #3 from Bill Schmidt ---
Patch isn't acceptable; still investigating.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79908
--- Comment #4 from Bill Schmidt ---
Any fix for this must also handle this reduced test case:
typedef __builtin_va_list __gnuc_va_list;
typedef __gnuc_va_list va_list;
void
foo (va_list args)
{
va_list ap;
__builtin_va_copy (ap, args);
(
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79905
Bill Schmidt changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80054
Bill Schmidt changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |wschmidt at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80054
--- Comment #3 from Bill Schmidt ---
Reproducible on ppc64le without any -march.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80054
--- Comment #4 from Bill Schmidt ---
PRE creates a situation where a conditional SLSR candidate depends on a PHI
that occurs prior to the basis for the candidate. SLSR doesn't notice this and
eventually creates a phi basis that is not dominated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80054
--- Comment #5 from Bill Schmidt ---
Author: wschmidt
Date: Mon Mar 20 20:04:25 2017
New Revision: 246290
URL: https://gcc.gnu.org/viewcvs?rev=246290&root=gcc&view=rev
Log:
[gcc]
2017-03-20 Bill Schmidt
PR tree-optimization/80054
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80054
Bill Schmidt changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79908
--- Comment #5 from Bill Schmidt ---
Author: wschmidt
Date: Tue Mar 21 13:57:20 2017
New Revision: 246319
URL: https://gcc.gnu.org/viewcvs?rev=246319&root=gcc&view=rev
Log:
[gcc]
2017-03-21 Bill Schmidt
Richard Biener
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79908
Bill Schmidt changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80136
--- Comment #4 from Bill Schmidt ---
OK. I'm going to revert the original patch until I can reproduce this and
start looking at it. There's clearly something different about the aarch64
port and varargs that doesn't like this approach. None of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79908
Bill Schmidt changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79908
--- Comment #8 from Bill Schmidt ---
Author: wschmidt
Date: Tue Mar 21 18:14:42 2017
New Revision: 246330
URL: https://gcc.gnu.org/viewcvs?rev=246330&root=gcc&view=rev
Log:
[gcc]
2017-03-21 Bill Schmidt
PR tree-optimization/79908
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80136
Bill Schmidt changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80136
--- Comment #6 from Bill Schmidt ---
Back up in expand_ifn_va_arg_1, when we reach
expr = targetm.gimplify_va_arg_expr (ap, type, &pre, &post);
the statement being processed is:
(gdb) ps stmt
# .MEM_3410 = VDEF <.MEM_2810>
VA_ARG (&arg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80136
--- Comment #7 from Bill Schmidt ---
Looking at aarch64_gimplify_va_arg_expr, it allocates several temporary
variables, and creates a number of modify_exprs that use them, nested inside
this enormous compound_expr. But it does no gimplification
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80136
--- Comment #8 from Bill Schmidt ---
Placing a call to gimplify_and_add prior to the call to force_gimple_operand
seems to do what we want. The compile completes and the side effects code is
all generated as expected. Christophe, James, Andrew,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80136
--- Comment #9 from Bill Schmidt ---
I am really doubtful that is the right fix, by the way, but I want to get some
evidence about what's going on...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80136
--- Comment #10 from Bill Schmidt ---
Note that force_gimple_operand would do the gimplify_and_add for expr under
some circumstances:
if (TREE_CODE (expr) != MODIFY_EXPR
&& TREE_TYPE (expr) == void_type_node)
{
gimplify_and_add
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80136
--- Comment #15 from Bill Schmidt ---
Jakub, thanks for the confirmation that force_gimple_operand is unnecessary.
Christophe, thanks for testing. Thus I am now regstrapping:
Index: gcc/testsuite/gcc.dg/torture/pr79908.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80136
--- Comment #18 from Bill Schmidt ---
Thanks, all. I will commit the patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80136
--- Comment #19 from Bill Schmidt ---
Author: wschmidt
Date: Thu Mar 23 13:13:44 2017
New Revision: 246418
URL: https://gcc.gnu.org/viewcvs?rev=246418&root=gcc&view=rev
Log:
[gcc]
2017-03-23 Bill Schmidt
Richard Biener
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79908
--- Comment #9 from Bill Schmidt ---
Author: wschmidt
Date: Thu Mar 23 13:13:44 2017
New Revision: 246418
URL: https://gcc.gnu.org/viewcvs?rev=246418&root=gcc&view=rev
Log:
[gcc]
2017-03-23 Bill Schmidt
Richard Biener
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79908
Bill Schmidt changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80136
Bug 80136 depends on bug 79908, which changed state.
Bug 79908 Summary: ICE in gimplify_expr (gimplify.c:12155) gimplification failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79908
What|Removed |Added
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80136
Bill Schmidt changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80158
--- Comment #3 from Bill Schmidt ---
Richard, what flags are you using with the reduced test case? Hoping I can
reproduce this on ppc64le without a cross, but so far no luck.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80158
--- Comment #5 from Bill Schmidt ---
OK, I will have to find an x86 box -- fortran cross is too challenging.
Meanwhile, could you please add -fdump-tree-reassoc2 and
-fdump-tree-slsr-details and post the results? Might be able to figure it out
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80158
--- Comment #9 from Bill Schmidt ---
Thanks, those dumps are very helpful. I found an x86 box, just need to get set
up now. The SLSR dump is truncated but it still tells me what it was working
on when it died, so should help me out.
901 - 1000 of 1697 matches
Mail list logo
