I'm leaving IBM and am changing my email to my my personal address.
ChangeLog:
2019-11-15 Kelvin Nilsen
* MAINTAINERS: Change my email address as maintainer.
Index: MAINTAINERS
===
--- MAINTAINERS (revision 278306
On 10/25/19 8:30 PM, Kelvin Nilsen wrote:
>
> This patch adds a new optimization pass for rs6000 targets.
>
> This new pass scans existing rtl expressions and replaces X-form loads and
> stores with rtl expressions that favor selection of the D-form instructions
> in
and tested without regressions on
powerpc64le-unknown-linux.
Is this ok for trunk?
gcc/ChangeLog:
2019-11-06 Kelvin Nilsen
* config/rs6000/vsx.md (xxswapd_): Add support for V2DF and
V2DI modes.
Index: gcc/config/rs6000/vsx.md
Kelvin Nilsen
* config/rs6000/rs6000-p9dform.c: New file.
* config/rs6000/rs6000-passes.def: Add pass_insert_dform.
* config/rs6000/rs6000-protos.h
(rs6000_target_supports_dform_offset_p): New function prototype.
(make_pass_insert_dform): Likewise
On 10/17/19 5:57 PM, Segher Boessenkool wrote:
> Hi Kelvin,
>
> On Wed, Oct 09, 2019 at 03:28:45PM -0500, Kelvin Nilsen wrote:
>> This new pass scans existing rtl expressions and replaces them with rtl
>> expressions that favor selection of the D-form instructions in c
tested this patch on powerpc64le-unknown-linux
target with no regressions.
Is this ok for trunk?
gcc/ChangeLog:
2019-10-09 Kelvin Nilsen
* config/rs6000/rs6000-p9dform.c: New file.
* config/rs6000/rs6000-passes.def: Add pass_insert_dform.
* config/rs6000/rs6000-protos.h
and cooling costs for heavy server workloads would benefit.
I have built and regression tested this patch on powerpc64le-unknown-linux
target with no regressions.
Is this ok for trunk?
gcc/ChangeLog:
2019-09-03 Kelvin Nilsen
* config/rs6000/rs6000-p9dform.c: New file.
* config
Kelvin Nilsen
PR target/89765
* config/rs6000/rs6000-c.c (altivec_resolve_overloaded_builtin):
In handling of ALTIVEC_BUILTIN_VEC_INSERT, use modular arithmetic
to compute vector element selector for both constant and variable
operands.
* config/rs6000
?
Thanks.
gcc/ChangeLog:
2019-04-25 Kelvin Nilsen
PR target/89424
* config/rs6000/rs6000.c (rs6000_expand_vector_extract): Add
handling of V1TImode.
gcc/testsuite/ChangeLog:
2019-04-25 Kelvin Nilsen
PR target/89424
* gcc.target/powerpc/pr89424-0.c
/ChangeLog:
2019-04-25 Kelvin Nilsen
PR target/89424
* config/rs6000/rs6000.c (rs6000_expand_vector_extract): Add
handling of V1TImode.
gcc/testsuite/ChangeLog:
2019-04-25 Kelvin Nilsen
PR target/89424
* gcc.target/powerpc/pr89424-0.c: New test
) and on powerpc-linux (P7 and P8, both
-m32 and -m64).
Is this ok for trunk and backports?
Thanks.
gcc/ChangeLog:
2019-04-09 Kelvin Nilsen
PR target/87532
* config/rs6000/rs6000.c (rs6000_split_vec_extract_var): Use inner
mode of vector rather than mode of destination
with trunk.
gcc/testsuite/ChangeLog:
2019-03-19 Kelvin Nilsen
PR target/89736
* gcc.target/powerpc/pr87532-mc.c: Modify dejagnu directives to
restrict this test to vsx targets.
Index: gcc/testsuite/gcc.target/powerpc/pr87532-mc.c
itted and those tests have been
updated.
This has bootstrapped and tested without regressions on
powerpc64le-unknown-linux (both P8 and P9) and on powerpc-linux (P7 big-endian,
with both -m32 and -m64 target options).
Is this ok for trunk?
gcc/ChangeLog:
2019-03-13 Kelvin Nilsen
PR tar
on
powerpc64le-unknown-linux (both P8 and P9) and on powerpc-linux (P7 big-endian,
with both -m32 and -m64 target options).
Is this ok for trunk?
gcc/ChangeLog:
2019-03-08 Kelvin Nilsen
PR target/87532
* config/rs6000/rs6000-c.c (altivec_resolve_overloaded_builtin):
When handling
tested this on powerpc64-linux (P7 big-endian, both -m32 and
-m64), both 32-bit and 64-bit. Is this ok for trunk and for various backports
to which the original patch is to be directed?
gcc/testsuite/ChangeLog:
2019-02-01 Kelvin Nilsen
* gcc.target/powerpc/vec-extract-slong-1.c
lt of vec_extract so that it matches the type of
the array element supplied as its first argument.
I have built and regression tested this patch on powerpc64le-unknown-linux with
no regressions. Is this ok for trunk?
gcc/ChangeLog:
2019-01-28 Kelvin Nilsen
* config/rs6000
(Power9) target with no regressions.
Is this ok for trunk?
gcc/ChangeLog:
2018-12-13 Kelvin Nilsen
* config/rs6000/rs6000-p9dform.c: New file.
* config/rs6000/rs6000-passes.def: Add pass_insert_dform after
pass_loop2.
* config/rs6000/rs6000-protos.h
invite comments and suggestions regarding this draft patch at this time.
gcc/ChangeLog:
2018-11-10 Kelvin Nilsen
* config.gcc: Add entry to compile new object rs6000-p9indexing.o.
* config/rs6000/rs6000-passes.def: Add pass_fix_indexing after
pass_loop2.
* config
My "consistency" check was against the implementation.
On 8/2/18 11:38 AM, Segher Boessenkool wrote:
> Hi Kelvin,
>
> On Wed, Aug 01, 2018 at 02:55:22PM -0500, Kelvin Nilsen wrote:
>> Several errors were discovered in the descriptions of the __builtin_bcdadd
.
This patch corrects these documentation errors.
I have built the gcc.pdf file and reviewed the formatting, and all looks good.
Is this ok for trunk?
gcc/ChangeLog:
2018-08-01 Kelvin Nilsen
* doc/extend.texi (PowerPC AltiVec Built-in Functions Available on
ISA 2.07): Correct spelling
gt; On Thu, Jul 26, 2018 at 08:40:01AM -0500, Kelvin Nilsen wrote:
>> To improve internal consistency and to improve consistency with published
>> ABI documents, this patch replaces the __uint128_t type with __uint128 and
>> replaces __int128_t with __int128.
>
>> Is this
built and reviewed the gcc.pdf file.
Is this ok for trunk?
gcc/ChangeLog:
2018-07-25 Kelvin Nilsen
* doc/extend.texi (Basic PowerPC Built-in Functions Available on
ISA 2.05): Replace __uint128_t with __uint128 and __int128_t with
__int128 in built-in function
.
Is this ok for trunk?
gcc/ChangeLog:
2018-07-17 Kelvin Nilsen
* doc/extend.texi (PowerPC AltiVec/VSX Built-in Functions):
Corrected spelling of this subsection. Moved some material to new
subsubsections "PowerPC AltiVec Built-in Functions on ISA 2.06" and
e a compiler optimization flag that allows the optimizer to ignore array
index integer overflow in considering legal optimizations?
On 7/13/18 9:14 PM, Bin.Cheng wrote:
> On Fri, Jul 13, 2018 at 6:04 AM, Kelvin Nilsen wrote:
>> A somewhat old "issue report" pointed me to the code gen
A somewhat old "issue report" pointed me to the code generated for a 4-fold
manually unrolled version of the following loop:
> while (++len != len_limit) /* this is loop */
> if (pb[len] != cur[len])
>
. */
< /* vec_unsignede requires -mcpu=power8. */
< /* vec_unsignede requires -mvsx. */
< /* vec_unsignedo requires -mvsx. */
< /* vec_unsigned requires -mvsx. */
Is this patch ok for trunk?
gcc/ChangeLog:
2018-07-10 Kelvin Nilsen
* doc/extend.texi (PowerPC AltiVec Built-
Hi Jeff,
Is it ok to backport this patch to gcc 8? There are other backports of test
programs that would like to use the new selector options.
Thanks.
On 5/23/18 12:31 PM, Segher Boessenkool wrote:
> On Tue, May 22, 2018 at 03:21:30PM -0600, Jeff Law wrote:
>> On 05/21/2018 03:46 PM, Segher
Hi Segher,
This patch, as revised in response to your suggestions, was committed to trunk
on 4/17/2018.
Is this ok for backporting to gcc8, gcc7, and gcc6?
Thanks.
On 4/13/18 3:15 PM, Kelvin Nilsen wrote:
> Twelve failures have been occuring in the bfp test directory during -
regression testing, I have committed this
patch as obvious.
gcc/testsuite/ChangeLog:
2018-06-26 Kelvin Nilsen
* gcc.target/powerpc/builtins-1.c: Correct a comment.
Index: gcc/testsuite/gcc.target/powerpc/builtins-1.c
===
--- gcc
Hi Segher,
After waiting a few days for this newly committed patch to settle, is it ok to
backport to gcc 6, gcc 7, and gcc 8?
Thanks.
On 6/22/18 5:34 PM, Kelvin Nilsen wrote:
> Thanks for feedback. It turns out that the vmrgew and vmrgow instructions
> require power 8.
>
e, Jun 19, 2018 at 01:37:51PM -0500, Kelvin Nilsen wrote:
>> --- gcc/testsuite/gcc.target/powerpc/builtins-9.c(nonexistent)
>> +++ gcc/testsuite/gcc.target/powerpc/builtins-9.c(working copy)
>> @@ -0,0 +1,21 @@
>> +/* { dg-do compile } */
>> +/* { dg-requi
This has been committed to trunk.
Is this ok to backport to gcc6, gcc7, and gcc8?
Thanks.
On 6/19/18 2:30 PM, Segher Boessenkool wrote:
> Hi!
>
> On Mon, Jun 18, 2018 at 11:29:55AM -0500, Kelvin Nilsen wrote:
>> +/* A single vpkudus matches twice because this is co
directives.
This patch has bootstrapped and tested without regressions on
powerpc64le-unknown-linux (both P8 and P9) and on powerpc-linux (P8 big-endian,
both -m32 and -m64).
Is this ok for the trunk?
gcc/ChangeLog:
2018-06-19 Kelvin Nilsen
* config/rs6000/rs6000-c.c
,
both -m32 and -m64).
Is this ok for the trunk?
gcc/ChangeLog:
2018-06-18 Kelvin Nilsen
* config/rs6000/rs6000-c.c (altivec_overloaded_builtins): Change
behavior of vec_packsu (vector unsigned long long, vector unsigned
long long) to match behavior of vec_packs
for the trunk?
gcc/ChangeLog:
2018-06-14 Kelvin Nilsen
* config/rs6000/rs6000-c.c (altivec_overloaded_builtins): Change
behavior of vec_pack (double, double) to match behavior of
vec_float2 (double, double).
gcc/testsuite/ChangeLog:
2018-06-14 Kelvin Nilsen
x (P8). I have also built the gcc.pdf file and
reviewed its contents.
Segher: if you prefer, I can break this into multiple smaller patches. What
would be the ideal size of each patch?
Is this ok for trunk?
gcc/ChangeLog:
2018-06-04 Kelvin Nilsen
* doc/extend.texi (PowerPC Alt
-unknown-linux (P8). I have built the gcc.pdf file and reviewed its
contents.
Is this ok for trunk?
gcc/ChangeLog:
2018-06-04 Kelvin Nilsen
* doc/extend.texi (PowerPC AltiVec Built-in Functions): Remove
volatile qualifier from vec_lvsl and vec_lvsr argument prototypes.
Index: gcc
bootstrapped and tested without regressions on
powerpc64le-unknown-linux (P8).
Is this ok for trunk?
gcc/ChangeLog:
2018-06-01 Kelvin Nilsen
* config/rs6000/rs6000-builtin.def (VSX_BUILTIN_VEC_LD,
VSX_BUILTIN_VEC_ST): Add comment to explain non-traditional uses
on both powerpc64le-unknown-linux (P8) and on
powerpc-linux (P7 big-endian, with both -m32 and -m64 target options).
The patch affects only extend.texi. The gcc.pdf file has been built
and reviewed.
Is this ok for the trunk?
gcc/ChangeLog:
2018-05-23 Kelvin Nilsen <kel...@gcc.gnu.org>
Kelvin Nilsen <kel...@gcc.gnu.org>
* doc/extend.texi (Basic PowerPC Built-in Functions): Rename this
subsection to be "PowerPC Built-in Functions".
(PowerPC Altivec/VSX Built-in Functions): Change this
subsection to subsubsection and rename as
orm because it is missing relevant fonts.
Is this ok for the trunk?
2018-05-09 Kelvin Nilsen <kel...@gcc.gnu.org>
* doc/extend.texi (PowerPC Built-in Functions): Rename this
subsection.
(Basic PowerPC Built-in Functions): The new name of the
subsection previ
!
>
> On Tue, Apr 24, 2018 at 02:25:58PM -0500, Kelvin Nilsen wrote:
>>> 4. Remove descriptions of built-in function that do not belong in this
>>> section because the
>>>built-in functions are generic (not specific to PowerPC):
>>> __bu
as submitted previously.
On 4/24/18 9:12 AM, Kelvin Nilsen wrote:
> This is the first of several patches to address shortcomings in existing
> documentation of
> PowerPC built-in functions. The focus of this particular patch is to
> improve documentation
> of low-level built-in fu
unction descriptions into these sections.
This patch affects only extend.texi. The gcc.pdf file has been built
and reviewed.
Is this ok for the trunk?
gcc/ChangeLog:
2018-04-24 Kelvin Nilsen <kel...@gcc.gnu.org>
* doc/extend.texi: Tidy documentation of PowerPC built-in functions.
/ChangeLog:
2018-04-13 Kelvin Nilsen <kel...@gcc.gnu.org>
* config/rs6000/rs6000-protos.h (rs6000_builtin_is_supported_p):
New prototype.
* config/rs6000/rs6000-c.c (altivec_resolve_overloaded_builtin):
Add note to error message to explain internal mapping of overloaded
b
This new test case required a dejagnu qualifier to restrict its
execution on big-endian platforms.
The patch bootstrapped and tested without regressions. Was committed as
obvious.
gcc/testsuite/ChangeLog:
2018-04-12 Kelvin Nilsen <kel...@gcc.gnu.org>
PR target/85347
* gcc.
st program.
This patch has bootstrapped and tested without regressions on both
powerpc64le-unknown-linux (P8) and on powerpc-linux (P7 big-endian, with
both -m32 and -m64 target options).
Is this ok for trunk?
gcc/ChangeLog:
2018-04-03 Kelvin Nilsen <kel...@gcc.gnu.org>
* config/r
for trunk?
gcc/ChangeLog:
2018-03-29 Kelvin Nilsen <kel...@gcc.gnu.org>
* config/rs6000/rs6000-c.c (altivec_overloaded_builtins): Remove
erroneous entries for
"vector int vec_ldl (int, long int *)", and
"vector unsigned int vec_ldl (int, unsigned
/ChangeLog:
2018-03-14 Kelvin Nilsen <kel...@gcc.gnu.org>
* config/rs6000/rs6000-c.c (altivec_overloaded_builtins): Add
entries for V1TI variants of __builtin_altivec_ld builtin.
* config/rs6000/rs6000.c (altivec_expand_lv_builtin): Add test and
handling of V1TI v
, with
both -m32 and -m64 target options).
Is this patch ok for trunk?
gcc/ChangeLog:
2018-03-14 Kelvin Nilsen <kel...@gcc.gnu.org>
* config/rs6000/rs6000-builtin.def: Remove various BU_ALTIVEC_X
macro expansions for definition of ST_INTERNAL_ and
LD_INTERNAL_ bu
) and on powerpc-linux (P7 big-endian, with
both -m32 and -m64 target options).
Is this patch ok for trunk?
gcc/ChangeLog:
2018-03-09 Kelvin Nilsen <kel...@gcc.gnu.org>
* config/rs6000/rs6000-builtin.def: Remove various BU_ALTIVEC_X
macro expansions for definition of ST_INT
Is this revision to the existing draft GCC 8 release notes ok for
commit?
Thanks
? cvs.diffs
Index: htdocs/gcc-8/changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-8/changes.html,v
retrieving revision 1.36
diff -u -3 -p
on
powerpc64le-unknown-linux. Is this ok for trunk?
gcc/ChangeLog:
2018-02-13 Kelvin Nilsen <kel...@gcc.gnu.org>
* config/rs6000/rs6000.c (rs6000_option_override_internal): Issue
warning message if user requests -maltivec=be.
gcc/testsuite/ChangeLog:
2018-02-13 Kelvin
and regression testing, with preapproval,
this patch has been committed to the trunk.
It it ok to backport to GCC 7 and GCC 6 (after testing on those
platforms)?
Thanks.
gcc/ChangeLog:
2018-01-29 Richard Biener <rguent...@suse.de>
Kelvin Nilsen <kel...@gcc.gnu.org>
) with
both -m32 and -m64 target options. Is this ok for trunk?
gcc/ChangeLog:
2018-01-16 Kelvin Nilsen <kel...@gcc.gnu.org>
* config/rs6000/rs6000-p8swap.c (rs6000_gen_stvx): Generate
different rtl trees depending on TARGET_64BIT.
(rs6000_gen_lvx): Likewise.
runk4test99327/gcc/dse.c:3569^M
> ;; 0x112e525b execute^M
> ;; /home/kelvin/gcc/gcc-trunk4test99327/gcc/dse.c:3627^M
> ;; Please submit a full bug report,^M
Is this patch ok for trunk?
gcc/ChangeLog:
2018-01-10 Kelvin Nilsen <kel...@gcc.gnu.org>
* config/rs60
I would like to backport the following patch to the GCC 7 branch.
PR80101: Fix ICE in store_data_bypass_p
https://gcc.gnu.org/ml/gcc-patches/2017-04/msg00953.html
This patch has been bootstrapped and regression tested on the
GCC 7 branch.
Is this ok for backporting to GCC 7?
-09-29 Kelvin Nilsen <kel...@gcc.gnu.org>
* gcc.target/powerpc/swaps-p8-30.c: Exchange the order of dg-do
and dg-require-effective-target directives to correct testing
behavior.
* gcc.target/powerpc/swaps-p8-32.c: Likewise.
* gcc.target/powerpc/swaps-p
).
Is this ok for trunk?
gcc/ChangeLog:
2017-09-25 Kelvin Nilsen <kel...@gcc.gnu.org>
* config/rs6000/rs6000-p8swap.c (const_load_sequence_p): Revise
this function to return false if the definition used by the swap
instruction is artificial, or if the memory address from
Kelvin Nilsen <kel...@gcc.gnu.org>
* config/rs6000/rs6000-p8swap.c (const_load_sequence_p): Revise
this function to return false if the definition used by the swap
instruction is artificial, or if the memory address from which the
constant value is
I would like to backport the following patches to the GCC 6 branch.
PR9: Fix failure of gcc.dg/loop-8.c on Power
https://gcc.gnu.org/ml/gcc-patches/2017-01/msg01788.html
PR68972: g++.dg/cpp1y/vla-initlist1.C test case fails on power
-30 Kelvin Nilsen <kel...@gcc.gnu.org>
PR target/80103
* gcc.target/powerpc/pr80103-1.c (b): Correct spelling of
__attribute__.
Index: gcc/testsuite/gcc.target/powerpc/pr80103-1.c
===
--- gcc/tes
04:14 PM, Segher Boessenkool wrote:
> On Fri, Mar 24, 2017 at 04:04:33PM -0600, Kelvin Nilsen wrote:
>> PR 80103 provides a test case which results in an internal
>> compiler error when invoked with -mno-direct-move -mpower9-dform-
>> vector target options. The internal c
I have bootstrapped and tested this patch on
powerpc64le-unkonwn-linux-gnu with no regressions. Is this ok for
backporting to gcc 6?
On 03/22/2017 10:17 PM, Segher Boessenkool wrote:
> On Wed, Mar 22, 2017 at 05:55:53PM -0600, Kelvin Nilsen wrote:
>>> Or it could do -mpower9-
Is this ok for backport to GCC 6?
On 02/06/2017 03:20 PM, Kelvin Nilsen wrote:
>
> The test g++.dg/cpp1y/vla-initlist1.C makes assumptions that the memory
> used to represent the private temporary variables of neighboring control
> blocks at the same control nesting level is:
&
Is it ok to backport this patch to GCC-6?
On 01/23/2017 09:59 AM, Kelvin Nilsen wrote:
>
> The test gcc.dg/loop-8.c makes assumptions that are not valid on Power
> architecture (and on certain other architectures for which this issue
> has already been addressed). The test
Kelvin Nilsen <kel...@gcc.gnu.org>
* config/rs6000/rs6000-c.c (altivec_overloaded_builtins): Add
array entries to represent __ieee128 versions of the
scalar_test_data_class, scalar_test_neg, scalar_extract_exp,
scalar_extract_sig, and scalar_insert_exp
due to
alignment of tabs in the diff output.
The patch has been bootstrapped and tested on powerpc64le-unknown-linux
and powerpc-unknown-linux (big-endian, with both -m32 and -m64 target
options) with no regressions.
Is this ok for the trunk?
gcc/testsuite/ChangeLog:
2017-05-08 Kelvin Nilsen
.
Is this ok for the trunk?
gcc/ChangeLog:
2017-04-28 Kelvin Nilsen <kel...@gcc.gnu.org>
* config/rs6000/rs6000.c (rs6000_builtin_mask_calculate): Add
support for TARGET_CMPB.
* config/rs6000/rs6000.h: Add support for RS6000_BTM_CMPB.
* config/rs6000/
without regressions on
powerpc64le-unknown-linux-gnu. Is this ok for the trunk?
gcc/testsuite/ChangeLog:
2017-04-20 Kelvin Nilsen <kel...@gcc.gnu.org>
PR target/80101
* gcc.target/powerpc/pr80101-1.c: New test.
gcc/ChangeLog:
2017-04-20 Kelvin Nilsen <kel...@gc
changes to
the function do as well.
The patch has been boostrapped without regressions on
powerpc64le-unknown-linux-gnu. Is this ok for the trunk?
gcc/testsuite/ChangeLog:
2017-04-14 Kelvin Nilsen <kel...@gcc.gnu.org>
* gcc.target/powerpc/pr80101-1.c: New test.
gcc/ChangeLog:
2017
confirmed that these test programs reproduce the
error reported with PR80315 before yesterday's patch was applied, and
that all test programs pass following application of yesterday's patch.
Is this ok for the trunk?
gcc/testsuite/ChangeLog:
2017-04-12 Kelvin Nilsen <kel...@gcc.gnu.
that by the time the hardware executes the consumer, the stored
value is no longer in the write buffer, so even though we might have
"thought" two PARALLEL rtl expressions qualified for the store bypass
optimization, we really should have returned false.
Can someone help me understand this better?
Thanks much.
--
Kelvin Nilsen, Ph.D. kdnil...@linux.vnet.ibm.com
home office: 801-756-4821, cell: 520-991-6727
IBM Linux Technology Center - PPC Toolchain
boostrapped without regressions on
powerpc64le-unknown-linux-gnu. Is this ok for the trunk?
gcc/ChangeLog:
2017-03-29 Kelvin Nilsen <kel...@gcc.gnu.org>
PR target/80101
* recog.c (store_data_bypass_p): Rather than terminate with
assertion error, return false if
. Is
this ok for the trunk?
gcc/ChangeLog:
2017-04-06 Kelvin Nilsen <kel...@gcc.gnu.org>
PR target/80108
* config/rs6000/rs6000.c (rs6000_option_override_internal):
Enhance special handling given to the TARGET_P9_MINMAX option in
relation to certain other options
contexts.
This patch has been bootstrapped and tested with no regressions on both
powerpc64-unknown-linux-gnu and powerpc64le-unknown-linux-gnu. Is
this ok for the trunk?
gcc/ChangeLog:
2017-04-06 Kelvin Nilsen <kel...@gcc.gnu.org>
PR target/80108
* config/rs6000/rs
-options directive to exercise the problematic
command-line options.
This patch has been bootstrapped and tested with no regressions on both
powerpc64-unknown-linux-gnu and powerpc64le-unknown-linux-gnu. Is
this ok for the trunk?
gcc/ChangeLog:
2017-03-31 Kelvin Nilsen <kel...@gcc.gnu.
with an assertion error. False indicates that
the passed arguments are not eligible for the store bypass scheduling
optimization.
The patch has been boostrapped without regressions on
powerpc64le-unknown-linux-gnu. Is this ok for the trunk?
gcc/ChangeLog:
2017-03-29 Kelvin Nilsen <
=power9 target options.
This patch has been bootstrapped and tested with no regressions on
both powerpc64-unknown-linux-gnu and powerpc64le-unknown-linux-gnu.
Is this ok for the trunk?
gcc/testsuite/ChangeLog:
2017-03-24 Kelvin Nilsen <kel...@gcc.gnu.org>
PR target
On 03/22/2017 05:35 PM, Segher Boessenkool wrote:
> On Wed, Mar 22, 2017 at 11:44:49AM -0600, Kelvin Nilsen wrote:
>> Internal testing recently revealed that use of the -mno-power9-vector
>> target option in combination with the -mcpu=power9 target option
>> results
to
demonstrate the fix.
The patch has been bootstrapped and tested with no regressions on both
powerpc64-unknown-linux-gnu and powerpc64le-unknown-linux-gnu. Is this
ok for the trunk?
gcc/testsuite/ChangeLog:
2017-03-21 Kelvin Nilsen <kel...@gcc.gnu.org>
* gcc.target/powerpc/p9-options-1.
Kelvin Nilsen <kel...@gcc.gnu.org>
* config/rs6000/rs6000-c.c (rs6000_target_modify_macros): Add
comments.
* config/rs6000/rs6000.c (rs6000_option_override_internal): Add
comments.
Index: gcc/config/rs6000/rs60
patch, it was discovered that changes to the C++
templates representing the vec_all_ne and vec_any_eq built-in functions
were incomplete.
This patch has bootstrapped and been tested on
powerpc64le-unknown-linux with no regressions.
Is this ok for trunk?
gcc/ChangeLog:
2017-03-14 Kelvin Nilsen
in the PR 79395 report.
This patch has been bootstrapped and tested on
powerpc64le-unknown-linux with no regressions.
Is this ok for trunk?
gcc/ChangeLog:
2017-02-28 Kelvin Nilsen <kel...@gcc.gnu.org>
PR target/79395
* config/rs6000/altivec.h (vec_ctz and others):
This patch amends a patch merged with the trunk on 2017-01-14. One of
the new test cases added at that time has proven to be unreliable so
this path removes it.
Is this patch ok for trunk?
gcc/testsuite/ChangeLog:
2017-02-17 Kelvin Nilsen <kel...@gcc.gnu.org>
PR target
this particular test case on power hardware.
The patch has been bootstrapped and tested on
powerpc64le-unknown-linux with no regressions.
Is this ok for trunk?
gcc/testsuite/ChangeLog:
2017-02-07 Kelvin Nilsen <kel...@gcc.gnu.org>
PR target/68972
* g++.dg/cpp1y/vla-ini
Kelvin Nilsen <kel...@gcc.gnu.org>
PR target/68972
* g++.dg/cpp1y/vla-initlist1.C: Add dg-skip-if directive to
disable this test on power architecture.
Index: gcc/testsuite/g++.dg/cpp1y/vla-initl
-propagated within the loop, and the subsequent
loop-invariant code motion moves two loop-invariant statements out of
the loop.
This patch simply disables this test case on Power architecture.
gcc/testsuite/ChangeLog:
2017-01-23 Kelvin Nilsen <kel...@gcc.gnu.org>
PR target
tested on
powerpcle-unknown-linux (little-endian) and on
powerpc-unknown-linux (big-endian, with both -m32 and -m64 target
option) with no regressions. Is this ok for the trunk?
gcc/testsuite/ChangeLog:
2017-01-19 Kelvin Nilsen <kel...@gcc.gnu.org>
* gcc.target/powerpc/bfp/scala
e-unknown-linux and powerpc-unknown-linux (big-endian, with
both -m32 and -m64 target options) with no regressions.
Is this patch ok for trunk?
gcc/testsuite/ChangeLog:
2016-12-16 Kelvin Nilsen <kel...@gcc.gnu.org>
PR target/78056
* gcc.target/powerpc/pr78056-1.c: New test.
. They are checking that the compiler rejects those
programs with appropriate error messages.
On 12/13/2016 03:14 PM, Segher Boessenkool wrote:
> Hi Kelvin,
>
> On Mon, Dec 12, 2016 at 05:40:05PM -0700, Kelvin Nilsen wrote:
>> The patch has been bootstrapped and tested on
>> powe
target options) with no regressions.
Is this ok for the trunk?
gcc/testsuite/ChangeLog:
2016-12-12 Kelvin Nilsen <kel...@gcc.gnu.org>
* gcc.target/powerpc/byte-in-either-range-0.c: New test.
* gcc.target/powerpc/byte-in-either-range-1.c: New test.
* gcc.target/powerp
and tested without regressions on
powerpc64le-unknown-linux and powerpc-unknown-linux (big-endian, with
both -m32 and -m64 target options) with no regressions.
Is this patch ok for trunk?
gcc/ChangeLog:
2016-12-08 Kelvin Nilsen <kel...@gcc.gnu.org>
PR target/78056
*
for the trunk?
gcc/testsuite/ChangeLog:
2016-12-05 Kelvin Nilsen <kel...@gcc.gnu.org>
* gcc.target/powerpc/byte-in-either-range-0.c: New test.
* gcc.target/powerpc/byte-in-either-range-1.c: New test.
* gcc.target/powerpc/byte-in-range-0.c: New test.
* gcc.
of generated code, since the existing implementation
implicitly coerces the operand types to the declared type.
The patch has been bootstrapped and tested on powerpc64le-unknown-linux
without regressions.
Is this ok for the trunk?
gcc/ChangeLog:
2016-11-30 Kelvin Nilsen <kel...@gcc.gnu.
in define_expands?
>
The pattern I'm familiar with is to allocate the temporary scratch
register during expansion, and to use the allocated temporary at insn
match time. I'll have to teach myself a new pattern to do all of this
at insn match time. Feel free to point me to an example of define
Thank you very much for the prompt and thorough review. There are a few
points below where I'd like to seek further clarification.
On 11/15/2016 04:19 AM, Segher Boessenkool wrote:
> Hi!
>
> On Mon, Nov 14, 2016 at 04:43:35PM -0700, Kelvin Nilsen wrote:
>> * config/rs
?
gcc/testsuite/ChangeLog:
2016-11-14 Kelvin Nilsen <kel...@gcc.gnu.org>
* gcc.target/powerpc/byte-in-either-range-0.c: New test.
* gcc.target/powerpc/byte-in-either-range-1.c: New test.
* gcc.target/powerpc/byte-in-range-0.c: New test.
* gcc.target/powerp
integration since
the error has broken the trunk for certain system configurations.
Is this patch ok for trunk?
gcc/ChangeLog:
2016-10-25 Kelvin Nilsen <kel...@gcc.gnu.org>
PR target/78056
* config/rs6000/rs6000.c (spe_init_builtins): Modify loops to not
define b
This trivial/obvious patch was committed without review as svn revision
240783. The patch fixes a compile-time error that recently surfaced
with big-endian Power architecture builds.
libcpp/ChangeLog:
2016-10-04 Kelvin Nilsen <kel...@gcc.gnu.org>
PR target/77847
*
1 - 100 of 128 matches
Mail list logo
