. */
< /* 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-in
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])
> break
there 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 c
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
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
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
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
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
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 cont
n the implementation of do_compile () to
immediately preceding the invocation of handle_common_deferred_options
() (inside toplev::main ()).
gcc/ChangeLog:
2016-01-14 Kelvin Nilsen
* toplev.c (do_compile): remove invocation of process_options ()
from within do_compile ()
(t
ether Pmode can change with attribute
target. It cannot.
gcc/ChangeLog:
2016-01-27 Kelvin Nilsen
* toplev.c (do_compile): Invoke finish_deferred_option_handling ()
upon return from process_options () and provide comment to explain
why.
* opts-glo
Ping. Thanks.
On 01/27/2016 11:12 AM, Kelvin Nilsen wrote:
This patch has bootstrapped and tested on
powerpc64le-unknown-linux-gnu with no regressions. Is this ok for the
trunk?
See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48344 for the
original problem report. The error resulted
and eliminated special initialization function that had been proposed in
the V3 patch.
gcc/testsuite/ChangeLog:
2016-02-11 Kelvin Nilsen
* gcc.target/powerpc/pr48344-1.c: New test.
gcc/ChangeLog:
2016-02-11 Kelvin Nilsen
* opts-global.c (handle_common_deferred_op
at field alignment calculations on 64-bit architectures ignore the
-malign-power command-line option. With this fix, the test case identified in
the PR behaves as was expected by the submitter.
gcc/ChangeLog:
2016-02-17 Kelvin Nilsen
PR target/66337
* config/rs6000/freebsd
:
2015-11-07 Kelvin Nilsen
* cfgloopmanip.h
(in_loop_p): new extern declaration
(zero_loop_frequencies): new extern declaration
(increment_loop_frequencies): new extern declaration
* cfgloopmanip.c
(in_loop_p): new helper routine
functions, comments now clarify the bound on
the recursion depth.
c) Code that had been conditionally compiled under the
ENABLE_CHECKING attribute is now unconditionally compiled and executed
only if the flag_checking variable is non-zero.
gcc/ChangeLog:
2015-11-20 Kelvin Nilsen
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
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
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 2
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
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
Kelvin Nilsen
* 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 built-in functions
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 case as
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:
>
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-dfor
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
-30 Kelvin Nilsen
PR target/80103
* gcc.target/powerpc/pr80103-1.c (b): Correct spelling of
__attribute__.
Index: gcc/testsuite/gcc.target/powerpc/pr80103-1.c
===
--- gcc/testsuite/gcc.target/powerpc/pr80103
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?
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
-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
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 AltiVe
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
,
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 with
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
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
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
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.
>
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,
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 -
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 B
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
* config/rs6000/rs6
) with
both -m32 and -m64 target options. Is this ok for trunk?
gcc/ChangeLog:
2018-01-16 Kelvin Nilsen
* config/rs6000/rs6000-p8swap.c (rs6000_gen_stvx): Generate
different rtl trees depending on TARGET_64BIT.
(rs6000_gen_lvx): Likewise.
Index: gcc/config/rs6000
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
Kelvin Nilsen
PR bootstrap/80867
* tree-vect
on
powerpc64le-unknown-linux. Is this ok for trunk?
gcc/ChangeLog:
2018-02-13 Kelvin Nilsen
* config/rs6000/rs6000.c (rs6000_option_override_internal): Issue
warning message if user requests -maltivec=be.
gcc/testsuite/ChangeLog:
2018-02-13 Kelvin Nilsen
* gcc.dg
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 -r1.36
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
* config/rs6000/rs6000-builtin.def: Remove various BU_ALTIVEC_X
macro expansions for definition of ST_INTERNAL_ and
LD_INTERNAL_
, with
both -m32 and -m64 target options).
Is this patch ok for trunk?
gcc/ChangeLog:
2018-03-14 Kelvin Nilsen
* config/rs6000/rs6000-builtin.def: Remove various BU_ALTIVEC_X
macro expansions for definition of ST_INTERNAL_ and
LD_INTERNAL_ builtins.
* config
gcc/ChangeLog:
2018-03-14 Kelvin Nilsen
* 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 variant of LVX icode pa
for trunk?
gcc/ChangeLog:
2018-03-29 Kelvin Nilsen
* 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 long int *)".
Add commen
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
* config/rs6000/
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
PR target/85347
* gcc.target/powerpc/vec-ldl-1.c
/ChangeLog:
2018-04-13 Kelvin Nilsen
* 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
built-in function name to non-
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
* doc/extend.texi: Tidy documentation of PowerPC built-in functions.
Index:
me 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 f
e:
> Hi!
>
> 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):
>>
orm because it is missing relevant fonts.
Is this ok for the trunk?
2018-05-09 Kelvin Nilsen
* doc/extend.texi (PowerPC Built-in Functions): Rename this
subsection.
(Basic PowerPC Built-in Functions): The new name of the
subsection previously known as "Po
Kelvin Nilsen
* 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 "PowerPC Altivec
Bui
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
* doc/extend.texi (P
(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
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
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
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
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
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
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
/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
?
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
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
c_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
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
bootstrapped and tested on powerpc64le-unknown-linux
and on powerpc64-unknown-linux (big-endian) with no regressions. Is
this ok for the trunk?
gcc/ChangeLog:
2016-08-04 Kelvin Nilsen
* config/rs6000/rs6000-c.c (altivec_overloaded_builtins): Add
overloaded binary floating point
ally to GCC 6.2?
>>
>> [gcc]
>> 2016-05-23 Michael Meissner
>> Kelvin Nilsen
>>
>> * config/rs6000/rs6000.c (rs6000_expand_vector_set): Generate
>> vpermr/xxpermr on ISA 3.0.
>> (altivec_expand
on
infrastructure that has not yet been backported to gcc-6. Once the
necessary infrastructure is available, is this ok for backporting to
gcc6 following bootstrap and regression testing?
Thanks,
Kelvin
gcc/ChangeLog:
2016-05-27 Kelvin Nilsen
* config/rs6000/altivec.h (vec_slv): New
with the
gcc-6-branch after waiting a few days following the trunk integration?
gcc/ChangeLog:
2016-06-02 Kelvin Nilsen
* config/rs6000/rs6000.h (RS6000_BTM_COMMON): Add the
RS6000_BTM_MODULO flag into the set of flags that are considered
to be part of the common
for backporting to gcc6 after a few days of burn-in time on the
trunk?
gcc/testsuite/ChangeLog:
2016-06-06 Kelvin Nilsen
* gcc.target/powerpc/vadsdu-0.c: New test.
* gcc.target/powerpc/vadsdu-1.c: New test.
* gcc.target/powerpc/vadsdu-2.c: New test.
* gcc.target
trunk?
gcc/ChangeLog:
2016-06-08 Kelvin Nilsen
* config/rs6000/altivec.h (vec_absd): New macro for vector absolute
difference unsigned.
(vec_absdb): New macro for vector absolute difference unsigned
byte.
(vec_absdh): New macro for vector absolute
tested by vadsdub-1.c. In the previous commit, these
two tests were identical.
gcc/testsuite/ChangeLog:
2016-06-16 Kelvin Nilsen
* gcc.target/powerpc/vadsdu-0.c: Replace
dg-require-effective-target directive to allow test to run on more
platforms, and add dg-skip-if
On 06/16/2016 11:47 AM, Kelvin Nilsen wrote:
> This patch improves upon a recently committed patch to add support for
> Power9 vector absolute difference unsigned instructions in two ways:
>
> 1. The dg-require-effective-target directive is changed in all tests to
> allow the t
anks.
gcc/ChangeLog:
2016-06-20 Kelvin Nilsen
* config/rs6000/rs6000.h: Add conditional preprocessing directives
to disable Power9-specific compiler features if HAVE_AS_POWER9 is
not defined.
gcc/testsuite/ChangeLog:
2016-06-20 Kelvin Nilsen
* gcc.target/p
/ChangeLog:
2016-06-27 Kelvin Nilsen
* gcc.target/powerpc/dtstsfi-0.c: New test.
* gcc.target/powerpc/dtstsfi-1.c: New test.
* gcc.target/powerpc/dtstsfi-10.c: New test.
* gcc.target/powerpc/dtstsfi-11.c: New test.
* gcc.target/powerpc/dtstsfi-12.c: New
ok for trunk? Is it ok
for gcc-6 after burn-in on the trunk?
Thanks.
gcc/testsuite/ChangeLog:
2016-06-28 Kelvin Nilsen
* gcc.target/powerpc/vslv-0.c: Add a dg-require-effective-target
directive to run this test only with compilers that are aware of
Power9 instructions
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
https://gcc.gnu.org/ml/gcc-patches/2017-02/msg00541.htm
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
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
* gcc.target/powerpc/bfp/scalar-inse
-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
PR target/9
* gcc.dg/loop-8.c
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
* gcc.target/powerpc/p9-options-1.c: New test.
gcc
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 in te
=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
PR target/80103
* gcc.target/powerpc
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
PR
-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
PR target/80108
more 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
PR target/80108
* config/rs6000/rs6
. Is
this ok for the trunk?
gcc/ChangeLog:
2017-04-06 Kelvin Nilsen
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.
gcc/testsuite/Chan
boostrapped without regressions on
powerpc64le-unknown-linux-gnu. Is this ok for the trunk?
gcc/ChangeLog:
2017-03-29 Kelvin Nilsen
PR target/80101
* recog.c (store_data_bypass_p): Rather than terminate with
assertion error, return false if either function argument is
ching consumer, then it is
possible 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
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
*
nd my 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
* gcc.target/powerpc/pr80101-1.c: New test.
gcc/ChangeLog:
2017-04-14 Kelvin N
without regressions on
powerpc64le-unknown-linux-gnu. Is this ok for the trunk?
gcc/testsuite/ChangeLog:
2017-04-20 Kelvin Nilsen
PR target/80101
* gcc.target/powerpc/pr80101-1.c: New test.
gcc/ChangeLog:
2017-04-20 Kelvin Nilsen
PR target/80101
* config
.
Is this ok for the trunk?
gcc/ChangeLog:
2017-04-28 Kelvin Nilsen
* 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/rs6000-builtin.def (BU_P6_CMPB_2
Kelvin Nilsen
* 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 loaded is not represented by a base
ok for trunk?
gcc/ChangeLog:
2017-09-25 Kelvin Nilsen
* 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
1 - 100 of 128 matches
Mail list logo
