> 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
>
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
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
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
> 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
> 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
> 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:
> 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
> 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:
> Date: Tue, 26 Sep 2023 01:56:55 +
> From: waffl3x
> Signed-off-by: waffl3x
I think I've read that you have to put your actual name in
the DCO; using an alias (presumably) as above would be
wrong.
Ah, it's on https://gcc.gnu.org/dco.html - the *second* DCO
link; under "Signed-off-by", on
Ok to commit?
-- >8 --
A recent patch made __atomic_test_and_set no longer fall
back to emitting non-atomic code, but instead will then emit
a call to __atomic_test_and_set, thereby exposing the need
to gate also this test on support for atomics, similar to
r14-3980-g62b29347c38394.
libstdc++-v3:
Tested cris-elf, native x86_64-pc-linux-gnu and arm-eabi.
For arm-eabi, notably lacking any atomic support for the
default multilib, with --target_board=arm-sim it regressed
29_atomics/atomic_flag/cons/value_init.cc with the expected
linker failure due to lack of __atomic_test_and_set - which
is
> From: Qing Zhao
> Date: Tue, 19 Sep 2023 14:19:09 +
> > On Sep 17, 2023, at 12:36 PM, Hans-Peter Nilsson via Gcc-patches
> > wrote:
> >> From: Sam James
> >> Date: Sun, 17 Sep 2023 05:00:37 +0100
> >> Did some bug ever get filed for th
> From: Sam James
> Date: Mon, 18 Sep 2023 08:21:45 +0100
> Hans-Peter Nilsson writes:
>
> >> From: Sam James
> >> Date: Sun, 17 Sep 2023 05:00:37 +0100
> >
> >> Hans-Peter Nilsson via Gcc-patches writes:
> >> > The situation was descr
> From: Sam James
> Date: Sun, 17 Sep 2023 05:00:37 +0100
> Hans-Peter Nilsson via Gcc-patches writes:
>
> >> Date: Tue, 29 Aug 2023 15:42:27 -0400
> >> From: Marek Polacek via Gcc-patches
> >
> >> Surely, there must be no ABI impact, the optio
> Date: Tue, 29 Aug 2023 15:42:27 -0400
> From: Marek Polacek via Gcc-patches
> Surely, there must be no ABI impact, the option cannot cause
> severe performance issues,
> Currently, -fhardened enables:
...
> -ftrivial-auto-var-init=zero
> Thoughts?
Regarding -ftrivial-auto-var-init=zero, I
> Date: Thu, 7 Sep 2023 00:11:04 +0100
> From: Jonathan Wakely via Gcc-patches
> On Thu, 7 Sept 2023 at 00:10, Jonathan Wakely wrote:
> > I don't think there's a bug. $is_hosted is true for
> > --enable-hosted-libstdcxx which is on by default.
>
> And IIRC __STDC_HOSTED__ is defined unless you
> From: Jonathan Wakely
> Date: Wed, 6 Sep 2023 23:30:08 +0100
> On Mon, 4 Sept 2023 at 17:49, Jonathan Wakely wrote:
> >
> > On Mon, 4 Sept 2023 at 17:47, Hans-Peter Nilsson via Libstdc++
> > wrote:
> > >
> > > > Date: Fri, 1 Sep 2023
> Date: Fri, 1 Sep 2023 12:16:40 +0100
> Reply-To: Jonathan Wakely
>
> On Wed, 23 Aug 2023 at 17:03, Jonathan Wakely via Libstdc++
> wrote:
> >
> > Any objections to this? It's a C++23 feture, so should be enabled by
> > default.
>
> I've pushed this to trunk, so let's see what breaks!
>
>
>
I was about to enter a PR for the regression, but as you're
already aware, I'll wait 24 hours to see if this magically
goes away. :]
> On Fri, 1 Sept 2023 at 12:16, Jonathan Wakely wrote:
> >
> > On Wed, 23 Aug 2023 at 17:03, Jonathan Wakely via Libstdc++
> > wrote:
> > >
> > > Any objections
oo, which I just changed for
consistency-- but it's close enough for me.)
With this, retesting plugin.exp for cris-elf works.
Ok to commit?
-- >8 --
From: Hans-Peter Nilsson
Date: Fri, 1 Sep 2023 04:36:03 +0200
Subject: [PATCH] testsuite: Fix analyzer_cpython_plugin.c declarations, PR
testsui
oo, which I just changed for
consistency-- but it's close enough for me.)
With this, retesting plugin.exp for cris-elf works.
Ok to commit?
-- >8 --
From: Hans-Peter Nilsson
Date: Fri, 1 Sep 2023 04:36:03 +0200
Subject: [PATCH] testsuite: Fix analyzer_cpython_plugin.c declarations, P
> From: Hans-Peter Nilsson
> Date: Thu, 31 Aug 2023 19:05:19 +0200
> > Date: Thu, 31 Aug 2023 17:25:45 +0200
> > From: Christophe Lyon via Gcc-patches
> > However, this would hide the fact that libstdc++ somehow forces the
> > user to use -Wl,-gc-sections to avoid
> Date: Thu, 31 Aug 2023 17:25:45 +0200
> From: Christophe Lyon via Gcc-patches
> As discussed in PR104167 (comments #8 and below), and PR111238, using
> -Wl,-gc-sections in the libstdc++ testsuite for arm-eabi
> (cross-toolchain) avoids link failures for a few tests:
>
>
On Tue, 29 Aug 2023, Tsukasa OI wrote:
> On 2023/08/29 8:09, Hans-Peter Nilsson wrote:
> > On Mon, 28 Aug 2023, Jeff Law via Gcc-patches wrote:
> >>
> >>
> >> On 8/9/23 00:11, Tsukasa OI via Gcc-patches wrote:
> >>> From: Tsuk
On Mon, 28 Aug 2023, Jeff Law via Gcc-patches wrote:
>
>
> On 8/9/23 00:11, Tsukasa OI via Gcc-patches wrote:
> > From: Tsukasa OI
> >
> > This built-in does not imply the 'Xgnuzihintpausestate' extension.
> > It does not change architectural state (because all HINTs are prohibited
> > from
> Date: Wed, 23 Aug 2023 11:10:02 +0200
> From: Jan Hubicka via Gcc-patches
> Hi,
> this patch adds missing profile update to maybe_optimize_range_tests.
[...]
> Jakub, it seems that the code is originally yours. Any idea why those are
> not turned to
> constant true or false conditionals?
>
Oops, looks like the PR title annotation didn't work and I
forgot the classic changelog annotation.
Anyway, after fixing a testsuite inconsistency, this test
fails for *some* architectures and shows up as a regression;
see the PR.
-- >8 --
* gcc.dg/tree-ssa/update-threading.c: Xfail for
> Date: Thu, 17 Aug 2023 21:32:29 +0100
> From: Jonathan Wakely via Gcc-patches
> Tested x86_64-linux. Pushed to trunk.
Does the below typo imply that for x86_64-linux,
"__DBL_MANT_DIG__ == __LDBL_MANT_DIG__" is false and the
code is actually untested?
> libstdc++-v3/ChangeLog:
>
> *
Re-testing as previously mentioned, reposted freshly for reference.
-- >8 --
While there's another patch that fixes the immediate error
in the PR by other means, the include of tree.h here is
something I prefer to avoid.
PR bootstrap/111021
* config/cris/cris-protos.h: Revert
> From: Hans-Peter Nilsson
> Date: Tue, 15 Aug 2023 06:57:04 +0200
Whoops, of course there was a typo due to
insufficient-last-minute-renaming syndrome. :)
> -#define TARGET_LEGITIMATE_ADDRESS_P cris_legitimate_address_p
> +#define TARGET_LEGITIMATE_ADDRESS_P cris_target_legitima
I'll commit this in a few hours pending testing. It seems
trivial enough to be posted before testing is finished
though, now that it has passed the previous
point-of-breakage. JFTR, I'm testing against the version
with the "first" breaking commit: r14-3092, not r14-3093 the
one with recog.h.
--
> Date: Mon, 14 Aug 2023 16:47:40 +0800
> From: "Kewen.Lin via Gcc-patches"
> on 2023/8/14 15:53, Jan-Benedict Glaw wrote:
> > echo timestamp > s-constrs-h
> > /var/lib/laminar/run/gcc-local/82/local-toolchain-install/bin/g++
> > -std=c++11 -c -g -O2 -DIN_GCC-fno-exceptions -fno-rtti
>
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
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
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:
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
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,
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
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
This is just expected to be a change in representation.
No code is expected to change; no new tests are added.
* config/cris/cris.md (CRIS_UNSPEC_SWAP_BITS): Remove.
("cris_swap_bits", "ctzsi2"): Use bitreverse instead.
---
gcc/config/cris/cris.md | 9 ++---
1 file changed, 2
Committed as obvious after regtest for cris-elf together
with the "next" patch, that replaces unspec
CRIS_UNSPEC_SWAP_BITS with bitreverse (which hit the ICE).
-- >8 --
This seems to have just been overlooked when introducing
BITREVERSE. Note that the function name mem_loc_descriptor
is a
> Date: Mon, 26 Jun 2023 11:57:49 -0700
> From: Thomas Rodgers via Gcc-patches
> On Wed, May 17, 2023 at 12:32 PM Jonathan Wakely wrote:
> > All the actual code changes look good.
Unfortunately, this overwrote the fix for PR108672. I take
it there's a step missing from the synchronization
Left-over from r14-383-gfaf8bea79b6256.
* lib/target-supports.exp (check_effective_target_lra): Remove
cris-*-* from expression for exceptions to LRA.
---
gcc/testsuite/lib/target-supports.exp | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git
Oops. The validation was there, but PATTERN was applied
before that. Noticeable only with rtl-checking (for example
as in the report: "--enable-checking=yes,rtl") as this
statement was only a (one of many) straggling olde-C
declare-and-initialize-at-beginning-of-block thing.
PR
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" "")
> +
Thank you for your consideration. (Or is that phrase only used negatively?)
> From: Jonathan Wakely
> Date: Fri, 9 Jun 2023 21:40:15 +0100
> test01, test02, test03 and test04 should run almost instantly. On my system
> they take about 5 microseconds each. So I don't think splitting those up
>
> From: Mike Stump
> Date: Fri, 9 Jun 2023 10:18:45 -0700
> On Jun 9, 2023, at 9:20 AM, Hans-Peter Nilsson via Gcc-patches
> wrote:
> >
> > The test 27_io/basic_istream/ignore/wchar_t/94749.cc takes
> > about 10 minutes to run for cris-elf in the "gdb
Hi!
The test 27_io/basic_istream/ignore/wchar_t/94749.cc takes
about 10 minutes to run for cris-elf in the "gdb simulator"
here on my arguably way-past-retirement machine (and it
looks like it gained a minute with LRA). I've seen it
timing out every now and then on busy days with load >
`nproc`.
> Date: Wed, 7 Jun 2023 18:06:15 -0400
> From: Jason Merrill via Gcc-patches
> Tested x86_64-pc-linux-gnu, applying to trunk.
>
> -- 8< --
>
> Now that we support NRV from an inner block, we can also support non-NRV
> returns from other blocks, since once the NRV is out of scope a later
> Date: Tue, 6 Jun 2023 16:30:12 +0100
> From: Jonathan Wakely via Gcc-patches
> On Thu, 1 Jun 2023 at 16:59, Jonathan Wakely via Libstdc++ <
> libstd...@gcc.gnu.org> wrote:
>
> > Tested x86_64-linux. I'd appreciate a second set of eyeballs on this
> > before I push it.
> >
>
> Pushed to trunk
Oops. Sorry. Committed as obvious. A bootstrap
--enable-checking=yes,extra,rtl (same as the reporter, but
not the default) with the patch completed, where a bootstrap
without it failed.
-- >8 --
PR bootstrap/110120
* postreload.cc (reload_cse_move2add, move2add_use_add2_insn):
> From: Jonathan Wakely
> Date: Wed, 31 May 2023 21:06:16 +0100
> On Wed, 31 May 2023 at 16:32, Jonathan Wakely wrote:
> > On Wed, 31 May 2023 at 16:29, Hans-Peter Nilsson via Libstdc++ <
> > libstd...@gcc.gnu.org> wrote:
> >
> >> Since I don't see
Since I don't see a quick fix at r14-1444-g3f4853a5f00fab, I
thought I'd better notify the author (I have written authors
if there was more than one ;-) of suspect commits in the
range r14-1425-g80ee7d02e8db48..e1240bda3e0b for the
build-break at r14-1442-ge1240bda3e0bb1 for cris-elf, where
I get:
Tested cris-elf, bootstrapped & checked native
x86_64-pc-linux-gnu for good measure. Ok to commit?
If it wasn't for there already being an auto_inc_dec pass,
this looks like a good place to put it, considering the
framework data. (BTW, current auto-inc-dec generation is so
poor that you can
> From: Hans-Peter Nilsson
> Date: Sat, 13 May 2023 02:56:39 +0200
>
> > From: "Roger Sayle"
> > Date: Fri, 12 May 2023 15:04:03 +0100
>
> > Hi H-P,
> > This patch should now already be on trunk:
> > https://gcc.gnu.org/git/?p=gcc.git;a=co
> From: "Roger Sayle"
> Date: Fri, 12 May 2023 15:04:03 +0100
> Hi H-P,
> This patch should now already be on trunk:
> https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=d8a6945c6ea22efa4d5e42fe1922d2
> b27953c8cd
> Many thanks to Jeff for the review/approval.
> There have been no reported adverse
> From: Hans-Peter Nilsson
> Date: Fri, 12 May 2023 15:53:49 +0200
> Anyway, Roger mentioned that the clobbers emitted by the
> lower-subreg passes were apparently damaging, so I'll try
> this out "for fun", on the assumption that they're actually
> unnecessary. I d
> From: Hans-Peter Nilsson
> Date: Thu, 11 May 2023 17:05:40 +0200
> Next, I'll turn around completely, and try defaulting to
> -fsplit-wide-types-early, which sounds more promising. :)
> I don't like throwing defaults around randomly, but trying
> out a promising ide
> Date: Thu, 11 May 2023 12:15:20 -0600
> From: Jeff Law
> On 5/11/23 10:55, Paul Koning wrote:
> >
> >
> >> On May 11, 2023, at 11:05 AM, Hans-Peter Nilsson via Gcc-patches
> >> wrote:
> >>
> >> ...
> >> Yes, very int
> From: "Roger Sayle"
> Date: Tue, 2 May 2023 00:37:14 +0100
> Jeff Law wrote:
> > This patch converts the xstormy16 patch to LRA. It introduces a code
> > quality regression in the shiftsi testcase, but it also fixes numerous
> > aborts/errors. IMHO it's a good tradeoff.
>
> I've
Typo spotted while doing CCmode improvements, as a missed
optimization. It's almost visible from the patch context;
there's not much done in terms of "mode-adjustment" when
replacing (reg:CC CRIS_CC0_REGNUM) with a copy!
This bug affects functions in the newlib printf-formatting
functions
Unfortunately, doesn't cause a performance improvement for coremark,
but happens a few times in newlib, just enough to affect coremark
0.01% by size (or 4 bytes, and three cycles (__fwalk_sglue and
__vfiprintf_r each two bytes).
gcc:
* config/cris/cris.md (splitop): Add PLUS.
*
While moves of constants into registers are separately
optimizable, a combination of a move with a subsequent "and"
is slightly preferable even if the move can be generated
with the same number (and timing) of insns, as moves of
"just" registers are eliminated now and then in different
passes,
Observed after opsplit1 with AND in libgcc floating-point
functions, like the first spottings of opsplit1/AND
opportunities. Two patterns are nominally needed, as the
peephole2 optimizer continues from the *first replacement*
insn, not from a minimum context for general matching; one
that
This kind of transformation seems pretty generic and might be a
candidate for adding to the middle-end, perhaps as part of combine.
I noticed these happened more often for LRA, which is the reason I
went on this track of low-hanging-fruit-microoptimizations that are
such an itch when noticing
This has no effect on arith-rand-ll (which suffers badly from LRA) and
marginal effects (0.01% improvement) on coremark, but the size of
coremark shrinks by 0.2%. An earlier version was tested with a tree
around 2023-03 which showed (marginally) that ALL_REGS is preferable
to GENERAL_REGS.
Ping again.
> From: Hans-Peter Nilsson
> Date: Thu, 27 Apr 2023 01:55:24 +0200
>
> > From: Hans-Peter Nilsson
> > Date: Wed, 19 Apr 2023 18:59:14 +0200
> [...]
>
> > So again: Approvers: pdf output reviewed. Ok to commit?
> > -- >8 --
>
On previous occasions when a general LRA transition has been
discussed, IIRC, the argument was used, that everything is ready for
targets and their maintainers to make the transition. As I pointed
out then (though more than a year ago last time, people forget) that's
still not true: LRA
> Date: Mon, 1 May 2023 07:21:59 -0600
> From: Jeff Law
> 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
On Fri, 28 Apr 2023, Jeff Law wrote:
> On 4/28/23 16:42, Hans-Peter Nilsson wrote:
> > On Sat, 22 Apr 2023, Ajit Agarwal via Gcc-patches wrote:
> > I don't see anything in those functions that checks if
> > ZERO_EXTEND is actually a feature of the ABI, e.g. as oppose
On Sat, 22 Apr 2023, Ajit Agarwal via Gcc-patches wrote:
> Hello All:
>
> This new version of patch 4 use improve ree pass for rs6000 target using
> defined ABI interfaces.
> Bootstrapped and regtested on power64-linux-gnu.
>
> Thanks & Regards
> Ajit
>
>
> ree: Improve ree pass for
Ok to commit?
-- >8 --
I tried to make use of check-function-bodies for cris-elf and was a
bit surprised to see it failing. There's a deliberate empty line
after the filled delay slot of the return-function which was
mishandled. I thought "aha" and tried to add an empty line
(containing just a
> From: Paul Koning
> Date: Wed, 26 Apr 2023 21:02:31 -0400
> > On Apr 26, 2023, at 8:05 PM, Hans-Peter Nilsson wrote:
> >
> > Not many targets define this besides msp430, pdp1, xtensa,
> > and arm compared to those that appear to unconditionally
> > have a
Not many targets define this besides msp430, pdp1, xtensa,
and arm compared to those that appear to unconditionally
have a hardware division instruction (also, pdp11 and
msp430 seem confused and should be empty instead of "1" and
"(! TARGET_HWMULT)" - and having hardware multiplication
doesn't
> From: Hans-Peter Nilsson
> Date: Wed, 19 Apr 2023 18:59:14 +0200
[...]
> So again: Approvers: pdf output reviewed. Ok to commit?
> -- >8 --
> I was a bit surprised when my newly-added define_peephole2 didn't
> match, but it was because it was expected to partially match t
On Mon, 17 Apr 2023, Richard Biener wrote:
> On Fri, 14 Apr 2023, Hans-Peter Nilsson wrote:
> > If after all, a change to the size of the code and mode
> > bit-fields in rtx_def is necessary, like to still fit 64 bytes
(Sorry: 64 bits, not counting the union u.)
> > such
thing else entirely unexpected. :)
> >Please also see below.
> >
> >On 19 April 2023 18:59:14 CEST, Hans-Peter Nilsson via Gcc-patches
> > wrote:
> >>Anyway, the missing-context problem I ran into remains: if
> >>you have an insn sequence {f
> From: Hans-Peter Nilsson
> Date: Wed, 19 Apr 2023 06:06:27 +0200
>
> Patch retracted, at least temporarily. My "understanding"
> may be clouded by looking at an actual bug. Sigh.
Mea culpa. I was looking at the result of one
define_peephole2 and thinking it was
I'll commit this as obvious, so it doesn't trick anyone else
anymore.
-- >8 --
* recog.cc (peep2_attempt, peep2_update_life): Correct
head-comment description of parameter match_len.
---
gcc/recog.cc | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
> From: Hans-Peter Nilsson
> Date: Wed, 19 Apr 2023 05:15:27 +0200
> Approvers: pdf output reviewed. Ok to commit?
Patch retracted, at least temporarily. My "understanding"
may be clouded by looking at an actual bug. Sigh.
brgds, H-P
> From: Hans-Peter Nilsson
> Date: Tue, 18 Apr 2023 20:44:12 +0200
>
> > From: Paul Koning
>
> > Date: Tue, 18 Apr 2023 14:32:07 -0400
> >
> > I'm not sure about the meaning of part of this.
> > "...resumes at the last generated insn." Do
e words
> to say more explicitly which it is.
I'm referring to an example on the same pdf page.
But perhaps s/resumes at the last generated insn/resumes at
the last insn in the replacement sequence/ would help?
brgds, H-P
>
> paul
>
> > On Apr 18, 2023, at 1:55 PM, Han
Generated pdf inspected. Ok to commit?
Thoughts on fixing the IMHO wart to also expose all
replacements to all define_peephole2? Looks feasible
(famous last words), but then again I haven't checked the
history yet.
-- >8 --
I was a bit surprised when my define_peephole2 didn't match,
but it
> Date: Tue, 18 Apr 2023 07:43:41 -0600
> From: Jeff Law
> On 2/15/23 08:34, Hans-Peter Nilsson via Gcc-patches wrote:
> > Regtested cris-elf with its LEGITIMIZE_RELOAD_ADDRESS
> > disabled, where it regresses gcc.target/cris/rld-legit1.c;
> > as expected, beca
On Thu, 13 Apr 2023, Richard Biener via Gcc-patches wrote:
> On Thu, 13 Apr 2023, Richard Sandiford wrote:
>
> > ??? writes:
> > > Yeah, like kito said.
> > > Turns out the tuple type model in ARM SVE is the optimal solution for RVV.
> > > And we like ARM SVE style implmentation.
> > >
> > >
Committed as obvious. See also the previous discussion
regarding my define_split doc patch.
-- >8 --
The line-break in the example looked odd, even more so with
a page-break in the middle of it, due to recently added text
in preceding pages.
* doc/md.texi (Including Patterns): Fix page
On Tue, 28 Mar 2023, Jiawei wrote:
> + // Zfinx is conflict with float extensions.
> + if (TARGET_ZFINX && TARGET_HARD_FLOAT)
> +error ("z*inx is conflict with float extensions");
> +
While I'm not a native English speaker, "is conflict with"
doesn't sound grammatically correct. Perhaps
> Date: Fri, 31 Mar 2023 15:48:22 -0400
> From: Andrew MacLeod via Gcc-patches
> Reply-To: Andrew MacLeod
> commit 55bf4f0d443e5adbacfcdbbebf4b2e0c74d1dcc8
> Author: Andrew MacLeod
> Date: Fri Mar 31 15:42:43 2023 -0400
>
> Adjust testcases to not produce errors..
>
>
> Attached. I also removed the bogus warning in Walloc-13.c that no longer
> happens
> Add recursive GORI recompuations with a depth limit.
>
> PR tree-optimization/109154
> gcc/
> * gimple-range-gori.cc (gori_compute::may_recompute_p): Add depth
>
On Fri, 24 Mar 2023, Peter Bergner via Gcc-patches wrote:
> On 3/23/23 6:12 PM, Jeff Law via Gcc-patches wrote:
> Is there a reason why REE cannot see that our (reg:QI 4) is a param
> register
> and thus due to our ABI, already correctly sign/zero extended?
> >>>
> >>> I don't
Stepping through a gdb session inspecting costs that cause
gcc.dg/tree-ssa/slsr-13.c to fail, exposed that before this
patch, cris_rtx_costs told that a shift of 1 of a register
costs 5, while adding two registers costs 4.
Making the cost of a quick-immediate constant equal to using
a register
> From: Hans-Peter Nilsson
> Date: Tue, 14 Mar 2023 17:04:43 +0100
Ping #2 on contents (formatting is approved):
> -- >8 --
> I needed to check what was allowed in a define_split, but
> had problems understanding what was meant by "Splitting of
> jump instructi
This patch has no effect on builds using reload of libgcc, newlib libc, my
own at-a-glance-testsuite and coremark. That somewhat surprisingly
also goes for LRA builds, even with all CRIS reload_in_progress
augmented to include lra_in_progress. I just noticed it when checking
because another port
The test-case gcc.target/cris/rld-legit1.c is a reduced
test-case that required defining LEGITIMIZE_RELOAD_ADDRESS
to stop the address from being decomposed into several insns
by reload. Valid but suboptimal code was generated.
(Before implementing that hook for CRIS, the same test-case
also
This patch affects a post-reload define_split for CRIS that transforms
a condition-code-clobbering addition into a non-clobbering addition.
(A "two-operand" addition between registers is the only insn that has
both a condition-code-clobbering and a non-clobbering variant for
CRIS.) Many more
gcc:
* config/cris/constraints.md ("R"): Remove unused constraint.
---
gcc/config/cris/constraints.md | 10 --
1 file changed, 10 deletions(-)
diff --git a/gcc/config/cris/constraints.md b/gcc/config/cris/constraints.md
index 05a1d24ef5a1..5efb61364f46 100644
---
Tested native x86_64-linux and cris-elf. The "recent patch
to gcc.dg/tree-ssa/pr100359.c" refers to r13-6838.
Committed as obvious after that commit.
-- >8 --
The test gcc.dg/tree-ssa/ssa-fre-100.c fails the
scan-tree-dump-not fre1 "baz" for at least m68k-linux,
pru-elf, and cris-elf according to
(CC to respectively author and committer of pr100359.c.)
Tested cris-elf and native x86_64-linux: the two
scan-tree-dumps pass and x86_64-linux still links. Ok to
commit?
-- >8 --
The test gcc.dg/tree-ssa/pr100359.c fails the "test for
excess errors" for at least m68k-linux, pru-elf, and
> From: Hans-Peter Nilsson
> CC: ,
> Date: Tue, 14 Mar 2023 17:04:43 +0100
Ping on contents (formatting is approved):
> I needed to check what was allowed in a define_split, but
> had problems understanding what was meant by "Splitting of
> jump instruction into sequen
101 - 200 of 1367 matches
Mail list logo
