On Thu, May 04, 2023 at 11:02:25AM +, Richard Biener via Binutils wrote:
> So since we expect the linker to use the host side table is there a way
> for the plugin to exactly query that (the set of symbols the linker
> uses from the object passed to the plugin)?
That would be possible and rela
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
On Mon, May 23, 2022 at 07:42:29PM -0400, David Malcolm via Binutils wrote:
> Any objections, or is there a reason to keep these macros that I'm
> not aware of? (and did I send this to all the pertinent lists?)
No objection from me. These macros are not used anywhere in
binutils-gdb.
--
Alan M
On Tue, May 10, 2022 at 10:56:22AM +0200, Martin Liška wrote:
> diff --git a/libiberty/hashtab.c b/libiberty/hashtab.c
> @@ -457,15 +457,15 @@ htab_empty (htab_t htab)
>else if (htab->free_with_arg_f != NULL)
> (*htab->free_with_arg_f) (htab->alloc_arg, htab->entries);
>if (
On Tue, May 10, 2022 at 10:57:47AM +0200, Martin Liška wrote:
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>
> @Alan: Are you fine with the change from binutils/gdb perspective?
I'm fine if this isn't going into the binutils-gdb repo immediately.
There are occurrences
The idea is for opcodes to be able to see whether bfd is compiled
for 64-bit. A lot of --enable-targets=all libopcodes is wasted space
if bfd can't load 64-bit target object files.
* Makefile.def (configure-opcodes): Depend on configure-bfd.
* Makefile.in: Regenerate.
Applied to
Current ubsan complains on every use of __PTR_ALIGN (when ptrdiff_t is
as large as a pointer), due to making calculations relative to a NULL
pointer. This patch avoids the problem by extracting out and
simplifying __BPTR_ALIGN for the usual case. I've continued to use
ptrdiff_t here, where it mig
On Wed, Jul 21, 2021 at 08:59:04AM -0400, David Edelsohn wrote:
> On Wed, Jul 21, 2021 at 4:29 AM Alan Modra wrote:
> >
> > On Wed, Jul 14, 2021 at 08:24:16PM -0400, David Edelsohn wrote:
> > > > > > * config/rs6000/morestack.S (R2_SAVE): Define.
> > > > > > (__morestack): Save and restore
On Wed, Jul 07, 2021 at 08:03:45PM +0100, Nick Alcock via Gcc-patches wrote:
> On 7 Jul 2021, Nick Clifton told this:
>
> > Hi Nick,
> >
> >> Ping?
> >
> > Oops.
>
> I sent a bunch of pings out at the same time, to a bunch of different
> projects. You are the only person to respond, so thank you!
On Wed, Jun 30, 2021 at 05:06:30PM -0300, Tulio Magno Quites Machado Filho
wrote:
> Alan Modra via Gcc-patches writes:
>
> > 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
> >
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
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-
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
On Tue, May 18, 2021 at 05:48:40AM -0500, Segher Boessenkool wrote:
> I wrote a bit later:
>
> > > Can you make this less hacky please? Changing the generic code is just
> > > fine as well, it needs some love.
>
> In effect making a callback / hook without making that explicit is bad
> for maint
On Mon, May 10, 2021 at 04:39:55PM -0500, Segher Boessenkool wrote:
> Hi!
>
> On Fri, May 07, 2021 at 12:19:52PM +0930, Alan Modra wrote:
> > PowerPC64 ELFv2 dual entry point functions have a couple of problems
> > with -fpatchable-function-entry. One is that the nops added after the
> > global e
On Fri, May 07, 2021 at 07:24:02PM -0500, Segher Boessenkool wrote:
> Looks good with those things tweaked.
Except that the patch chose the wrong section to emit the label,
because the decl is wrong. But of course I was using the same decl as
used in existing SHF_LINK_ORDER support, so it was alr
PowerPC64 ELFv2 dual entry point functions have a couple of problems
with -fpatchable-function-entry. One is that the nops added after the
global entry land in the global entry code which is constrained to be
a power of two number of instructions, and zero global entry code has
special meaning for
This reverts commit b680b9049737198d010e49cf434704c6a6ed2b3f now
that the PowerPC64 ELFv1 regression is fixed properly.
PR testsuite/98125
* targhooks.h (default_print_patchable_function_entry_1): Delete.
* targhooks.c (default_print_patchable_function_entry_1): Delete.
On PowerPC64 ELFv1 function symbols are defined on function
descriptors in an .opd section rather than in the function code.
.opd is not split up by the PowerPC64 backend for comdat groups or
other situations where per-function sections are required. Thus
SECTION_LINK_ORDER can't use the function
This series of patches fixes -fpatchable-function-entry on PowerPC64
ELFv1 so that SECTION_LINK_ORDER (.section 'o' arg) is now supported,
and on PowerPC64 ELFv2 to not break the global entry code.
Bootstrapped powerpc64le-linux and x86_64-linux all langs. I did see
one regression on both targets
On Wed, May 05, 2021 at 08:05:29AM +0100, Iain Sandoe wrote:
> Alan Modra via Gcc-patches wrote:
>
> > On 2021-05-04 8:42 a.m., Nick Clifton wrote:
> > > Hi Guys,
> > >
> > > On 4/30/21 7:36 PM, Simon Marchi wrote:
> > > > I think thi
On 2021-05-04 8:42 a.m., Nick Clifton wrote:
> Hi Guys,
>
> On 4/30/21 7:36 PM, Simon Marchi wrote:
>> I think this fix is obvious enough, I encourage you to push it,
>
> OK - I have pushed the patch to the mainline branches of both
> the gcc and binutils-gdb repositories.
Thanks Nick! Incident
On Mon, May 03, 2021 at 10:47:15AM -0400, Simon Marchi wrote:
> > Yes, I prefer the configure fix too. If we state we require C99 in
> > binutils then we ought to be able to use C99..
> >
> > Nick, does the configure.ac change also need to go in all subdirs, to
> > support people running make in
On Fri, Apr 30, 2021 at 03:48:00PM -0600, Jeff Law via Gcc-patches wrote:
>
> On 4/30/2021 12:36 PM, Simon Marchi via Gcc-patches wrote:
> > On 2021-04-26 7:32 a.m., Nick Clifton via Gdb-patches wrote:> Hi Guys,
> > >Given that gcc, gdb and now binutils are all now requiring C99 as a
> > >
On Wed, Feb 17, 2021 at 11:23:12AM +, Jozef Lawrynowicz wrote:
> In previous discussions, it seemed to me that there was general support
> for the "used" attribute implying SHF_GNU_RETAIN and saving symbols from
> linker garbage collection[1]. Of course, the current implementation
> results in
On Mon, Feb 08, 2021 at 11:16:31AM +, Nick Alcock via Binutils wrote:
> intl/ChangeLog
> 2021-02-04 Nick Alcock
>
> * configure.ac (LIBINTL): Transform into -L/-lintl form.
> * configure: Regenerate.
OK for binutils.
--
Alan Modra
Australia Development Lab, IBM
On Mon, Feb 08, 2021 at 11:16:30AM +, Nick Alcock via Binutils wrote:
> intl/ChangeLog
> 2021-02-02 Nick Alcock
>
> * aclocal.m4: include picflag.m4.
> * configure.ac (PICFLAG): Add and substitute.
> * Makefile.in (PICFLAG): New.
> (COMPILE): Use it.
> * config
On Fri, Jan 29, 2021 at 11:11:23AM +0800, HAO CHEN GUI via Gcc-patches wrote:
> This patch tries to optimize PowerPC 64 bit constant generation when the
> constant can be transformed from a 32 bit or 16 bit constant by rotating,
> shifting and mask AND.
All and more of what you are doing here f
On Mon, Jan 25, 2021 at 04:51:43PM -0600, Segher Boessenkool wrote:
> Hi!
>
> On Thu, Oct 08, 2020 at 09:27:57AM +1030, Alan Modra wrote:
> > * config/rs6000/rs6000.c (rotate_insert_cost): New function.
> > (rs6000_rtx_costs): Cost IOR.
> >
> > diff --git a/gcc/config/rs6000/rs6000.c b/gc
On Mon, Jan 25, 2021 at 04:37:21PM -0600, Segher Boessenkool wrote:
> I still do not see what this improves, I only see possible obvious
> regressions :-(
You asked me to break the patch series into small pieces, for ease of
review and to separate tidies from functional changes. Well OK, fair
eno
Ping.
On Tue, Jan 12, 2021 at 02:03:18PM +1030, Alan Modra wrote:
> Ping
> https://gcc.gnu.org/pipermail/gcc-patches/2020-October/557587.html
>
> On Fri, Oct 30, 2020 at 07:00:14PM +1030, Alan Modra wrote:
> > And now waking up to what you meant by the lvsl-lvsr.c \s comment,
> > plus a revised p
Ping.
On Tue, Jan 12, 2021 at 02:02:36PM +1030, Alan Modra wrote:
> Ping
> https://gcc.gnu.org/pipermail/gcc-patches/2020-October/555759.html
>
> On Thu, Oct 08, 2020 at 09:28:00AM +1030, Alan Modra wrote:
> > When optimizing for size we shouldn't be using metrics based on speed
> > or vice-versa
Ping.
On Tue, Jan 12, 2021 at 02:02:27PM +1030, Alan Modra wrote:
> Ping
> https://gcc.gnu.org/pipermail/gcc-patches/2020-October/555758.html
>
> On Thu, Oct 08, 2020 at 09:27:59AM +1030, Alan Modra wrote:
> > The aim of this patch is to make rtx_costs for SETs closer to
> > insn_cost for SETs.
Ping.
On Tue, Jan 12, 2021 at 02:02:18PM +1030, Alan Modra wrote:
> Ping
> https://gcc.gnu.org/pipermail/gcc-patches/2020-October/555756.html
>
> On Thu, Oct 08, 2020 at 09:27:57AM +1030, Alan Modra wrote:
> > * config/rs6000/rs6000.c (rotate_insert_cost): New function.
> > (rs6000_rtx_co
Ping.
On Tue, Jan 12, 2021 at 02:02:09PM +1030, Alan Modra wrote:
> Ping
> https://gcc.gnu.org/pipermail/gcc-patches/2020-October/555755.html
>
> On Thu, Oct 08, 2020 at 09:27:56AM +1030, Alan Modra wrote:
> > Most cases use "return false" rather than breaking out of the switch.
> > Do so in all
Ping.
On Tue, Jan 12, 2021 at 02:01:57PM +1030, Alan Modra wrote:
> Ping
> https://gcc.gnu.org/pipermail/gcc-patches/2020-October/555754.html
>
> On Thu, Oct 08, 2020 at 09:27:55AM +1030, Alan Modra wrote:
> > * config/rs6000/rs6000.c (rs6000_rtx_costs): Tidy AND code.
> > Don't avoid rec
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.
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 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 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 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 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 Tue, Jan 05, 2021 at 03:25:10PM +, Nick Alcock wrote:
> This enables 'make libctf-check', used by a new libctf testsuite in
> binutils.
>
> 2021-01-05 Nick Alcock
>
> * Makefile.def (libctf): No longer no_check. Checking depends on
> all-ld.
> * Makefile.in: Regenerat
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
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
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]
This patch retires ppc64-fp.c in favour of using
"LIB2_SIDITI_CONV_FUNCS = yes", which is a lot better solution than
having a copy of selected libgcc2.c functions.
So for powerpc64-linux we see these changes in libgcc files (plus
corresponding _s.o variants).
+_fixdfti.o
+_fixsfti.o
+_fixtfti.o
+_
On Tue, Nov 10, 2020 at 09:19:37PM -0700, Jeff Law wrote:
> I think the const char * is fine. That should force resolution to the
> same routine we were using earlier. Do you want to commit that fix or
> shall I?
Commited 693a79a355e1.
--
Alan Modra
Australia Development Lab, IBM
On Tue, Nov 10, 2020 at 11:45:37AM -0700, Jeff Law wrote:
>
> On 11/12/19 11:28 PM, Strager Neds wrote:
> > * gcc/cgraph.h (symtab_node::get_section): Constify.
> > (symtab_node::set_section): Declare new overload.
> > * gcc/symtab.c (symtab_node::set_section): Define new overload.
> > (symtab_nod
On PowerPC we can tail call if the callee has less or equal
REG_PARM_STACK_SPACE than the caller, as demonstrated by the
testcase. So we should use
/* If reg parm stack space increases, we cannot sibcall. */
if (REG_PARM_STACK_SPACE (decl ? decl : fntype)
> INCOMING_REG_PARM_STACK_SPAC
On Sat, Oct 31, 2020 at 12:10:35AM +1030, Alan Modra wrote:
> Would it be better if I post the patches again, restructuring them as
> 1) completely no functional change just moving the existing condition
>to the powerpc and i386 target hooks, and
> 2) twiddling the powerpc target hook?
The no
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
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
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
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
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-
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 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
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
>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
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
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
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
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.
>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/
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
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-
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:
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 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 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:
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
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.
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
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
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
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
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 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,
>
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
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
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
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,
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: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 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 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
* 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,
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/
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
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
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
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_):
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)
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
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
This is a revised version of the patch series posted at
https://gcc.gnu.org/pipermail/gcc-patches/2020-September/553919.html
Patch 8/8 in particular changes rather a lot more than the original
!speed changes. Bootstrapped and regression tested powerpc64le-linux
and powerpc64-linux biarch.
Alan M
This small patch to rs6000_rtx_costs considerably improves code
generated for large constants in 64-bit code, teaching gcc that it is
better to load a constant from memory than to generate a sequence of
up to five dependent instructions. Note that the rs6000 backend does
generate large constants a
When optimizing for size we shouldn't be using metrics based on speed
or vice-versa. rtlanal.c:get_full_rtx_cost wants both speed and size
metric from rs6000_rtx_costs independent of the global optimize_size.
Note that the patch changes param_simultaneous_prefetches,
param_l1_cache_size, param_l1
The aim of this patch is to make rtx_costs for SETs closer to
insn_cost for SETs. One visible effect on powerpc code is increased
if-conversion.
* config/rs6000/rs6000.c (rs6000_rtx_costs): Reduce cost of SET
operands.
diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/r
1 - 100 of 158 matches
Mail list logo
