https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78638
Segher Boessenkool changed:
What|Removed |Added
CC||krebbel at gcc dot gnu.org
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78561
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78561
--- Comment #5 from Segher Boessenkool ---
Oh btw, you forgot to commit the testcase in 2/2.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78342
--- Comment #11 from Segher Boessenkool ---
No, we probably still want backports.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78610
--- Comment #4 from Segher Boessenkool ---
Nope, backports are needed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78561
--- Comment #8 from Segher Boessenkool ---
I usually use --disable-libgomp, but otherwise everything default (well,
--enable-languages=all,ada,go,obj-c++).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78561
--- Comment #10 from Segher Boessenkool ---
gcc112 is LE, it cannot run 32-bit at all :-)
Try gcc110, that works.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78561
--- Comment #12 from Segher Boessenkool ---
It still happens here, also on gcc110. Note you need --disable-werror,
to avoid another bootstrap error.
Did you perchance use --disable-bootstrap?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78561
--- Comment #14 from Segher Boessenkool ---
I used trunk. --disable-bootstrap fails the same, just much faster ;-)
Maybe the binutils etc. version matters?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78561
--- Comment #17 from Segher Boessenkool ---
(In reply to James Greenhalgh from comment #16)
> Created attachment 40267 [details]
> Proposed Patch
>
> Would you mind testing the attached to see if it fixes your issue?
Bootstrapped fine, regressi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78626
--- Comment #2 from Segher Boessenkool ---
I have tested something similar, and it does work, but it prevents any
optimisation by cprop of any trap_if, also if it would not turn into
an unconditional trap. This is pretty bad :-(
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78626
--- Comment #5 from Segher Boessenkool ---
(In reply to Bernd Schmidt from comment #3)
> Not sure it's that bad really. An unconditional trap is pretty much by
> definition not performance-critical.
Sure, but this was prohibiting propagating any
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72717
--- Comment #4 from Segher Boessenkool ---
That works I guess... Please test on BE and 32-bit as well. Oh, and
no parens in a = (b) ? c : d; (for simple b at least).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78626
--- Comment #7 from Segher Boessenkool ---
(In reply to Bernd Schmidt from comment #4)
> Created attachment 40269 [details]
> Candidate patch
That looks great :-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78626
--- Comment #8 from Segher Boessenkool ---
... and works fine, too!
ms:
stwu 1,-32(1)
lis 9,qs@ha
lwz 9,qs@l(9)
twnei 9,0
.L6:
b .L6
Nice :-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77957
--- Comment #7 from Segher Boessenkool ---
Author: segher
Date: Wed Dec 7 23:07:58 2016
New Revision: 243415
URL: https://gcc.gnu.org/viewcvs?rev=243415&root=gcc&view=rev
Log:
rs6000: Don't forget to initialize the TOC (PR77957)
The code gener
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77957
--- Comment #8 from Segher Boessenkool ---
Author: segher
Date: Wed Dec 7 23:11:23 2016
New Revision: 243416
URL: https://gcc.gnu.org/viewcvs?rev=243416&root=gcc&view=rev
Log:
rs6000: Don't forget to initialize the TOC (PR77957)
The code gener
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77957
--- Comment #9 from Segher Boessenkool ---
Fixed on all open branches.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77957
Segher Boessenkool changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78638
--- Comment #6 from Segher Boessenkool ---
Author: segher
Date: Thu Dec 8 00:09:01 2016
New Revision: 243420
URL: https://gcc.gnu.org/viewcvs?rev=243420&root=gcc&view=rev
Log:
simplify-rtx: Fix the last fix (PR78638)
I managed to get the last
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78638
Segher Boessenkool changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78610
Segher Boessenkool changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
||2016-12-09
CC||segher at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #4 from Segher Boessenkool ---
Confirmed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78683
--- Comment #1 from Segher Boessenkool ---
Author: segher
Date: Fri Dec 9 19:31:06 2016
New Revision: 243499
URL: https://gcc.gnu.org/viewcvs?rev=243499&root=gcc&view=rev
Log:
rs6000: clz/ctz/ffs improvement (PR78683)
On CPUs that implement po
||segher at gcc dot gnu.org
Resolution|FIXED |---
--- Comment #18 from Segher Boessenkool ---
This gives a warning in powerpc-linuc (which breaks bootstrap), when
compiling tree-inline.c:
/home/segher/src/gcc/gcc/vec.h:1613:5: error: argument 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=17308
--- Comment #19 from Segher Boessenkool ---
powerpc64-linux, even.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78817
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78817
--- Comment #3 from Segher Boessenkool ---
It is a warning (as well as a bootstrap comparison error) on powerpc64-linux.
You tested on powerpc64le-linux, different animal.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78764
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71216
Segher Boessenkool changed:
What|Removed |Added
CC||rin at NetBSD dot org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78764
Segher Boessenkool changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71216
--- Comment #8 from Segher Boessenkool ---
Hi Rin,
> However, I have a question on this fix. How about the case where
> "-Wa,-mXXX" option is given without "-mcpu=YYY" option specified?
That might or might not work; the user had better know wha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78751
--- Comment #2 from Segher Boessenkool ---
In this testcase ifcvt happens upon a branch like:
(jump_insn 28 27 65 2 (set (pc)
(if_then_else (eq (reg:CCEQ 183)
(const_int 0 [0]))
(label_ref:SI 65)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78683
Segher Boessenkool changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78751
--- Comment #3 from Segher Boessenkool ---
Created attachment 40383
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40383&action=edit
patch
I use this patch as workaround. It, well, sucks. But it does work.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77345
--- Comment #5 from Segher Boessenkool ---
It looks very much like PR71724 indeed, but I cannot get this one to fail.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71724
--- Comment #5 from Segher Boessenkool ---
I am using the following, which also fixes the infinite loop, and seems to
not regress code quality much at all (I found *one* pattern where it made
things one machine insn worse, involving a define_insn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78904
Segher Boessenkool changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71216
--- Comment #10 from Segher Boessenkool ---
(In reply to Rin Okuyama from comment #9)
> > > However, I have a question on this fix. How about the case where
> > > "-Wa,-mXXX" option is given without "-mcpu=YYY" option specified?
> >
> > That mig
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78904
--- Comment #3 from Segher Boessenkool ---
(In reply to Uroš Bizjak from comment #2)
> No, unfortunately the above is not a valid x86 insn. x86 has two-operand
> instructions, so output has to match one of the operands.
But these are pseudos.
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78904
--- Comment #7 from Segher Boessenkool ---
Ah, "high byte" registers are never a separate register in the i386
backend, I see.
combine would need to combine four insns to arrive at your current
pattern, but it doesn't try because it thinks they
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78342
Segher Boessenkool changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78626
--- Comment #11 from Segher Boessenkool ---
It is ready to be committed AFAIK; same for the related PR78727.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68803
Segher Boessenkool changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
Assignee: unassigned at gcc dot gnu.org
Reporter: segher at gcc dot gnu.org
Target Milestone: ---
The testcase fails with -m32, as reported by Andreas in
https://gcc.gnu.org/ml/gcc-patches/2017-01/msg00017.html .
This is because long is just 32 bits with -m32, so generates the same code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79039
Segher Boessenkool changed:
What|Removed |Added
Target||powerpc*-*-*
Status|UNC
: unassigned at gcc dot gnu.org
Reporter: segher at gcc dot gnu.org
Target Milestone: ---
/home/segher/build/tot-master/gcc/include/altivec.h:392:0: warning: "vec_cntlz"
redefined
#define vec_cntlz __builtin_vec_vctz
/home/segher/build/tot-master/gcc/include/altivec.h:352:0: not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79040
Segher Boessenkool changed:
What|Removed |Added
Target||powerpc*-*-*
Status|UNC
||2017-01-10
CC||segher at gcc dot gnu.org
Ever confirmed|0 |1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71847
Segher Boessenkool changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79058
--- Comment #9 from Segher Boessenkool ---
With the code and flags in comment 2 i get a segmentation fault, instead
(with a powerpc64-linux host), somewhere during LRA.
insn 10 is
===
(insn 10 8 11 2 (set (reg:DI 120)
(and:DI (subreg:DI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78751
--- Comment #5 from Segher Boessenkool ---
Oh, the patch isn't ugly, just the resulting code is :-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79066
--- Comment #3 from Segher Boessenkool ---
Confirmed. The constant is forced to mem in LRA.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79066
--- Comment #5 from Segher Boessenkool ---
-mno-lra calls rs6000_emit_move to load the address of the const mem
it creates; -mlra does not. It should, but how what where.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71724
--- Comment #6 from Segher Boessenkool ---
*** Bug 77345 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77345
Segher Boessenkool changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72749
--- Comment #9 from Segher Boessenkool ---
(In reply to Arseny Solokha from comment #7)
> I wonder if the following ICE is somehow related to the one reported here.
> I'll file a new PR if it's not.
This is a different bug (it still happens with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72749
--- Comment #13 from Segher Boessenkool ---
I have a patch bootstrapping, let's not close this yet.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61729
--- Comment #1 from Segher Boessenkool ---
This testcase uses a 2-byte scoped enum, which doesn't get the integer
promotions if I read the C++ standard correctly -- but it is passed via
varargs, and the target code expects that to be promoted alw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78751
--- Comment #6 from Segher Boessenkool ---
Author: segher
Date: Sun Jan 15 17:03:55 2017
New Revision: 244476
URL: https://gcc.gnu.org/viewcvs?rev=244476&root=gcc&view=rev
Log:
ifcvt: Don't make invalid insns for a cond trap (PR78751)
As shown
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72749
--- Comment #14 from Segher Boessenkool ---
Author: segher
Date: Sun Jan 15 17:06:00 2017
New Revision: 244477
URL: https://gcc.gnu.org/viewcvs?rev=244477&root=gcc&view=rev
Log:
Make rtl_split_edge work for jumps that fall through (PR72749)
If
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72749
Segher Boessenkool changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78751
Segher Boessenkool changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61729
--- Comment #3 from Segher Boessenkool ---
Okay, I'll make it work for SVR4 in the rs6000 backend then.
The generic code makes suboptimal code, many ABIs need to update (even
those that haven't changed for 25 years), and more backends will need
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78952
--- Comment #3 from Segher Boessenkool ---
Note avr has an "any_extract" code_iterator for this. That of course
is a crutch but could be a workaround for you for now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78875
--- Comment #2 from Segher Boessenkool ---
Author: segher
Date: Tue Jan 17 22:02:42 2017
New Revision: 244556
URL: https://gcc.gnu.org/viewcvs?rev=244556&root=gcc&view=rev
Log:
-mstack-protector-guard and friends (PR78875)
Currently, on PowerPC
||7.0
Assignee|unassigned at gcc dot gnu.org |segher at gcc dot
gnu.org
Known to fail|7.0 |
--- Comment #4 from Segher Boessenkool ---
Should work on trunk now. Needs backports to all open release branches.
|unassigned at gcc dot gnu.org |segher at gcc dot
gnu.org
||2017-01-19
Assignee|unassigned at gcc dot gnu.org |segher at gcc dot
gnu.org
Ever confirmed|0 |1
--- Comment #1 from Segher Boessenkool ---
Confirmed. I have a patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77346
--- Comment #13 from Segher Boessenkool ---
(In reply to Jeffrey A. Law from comment #12)
> It does raise the question of how long we're going to support -mno-lra on
> PPC.
The plan is to remove it in GCC 8.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78875
--- Comment #5 from Segher Boessenkool ---
Author: segher
Date: Fri Jan 20 01:22:27 2017
New Revision: 244677
URL: https://gcc.gnu.org/viewcvs?rev=244677&root=gcc&view=rev
Log:
rs6000: Fix the new SSP guard configuration code (PR79140)
I foolis
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79140
--- Comment #2 from Segher Boessenkool ---
Author: segher
Date: Fri Jan 20 01:22:27 2017
New Revision: 244677
URL: https://gcc.gnu.org/viewcvs?rev=244677&root=gcc&view=rev
Log:
rs6000: Fix the new SSP guard configuration code (PR79140)
I foolis
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61729
--- Comment #4 from Segher Boessenkool ---
Author: segher
Date: Sat Jan 21 03:11:49 2017
New Revision: 244740
URL: https://gcc.gnu.org/viewcvs?rev=244740&root=gcc&view=rev
Log:
rs6000: Small varargs for BE SVR4 (PR61729, PR77850)
The varargs co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77850
--- Comment #1 from Segher Boessenkool ---
Author: segher
Date: Sat Jan 21 03:11:49 2017
New Revision: 244740
URL: https://gcc.gnu.org/viewcvs?rev=244740&root=gcc&view=rev
Log:
rs6000: Small varargs for BE SVR4 (PR61729, PR77850)
The varargs co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79197
--- Comment #3 from Segher Boessenkool ---
Ah I can reproduce it now... -mcpu=power7 -mno-popcntd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78559
--- Comment #10 from Segher Boessenkool ---
I am leaning toward accepting Bin's patch, but testing whether that hurts
generated code too much still hasn't finished.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79211
--- Comment #1 from Segher Boessenkool ---
I cannot reproduce this problem; are there any special (configure)
flags I need?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79211
Segher Boessenkool changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79211
--- Comment #4 from Segher Boessenkool ---
Ah. That reg:SF 3 is not an fpr_reg_operand (3 is GPR 3).
Now how did that happen...
|unassigned at gcc dot gnu.org |segher at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67288
--- Comment #6 from Segher Boessenkool ---
(In reply to Bernd Schmidt from comment #5)
> (In reply to Christophe Leroy from comment #0)
>
> > The following section is just useless: (shift left 4 bits, remove 16, shift
> > right 4 bits, add 1)
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68664
--- Comment #12 from Segher Boessenkool ---
new_ready just adds insns to the ready list. High latency isn't
directly a problem: if we can schedule a high latency insn early
speculatively, that is a _good_ thing!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68664
--- Comment #14 from Segher Boessenkool ---
I'm not sure how to read your remark. An insn where the result is
not used is not on the critical path by definition; and you seem to
be arguing for -fno-sched-spec by default?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79295
--- Comment #1 from Segher Boessenkool ---
So operands[0] is wrong (should be an AltiVec reg, is an FP reg).
||2017-02-03
Resolution|WONTFIX |---
Assignee|unassigned at gcc dot gnu.org |segher at gcc dot
gnu.org
Ever confirmed|0 |1
--- Comment #3 from Segher Boessenkool ---
See https://gcc.gnu.org/ml/gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79354
--- Comment #4 from Segher Boessenkool ---
That looks good to me. Mike, to you too?
-end |rtl-optimization
Assignee|unassigned at gcc dot gnu.org |segher at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68664
--- Comment #18 from Segher Boessenkool ---
Author: segher
Date: Mon Feb 6 19:19:49 2017
New Revision: 245215
URL: https://gcc.gnu.org/viewcvs?rev=245215&root=gcc&view=rev
Log:
sched: Do not move expensive insns speculatively (PR68664)
Schedul
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68664
Segher Boessenkool changed:
What|Removed |Added
Status|ASSIGNED|NEW
--- Comment #19 from Segher Boe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68664
--- Comment #22 from Segher Boessenkool ---
(In reply to Jan Hubicka from comment #20)
> There was also regression on cray for x86-64
> https://gcc.opensuse.org/c++bench-czerny/c-ray/
> Is it the same issue?
I don't think so. But I don't know m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68664
--- Comment #24 from Segher Boessenkool ---
(In reply to Jan Hubicka from comment #23)
> > > Also with profile feedback perhaps you have enough info to tell that the
> > > speculative path is almost as likely as the original placement.
> >
> > M
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64081
--- Comment #52 from Segher Boessenkool ---
(In reply to Aldy Hernandez from comment #50)
> Though at this
> point, I'd rather we figure out why the erroneous code is being generated in
> comment 45.
If you can send me the output (.s and .c.*) w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64081
--- Comment #54 from Segher Boessenkool ---
Thanks Aldy, this makes it clear what happens, and it is actually
pretty simple.
The patch changes check_simple_exit to also return true if
check_complex_exit is true (as well as some other conditions)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79397
--- Comment #1 from Segher Boessenkool ---
Author: segher
Date: Wed Feb 8 09:59:55 2017
New Revision: 245276
URL: https://gcc.gnu.org/viewcvs?rev=245276&root=gcc&view=rev
Log:
rs6000: Fix spelling of AltiVec in rs6000.opt (PR79397)
It was spel
||2017-02-08
CC||segher at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #2 from Segher Boessenkool ---
Fixed on trunk; will commit to 5 and 6 in a bit. Thanks for the report.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64081
--- Comment #56 from Segher Boessenkool ---
Yes, and a function that computes a "more permissive" version should
not have "simple_loop" in its name, it is very misleading. Reusing
existing functions to do something different may seem attractive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79427
--- Comment #1 from Segher Boessenkool ---
I get the correct output on BE (gcc110). This is glibc 2.18, maybe
that is the difference?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64081
--- Comment #58 from Segher Boessenkool ---
You can keep get_simple_loop_desc, find_simple_exit etc.; just make them
inline functions or similar.
I'm sceptical that this will not cause any more problems, we're deep into
stage 4 already :-/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79397
--- Comment #3 from Segher Boessenkool ---
Author: segher
Date: Wed Feb 8 21:41:31 2017
New Revision: 245286
URL: https://gcc.gnu.org/viewcvs?rev=245286&root=gcc&view=rev
Log:
rs6000: Fix spelling of AltiVec in rs6000.opt (PR79397)
It was spel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79397
--- Comment #4 from Segher Boessenkool ---
Author: segher
Date: Wed Feb 8 21:44:37 2017
New Revision: 245287
URL: https://gcc.gnu.org/viewcvs?rev=245287&root=gcc&view=rev
Log:
rs6000: Fix spelling of AltiVec in rs6000.opt (PR79397)
It was spel
1601 - 1700 of 3229 matches
Mail list logo
