> From: Christophe Lyon
> Date: Tue, 3 Oct 2023 15:20:39 +0200
> The patch passed almost all our CI configurations, except arm-eabi when
> testing with
> -mthumb/-march=armv6s-m/-mtune=cortex-m0/-mfloat-abi=soft/-mfpu=auto
> where is causes these failures:
> FAIL: 29_atomics/atomic_flag/clear/1.
> From: Christophe Lyon
> Date: Tue, 3 Oct 2023 15:20:39 +0200
> Maybe we need a new variant of dg-require-thread-fence ?
Yes: many of the dg-require-thread-fence users need
something stronger. Tested arm-eabi together with the next
patch (2/2) with
RUNTESTFLAGS=--target_board=arm-sim/-mthumb/-
> From: Christophe Lyon
> Date: Tue, 3 Oct 2023 15:20:39 +0200
> The patch passed almost all our CI configurations, except arm-eabi when
> testing with
> -mthumb/-march=armv6s-m/-mtune=cortex-m0/-mfloat-abi=soft/-mfpu=auto
> where is causes these failures:
> FAIL: 29_atomics/atomic_flag/clear/1.
> From: Jonathan Wakely
> Date: Wed, 4 Oct 2023 09:29:43 +0100
> The new dg-require proc checks for __atomic_exchange, which is not the
> same as compare-exchange, and not the same as test-and-set on
> atomic_flag. Does it just happen to be true for arm that the presence
> of __atomic_exchange al
> From: Hans-Peter Nilsson
> Date: Wed, 4 Oct 2023 17:15:28 +0200
> New version coming up.
Using pointer-sized int instead of int,
__atomic_compare_exchange instead of __atomic_exchange,
renamed to atomic-cmpxchg-word from atomic-exchange, and
updating a comment that already seemed r
s/atomic-exchange/atomic-cmpxchg-word/g.
Tested as v1.
Ok to commit?
-- >8 --
These tests actually use a form of atomic compare and exchange
operation, not just atomic loading and storing. Some targets (not
supported by e.g. libatomic) have atomic loading and storing, but not
compare and exchange
Ping.
> From: Hans-Peter Nilsson
> Date: Wed, 4 Oct 2023 19:04:55 +0200
>
> > From: Hans-Peter Nilsson
> > Date: Wed, 4 Oct 2023 17:15:28 +0200
>
> > New version coming up.
>
> Using pointer-sized int instead of int,
> __atomic_compare_exchange ins
Ping.
> From: Hans-Peter Nilsson
> Date: Wed, 4 Oct 2023 19:08:16 +0200
>
> s/atomic-exchange/atomic-cmpxchg-word/g.
> Tested as v1.
>
> Ok to commit?
> -- >8 --
> These tests actually use a form of atomic compare and exchange
> operation, not just atomic l
> From: Vineet Gupta
> Date: Thu, 28 Sep 2023 14:43:41 -0700
Please forgive my daftness, but...
> ```
> foo2:
> sext.w a6,a1 <-- this goes away
> beq a1,zero,.L4
> li a5,0
> li a0,0
> .L3:
> addwa4,a2,a5
> addwa5,a3,a5
>
> Date: Fri, 29 Sep 2023 16:37:21 -0600
> From: Jeff Law
> So this ends up looking a lot like the bits that I had to revert several
> weeks ago :-)
>
> The core issue we have is given an INSN the generic code will cost the
> SET_SRC and SET_DEST and sum them. But that's far from ideal on a RI
On Thu, 23 Jun 2022, Alexandre Oliva via Gcc-patches wrote:
> +proc check_effective_target_two_plus_gigs { } {
> +return [check_no_compiler_messages two_plus_gigs executable {
> + int dummy[0x8000];
Don't you mean "char" as in "char dummy[0x8000]"?
Or else the effective predicate
On Mon, 27 Jun 2022, Xi Ruoyao via Gcc-patches wrote:
> egrep has been deprecated in favor of grep -E for a long time, and the
> next GNU grep release (3.8 or 4.0) will print a warning if egrep is used.
> Unfortunately, old hosts with non-GNU grep may lack the support for -E
> option. Use AC_PROG_
On Fri, 1 Jul 2022, Dimitrije Milosevic wrote:
> Fix kernel_stat structure size for non-Android 32-bit Mips.
> LLVM currently has this value for the kernel_stat structure size,
> as per compiler-rt/lib/sanitizer-common/sanitizer_platform_limits_posix.h.
> This also resolves one of the build issues
On Sat, 9 Jul 2022, Xi Ruoyao wrote:
> On Fri, 2022-07-08 at 21:42 -0400, Hans-Peter Nilsson wrote:
> > On Fri, 1 Jul 2022, Dimitrije Milosevic wrote:
> >
> > > Fix kernel_stat structure size for non-Android 32-bit Mips.
> > > LLVM currently has this value f
this change, I'm not sure what should be done?
> Should this be committed now, while the LLVM change is cherry-picked once
> it's committed.
> Best regards,
> Dimitrije Milosevic
>
>
> From: Hans-Peter Nilsson
> Sent: Saturday, July 9, 2022 4:44 PM
> To: Xi Ruo
On Mon, 1 May 2023, Jeff Law wrote:
>
> Spurred by Segher's RFC, I went ahead and tested several ports with LRA
> enabled. Not surprisingly, many failed, but a few built their full set of
> libraries successful and of those a few even ran their testsuites with no
> regressions. In fact, enablin
Since the change r14-383-gfaf8bea79b6256 "Enable LRA on
several ports", mmix has been broken building libstdc++-v3:
libtool: compile: /obj/./gcc/xgcc -shared-libgcc -B/obj/./gcc
-nostdinc++ -L/obj/mmix/libstdc++-v3/src
-L/obj/mmix/libstdc++-v3/src/.libs
-L/obj/mmix/libstdc++-v3/libsupc++/.libs -no
When LRA is in progress, it can try and validate insns
half-way through frame-pointer (FP) to stack-pointer (SP)
elimination. Operands have then been substituted where the
offset is from the SP elimination but the register is the
(hard) frame-pointer:
lra-eliminations.cc:lra_eliminate_regs_1:370:
After fixing the one problem for MMIX, there's just one
test-case regressing between reload and LRA.
-- 8< --
* config/mmix/mmix.cc: Re-enable LRA.
---
gcc/config/mmix/mmix.cc | 3 ---
1 file changed, 3 deletions(-)
diff --git a/gcc/config/mmix/mmix.cc b/gcc/config/mmix/mmix.cc
index 51
This is just a mechanical update.
It fixes no observed problems for LRA.
* config/mmix/predicates.md (mmix_address_operand): Use
lra_in_progress, not reload_in_progress.
---
gcc/config/mmix/predicates.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/confi
On Tue, 30 May 2023, HAO CHEN GUI via Gcc-patches wrote:
> +++ b/gcc/config/rs6000/rs6000.md
> @@ -7891,6 +7891,36 @@ (define_insn "*mov_internal2"
> (set_attr "dot" "yes")
> (set_attr "length" "4,4,8")])
>
> +(define_peephole2
> + [(set (match_operand:CC 2 "cc_reg_operand" "")
> + (
On Thu, 15 Jun 2023, Manolis Tsamis wrote:
> This is a new RTL pass that tries to optimize memory offset calculations
> by moving them from add immediate instructions to the memory loads/stores.
> For example it can transform this:
>
> addi t4,sp,16
> add t2,a6,t4
> shl t3,t2,1
> ld a
On Sun, 9 Jul 2023, Hans-Peter Nilsson wrote:
> On Thu, 15 Jun 2023, Manolis Tsamis wrote:
>
> > This is a new RTL pass that tries to optimize memory offset calculations
> > by moving them from add immediate instructions to the memory loads/stores.
> It punts on all "u
> From: Thomas Schwinge
> Date: Thu, 19 Oct 2023 12:42:26 +0200
> It's just GCC and Binutils/GDB, or are the top-level files also shared
> with additional projects?
Not sure if that counts as "shared", but I regularly drop
in* newlib to build simulator targets (*-elf, *-newabi).
That's git://sou
> From: Richard Sandiford
> Date: Tue, 24 Oct 2023 11:14:20 +0100
> reload and constrain_operands had some old code to look through unary
> operators. E.g. an operand could be (sign_extend (reg X)), and the
> constraints would match the reg rather than the sign_extend.
>
> This was previously u
On Fri, 24 Feb 2023, Christoph Muellner wrote:
> diff --git a/gcc/config/riscv/thead.md b/gcc/config/riscv/thead.md
> index 158e9124c3a..2c684885850 100644
> --- a/gcc/config/riscv/thead.md
> +++ b/gcc/config/riscv/thead.md
> @@ -29,3 +29,14 @@ (define_insn "*th_addsl"
>"th.addsl\t%0,%3,%1,%2"
On Sun, 26 Feb 2023, Jonathan Yong via Gcc-patches wrote:
> Patch OK for master branch? I did not see any obvious issues to exclude LLP64
> specifically.
I see "lp64 || lp64" in that patch (which should preferably have
been sent inline, as it's harder to quote an attached patch,
QED). Sending
On Mon, 27 Feb 2023, Jonathan Yong via Gcc-patches wrote:
> This test is for LP64 only, exclude LLP64 too.
> Patch OK?
I may be confused, but you're not making use of the "llp64"
effective target, there instead excluding/including lp64 /
ilp32 in sets that not obviously mean "exclude LLP64".
On Tue, 28 Feb 2023, Jonathan Yong wrote:
> On 2/28/23 03:06, Hans-Peter Nilsson wrote:
> >
> > On Mon, 27 Feb 2023, Jonathan Yong via Gcc-patches wrote:
> >
> > > This test is for LP64 only, exclude LLP64 too.
> > > Patch OK?
> >
> > I may b
On Tue, 28 Feb 2023, Christoph Müllner wrote:
> On Sun, Feb 26, 2023 at 12:42 AM Hans-Peter Nilsson wrote:
> >
> > On Fri, 24 Feb 2023, Christoph Muellner wrote:
> > > diff --git a/gcc/config/riscv/thead.md b/gcc/config/riscv/thead.md
> > > index 158e9124c3
On Fri, 26 Feb 2021, Thiago Macieira via Gcc-patches wrote:
> ints can be used in futexes. chars can't.
Shouldn't that be an atomic type instead of a bare int then?
> ---
> libstdc++-v3/include/std/barrier | 21 -
> 1 file changed, 12 insertions(+), 9 deletions(-)
>
> diff --
On Fri, 26 Feb 2021, Thiago Macieira via Gcc-patches wrote:
> On Friday, 26 February 2021 11:31:00 PST Andreas Schwab wrote:
> > On Feb 26 2021, Thiago Macieira wrote:
> > > On Friday, 26 February 2021 10:14:42 PST Andreas Schwab wrote:
> > >> On Feb 26 2021, Thiago Macieira via Gcc-patches wro
On Wed, 3 Mar 2021, Jonathan Wakely wrote:
> For int, there shouldn't be any need to force the alignment. I don't
> think any ABI supported by GCC allows int members to be aligned to
> less than __alignof__(int).
(sizeof(int) last)
The CRIS ABI does as in default packed, and ISTR there was some
o
A simulator can easily spend more than 10 minutes running this
test-case, and the default timeout is at 5 minutes. Better allow
even slower machines; use 4 as the factor.
Regarding relative runtime numbers (very local; mmixware simulator for
mmix-knuth-mmixware): test01 and test05 finish momentari
On Thu, 24 Sep 2020, Tom de Vries wrote:
> Hi,
>
> With the nvptx target, we run into:
> ...
> FAIL: gcc.dg/pr94600-1.c scan-rtl-dump-times final "\\(mem/v" 6
> FAIL: gcc.dg/pr94600-1.c scan-rtl-dump-times final "\\(set \\(mem/v" 6
> FAIL: gcc.dg/pr94600-3.c scan-rtl-dump-times final "\\(mem/v" 1
On Wed, 30 Sep 2020, Tom de Vries wrote:
> [ was: Re: [committed][testsuite] Require non_strict_align in
> pr94600-{1,3}.c ]
>
> On 9/30/20 4:53 AM, Hans-Peter Nilsson wrote:
> > On Thu, 24 Sep 2020, Tom de Vries wrote:
> >
> >> Hi,
> >>
> >> Wit
On Thu, 1 Oct 2020, Tom de Vries wrote:
> [ was: Re: [committed][testsuite] Re-enable pr94600-{1,3}.c tests for arm ]
>
> On 10/1/20 7:38 AM, Hans-Peter Nilsson wrote:
> > On Wed, 30 Sep 2020, Tom de Vries wrote:
> >> I've analyzed the compilation on strict-a
Please excuse a comment from the gallery:
On Mon, 28 Sep 2020, will schmidt via Gcc-patches wrote:
> On Fri, 2020-09-04 at 12:52 -0300, Raoni Fassina Firmino via Gcc-patches
> wrote:
> > 2020-08-13 Raoni Fassina Firmino
> >
> > gcc/ChangeLog:
> > * config/rs6000/rs6000.md (fegetroundsi):
On Thu, 3 Feb 2022, David Seifert via Gcc-patches wrote:
> On Thu, 2022-02-03 at 12:50 +0100, Jakub Jelinek wrote:
> > On Thu, Feb 03, 2022 at 12:30:11PM +0100, David Seifert wrote:
> > > * `-Werror` can cause issues when a more recent version of GCC
> > > compiles
> > > ? an older version:
> > >
On Fri, 11 Feb 2022, Jonathan Wakely via Gcc-patches wrote:
> diff --git
> a/libstdc++-v3/testsuite/20_util/unsynchronized_pool_resource/allocate.cc
> b/libstdc++-v3/testsuite/20_util/unsynchronized_pool_resource/allocate.cc
> index c81344a20e4..25e5ce63b58 100644
> --- a/libstdc++-v3/testsuite/2
On Wed, 12 Oct 2022, Jørgen Kvalsvik via Gcc-patches wrote:
> This patch adds support in gcc+gcov for modified condition/decision
> coverage (MC/DC) with the -fprofile-conditions flag.
I'd love improvements in this area.
But this is a serious concern:
> gcov --conditions:
>
> 3: 17:vo
On Sat, 13 Aug 2022, mtsamis wrote:
> When using SWAR (SIMD in a register) techniques a comparison operation within
*within
> such a register can be made by using a combination of shifts, bitwise and and
> multiplication. If code using this scheme is vectorized then there is
> potential
> to rep
On Mon, 15 Aug 2022, Xi Ruoyao via Gcc-patches wrote:
> Can we make a final solution to this soon? Now the merge window of
> Linux 6.0 is closed and we have two Linux kernel releases not possible
> to be built with Binutils or GCC with new relocation types. This is
> just ugly...
>
> On Fri, 202
> From: Gerald Pfeifer
> Date: Sun, 10 Nov 2019 14:53:23 +0100
> Hi H-P,
>
> it appears this download is gone. Do you have an alternate location?
Wha...? No, not at the moment.
>http://ftp.axis.se/pub/users/hp/pgccfd/";>
While I could certainly enter a ticket and hope to get it
reinstate
On Thu, 7 Nov 2019, Egeyar Bagcioglu wrote:
> On 11/7/19 8:47 AM, Segher Boessenkool wrote:
> > On Wed, Nov 06, 2019 at 06:21:33PM +0100, Egeyar Bagcioglu wrote:
> > > +proc dg-require-target-object-format { args } {
> > > +if { [gcc_target_object_format] == [lindex $args 1] } {
> > > + return
On Tue, 3 Nov 2020, Nathan Sidwell wrote:
> Here is the implementation of C++20 modules that I have been developing on the
> devel/c++-modules branch over the last few years.
Ow.
> I have bootstrapped and tested on:
> x86_64-linux
> aarch64-linux
> powerpc8le-linux
> powerpc8-aix
>
> Iain Sandoe
On Wed, 4 Nov 2020, Jozef Lawrynowicz wrote:
> I personally do not see the problem with the .retain attribute, however
> if it is going to be a barrier to getting the functionality committed, I
> am happy to change it, since I really just want the functionality in
> upstream sources.
>
> If a globa
On Wed, 4 Nov 2020, H.J. Lu wrote:
> On Wed, Nov 4, 2020 at 10:09 AM Hans-Peter Nilsson wrote:
> >
> > On Wed, 4 Nov 2020, Jozef Lawrynowicz wrote:
> > > I personally do not see the problem with the .retain attribute, however
> > > if it is going to be a bar
On Wed, 4 Nov 2020, H.J. Lu wrote:
> On Wed, Nov 4, 2020 at 1:03 PM Hans-Peter Nilsson wrote:
> >
> > On Wed, 4 Nov 2020, H.J. Lu wrote:
> > > On Wed, Nov 4, 2020 at 10:09 AM Hans-Peter Nilsson
> > > wrote:
> > > >
> > > > On Wed, 4
On Wed, 4 Nov 2020, H.J. Lu wrote:
> On Wed, Nov 4, 2020 at 1:56 PM Hans-Peter Nilsson wrote:
> > On Wed, 4 Nov 2020, H.J. Lu wrote:
> >
> > > On Wed, Nov 4, 2020 at 1:03 PM Hans-Peter Nilsson
> > > wrote:
> > > >
> > > > On Wed, 4 Nov 20
On Wed, 4 Nov 2020, H.J. Lu wrote:
> .retain is ill-defined. For example,
>
> [hjl@gnu-cfl-2 gcc]$ cat /tmp/x.c
> static int xyzzy __attribute__((__used__));
> [hjl@gnu-cfl-2 gcc]$ ./xgcc -B./ -S /tmp/x.c -fcommon
> [hjl@gnu-cfl-2 gcc]$ cat x.s
> .file "x.c"
> .text
> .retain xyzzy < Wha
On Sun, 15 Nov 2020, Maciej W. Rozycki wrote:
> Hi,
>
> In the course of my recent VAX backend modernisation effort
Hi. That reminds me that VAX is "still" a cc0 target.
Are you aware of anyone planning on that level of modernization?
More than a year ago, there was a major heads-up that all
On Fri, 13 Nov 2020, H.J. Lu via Gcc-patches wrote:
> Done. Here is the updated patch.
Hi. I see a test-case for this kind of construct:
int foo __attribute__((__used__, __section__ (".bar"))) = 42;
and IIUC that it's handled as I'd hope (setting "R" on the named
section, not another derived
100644
--- a/contrib/ChangeLog
+++ b/contrib/ChangeLog
@@ -1,3 +1,8 @@
+2020-01-17 Hans-Peter Nilsson
+
+ * gcc_update : Use git log "--pretty=tformat:%p:%t:%H",
+ not "--pretty=%p:%t:%H".
+
2020-01-16 Andreas Schwab
* gcc-git-customization.sh: Avoi
testsuite:
* lib/target-supports.exp (effective_target_march_option): New.
I see no (other) way to, depending on the absence of an option,
add an option for a specific target. Specifically, I don't see
how to do this with dg-skip-if and its friends.
For gcc.dg/torture/pr26515.c and cris-
changed, 6 insertions(+)
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 423899d3988..b4c45a45087 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,7 @@
+2020-01-17 Hans-Peter Nilsson
+
+ * config.gcc : Add crisv32-*-* and cris-*-linux*
+
2020-01-17 Richard Sandiford
libgcc:
* config/cris/arit.c (DS): Apply attribute __fallthrough__.
Without this, there are, for each compilation of arit.c, 30ish
occurrences of "this statement may fall through
[-Wimplicit-fallthrough=]", for lines that look like
case 32: DS; case 31: DS; case 30: DS; case 29: DS;
N
With march_option in place, here's the rest. (And yes, that
cris-linux line in the last context goes away in the patchset
putting that target down.)
gcc/testsuite:
* gcc.dg/torture/pr26515.c (cris*-*-*): Conditionalize
-march=v10 option on target ! march_option.
* gcc.targ
> From: "Richard Earnshaw (lists)"
> Date: Fri, 17 Jan 2020 12:21:07 +0100
> As far as possible, I've made the script automatically restructure any
> existing fetch or push lines that earlier versions of the scripts may
> have created - the gcc-git-customization.sh script will convert all
> ve
> From: Hans-Peter Nilsson
> Date: Tue, 21 Jan 2020 02:47:57 +0100
> (I did not use gcc-git-customization.sh or git-fetch-vendor.sh before
> XX, so there's presumably nothing to clean up.)
Bah; "before 24b178184f260a6ec1516cfb8bb8876874a078a7".
brgds, H-P
gcc/testsuite:
* gcc.target/cris/asm-v8.S, gcc.target/cris/inasm-v8.c,
gcc.target/cris/sync-1.c: Apply effective_target_march_option.
Oops. A few stragglers, same as recent update: differing
-march=... options is an error, noticed with e.g.
"make check RUNTESTFLAGS=--target_board=
> From: "Richard Earnshaw (lists)"
> Date: Tue, 21 Jan 2020 14:36:32 +0100
> Correction, the branch should be named /, so the push
> should be
>
> git push vendors/ /
>
> For example, for the ARM vendor, the push would be
>
> git push vendors/ARM ARM/
>
> R.
>
> > will work as expected.
> >
This patchset is applied to vendors/axis/cris-decc0.
The intent is to apply it myself to master, once master opens
for stage 1, before the planned destruction of cc0 targets that
was announced last September. I've earlier obsoleted the
crisv32-* and cris-*-linux* sub-ports as no longer relevant (
gcc:
* config.gcc: Remove support for crisv32-*-* and cris-*-linux*.
Or really, move from the obsolete targets section, to
unsupported targets section, and remove crisv32-*-* and
cris-*-linux* from the rest.
---
gcc/config.gcc | 28 ++--
1 file changed, 2 insertions(+), 26
..000
--- a/gcc/config/cris/linux.h
+++ /dev/null
@@ -1,150 +0,0 @@
-/* Definitions for GCC. Part of the machine description for CRIS.
- Copyright (C) 2001-2020 Free Software Foundation, Inc.
- Contributed by Axis Communications. Written by Hans-Peter Nilsson.
-
-This file is part of GCC
libgcc:
* config.host: Remove support for crisv32-*-* and cris*-*-linux.
* config/cris/libgcc-glibc.ver, config/cris/t-linux: Remove.
Part of the removal of crisv32-* and cris-*-linux* (cris-elf remains).
---
libgcc/config.host | 9 -
libgcc/config/cris/libgcc-glibc.ver |
;\\\.ifnc \\\$r9-\\\$r10-\\\$r11-\\\$r12" } } */
/* Sanity check for asm register operands in syscall failed for
- cris-axis-linux-gnu due to regmove bug.
+ cris-axis-linux-gnu due to a regmove bug.
Hans-Peter Nilsson . */
extern void lseek64 (int, long long, int);
diff --git a/gcc/testsu
468..4ac2ee45fbf 100644
--- a/gcc/testsuite/gcc.dg/sibcall-10.c
+++ b/gcc/testsuite/gcc.dg/sibcall-10.c
@@ -5,7 +5,7 @@
Copyright (C) 2002 Free Software Foundation Inc.
Contributed by Hans-Peter Nilsson*/
-/* { dg-do run { xfail { { amdgcn*-*-* cris-*-* crisv32-*-* csky-*-* h8300-*-*
hpp
gcc:
* config/cris/t-elfmulti: Remove crisv32 multilib.
Part of the removal of crisv32-* and cris-*-linux* (cris-elf remains).
---
gcc/config/cris/t-elfmulti | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/gcc/config/cris/t-elfmulti b/gcc/config/cris/t-elfmulti
index 3c
gcc:
* config/cris: Remove shared-library and CRIS v32 support.
Part of the removal of crisv32-* and cris-*-linux* (cris-elf remains).
Essentially everything is gone, including functions and
target-specific definitions and most obvious knock-on effects,
like removing unused functions and argument
PR target/93372
* gcc.target/cris/sync-2s.c, gcc.target/cris/sync-2i.c: XFAIL.
Unfortunately, some assembly-code-matches have to be xfailed
until the port is improved to use other than straight
compare-insns.
---
gcc/testsuite/gcc.target/cris/sync-2i.c | 5 +++--
gcc/testsuite/gcc.target/cris/syn
gcc:
* target.def (flags_regnum): Also mention effect on delay slot filling.
* doc/tm.texi: Regenerate.
Noticed the "hard way" dealing with performance fallout for the
CRIS decc0ration.
Previously, the documentation blurb only mentioned an effect on
compare elimination. The technical contents is
Compared to the cc0 version, I noticed a regression in
delay-slot-filling for CRIS for several functions in libgcc with
a similar layout, one being lshrdi3, where with cc0 all
delay-slots were filled, as exposed by the test-case. I ended
up including the thankfully-small lshrdi3 as-is, for simplic
> From: Jeff Law
> Date: Fri, 20 Sep 2019 17:38:38 +0200
Hi. I'm not going to question
> The first step in that process is to drop support for cc0.
but could you please elaborate on...
> [cc0 support in gcc core]
> code is broken in various ways,
> particularly WRT exceptions.
...that last
> From: Segher Boessenkool
> Date: Mon, 27 Jan 2020 23:52:21 +0100
> Hi!
>
> On Wed, Jan 22, 2020 at 07:11:27AM +0100, Hans-Peter Nilsson wrote:
> > I intend to put back as many as I find use for, of those
> > anonymous patterns in a controlled manner, with self-conta
Committed as obvious.
gcc:
* md.texi (Define Subst): Match closing paren in example.
diff --git a/gcc/doc/md.texi b/gcc/doc/md.texi
index cec74ea78..66c5eea3b 100644
--- a/gcc/doc/md.texi
+++ b/gcc/doc/md.texi
@@ -10545,7 +10545,7 @@ generated with the following @code{define_subst}:
""
Stuff I broke out from the CRIS decc0ration work;
compare-decanonicalization and tests that would be regressions
in a future timeline, but fixed later on.
Besides the first patch, nothing you'd normally care about, and
perhaps for people doing CC0 work: the test-cases and the cc0
effective-target
* config/cris/cris.c (cris_reduce_compare): New function.
* config/cris/cris-protos.h (cris_reduce_compare): Add prototype.
* config/cris/cris.md ("cbranch4", "cbranchdi4", "cstoredi4")
(cstore4"): Apply cris_reduce_compare in expanders.
The decc0ration work of the CRIS port made me look closer a
To simplify separating the cc0-specific xfails, let's have an
effective-target.
This likely fits all targets.
---
gcc/testsuite/gcc.target/cris/cris.exp | 11 +++
1 file changed, 11 insertions(+)
diff --git a/gcc/testsuite/gcc.target/cris/cris.exp
b/gcc/testsuite/gcc.target/cris/cris.ex
This test was separated from the posted and approved patch named
"dbr: Filter-out TARGET_FLAGS_REGNUM from end_of_function_needs"
and applied: it doesn't fail yet. It differs from the posted
version in that function "g" is commented-out; see the added
comment.
---
gcc/testsuite/gcc.target/cris/pr
* gcc.target/cris/pr93372-2.c, gcc.target/cris/pr93372-5.c,
gcc.target/cris/pr93372-8.c: New tests.
These tests fails miserably both at being an example of cc0
eliminating compare instructions, and post-cc0-CRIS at showing a
significant improvement. They're here to track suboptimal
comparison cod
PR target/93372
* gcc.target/cris/pr93372-3.c, gcc.target/cris/pr93372-4.c,
gcc.target/cris/pr93372-6.c, gcc.target/cris/pr93372-7.c,
gcc.target/cris/pr93372-9.c, gcc.target/cris/pr93372-10.c,
gcc.target/cris/pr93372-11.c, gcc.target/cris/pr93372-12.c,
gcc.target/cris/pr93372-13.c, gcc.target/cris/
Random spotting. Exposes the missed benefit for delay-slot
filling of a splitter for indexed addressing mode (the [rN+M]
one). To be considered for common instructions and perhaps only
for suitable M; at least +-63 is obious (when there's a register
available) as both the original and the add fit
I was using ira-conflicts.c:print_hard_reg_set with a local
patch to gdbinit.in in a debug-session, and noticed the
erroneous output. I see there's an almost identical function in
ira-color.c and on top of that, there's another function by the
same name and with similar semantics in sel-sched-dump
I just rebased and updated the vendors/axis branch
axis/cris-decc0 with the following commits, which should bring
back compare-elimination results to that of cc0 on master.
With the exception of the bit-test patterns (btst / btstq which
is more of a "combine" matter), everything is centered around
PR target/93372
* config/cris/cris.md (zcond): New code_iterator.
("*cbranch4_btstq"): New insn_and_split.
As the added FIXME says, the new insn_and_split generates only a
small subset of the bit-tests that can be matched by "*btst" and
that were emitted by the undecc0rated cris.md at combine-time
* config/cris/cris.c (TARGET_FLAGS_REGNUM): Define.
This made a whole lot of difference regarding regressions in the
delay-slot filling. Before this, comparing __lshrdi3 for v10
before/after decc0ration and other nearby functions was worse by
several missing delay-slot fills; now down to 1.
Also
* config/cris/cris.h (REVERSIBLE_CC_MODE): Define to true.
For some reason (like a buglet in the user in jump.c), defining this makes
a beneficial difference in ledf2, thus this is separated to its own commit.
Also, add comment on (not defining) REVERSE_CONDITION.
---
gcc/config/cris/cris.h | 3 +
* config/cris/cris.md ("movsi"): For memory destination
post-reload, generate clobberless variant.
("*mov_tomem_split"): New split.
("*mov_tomem"): New insn.
("enabled", mov_tomem_enabled): Define and use to exclude "x" ->
"Q>m" for less-than-SImode.
In preparation for compare-elimination (for it
* config/cris/cris.md ("movsi"): For a zero-source post-reload,
generate a clobberless variant.
("*mov_fromzero_split"): New split.
("*mov_fromzero"): New insn.
A separated follow-up to the previous change: Also emit moves
from zero as not clobbering condition-codes.
---
gcc/config/cris/cris.md |
Prepare for cmpelim pass to eliminate redundant compare insns.
* config/cris/cris-modes.def: New file.
* config/cris/cris-protos.h (cris_select_cc_mode): Declare.
(cris_notice_update_cc): Remove left-over declaration.
* config/cris/cris.c (TARGET_CC_MODES_COMPATIBLE): Define.
(cris_select_cc_mode,
* config/cris/cris.md ("cc"): Comment on new use.
("cc_enabled"): New attribute.
("enabled"): Make default fall back to cc_enabled.
("setnz", "ccnz", "setnzvc", "ccnzvc", "setcc", ""): New
default_subst_attrs.
("setnz_subst", "setnzvc_subst", "setcc_subst"): New default_subst.
("*movsi_internal
* config/cris/cris.md ("anz", "anzvc", "acc"): New define_subst_attrs.
("movhi"): Rename from
"movhi". Rename "cc" attribute to "cc".
("movqi"): Similar from
"movqi". Correct contents of, and rename "cc" attribute to
"cc".
("*b"): Rename from "b".
("*b"): Rename from "b".
("*b"): Rename from "*b"
* config/cris/cris.md
("extendsi2"):
Rename from "extendsi2".
("zero_extendsi2"):
Similar, from "zero_extendsi2".
Enable dropping of compares with zero of the result, through the
three CCmode substitutions and the cmpelim pass.
---
gcc/config/cris/cris.md | 4 ++--
1 file changed, 2 insertions(+)
* config/cris/cris.md ("*adddi3"): Rename from "*adddi3".
cris: Enable 32-bit addition to set condition codes.
("*subdi3"): Similarly from "*subdi3".
("*addsi3"): Similarly from "*addsi3".
("*subsi3"): Similarly from "*subsi3".
("*addhi3"): Similarly from "*addhi3" and decorate the
"cc" attribute t
* config/cris/cris.md
("si3"):
Rename from "si3".
("clzsi2"):
Rename from "clzsi2".
("bswapsi2"):
Rename from "bswapsi2".
("*uminsi3"): Rename from "*uminsi3".
Enables dropping of compares with zero of the result, through
any CCmode substitution.
---
gcc/config/cris/cris.md | 8
1 file c
* config/cris/cris.md ("*expanded_andsi"):
Rename from "*expanded_andsi".
("*iorsi3"): Similar from "*iorsi3".
Decorate "cc" attribute to make "cc".
("*iorhi3"): Similar from "*iorhi3".
("*iorqi3"): Similar from "*iorqi3".
("*expanded_andhi"): Similar from
"*expanded_andhi". Add quick cc-setting a
* config/cris/cris-modes.def (CC_ZnN): New CC_MODE.
* config/cris/cris.c (cris_rtx_costs): Handle pre-split bit-test
* config/cris/cris.md (ZnNNZSET, ZnNNZUSE): New mode_iterators.
(znnCC, rznnCC): New code_attrs.
("*btst"): Iterator over ZnNNZSET instead of NZVCSET. Remove
obseolete comment. Add
* config/cris/cris.c (cris_select_cc_mode): Return CC_NZmode for
NEG too. Correct comment.
* config/cris/cris.md ("neg2"): Rename from
"neg2".
While gcc seems to prefer transforming tests on the result of
reversible operations, into tests on the original, it also can
work with the destination, if
On Tue, 11 Feb 2020, Richard Biener wrote:
> Bootstrapped / tested on x86_64-unknown-linux-gnu, pushed.
> diff --git a/gcc/testsuite/gcc.dg/pr93661.c b/gcc/testsuite/gcc.dg/pr93661.c
> new file mode 100644
> index 000..e311ba545c4
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/pr93661.c
> @@
1 - 100 of 1204 matches
Mail list logo
