https://gcc.gnu.org/g:c68bd7e8023f65d1dc23237f5a04a863344b1264
commit r15-916-gc68bd7e8023f65d1dc23237f5a04a863344b1264
Author: Hans-Peter Nilsson
Date: Thu May 30 01:57:39 2024 +0200
Revert "resource.cc: Replace calls to find_basic_block with cfgrtl
BLOCK_FOR_INSN"
This reverts
https://gcc.gnu.org/g:afe48a45b8baa310c8373499b1e5b5407a3e2b94
commit r15-915-gafe48a45b8baa310c8373499b1e5b5407a3e2b94
Author: Hans-Peter Nilsson
Date: Thu May 30 01:57:29 2024 +0200
Revert "resource.cc (mark_target_live_regs): Remove check for bb not found"
This reverts commit
https://gcc.gnu.org/g:c31a9d3152d6119aab83c403308ddb933fe905c5
commit r15-914-gc31a9d3152d6119aab83c403308ddb933fe905c5
Author: Hans-Peter Nilsson
Date: Thu May 30 01:57:16 2024 +0200
Revert "resource.cc: Remove redundant conditionals"
This reverts commit
https://gcc.gnu.org/g:802a98d128f9b0eea2432f6511328d14e0bd721b
commit r15-880-g802a98d128f9b0eea2432f6511328d14e0bd721b
Author: Hans-Peter Nilsson
Date: Tue May 28 23:18:14 2024 +0200
resource.cc: Remove redundant conditionals
No functional change.
- We always have a
https://gcc.gnu.org/g:e1abce5b6ad8f5aee86ec7729b516d81014db09e
commit r15-879-ge1abce5b6ad8f5aee86ec7729b516d81014db09e
Author: Hans-Peter Nilsson
Date: Tue May 28 23:17:31 2024 +0200
resource.cc (mark_target_live_regs): Remove check for bb not found
No functional change.
https://gcc.gnu.org/g:933ab59c59bdc1ac9e3ca3a56527836564e1821b
commit r15-878-g933ab59c59bdc1ac9e3ca3a56527836564e1821b
Author: Hans-Peter Nilsson
Date: Tue May 28 23:16:48 2024 +0200
resource.cc: Replace calls to find_basic_block with cfgrtl BLOCK_FOR_INSN
...and call
https://gcc.gnu.org/g:84b4ed45ea81ed5c4fb656a17846b26071c23e7d
commit r15-877-g84b4ed45ea81ed5c4fb656a17846b26071c23e7d
Author: Hans-Peter Nilsson
Date: Tue May 28 23:15:57 2024 +0200
resource.cc (mark_target_live_regs): Don't look past target insn, PR115182
The PR115182
https://gcc.gnu.org/g:f6ce85502eb2e4e7bbd9b3c6c1c065a004f8f531
commit r15-311-gf6ce85502eb2e4e7bbd9b3c6c1c065a004f8f531
Author: Hans-Peter Nilsson
Date: Wed May 8 04:11:20 2024 +0200
Revert "Revert "testsuite/gcc.target/cris/pr93372-2.c: Handle xpass from
combine improvement""
https://gcc.gnu.org/g:39f81924d88e3cc197fc3df74204c9b5e01e12f7
commit r14-9904-g39f81924d88e3cc197fc3df74204c9b5e01e12f7
Author: Hans-Peter Nilsson
Date: Wed Apr 10 17:24:10 2024 +0200
Revert "testsuite/gcc.target/cris/pr93372-2.c: Handle xpass from combine
improvement"
This
https://gcc.gnu.org/g:4c8b3600c4856f7915281ae3ff4d97271c83a540
commit r14-9799-g4c8b3600c4856f7915281ae3ff4d97271c83a540
Author: Hans-Peter Nilsson
Date: Fri Apr 5 02:50:16 2024 +0200
testsuite/gcc.target/cris/pr93372-2.c: Handle xpass from combine improvement
After
https://gcc.gnu.org/g:3b36e86d6af3b305207c1aa6d56c2b350fefba65
commit r14-9798-g3b36e86d6af3b305207c1aa6d56c2b350fefba65
Author: Hans-Peter Nilsson
Date: Fri Apr 5 01:36:54 2024 +0200
testsuite/gcc.dg/debug/btf/btf-datasec-1.c: Handle leading-underscore
I noticed my autotester
> 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
> 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 12:16:40 +0100
> > > > Reply-To: Jonathan Wakely
> > > >
> 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
(Looks like this was committed as r14-3580-g597b9ec69bca8a)
> Cc: gcc@gcc.gnu.org, gcc-patc...@gcc.gnu.org, Eric Feng
> From: Eric Feng via Gcc
> gcc/testsuite/ChangeLog:
> PR analyzer/107646
> * gcc.dg/plugin/analyzer_cpython_plugin.c: Implements reference count
> * checking for
(Looks like this was committed as r14-3580-g597b9ec69bca8a)
> Cc: g...@gcc.gnu.org, gcc-patches@gcc.gnu.org, Eric Feng
> From: Eric Feng via Gcc
> gcc/testsuite/ChangeLog:
> PR analyzer/107646
> * gcc.dg/plugin/analyzer_cpython_plugin.c: Implements reference count
> * checking for
> 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 undefined references to
> 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:
>
>
> 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_legitimate_address_p
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 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
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 a quick fix at r14-1444-g3f4853a5f00fab, I
> >>
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=commit;h=d8a6945c6ea22efa4d5e42fe1922d2
> > b27953c8cd
>
> 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 don't think actually removing
> 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 idea this way is easy.
> 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 --
> > I was a bit surprised when my newly-added
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
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 hardware division instruction (also,
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 the
> generated output
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 due to another, and
also
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." Does that mean:
[...]
> (Neither...)
[...]
> Sorry,
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
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
> 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
>
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 instruction into sequence that over by
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 sequence that over by another
> From: David Malcolm
> Date: Thu, 16 Mar 2023 14:42:58 -0400
> I think I prefer the top one-liner dg-skip-if approach you mentioned in
> your original email; it seems simplest.
Ok then. There's also a choice between adding a
target-specifier (i.e. "{ target { ! default_packed } }") to
the
> From: Hans-Peter Nilsson
> Date: Thu, 16 Mar 2023 19:25:05 +0100
> That doesn't seem like a good idea. At a glance the
> *testcode* will be simpler, but the patch will be slightly
> larger
Bah, s/but the patch will be slightly larger/and the patch
will certainly be smaller, but because less
> From: David Malcolm
> Date: Thu, 16 Mar 2023 13:55:48 -0400
> On Thu, 2023-03-09 at 19:56 +0100, Hans-Peter Nilsson wrote:
> > It's not obvious to me whether considered best to include or
> > exclude these tests that depend on structure layout details.
> > If excluding, the obvious alternative
Pinging this patch.
> From: Hans-Peter Nilsson
> Date: Thu, 9 Mar 2023 19:56:16 +0100
>
> It's not obvious to me whether considered best to include or
> exclude these tests that depend on structure layout details.
> If excluding, the obvious alternative to this patch is then
> to add a top
> Date: Mon, 13 Mar 2023 22:31:21 -0600
> From: Sandra Loosemore
> On 3/13/23 19:25, Hans-Peter Nilsson via Gcc-patches wrote:
> > Jan, did I get this right? This was from your
> > r0-36413-g6b24c25948265c / svn r44249, now on its 22nd year!
> >
> > I spo
Jan, did I get this right? This was from your
r0-36413-g6b24c25948265c / svn r44249, now on its 22nd year!
I spot-checked the pdf for readability. Also calling on a
doc maintainer to check grammos etc. Ok to commit?
-- >8 --
I needed to check what was allowed in a define_split, but
had
This takes care of the failing gcc.dg/torture/ftrapv-1.c and
-ftrapv-2.c for cris-elf.
For simplicity, assume simulators are the GNU simulator (in the gdb
repo). But cris-elf is newlib, so a newlib target forking? Yes: the
I/O, etc. interface to the simulator uses the Linux/CRIS ABI.
*
Committed as obvious.
-- >8 --
Targets that don't support scheduling get a warning:
cc1: warning: instruction scheduling not supported on this target machine
Do like other target-generic tests unconditionally passing
-fschedule-insns: require effective target scheduling.
*
Committed as obvious.
-- >8 --
Targets that don't support prefetching get a warning:
cc1: warning: '-fprefetch-loop-arrays' not supported for this target
Align with other tests passing -fprefetch-loop-arrays for
all targets: add "-w" to options.
* gcc.dg/pr106397.c: Add -w to options.
It's not obvious to me whether considered best to include or
exclude these tests that depend on structure layout details.
If excluding, the obvious alternative to this patch is then
to add a top one-liner (to dg-skip-if the test for
default_packed targets or a similar excluding expression).
I'm
Committed as obvious.
-- >8 --
The recently added tests missed checking for "fopenmp" (see
other tests where "-fopenmp" is passed), which makes them
fail on non-openmp systems.
* gcc.dg/analyzer/omp-parallel-for-get-min.c,
gcc.dg/analyzer/omp-parallel-for-1.c: Require effective
> From: Mike Stump
> Date: Mon, 6 Mar 2023 02:05:35 -0800
> Ok
Thanks! The server-side hook didn't like my ChangeLog
entry:
* lib/multiline.exp (_build_multiline_regex): Map
"{re:" to "(", ":re}" to ")" and ":re?}" to ")?".
It seems I forgot to validate that patch by
This is sort-of a spin-off from effective_target_tail_call: I thought
that'd best be implemented by scanning a tree-dump, specifically
-fdump-tree-optimized, but the "tail call" found there is emitted for
*all* targets. Debugged and ready to apply, putting it out for
consideration as someone will
Borderline obvious when tail_call is available, so I'll then apply.
-- >8 --
While gcc.dg/plugin/must-tail-call-2.c passes for all targets even
without this, the error message is, for a target like cris-elf that
doesn't implement sibling calls: "error: cannot tail-call: machine
description does
Will commit as obvious, when the 1/3 tail_call is applied.
-- >8 --
Spot-checked the PDF output for sanity.
* doc/sourcebuild.texi: Document check_effective_target_tail_call.
---
gcc/doc/sourcebuild.texi | 3 +++
1 file changed, 3 insertions(+)
diff --git a/gcc/doc/sourcebuild.texi
Ok to commit?
-- >8 --
The RTL "expand" dump is the first RTL dump, and it also appears to be
the earliest trace of the target having implemented sibcalls.
Including the "," in the pattern searched for, to try and avoid
possible false matches, but there doesn't appear to be any identifiers
or
Ping...
> From: Hans-Peter Nilsson
> Date: Fri, 24 Feb 2023 20:16:03 +0100
>
> Ok to commit?
> -- >8 --
> Those multi-line-patterns are literal. Sometimes a regexp
> needs to be matched. This is a start: just three elements
> are supported: "(" ")" and the compound ")?" (and on second
>
1 - 100 of 260 matches
Mail list logo
