On Mon, Jan 11, 2021 at 11:53:15AM -0800, H.J. Lu via Binutils wrote:
> Check if AR is usable for LTO build with --enable-pgo-build=lto:
>
> checking for -plugin option... ar: no operation specified
> Failed: ar --plugin
> /usr/gcc-11.0.0-x32/libexec/gcc/x86_64-pc-linux-gnu/11.0.0/liblto_plugin.s
On Sat, Dec 05, 2020 at 07:42:07PM +1030, Alan Modra wrote:
> Hi Segher,
> I've been holding off pinging these knowing you had a lot of other
> review work, but maybe that's settling down now? You already OK'd
> 1/8, 2/8 and 6/8.
Ping.
> [PATCH 3/8] [RS6000] rs6000_rtx_costs tidy AND
> https://g
On Mon, Jan 11, 2021 at 08:57:04AM -0800, H.J. Lu via Binutils wrote:
> Check if AR works with --plugin and rc before passing --plugin to AR and
> RANLIB.
Thanks for looking at this, but next time please assign the bug to
yourself. I fixed the bug too this morning, before seeing your
email.
--
On Mon, Jan 11, 2021 at 08:57:05AM -0800, H.J. Lu via Binutils wrote:
> diff --git a/config/gcc-plugin.m4 b/config/gcc-plugin.m4
> index c5b72e9a13d..798a2054edd 100644
> --- a/config/gcc-plugin.m4
> +++ b/config/gcc-plugin.m4
> @@ -145,6 +145,18 @@ for plugin in $plugin_names; do
> break
>
On Mon, Jan 11, 2021 at 04:07:22PM -0800, H.J. Lu wrote:
> These are not fatal errors. Here is the updated patch to use
> AC_MSG_WARN instead. OK for master?
OK by me. Please squash the two patches.
--
Alan Modra
Australia Development Lab, IBM
On Mon, Jan 11, 2021 at 02:52:43PM -0800, H.J. Lu wrote:
> On Mon, Jan 11, 2021 at 1:20 PM Alan Modra wrote:
> >
> > On Mon, Jan 11, 2021 at 11:53:15AM -0800, H.J. Lu via Binutils wrote:
> > > Check if AR is usable for LTO build with --enable-pgo-build=lto:
> > >
> > > checking for -plugin option.
Hi Segher,
I've been holding off pinging these knowing you had a lot of other
review work, but maybe that's settling down now? You already OK'd
1/8, 2/8 and 6/8.
[PATCH 3/8] [RS6000] rs6000_rtx_costs tidy AND
https://gcc.gnu.org/pipermail/gcc-patches/2020-October/555754.html
[PATCH 4/8] [RS6000]
On Thu, Oct 29, 2020 at 10:10:58PM +1030, Alan Modra wrote:
> Fixes
> FAIL: gcc.target/powerpc/signbit-1.c scan-assembler-not stxvd2x
> FAIL: gcc.target/powerpc/signbit-1.c scan-assembler-times mfvsrd 3
> FAIL: gcc.target/powerpc/signbit-1.c scan-assembler-times srdi 3
> FAIL: gcc.target/powerpc/si
On Mon, Dec 07, 2020 at 05:49:05PM -0600, will schmidt via Gcc-patches wrote:
> [PATCH, powerpc] testsuite update tests for powerpc power10 target codegen.
Appears to duplicate work I did earlier,
https://gcc.gnu.org/pipermail/gcc-patches/2020-October/557587.html
Except I omitted fold-vec-store-b
Ping?
On Fri, Oct 02, 2020 at 05:03:50PM +0930, Alan Modra wrote:
https://gcc.gnu.org/pipermail/gcc-patches/2020-October/555309.html
--
Alan Modra
Australia Development Lab, IBM
On Tue, Oct 20, 2020 at 01:55:56PM -0500, Segher Boessenkool wrote:
> On Thu, Oct 08, 2020 at 09:27:54AM +1030, Alan Modra wrote:
> > The existing "case AND" in this function is not sufficient for
> > optabs.c:avoid_expensive_constant usage, where the AND is passed in
> > outer_code. We'd like to
On Wed, Oct 21, 2020 at 03:29:11PM -0500, Segher Boessenkool wrote:
> Anyway:
>
> + || (outer_code == AND
> + && rs6000_is_valid_2insn_and (x, mode)))
> {
> *total = COSTS_N_INSNS (1);
> return true;
>
> It should return COSTS_N_INSNS (2)
gcc.target/powerpc/vsx_mask-count-runnable.c and others
Assembler messages:
Error: unrecognized opcode: `vcntmb'
I'm applying this one as obvious. Ref
https://gcc.gnu.org/pipermail/gcc-patches/2020-July/549757.html
* config/rs6000/vsx.md (vec_cntmb_, vec_extract_),
(vec_expand_):
FAIL: gcc.target/powerpc/vec-splati-runnable.c 1 blank line(s) in output
FAIL: gcc.target/powerpc/vec-splati-runnable.c (test for excess errors)
Excess errors:
rs6000_emit_xxspltidp_v2df called ...
and running the test fails. As the comment says
/* Although the instruction says the results are
These tests require -mno-pcrel because they are testing features
of the non-pcrel ABI.
* gcc.target/powerpc/cprophard.c: Add -mno-pcrel to options.
* gcc.target/powerpc/float128-hw3.c: Likewise.
* gcc.target/powerpc/pr79439-1.c: Likewise.
* gcc.target/powerpc/pr7943
This tests behaviour near the limit of 16-bit signed offsets. If
power10 prefix instructions are enabled, no such testing occurs.
* gcc.target/powerpc/dimode_off.c: Add -mno-prefixed to options.
Regstrapped powerpc64le-linux power10 and power8. OK?
diff --git a/gcc/testsuite/gcc.target
Running the assembler and linker catches more errors.
* gcc.target/powerpc/cfuged-1.c,
* gcc.target/powerpc/cntlzdm-1.c,
* gcc.target/powerpc/cnttzdm-1.c,
* gcc.target/powerpc/dg-future-1.c,
* gcc.target/powerpc/lsbb-runnable.c,
* gcc.target/powerpc/
* gcc.dg/pr56727-2.c,
* gcc.dg/vect/costmodel/ppc/costmodel-bb-slp-9a-pr63175.c,
* gcc.target/powerpc/fold-vec-load-builtin_vec_xl-char.c,
* gcc.target/powerpc/fold-vec-load-builtin_vec_xl-double.c,
* gcc.target/powerpc/fold-vec-load-builtin_vec_xl-float.c,
On Mon, Oct 12, 2020 at 10:37:05PM +1030, Alan Modra wrote:
> Ping?
>
> On Fri, Oct 02, 2020 at 05:03:50PM +0930, Alan Modra wrote:
> https://gcc.gnu.org/pipermail/gcc-patches/2020-October/555309.html
Ping^2
--
Alan Modra
Australia Development Lab, IBM
On Thu, Oct 22, 2020 at 05:33:46PM +1030, Alan Modra wrote:
> * gcc.dg/pr56727-2.c,
> * gcc.dg/vect/costmodel/ppc/costmodel-bb-slp-9a-pr63175.c,
> * gcc.target/powerpc/fold-vec-load-builtin_vec_xl-char.c,
> * gcc.target/powerpc/fold-vec-load-builtin_vec_xl-double.c,
>
On Thu, Oct 22, 2020 at 11:03:14AM -0500, Segher Boessenkool wrote:
> On Thu, Oct 22, 2020 at 08:58:10AM -0700, Carl Love wrote:
> > OK, looks like VSX_MM_SUFFIX doesn't exist anymore. Don't know what
> > happed to it. Thanks.
>
> It never existed on trunk. Please always regstrap patches on tru
On Thu, Oct 22, 2020 at 09:08:58AM -0700, Carl Love wrote:
> I see the error print statement you changed so that it would not wrap.
> I have always been told it is best not to break the print statement
> across two lines. The argument is it makes it harder to find it in the
> code when using grep
On Thu, Oct 22, 2020 at 11:25:09PM +1030, Alan Modra wrote:
> Some of these are wrong, sorry. I need to go over and check them
> thoroughly. Please consider the patch withdrawn.
Revised patch, removing changes to
gcc.target/powerpc/fold-vec-st-double.c,
gcc.target/powerpc/fold-vec-st-longlong.c,
gcc.target/powerpc/fold-vec-st-pixel.c and other testcases fail on
power10, generating
addi 9,5,12
rldicr 9,9,0,59
stxv 34,0(9)
rather than
addi 5,5,12
stvx 2,0,5
for an altivec lvx/stvx style address.
The problem starts with fwprop creating
(insn 9 4 0 2 (s
rs6000_emit_int_cmove generates isel so the condition below needs
fixing for power10. Bootstrapped and regression tested
powerpc64le-linux power10 and power8. OK?
* config/rs6000/rs6000.md (cstore4): Don't call
rs6000_emit_int_cmove for power10 when -mno-isel.
diff --git a/gcc/c
On Fri, Oct 23, 2020 at 01:22:31PM -0500, Segher Boessenkool wrote:
> On Fri, Oct 23, 2020 at 04:45:29PM +1030, Alan Modra wrote:
> > Revised patch, removing changes to
> > gcc.target/powerpc/fold-vec-st-double.c,
> > gcc.target/powerpc/fold-vec-st-longlong.c,
> > gcc.target/powerpc/fold-vec-st-pix
On Fri, Oct 23, 2020 at 07:18:44PM -0400, Hans-Peter Nilsson wrote:
> On Thu, 22 Oct 2020, Alan Modra via Gcc-patches wrote:
> > /* (reg) is costed at zero by rtlanal.c:rtx_cost. That sets a
> > baseline for rtx costs: If a constant is valid in an insn,
>
Hi Segher,
On Fri, Oct 23, 2020 at 11:31:02AM -0500, Segher Boessenkool wrote:
> On Fri, Oct 23, 2020 at 05:15:08PM +1030, Alan Modra wrote:
> > The problem starts with fwprop creating
> > (insn 9 4 0 2 (set (mem:V8HI (and:DI (plus:DI (reg/v/f:DI 121 [ vpp ])
> > (const_int 12
On Fri, Oct 23, 2020 at 04:06:57PM -0500, Segher Boessenkool wrote:
> On Fri, Oct 23, 2020 at 09:41:30AM +1030, Alan Modra wrote:
> > On Thu, Oct 22, 2020 at 11:03:14AM -0500, Segher Boessenkool wrote:
> > > On Thu, Oct 22, 2020 at 08:58:10AM -0700, Carl Love wrote:
> > > > OK, looks like VSX_MM_SU
On Sat, Oct 24, 2020 at 12:31:43PM -0500, Segher Boessenkool wrote:
> On Sat, Oct 24, 2020 at 02:59:34PM +1030, Alan Modra wrote:
> > Those instructions aren't generated, we don't see them anywhere on a
> > power10 all-lang bootstrap except in one testcase designed to exercise
> > them.
>
> But th
All these tests fail with -m32 due to lack of int128 support, in some
cases with what I thought was not the best error message. For example
vsx_mask-move-runnable.c:34:3: error: unknown type name 'vector'
is misleading. The problem isn't "vector" but "vector __uint128_t".
* gcc.target/po
FAIL: gcc.target/powerpc/swaps-p8-22.c (test for excess errors)
Excess errors:
cc1: error: '-mcmodel' not supported in this configuration
* gcc.target/powerpc/swaps-p8-22.c: Disable for -m32.
diff --git a/gcc/testsuite/gcc.target/powerpc/swaps-p8-22.c
b/gcc/testsuite/gcc.target/powerpc/s
When running with -m32
FAIL: gcc.target/powerpc/pr94740.c (test for excess errors)
Excess errors:
cc1: error: '-mpcrel' requires '-mcmodel=medium'
The others don't run for -m32, but remove the unnecessary -mpcrel
anyway.
* gcc.target/powerpc/localentry-1.c: Remove -mpcrel from options.
I thought this one was worth at least commenting as to why it fails
when biarch testing. OK?
* gcc.target/powerpc/bswap64-4.c: Comment.
diff --git a/gcc/testsuite/gcc.target/powerpc/bswap64-4.c
b/gcc/testsuite/gcc.target/powerpc/bswap64-4.c
index a3c05539652..11787000409 100644
--- a/gc
On Sun, Oct 25, 2020 at 10:43:12AM -0400, David Edelsohn wrote:
> On Sun, Oct 25, 2020 at 7:20 AM Alan Modra wrote:
> >
> > All these tests fail with -m32 due to lack of int128 support, in some
> > cases with what I thought was not the best error message. For example
> > vsx_mask-move-runnable.c:
On Mon, Oct 26, 2020 at 03:18:39PM -0500, Segher Boessenkool wrote:
> Hi!
>
> On Thu, Oct 22, 2020 at 05:28:17PM +1030, Alan Modra wrote:
> > These tests require -mno-pcrel because they are testing features
> > of the non-pcrel ABI.
>
> > --- a/gcc/testsuite/gcc.target/powerpc/cprophard.c
> > +++
On Mon, Oct 26, 2020 at 07:33:49AM -0500, Segher Boessenkool wrote:
> On Sun, Oct 25, 2020 at 09:50:01PM +1030, Alan Modra wrote:
> > All these tests fail with -m32 due to lack of int128 support,
>
> Is there any good reason __int128 is not enabled for rs6000 -m32, btw?
Lack of addti3 and subti3
On Mon, Oct 26, 2020 at 04:28:20PM +, Iain Sandoe wrote:
> David Edelsohn via Gcc-patches wrote:
>
> > FAIL: gcc.target/powerpc/swaps-p8-22.c (test for excess errors)
> > Excess errors:
> > cc1: error: '-mcmodel' not supported in this configuration
> >
> > * gcc.target/powerpc/swaps-p8-22.c:
Revised version.
* gcc.dg/pr56727-2.c,
gcc.dg/vect/costmodel/ppc/costmodel-bb-slp-9a-pr63175.c,
gcc.target/powerpc/fold-vec-load-builtin_vec_xl-char.c,
gcc.target/powerpc/fold-vec-load-builtin_vec_xl-double.c,
gcc.target/powerpc/fold-vec-load-builtin_vec_xl-
Subject was "[RS6000] Tests that use int128_t and -m32"
I meant to make this change before committing too. Pushed.
* gcc.target/powerpc/vsx_mask-count-runnable.c: Separate options
passed to dg-require-effective-target.
* gcc.target/powerpc/vsx_mask-expand-runnable.c: Likew
>From 6c1817cece47ce2cb36df1f57b533b9d2385f0a5 Mon Sep 17 00:00:00 2001
From: Alan Modra
Date: Tue, 27 Oct 2020 17:32:13 +1030
Subject:
These tests never checked assembly, because .s files were not
produced. One test was looking for the wrong instructions.
A typical error log
PASS: gcc.target/
On power10 these are "dg-do run" tests, so need -save-temps for the
assembler scanning.
Regression tested powerpc64le-linux power8 and power10. OK?
* gcc.target/powerpc/vsx-load-element-extend-char.c: Add -save-temps.
* gcc.target/powerpc/vsx-load-element-extend-int.c: Likewise.
On Tue, Oct 27, 2020 at 05:34:45PM -0500, Segher Boessenkool wrote:
> Hi!
>
> On Tue, Oct 27, 2020 at 09:26:10PM +1030, Alan Modra wrote:
> > These tests never checked assembly, because .s files were not
> > produced. One test was looking for the wrong instructions.
>
> -/* { dg-final { scan-as
git commit badeac77f552 changed expected number of addi instructions,
causing these fails on powerpc-linux.
gcc.target/powerpc/fold-vec-insert-int-p9.c: \\maddi\\M found 12 times
FAIL: gcc.target/powerpc/fold-vec-insert-int-p9.c scan-assembler-times
\\maddi\\M 8
gcc.target/powerpc/fold-vec-extrac
commit 25ffd3d34e means we no longer define an overloaded
__builtin_byte_in_set for -m32, so the more informative
"__builtin_byte_in_set is not supported in this compiler
configuration" is not reported.
Regression tested powerpc64-linux biarch. OK?
PR bootstrap/92661
* gcc.target
>From e7ce33cef478a826a2fe4e110b43b49586ef2438 Mon Sep 17 00:00:00 2001
From: Alan Modra
Date: Wed, 28 Oct 2020 15:57:57 +1030
Subject:
I noticed this test is unsupported on power10 when looking through
test logs. There seems no reason why that should be the case, ie.
likely the target test was
Otherwise some versions of dejagnu go ahead and run the vsx tests
below when they should not. To best cope with older dejagnu, put
"run" before "compile", the idea being that if the second dg-do always
wins then that won't cause fails.
The altivec tests also need -save-temps for the scan-assemble
On Wed, Oct 28, 2020 at 12:16:00PM -0500, Segher Boessenkool wrote:
> On Wed, Oct 28, 2020 at 09:20:56PM +1030, Alan Modra wrote:
> > Otherwise some versions of dejagnu go ahead and run the vsx tests
> > below when they should not. To best cope with older dejagnu, put
> > "run" before "compile", t
On Wed, Oct 28, 2020 at 01:44:54PM -0500, Segher Boessenkool wrote:
> On Wed, Oct 28, 2020 at 09:18:35PM +1030, Alan Modra wrote:
> > >From e7ce33cef478a826a2fe4e110b43b49586ef2438 Mon Sep 17 00:00:00 2001
> > From: Alan Modra
> > Date: Wed, 28 Oct 2020 15:57:57 +1030
> > Subject:
> >
> > I noti
On Wed, Oct 28, 2020 at 11:35:07PM -0400, David Edelsohn wrote:
> Alan,
>
> It is disrespectful for you to ignore the review of a maintainer and
> your colleague. You may not pick and choose amongst maintainers. And
> Segher should not be so disrespectful as to contradict his colleague
> and co-
Fixes
FAIL: gcc.target/powerpc/signbit-1.c scan-assembler-not stxvd2x
FAIL: gcc.target/powerpc/signbit-1.c scan-assembler-times mfvsrd 3
FAIL: gcc.target/powerpc/signbit-1.c scan-assembler-times srdi 3
FAIL: gcc.target/powerpc/signbit-2.c scan-assembler-times ld 1
FAIL: gcc.target/powerpc/signbit-2
And now waking up to what you meant by the lvsl-lvsr.c \s comment,
plus a revised ppc-ne0-1.c scan-assembler.
I think this covers all previous review corrections. Regression tested
powerpc64-linux power7 and powerpc64le-linux power10. OK?
* lib/target-supports.exp (check_effective_targe
On Fri, Oct 30, 2020 at 09:21:09AM +, Richard Sandiford wrote:
> Alan Modra via Gcc-patches writes:
> > This moves an #ifdef block of code from calls.c to
> > targetm.function_ok_for_sibcall. Only two targets, x86 and rs6000,
> > define REG_PARM_STACK_SPACE or OUTGOING
Hi Mike,
On Wed, Oct 28, 2020 at 08:42:04PM -0400, Michael Meissner via Gcc-patches
wrote:
> PowerPC: PR libgcc/97543, fix 64-bit long double issues
>
> There are two issues in PR libgcc/97543 which shows up if you build a GCC
> compiler with long double defaulting to 64-bit instead of 128-bit wi
This typo was fixed a little while ago in binutils-gdb with commit
e951225303. I noticed the difference today when importing libiberty
from gcc. Committed as obvious.
include/
* dwarf2.def: Correct spelling of DW_AT_namelist_item.
gcc/
* dwarf2out.cc (gen_namelist_decl): Adjust t
Compiling gcc/testsuite/gcc.dg/split-*.c and others with -mcpu=power10
and linking with a non-pcrel libgcc results in crashes due to the
power10 pcrel code not having r2 set for the generic-morestack.c
functions called from __morestack. There is also a problem when
non-pcrel code calls a pcrel lib
Bootstrapped and regression tested powerpc64le-linux power9 and
power10. OK for mainline?
* lib/target-supports.exp (check_effective_target_has_arch_pwr10): New.
* gcc.dg/pr56727-2.c,
gcc.dg/vect/costmodel/ppc/costmodel-bb-slp-9a-pr63175.c,
gcc.target/powerpc/fold-
On Thu, Jul 01, 2021 at 04:47:21PM -0500, Segher Boessenkool wrote:
> Hi!
>
> On Thu, Jul 01, 2021 at 10:59:15PM +0930, Alan Modra wrote:
> > * lib/target-supports.exp (check_effective_target_has_arch_pwr10): New.
>
> Mike added this already, please make sure to not add it twice :-)
Yup, reb
101 - 158 of 158 matches
Mail list logo
