h reload on by default and lra on by default)
and shows no testsuite regressions. Is this ok for trunk?
The bug is also present in the FSF 5 branch (4.9 is ok), is this ok for
that too, assuming my bootstrap/regtesting there are clean?
Peter
gcc/
PR target/67808
* config/rs6000/rs
s testing whether we ICE when -mlra -mvsx is enabled,
how about if we verify we're also getting the xxlxor too, with the
addition of:
/* { dg-final { scan-assembler-times "xxlxor" 1 } } */
to the test case?
Peter
Ping*2.
Torvald, David approved the code portion of the patch.
How does the documentation part you asked for look to you?
https://gcc.gnu.org/ml/gcc-patches/2015-09/msg00315.html
Peter
On Fri, 2015-10-09 at 16:41 +0200, Torvald Riegel wrote:
> On Thu, 2015-09-03 at 16:58 -0500, Peter Bergner wrote:
>> +Note that the semantics of the above HTM builtins are required to mimic the
>> +locking semantics used for critical sections. Builtins that are used to
&
On Fri, 2015-10-09 at 22:19 +0200, Torvald Riegel wrote:
> On Fri, 2015-10-09 at 11:52 -0500, Peter Bergner wrote:
>> Thanks for the review! I've attached the changes to the documentation below.
>> Is this better?
>
> Yes, thanks!
Great, thanks! This is committed a
d. Some
> of the changes to the libitm.texi ABI docs added in this patch already
> take this future work into account.
>
> Tested using the libitm testsuite on x86_64-linux.
I have fired off a test on powerpc64le-linux and will report back
on its status when it's done.
Peter
On Thu, 2015-11-19 at 09:35 -0600, Torvald Riegel wrote:
> Tested using the libitm testsuite on x86_64-linux.
Tested on powerpc64le-linux with no regressions and I confirmed
the new eh-5.C test case passes.
Peter
?
The same bug exists in FSF 9 anf FSF 8 branches. Ok for those too after
some burn in on trunk and clean regtests on the backports?
Peter
gcc/
PR target/93658
* config/rs6000/rs6000.c (rs6000_legitimate_address_p): Handle VSX
vector modes.
gcc/testsuite/
PR target
On 2/20/20 1:47 AM, Segher Boessenkool wrote:
> On Wed, Feb 19, 2020 at 09:17:26PM -0600, Peter Bergner wrote:
>> This passed bootstrap and regtesting on powerpc64le-linux and powerpc64-linux
>> (in both 32-bit and 64-bit modes) with no regressions. Ok for trunk?
>> The sam
On 2/20/20 11:33 AM, Peter Bergner wrote:
> Ok, I pushed the trunk fix now. I'll kick off the release branch
> backports now.
>
> Jakub, I know you're getting the GCC 8.4 release ready. Is this fix ok
> for FSF 8 now or do you want me to wait until after 8.4 is out?
Th
On 2/22/20 6:49 PM, Segher Boessenkool wrote:
> On Sat, Feb 22, 2020 at 06:25:43PM -0600, Peter Bergner wrote:
>> Is this still ok for GCC 8 & 9?
>
> Please do each of those backports as separate commits (so that if there
> is a problem with them, we can bisect it; it also
FAILing now?
Peter
PR target/93913
* gcc.target/powerpc/fold-vec-st-char.c (scan-assembler-times): Allow
stxv instruction as well.
* gcc.target/powerpc/fold-vec-st-float.c: Likewise.
* gcc.target/powerpc/fold-vec-st-int.c: Likewise.
* gcc.target
; +/* { dg-final { scan-assembler-times {\mstvx|stxv\M} 14 } } */
>
> That checks if either the string
> \mstvx
> or the string
> stxv\M
Oops, good catch.
> You want
> {\m(stvx|stxv)\M}
Is the patch ok with this variant? I think this is more readable to
me than the other variants you gave...at least to me. :-)
Peter
On 2/26/20 11:29 AM, Peter Bergner wrote:
>> You want
>> {\m(stvx|stxv)\M}
As we discussed offline, the regex above double counts everything,
so I went with {\m(?:stvx|stxv|stxvx)\M} which you pointed me to.
Pushed to master. I'll push to the gcc-9 branch tomorrow after
t). That means the caller's flags
must match exactly the callee's flags, for those flags that were explicitly
set in the callee.
Peter
a test that enforces that the
caller's ISA flags match exactly the callee's flags, for those flags
that were explicitly set in the callee. The patch below seems to fix
the issue (regtesting now). Does this look like what we want?
Peter
gcc/
* config/rs6000/rs6000.c (rs6000_can_
user knows this function will
be run with VSX hardware disabled or ...
Peter
On 10/15/19 10:44 AM, Richard Biener wrote:
> On October 15, 2019 5:09:52 PM GMT+02:00, Peter Bergner
> wrote:
>> If the user explicitly said not to compile a function with a particular
>> option, how can we justify ignoring that request just because we're
>> inlin
callee
function, but then using incompatible options on the caller and the callee,
so that it cannot. I think the error message is the correct thing here.
Peter
On 10/15/19 1:21 PM, Segher Boessenkool wrote:
> On Tue, Oct 15, 2019 at 12:47:02PM -0500, Peter Bergner wrote:
>> I'd say this is user error, telling the compiler it has to inline the callee
>> function, but then using incompatible options on the caller and the callee,
>
On 10/15/19 11:12 AM, Peter Bergner wrote:
> On 10/15/19 10:44 AM, Richard Biener wrote:
>> On October 15, 2019 5:09:52 PM GMT+02:00, Peter Bergner
>> wrote:
>>> If the user explicitly said not to compile a function with a particular
>>> option, how can we j
d patch, along with your extra test cases? I have not
bootstrapped or regtested this, so that still needs doing. If you're
busy, I can pick this up when I return to work on Monday.
Peter
gcc/
PR target/70010
* config/rs6000/rs6000.c (rs6000_can_inline_p): Prohibit in
On 11/7/19 1:06 PM, Peter Bergner wrote:
> Before, LRA, we have an insn that sets a TImode pseudo with an integer
> constant and a following insn that copies that TImode pseudo to a PTImode
> pseudo. During LRA spilling, we generate a new insn that sets a PTImode
> pseudo to t
till working on resolving that.
Peter
PR bootstrap/92661
* config/rs6000/rs6000-call.c: (def_builtin): Do not define the
builtin if we don't have an actual type.
(builtin_function_type): If the builtin function uses a DFP type
and decimal float has
On Sat, Mar 25, 2023 at 01:54:16AM -0700, Dan Li wrote:
> In the compiler part[4], most of the content is the same as Sami's
> implementation[3], except for some minor differences, mainly including:
>
> 1. The function typeid is calculated differently and it is difficult
> to be consistent.
This
-linux with no regressions. Is this ok for trunk?
Peter
gcc/
* config/rs6000/ppc-auxv.h (PPC_FEATURE2_DARN): New define.
(PPC_FEATURE2_SCV): Likewise.
* config/rs6000/rs6000.c (cpu_supports_info): Use them.
gcc/testsuite/
* gcc.target/powerpc/cpu-builtin-1.c (darn
On 6/27/17 10:51 AM, Segher Boessenkool wrote:
> On Mon, Jun 26, 2017 at 10:33:48PM -0500, Peter Bergner wrote:
>> Tulio added support for two new AT_HWCAP2 bits to GLIBC which have been
>> recently added to the kernel:
>>
>> https://www.sourceware.org/ml/libc-
ntry, etc.
Ah, that's make sense. I'll have a look at how easy it is.
In the mean time, I'll hold off on committing this.
Peter
remove the parts we don't need like hwcap.h's use of:
#if !defined(_SYS_AUXV_H) && !defined(_SYSDEPS_SYSDEP_H)
# error "Never include directly; use instead."
#endif
which would trigger for our use of it. And also to remove unneeded code from
dl-procinfo.h, since we only want the #defines.
Peter
n_cpu_supports ("vsx"))
> + return 1;
> + return 0;
...and more importantly, why limit us to testing "vsx"? Why not test
for "ppc32", which should be true for *all* kernels we'd ever run on,
including ppc32, ppc64 and ppc64le?
Peter
reported
in the PR81194.
This patch fixes the bug by expanding switch statements that contain only
a default case statement, as a GOTO to the default case's label.
This passed bootstrap and regtesting on x86_64-linux with no regressions.
Ok for trunk?
Peter
gcc/
PR middle-end/
ing a patch fixing both - your patch should still go in.
Ok, committed as revision 249783. Thanks.
Peter
size? There's no reason to
execute the compress labels loop if we didn't combine any of the
labels.
Peter
Index: gcc/tree-cfg.c
===
--- gcc/tree-cfg.c (revision 249783)
+++ gcc/tree-cfg.c (working copy)
@@ -1747
On 6/29/17 8:58 AM, Richard Biener wrote:
> On Thu, 29 Jun 2017, Peter Bergner wrote:
>> Should we offer an early out of group_case_labels_stmt() for the
>> fairly common case of new_size == old_size? There's no reason to
>> execute the compress labels loop if we
On 6/29/17 8:58 AM, Richard Biener wrote:
> On Thu, 29 Jun 2017, Peter Bergner wrote:
>
>> On 6/29/17 4:03 AM, Richard Biener wrote:
>>>
>>> This refactors things a bit to make CFG cleanup handle switches with
>>> just a default label. I
On 6/30/17 3:27 AM, Richard Biener wrote:
> On Thu, 29 Jun 2017, Peter Bergner wrote:
>> On 6/29/17 8:58 AM, Richard Biener wrote:
>>> We can also merge both loops, counting new_size upwards, storing
>>> to label new_size if new_size != i ...
>>
>> Like this
; regressions. Is this ok for trunk?
This falls under the "obvious" rule. Go ahead.
Peter
Segher, any response to my findings below about whether we should
try and share header files with GLIBC?
Peter
On 6/27/17 1:06 PM, Peter Bergner wrote:
> On 6/27/17 11:07 AM, Segher Boessenkool wrote:
>> Not use an installed header, that's not what I'm asking. Share the
s correct or not, but...
I know the return above this returns 0 as do other locations in
the file, but new code should return NULL_RTX.
Peter
e.c. The change to the rs6000 files are basically just a way to telling
cse.c that the vec_select it's seeing is a involutory byte swap. I did
have to make one change to rs6000_rtx_costs() to modify the cost of the
byte swap, because a byte swap of even a reg was many many time higher
than
if (REG_IN_TABLE (i) != REG_TICK (i))
+ if (REG_IN_TABLE (i) != -1 && REG_IN_TABLE (i) != REG_TICK (i))
return 0;
Peter
On 11/7/17 11:05 AM, Peter Bergner wrote:
> On 11/7/17 7:12 AM, Tulio Magno Quites Machado Filho wrote:
>> That's the same string adopted in glibc. [1]
>> PPC_FEATURE2_HTM_NO_SUSPEND is also user-visible in glibc as a macro and is
>> identical too.
>>
>> Noti
On 10/2/17 12:10 PM, Segher Boessenkool wrote:
> On Mon, Oct 02, 2017 at 12:00:55PM -0500, Peter Bergner wrote:
>> On 9/29/17 5:31 PM, Segher Boessenkool wrote:
>>> Looks great to me, please commit. But hold off until Monday please, it
>>> will interfere with
FP types, so using -msoft-float for 64-bit compiles might have problems.
That said, the following patch does allow Sebastian's build to complete.
This has been bootstrapped and regtested on powerpc64le-linux with no
regressions and Segher has approved it offline. Committed.
Peter
wer9-vector and
-mcpu=power8 together and then force ourselves to use the -mpower9 gas option.
This passed bootstrap and regtesting with no regressions and fixes a little over
150 testsuite failures. Ok for trunk and the appropriate release branches once
it's baked on trunk for a while?
Pete
On 6/5/18 11:23 AM, Segher Boessenkool wrote:
> On Mon, Jun 04, 2018 at 08:57:24PM -0500, Peter Bergner wrote:
>> The fix used here is to catch the special case when we use -mpower9-vector
>> and
>> -mcpu=power8 together and then force ourselves to use the -mpower9 gas
&g
hem also there. PR63177: Do not pass -mpower8
+ to the assembler if -mpower9-vector was also used. */
#define ASM_CPU_SPEC \
...
Peter
ou edit ~/.subversion/config and use the line:
diff-extensions = -u -p
that will do that for you. It's probably already in that config file and
just needs to be uncommented out.
Peter
On 6/6/18 2:54 PM, Segher Boessenkool wrote:
> On Tue, Jun 05, 2018 at 10:03:46PM -0500, Peter Bergner wrote:
>> On 6/5/18 3:22 PM, Segher Boessenkool wrote:
>>> Ah, that's the crux. Thanks. Add a comment to the code please?
>>
>> Like so? I tried placing it
On 6/7/18 10:09 AM, Carl Love wrote:
> * gcc/config/rs6000/vsx.md (vextract_fp_from_shorth
> vextract_fp_from_shortl): Add BE support.
Missing comma at the end of the first line I think.
Peter
address_offset test, which is what allows PRE_INC/PRE_DEC addresses
to be matched.
Is this ok for trunk and the release branches where the earlier fixes
were backported to, assuming no bootstrap errors and the testsuite runs
do not show any regressions?
Peter
gcc/
PR target/85755
On 6/7/18 5:12 PM, Peter Bergner wrote:
> Is this ok for trunk and the release branches where the earlier fixes
> were backported to, assuming no bootstrap errors and the testsuite runs
> do not show any regressions?
Hold off for now. I'm seeing a TImode issue I need to debug first.
Peter
On 6/7/18 8:16 PM, Peter Bergner wrote:
> On 6/7/18 5:12 PM, Peter Bergner wrote:
>> Is this ok for trunk and the release branches where the earlier fixes
>> were backported to, assuming no bootstrap errors and the testsuite runs
>> do not show any regressions?
>
> Hold
On 6/8/18 11:21 AM, Segher Boessenkool wrote:
> On Fri, Jun 08, 2018 at 10:35:22AM -0500, Peter Bergner wrote:
>> +/* { dg-final { scan-assembler-times {\mstdu\M} 2 } } */
>> +/* { dg-final { scan-assembler-not {\mstfdu\M} } } */
>
> Does this need p8 at all? Would it b
On 6/8/18 12:12 PM, Segher Boessenkool wrote:
> On Fri, Jun 08, 2018 at 12:07:34PM -0500, Peter Bergner wrote:
>> On 6/8/18 11:21 AM, Segher Boessenkool wrote:
>>> On Fri, Jun 08, 2018 at 10:35:22AM -0500, Peter Bergner wrote:
>>>> +/* { dg-final { sca
t; /* { dg-options "-maltivec -O2 -mcpu=power8" } */
> /* { dg-skip-if "do not override -mcpu" { powerpc*-*-* } { "-mcpu=*" } {
> "-mcpu=power8" } } */
Similarly, -mcpu=power8 also enables -maltivec so you can remove it.
Peter
once it has has baked
on trunk for a few days and assuming testing comes out clean?
The pr86324-2.c test case is also broken in GCC 7, but it looks like that
has been broken forever, so I'm not sure I'm inclined to want to backport
this that far. Thoughts?
Peter
gcc/
PR ta
On 6/27/18 3:26 PM, Peter Bergner wrote:
> gcc/
> PR target/86324
> * target.def (translate_mode_attribute): New hook.
> * targhooks.h (default_translate_mode_attribute): Declare.
> * targhooks.c (default_translate_mode_attribute): New function.
>
it
> everywhere where modes are created, or only where it is used now (the arg
> to a "mode" attribute)? Probably the latter, but it's not really clear
> from the text.
The latter and good idea. How about this wording instead?
Peter
Index: gcc/target.def
===
s this ok for the open release branches too, once testing has completed there?
Peter
gcc/
PR target/83399
* config/rs6000/rs6000.c (print_operand): Use
VECTOR_MEM_ALTIVEC_OR_VSX_P.
* config/rs6000/vsx.md (*vsx_le_perm_load_): Use
indexed
.
Is this ok for trunk?
Peter
* config/rs6000/x86intrin.h: Change #warning to #error. Update message.
* config/rs6000/emmintrin.h: Likewise.
* config/rs6000/mmintrin.h: Likewise.
* config/rs6000/xmmintrin.h: Likewise.
Index: gcc/config/rs6000/x86int
On 1/10/18 1:44 PM, Segher Boessenkool wrote:
> On Tue, Jan 09, 2018 at 12:22:38PM -0600, Peter Bergner wrote:
>> * config/rs6000/rs6000.c (print_operand): Use
>> VECTOR_MEM_ALTIVEC_OR_VSX_P.
>
> (print_operand) <'y'>: ...
Will fix.
>>
On 1/10/18 2:14 PM, Segher Boessenkool wrote:
> On Tue, Jan 09, 2018 at 04:09:25PM -0600, Peter Bergner wrote:
>> The following patch changes the x86 intrinsic compat headers to use #error
>> instead of #warning. We do this for two reasons. Firstly, we want the user
>> t
amed splitters): Likewise.
gcc/testsuite/
PR target/83399
* gcc.target/powerpc/pr83399.c: New test.
Peter
ames and kernel alternate
names and verifying we call cc1/cc1plus with the either the correct canonical
cpu names or we emit an error message and quit.
This has bootstrapped and regtested with no errors. Ok for mainline?
This patch applies fairly easy to the release branches, do we want this
fix there
ng
at the HWCAP for PPC_FEATURE_HAS_FPU, like I mentioned in the bugzilla entry
above. That's due to just because the cpu supports HW FP, we cannot know
what ABI the distro that is running on the cpu is using. I could very well
be using a soft-float ABI. Thoughts on that?
Ok, I'll move the table to driver-rs6000.c and I'll resubmit.
Peter
On 1/25/18 3:56 PM, Peter Bergner wrote:
> Ok, I'll move the table to driver-rs6000.c and I'll resubmit.
Ok, here is a separate translation table like you wanted. I still use the
RS6000_CPU table to hold entire list of canonical cpu names, the new
translation table in driver-
t;values[i].arg);
}
const char *hint = candidates_list_and_hint (arg, s, candidates);
if (hint)
inform (loc, "valid arguments to %qs are: %s; did you mean %qs?",
option->opt_text, s, hint);
else
inform (loc, "valid arguments to %qs are: %s", option->opt_text, s);
XDELETEVEC (s);
Peter
On 1/29/18 2:33 PM, Peter Bergner wrote:
> The current version of that code looks like the following, which I should
> copy instead. Unless you have a different suggestion?
>
> char *s;
>
> if (e->unknown_error)
> error_at (loc, e->unknow
On 1/29/18 6:30 PM, Segher Boessenkool wrote:
> On Mon, Jan 29, 2018 at 02:54:15PM -0600, Peter Bergner wrote:
> Why don't you want that? It let's the compiler say "hey silly human who
> can hardly type his own name correctly(*), you meant -mcpu-power8 where
> you
e I said in the other reply, I think we do want the code the patch
showed.
Either that, or I could still call candidates_list_and_hint() and just
throw the hint away, since it's meaningless.
Peter
On 1/31/18 11:39 AM, Segher Boessenkool wrote:
> On Mon, Jan 29, 2018 at 08:55:35PM -0600, Peter Bergner wrote:
>>
>> Either that, or I could still call candidates_list_and_hint() and just
>> throw the hint away, since it's meaningless.
>
> It's less code,
On 2/1/18 8:50 AM, Segher Boessenkool wrote:
> I think we also want this for 7 (after a bit of burn in). I wouldn't
> bother with 6 though (the problem has existed since 4.7).
Ok, committed. I'll wait a few days before committing the FSF 7 back port.
Thanks!
Peter
On 2/1/18 1:25 PM, Peter Bergner wrote:
> On 2/1/18 8:50 AM, Segher Boessenkool wrote:
>> I think we also want this for 7 (after a bit of burn in). I wouldn't
>> bother with 6 though (the problem has existed since 4.7).
>
> Ok, committed. I'll wait a few days b
xpand_mult()
which emits code that does the 64-bit multiply.
This passes bootstrap and regtesting on powerpc64le-linux, as well as on
powerpc64-linux (running the testsuite in both 32-bit and 64-bit modes).
Ok for trunk?
Peter
gcc/
PR target/83926
* config/rs6000/rs6000.md (*mul3):
On 2/5/18 7:32 PM, David Edelsohn wrote:
> Peter,
>
> Why can't you place the tests into the final condition of the pattern
> so that the pattern fails and the normal GCC fallback machinery is
> used instead of manually implementing the fallback emulation?
You mean somethin
On 2/5/18 10:48 PM, David Edelsohn wrote:
> On Mon, Feb 5, 2018 at 9:43 PM, Peter Bergner wrote:
>> I did also try calling expand_divmod() here which did generate correct
>> code, the problem was that it wasn't as clean/optimized as the change
>> to gen_divdi3.
>
&g
On 2/6/18 6:42 AM, Peter Bergner wrote:
> On 2/5/18 10:48 PM, David Edelsohn wrote:
>> On Mon, Feb 5, 2018 at 9:43 PM, Peter Bergner wrote:
>>> I did also try calling expand_divmod() here which did generate correct
>>> code, the problem was that it wasn't as clea
_* routines, then they'll work with no changes. Otherwise,
the new code would have to do something similar to this latest patch.
Kind of a "six of one, half dozen of the other" sort of thing.
I'm fine either way.
Peter
but check please.
The change from GPR to SDI iterator and my change to explicitly call
the __divdi3() lib function for DImode divides ends up generating the
exact same code generated for the following test case that we get with
the non patched compiler:
long long
foo (long long a, long long b)
{
return a / b;
}
Peter
On 2/6/18 10:36 AM, Peter Bergner wrote:
> On 2/6/18 10:20 AM, David Edelsohn wrote:
>> Do the gen_XXXdi3 calls work if you use SDI iterator instead of GPR
>> iterator, as Segher suggested?
>
> Well it works _if_ we use the first patch that changes the gen_*
> patterns.
On 2/8/18 10:38 AM, Peter Bergner wrote:
> * gcc.target/powerpc/builtins-1-be.c: Filter out gimple folding disabled
> message. Fix test for running in 32-bit mode.
As we talked about offline, here's a bigger change to builtins-1-be.c that
cleans up the test a little mor
I have committed the following obvious testsuite patch to fix PR81143.
The "bug" is that __ORDER_LITTLE_ENDIAN__ is always defined for both
little and big endian compiles. I checked and this is the only use
of this in the gcc.target/powerpc/ directory.
Peter
PR ta
On 2/9/18 10:17 AM, Segher Boessenkool wrote:
> On Thu, Feb 08, 2018 at 10:38:09AM -0600, Peter Bergner wrote:
>> -/* { dg-final { scan-assembler-times "divd" 4 } } */
>
>> +/* { dg-final { scan-assembler-times {\mdivd\M} 2 { target lp64 } } } */
>
>> +/* {
d. I'll fix that, thanks.
Peter
he "bug" is that the "Y" constraint
code, which is implemented by mem_operand_gpr() allows our altivec address
when it should not. The following patch which fixes the ICE adds code to
mem_operand_gpr() which disallows such addresses.
This patch passed bootstrap and retesting on pow
The following patch was approved offline by Segher to fix PR84365.
The problem is when compiling with -mcpu=power9, we don't generate
the LE unfriendly lxvd2x and instead emit an LE friendly lxv insn.
Peter
PR target/84365
* gcc.target/powerpc/altivec-7-le.c: Also match lxv
This patch removes an undocumented option that has since been deprecated and
removed and was causing this test case to FAIL. The obvious patch below was
approved by Segher offline. Committed.
Peter
PR target/84370
* gcc.target/powerpc/builtins-3-p9-runnable.c: Remove deprecated
9.C (working copy)
>> @@ -0,0 +1,35 @@
>> +/* { dg-do compile { target { powerpc*-*-* && lp64 } } } */
>
> I don't think this needs lp64?
Yeah, I think you're right. I'll remove it. Thanks.
Peter
Same problem as PR84365 and same fix. Committed as obvious.
Peter
PR target/84372
* gcc.target/powerpc/lvsl-lvsr.c: Also match lxv when compiling
with -mcpu=power9.
Index: gcc/testsuite/gcc.target/powerpc/lvsl-lvsr.c
On 2/13/18 5:51 PM, Segher Boessenkool wrote:
> On Tue, Feb 13, 2018 at 05:07:26PM -0600, Peter Bergner wrote:
>> It's up to you whether you want the backport because you don't trust
>> me being able to create a failing test case. :-)
>
> We can backport without ha
On 2/13/18 5:51 PM, Segher Boessenkool wrote:
> We can backport without having a failing testcase. Let's do that for 7
> at least?
Ok, the backport tested clean, so I committed it. Thanks.
Peter
mode).
It however does not support vector __int128_t which is what we're testing
here.
Peter
This had already been fixed on trunk and just needed back porting to the
release branches. Committed as obvious.
Peter
PR target/84390
* gcc.target/powerpc/vsxcopy.c: Also match lxv when compiling
with -mcpu=power9.
Index: gcc/testsuite/gcc.target/powerpc/vsxcopy.c
t;-mpower9-vector -mcpu=power9 -O2" } */
As we discussed offline, I don't know why we need -mpower[89]-vector
in dg-options if we're already specifying -mcpu=power[89].
Those are both implied by the -mcpu=power[89] options.
Peter
On 2/15/18 3:56 PM, Will Schmidt wrote:
> -/* { dg-options "-mcpu=power8" } */
> +/* { dg-options "-maltivec -mcpu=power8" } */
Why did you add -maltivec? That flag is enabled implicitly by -mcpu=power8
which we're already using?
Peter
x27;s generated because of the __builtin_vec_or and the
reg copies.
Ok for trunk?
Peter
gcc/testsuite/
PR target/84534
* gcc.target/powerpc/vec-setup-be-long.c: xfail.
* gcc.target/powerpc/vsx-vector-6-le.c: Do not count xxlor's.
* gcc.target/powerpc/vsx-vector
On 1/10/18 3:10 PM, Peter Bergner wrote:
> gcc/
> PR target/83399
> * config/rs6000/rs6000.c (print_operand) <'y'>: Use
> VECTOR_MEM_ALTIVEC_OR_VSX_P.
> * config/rs6000/vsx.md (*vsx_le_perm_load_ for VSX_D): Use
> ind
* gcc.target/powerpc/vsx-vector-6-le.p9.c: Likewise.
>
> Please add a comment to the testcase why there is no count here.
Will do.
Peter
On 2/28/18 5:01 PM, Segher Boessenkool wrote:
> On Wed, Feb 28, 2018 at 04:51:27PM -0600, Peter Bergner wrote:
>> Doh! I was going to say "why?" since we're xfailing it everywhere, but I
>
> Because you can use a few more words in changelog entries ;-)
>
&
201 - 300 of 1911 matches
Mail list logo
