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
Target|hppa*-*-* (32-bit) |hppa*-*-* (32-bit)
|
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=79545
Bill Schmidt changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
||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=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
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=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=79544
Bill Schmidt changed:
What|Removed |Added
Keywords||wrong-code
Version|unknown
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=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
--- 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=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=70012
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=79268
Bill Schmidt changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
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=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 #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=79268
Bill Schmidt changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
-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
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
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
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=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-
||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=65484
Bill Schmidt changed:
What|Removed |Added
Priority|P3 |P4
--- Comment #1 from Bill Schmidt ---
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=79160
Bill Schmidt changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
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=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=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=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
Status|UNCONFIRMED |NEW
Last reconfirmed|
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=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=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=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=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=78900
Bill Schmidt changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
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=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=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
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=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=78604
Bill Schmidt changed:
What|Removed |Added
CC||meissner at gcc dot gnu.org
--- Comment #
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=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
--- 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=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=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=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=79044
--- Comment #3 from Bill Schmidt ---
Patches submitted here:
https://gcc.gnu.org/ml/gcc-patches/2017-01/msg00651.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79044
Bill Schmidt changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79044
Bill Schmidt changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |wschmidt at gcc dot
gnu.org
,
||wschmidt at gcc dot gnu.org
--- Comment #1 from Bill Schmidt ---
Carl, please have a look -- looks like you meant vec_cnttz here. May have
committed wrong version?
,
||wschmidt at gcc dot gnu.org
--- Comment #1 from Bill Schmidt ---
CCing Carl. Carl, be sure to use long long instead of long so that you get 64
bits on both -m32 and -m64.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79006
Bill Schmidt changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: wschmidt at gcc dot gnu.org
Target Milestone: ---
Compile the following with -Os on GCC 6.3 or current trunk:
typedef struct
{
unsigned long a_type;
union
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77834
Bill Schmidt changed:
What|Removed |Added
CC||wschmidt at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78540
Bill Schmidt changed:
What|Removed |Added
CC||wschmidt at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78695
Bill Schmidt changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78695
--- Comment #12 from Bill Schmidt ---
Author: wschmidt
Date: Sun Dec 11 23:37:17 2016
New Revision: 243534
URL: https://gcc.gnu.org/viewcvs?rev=243534&root=gcc&view=rev
Log:
[gcc]
2016-12-11 Bill Schmidt
PR target/78695
* co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78695
--- Comment #11 from Bill Schmidt ---
Patch under test:
Index: gcc/config/rs6000/rs6000.c
===
--- gcc/config/rs6000/rs6000.c (revisio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78740
Bill Schmidt changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78740
--- Comment #7 from Bill Schmidt ---
Author: wschmidt
Date: Fri Dec 9 22:02:04 2016
New Revision: 243506
URL: https://gcc.gnu.org/viewcvs?rev=243506&root=gcc&view=rev
Log:
2016-12-09 Bill Schmidt
PR testsuite/78740
* gcc.tar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78740
--- Comment #3 from Bill Schmidt ---
Yes, that works:
Running
/home/wschmidt/gcc/gcc-mainline-test/gcc/testsuite/gcc.target/powerpc/powerpc.exp
...
=== gcc Summary for unix/-m64 ===
# of unsupported tests 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78740
Bill Schmidt changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78740
--- Comment #4 from Bill Schmidt ---
Since the test doesn't have a { dg-do ... }, I don't know whether you were
intending compile-only or an executable test. Use { dg-do run { target ... } }
as needed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78740
--- Comment #2 from Bill Schmidt ---
I think the target restriction
/* { dg-do compile { target { powerpc*-*-* && ilp32 } } } */
is probably sufficient to fix this. I can test that in a bit.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78695
--- Comment #10 from Bill Schmidt ---
Excellent, thanks.
I am out of the office today but will have a look at this tomorrow.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78646
--- Comment #11 from Bill Schmidt ---
Author: wschmidt
Date: Wed Dec 7 01:08:40 2016
New Revision: 243331
URL: https://gcc.gnu.org/viewcvs?rev=243331&root=gcc&view=rev
Log:
2016-12-06 Bill Schmidt
Backport from mainline
2016
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78646
--- Comment #10 from Bill Schmidt ---
Author: wschmidt
Date: Wed Dec 7 01:04:47 2016
New Revision: 243330
URL: https://gcc.gnu.org/viewcvs?rev=243330&root=gcc&view=rev
Log:
2016-12-06 Bill Schmidt
Backport from mainline
2016
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72827
--- Comment #29 from Bill Schmidt ---
Author: wschmidt
Date: Tue Dec 6 22:11:54 2016
New Revision: 243319
URL: https://gcc.gnu.org/viewcvs?rev=243319&root=gcc&view=rev
Log:
2016-12-06 Bill Schmidt
Backport from mainline
2016
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78695
--- Comment #6 from Bill Schmidt ---
Still no repro with bootstrap compiler.
wschmidt@genoa:~/src$ $GCC_INSTALL/bin/gcc -S -O3 pr78695.c
wschmidt@genoa:~/src$ $GCC_INSTALL/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/home/wschmidt/gcc/install/g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78695
--- Comment #5 from Bill Schmidt ---
Also does not reproduce with a debug compiler at r243219:
wschmidt@genoa:~/src$ $GCC_INSTALL/bin/gcc -S -O3 pr78695.c
wschmidt@genoa:~/src$ $GCC_INSTALL/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/home/wsch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78695
--- Comment #4 from Bill Schmidt ---
The offending line appears to be
rtx_insn *and_insn = DF_REF_INSN (base_def_link->ref);
which would seem to indicate an inconsistency in the dataflow information at
this point. It would be good to be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78695
--- Comment #3 from Bill Schmidt ---
Yeah, I can't reproduce this either (r243264). Do you have local
modifications?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78699
Bill Schmidt changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
Compo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78695
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=78646
Bill Schmidt changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78646
--- Comment #8 from Bill Schmidt ---
Author: wschmidt
Date: Mon Dec 5 21:48:27 2016
New Revision: 243272
URL: https://gcc.gnu.org/viewcvs?rev=243272&root=gcc&view=rev
Log:
2016-12-05 Bill Schmidt
Stefan Freudenberger
P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78646
Bill Schmidt changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78683
Bill Schmidt changed:
What|Removed |Added
Target||powerpc*-*-*
CC|
: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: wschmidt at gcc dot gnu.org
Target Milestone: ---
For this code:
unsigned r; r = (unsigned) __builtin_ctzl(v); return r;
GCC on POWER produces:
neg 9,3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78646
Bill Schmidt changed:
What|Removed |Added
CC||wschmidt at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78614
--- Comment #23 from Bill Schmidt ---
I've backported the insn_is_swappable_p bugfix to gcc-5-branch and
gcc-6-branch. Thanks again for fixing that, Alan!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78576
Bill Schmidt changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78576
--- Comment #12 from Bill Schmidt ---
Ah, I was incorrect about that. If I use -O0, the test produces 26 in my
environment as well. At higher optimization the whole computation is folded.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78576
--- Comment #11 from Bill Schmidt ---
Breno, what is your environment? Which glibc is present?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78576
--- Comment #10 from Bill Schmidt ---
OK, that accounts for it. That would be a glibc problem.
Building this code with GCC trunk on Ubuntu 14.04 with glibc 2.19, the program
produces 27 as expected.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78576
--- Comment #8 from Bill Schmidt ---
At the time, Breno reported 0x403b as the high half, which is
accurate. Looking back, I didn't get a report of the low half. If somehow
that were produced as a negative number, that would also a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78576
--- Comment #5 from Bill Schmidt ---
Andreas, it can't be a lack of accuracy, because 27.0 = 2^4 x 1.6875. There
can't be any rounding error; this is an exact number in all floating-point
representations.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78576
--- Comment #1 from Bill Schmidt ---
The conversion is done by __fixtfdi in libgcc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78396
--- Comment #6 from Bill Schmidt ---
gfortran.dg/vect/pr77848.f indeed still passes with this change.
I suppose that similar code where something else in the block could be
vectorized would still regress, though. I don't think that's sufficient
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78413
Bill Schmidt changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78396
--- Comment #5 from Bill Schmidt ---
OK, I'll test it out shortly.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78413
--- Comment #7 from Bill Schmidt ---
Author: wschmidt
Date: Mon Nov 21 14:10:11 2016
New Revision: 242661
URL: https://gcc.gnu.org/viewcvs?rev=242661&root=gcc&view=rev
Log:
[gcc]
2016-11-21 Bill Schmidt
PR tree-optimization/78413
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78396
--- Comment #3 from Bill Schmidt ---
The ??? comments worry me -- can't this leave us with the same kinds of
regressions that led to PR77848? I think the specific test in that PR may
regress again.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78413
--- Comment #5 from Bill Schmidt ---
Patch submitted here: https://gcc.gnu.org/ml/gcc-patches/2016-11/msg01951.html
701 - 800 of 1697 matches
Mail list logo
