Committed as obvious.
The typo here, is obviously mistaken removal of lines next
to a line that was validly removed. Targets affected are
those with a delay-slot *and* defining TARGET_FLAGS_REGNUM.
In-tree, a git-grep says the only ones matching are CRIS,
h8300 and visium. The code removal has t
Ok to commit?
When eyeballing the r12-440 / bd1cd0d0e0fe / "Remove
CC0" commit, I noticed parts that could be improved.
Regarding the first change: at first I thought that just
removing the word "better" was the best choice, as the
compared part (cc0) was apparently removed, but the
paragraph aft
> From: Segher Boessenkool
> Date: Sun, 16 May 2021 18:18:17 +0200
> On Sat, May 15, 2021 at 08:44:29PM +0200, Hans-Peter Nilsson via Gcc-patches
> wrote:
> > When eyeballing the r12-440 / bd1cd0d0e0fe / "Remove
> > CC0" commit, I noticed parts that could b
> From: Jonathan Wakely via Gcc-patches
> Date: Fri, 23 Dec 2022 00:37:04 +0100
> This is the largest missing piece of C++20 support. Only the cxx11 ABI
> is supported, due to the use of std::string in the API for time zones.
> libstdc++-v3/ChangeLog:
>
> * acinclude.m4 (GLIBCXX_ZONEINFO_
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: 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?
>
> 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:
>
> 27_io/filesystem/path/1
> 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
t declaration too, 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_plug
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 to
> 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!
>
>
>
> 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: 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
> 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
> 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
> 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
(Back from vacation, found that this had an unanswered question,
quoted last.)
> From: Segher Boessenkool
> Date: Tue, 14 Jul 2020 23:58:05 +0200
> Hi!
>
> On Mon, Jul 06, 2020 at 04:01:54AM +0200, Hans-Peter Nilsson via Gcc-patches
> wrote:
> > Most comments, includin
> From: Segher Boessenkool
> Date: Fri, 17 Jul 2020 02:05:19 +0200
> On Tue, Jul 14, 2020 at 04:33:42PM -0500, Segher Boessenkool wrote:
> > > If combine only did lower-cost combinations (perhaps with
> > > Richard Sandifords lower-size-when-tied suggestion), I guess
> > > this wouldn't happen. 0
Committed as obvious.
The bitfield-struct t0 in gcc.dg/pr94600-1.c ..-4.c is assigned through
a pointer that is a (volatile-and-pointer-)cast literal, so gcc doesn't
need to be otherwise told that the address is aligned. But, variants
pr94600-5.c ..-8.c are assigned through a "volatile t0 *", and
Originally I thought to bootstrap this patch on MIPS and SPARC
since they're both delayed-branch-slot targets but I
reconsidered, as neither is a TARGET_FLAGS_REGNUM target. It
seems only visium and CRIS has this feature set, and I see no
trace of visium in neither newlib nor the simulator next to
ets if that didn't work. I should be
able to use the existing machinery in this patch.
BTW, I happened to notice that bugs here are also somewhat more
visible than your ordinary wrong-result bug. :)
> Hans-Peter Nilsson via Gcc-patches writes:
> > Originally I thought to bootstrap
> From: Eric Botcazou
> CC: "gcc-patches@gcc.gnu.org"
> Date: Fri, 11 Sep 2020 13:09:48 +0200
> received-spf: None (smtp1.axis.com: no sender authenticity information
> available from domain of postmas...@mail-wr1-f54.google.com) identity=helo;
> client-ip=209.85.221.54; receiver=smtp1.axis.
> From: Hans-Peter Nilsson
> Date: Fri, 11 Sep 2020 13:24:18 +0200
> > > @@ -2618,6 +2643,16 @@ fill_slots_from_thread (rtx_jump_insn *insn, rtx
> > > condition, lose = 1;
> > >mark_set_resources (trial, &set, 0, MARK_SRC_DEST_CALL);
> > >
> From: Eric Botcazou
> Date: Fri, 11 Sep 2020 13:09:48 +0200
> > @@ -2618,6 +2643,16 @@ fill_slots_from_thread (rtx_jump_insn *insn, rtx
> > condition, lose = 1;
> >mark_set_resources (trial, &set, 0, MARK_SRC_DEST_CALL);
> >mark_referenced_resources (trial, &needed, true);
> > +
We say very little about reads and writes to aggregate /
compound objects, just scalar objects (i.e. assignments don't
cause reads). Let's lets say something safe about aggregate
objects, but only for those that are the same size as a scalar
type.
There's an equal-sounding section (Volatiles) in
> From: Hans-Peter Nilsson
> Date: Tue, 7 Jul 2020 06:01:37 +0200
> gcc:
> PR middle-end/94600
> * expr.c (expand_constructor): Make a temporary also if we're
> storing to volatile memory.
Oops, I dropped attribution here, but this patch is by Ric
> From: Martin Sebor
> Date: Wed, 8 Jul 2020 02:09:37 +0200
> On 7/6/20 10:02 PM, Hans-Peter Nilsson via Gcc-patches wrote:
> > We say very little about reads and writes to aggregate /
> > compound objects, just scalar objects (i.e. assignments don't
> > cause r
> From: Richard Biener
> Date: Tue, 7 Jul 2020 09:00:22 +0200
> On Tue, Jul 7, 2020 at 6:03 AM Hans-Peter Nilsson via Gcc-patches
> wrote:
> >
> > We say very little about reads and writes to aggregate /
> > compound objects, just scalar objects (i.e. assignments
> From: Segher Boessenkool
> Date: Tue, 7 Jul 2020 22:23:59 +0200
> Hi!
>
> On Tue, Jul 07, 2020 at 02:50:09AM +0200, Hans-Peter Nilsson wrote:
> > > On Mon, Jul 06, 2020 at 03:11:17AM +0200, Hans-Peter Nilsson wrote:
> > > > TL;DR: fixing a mi
> From: Segher Boessenkool
> Date: Tue, 7 Jul 2020 22:50:43 +0200
> I'll make a simpler patch. Thanks!
You're welcome. So, you'll take care of the updated patch
yourself?
(I'll wait a month before sending an update either way.)
brgds, H-P
Together with the combine.c patch posted (but remaining a WIP),
all coremark performance regressions are gone for CRIS, compared
to cc0. Unfortunately, I looked further, and found some issues
when running gcc.c-torture/execute/arith-rand.c and
arith-rand-ll.c, in those functions and the target-spe
Whoops. This little gem had the effect of making the output
operand (0) constraints disappear but not the input operand (1)
constraints for define_subst:ed patterns, probably because
there's another (match_dup 1) in the output template (not
investigated).
That went surprisingly unnoticed until I
Getting tired of:
make[1]: Entering directory 'x/gccobj/gcc'
Makefile:2682: warning: overriding recipe for target 'gt-cris.h'
xx/gcc/gcc/config/cris/t-cris:29: warning: ignoring old recipe for target
'gt-cris.h'
I'm just going to assume it is just stale cruft no longer (if
ever) needed since not
Comparing to the cc0 version of the CRIS port, I ran a few
microbenchmarks, for example gcc.c-torture/execute/arith-rand.c,
where there's sometimes an addition between an operation of
interest and the test on the result.
Unfortunately this patch doesn't remedy all the performance
regression for th
(All patches are committed.)
Delayed-branch-slot-filling a.k.a. reorg or dbr, often causes
opportunities for more compare-elimination than were visible for
the cmpelim pass. With cc0, these were caught by the
elimination pass run in "final", thus the missed opportunities
is a regression. A simpl
> From: Jeff Law
> Date: Tue, 5 May 2020 16:52:07 +0200
> On Mon, 2020-02-10 at 17:55 +0100, Hans-Peter Nilsson wrote:
> > * config/cris/cris.c (cris_reduce_compare): New function.
> > * config/cris/cris-protos.h (cris_reduce_compare): Add prototype.
> > * con
> From: Jeff Law via Gcc-patches
> Date: Tue, 5 May 2020 17:05:01 +0200
> On Wed, 2020-02-12 at 07:47 +0100, Hans-Peter Nilsson wrote:
> > I just rebased and updated the vendors/axis branch
> > axis/cris-decc0 with the following commits, which should bring
> > back com
Not that anyone would notice, except a few maintainers of
targets with delay-slots, and only if the first patch causes
fallout, as the others only touch stuff related to the CRIS target.
The 23 commits have been posted previously, around Jan-Feb. For
reference:
2c2d405 dbr: Filter-out TARGET_FLA
> From: Alexandre Oliva
> Date: Tue, 26 May 2020 15:52:57 +0200
> On May 26, 2020, Richard Biener wrote:
>
> > xgcc: error: unrecognized command-line option '-dumpbase'^M
>
> > xg++: error: unrecognized command-line option '-dA'; did you mean '-A'
>
> Here's a proper patch submission.
And he
> From: Alexandre Oliva
> Date: Wed, 27 May 2020 16:30:07 +0200
> On May 26, 2020, Hans-Peter Nilsson wrote:
>
> >> Here's a proper patch submission.
>
> > And here's an improper bug report.
>
> :-)
>
> Thanks, H-P,
>
> > xgcc: e
> From: Alexandre Oliva
> Date: Tue, 2 Jun 2020 13:29:03 +0200
> Hello, Anthony, H-P,
>
> On May 27, 2020, Anthony Green wrote:
>
> > Hans-Peter Nilsson via Gcc-patches writes:
> >> And here's an improper bug report.
> >>
> >> One of t
> From: Luis Machado via Gcc-patches
> Date: Mon, 11 Jan 2021 15:58:43 +0100
> This seems to have broken the builds on AArch64-Linux Ubuntu 18.04.
>
> make[2]: Entering directory 'binutils-gdb-master-bionic/libiberty'
> rm -f ./libiberty.a pic/./libiberty.a noasan/./libiberty.a
> ar --plugin /us
When cleaning out the multitude of patterns with unknown
coverage, this one went the way of the bathwater. It's use is
barely common enough to mark when diffing libgcc, and has a
minimal impact on performance-testsuites. Anyway, reinstated
with a couple of test-cases. It's suboptimal of gcc-core
The code in cris_select_cc_mode for selecting CC_NZmode was
partly inconsistent with the comment and partly seemed
ambiguous. I couldn't find a reason why I qualified selection
of CC_NZmode on the setting operation once a matching user was
spotted, so I just removed that. The cris.c update was du
Yet another misnumbering of operands: the asserted non-overlap
would be the only benign operands overlap. "Suddenly" exposed
by g++.dg/cpp0x/pr81325.C when testing unrelated changes
affecting register allocation.
To wit, operands 2 and 1 are the only ones that are safe for
overlap, it's only that
(The previous patch was also committed, FWIW, I just forgot to
mention it.)
Combine likes to change a zero-extension / and + shift as seen
in the test-case source to a logical shift followed by an and of
the shifted mask, like:
lsrq 1,r0
and.d 0x7f,r0
This was observed in the hot loop of corema
ot functions, and the swing between
different functions is larger than this difference; to be dealt
with separately.
Tested cris-elf, x86_64-linux, powerpc64le-linux, 2/3 through
aarch64-linux (unexpectedly slow).
Ok to commit?
2020-07-06 Hans-Peter Nilsson
PR target/93372
Most comments, including the second sentence in the head comment
of combine_validate_cost, the main decision-maker of the combine
pass, refer to the function as returning true if the new
insns(s) *cheaper* than the old insns, when in fact the function
returned true also if the cost was the same. R
> From: Richard Sandiford
> Date: Mon, 6 Jul 2020 11:48:25 +0200
> Out of interest, how do the results change if we still allow the
> combination for equal costs if the new sequence is shorter than
> the original? I think that still counts as "cheaper than",
> but maybe I'm too RISC-centric. ;-)
> From: Segher Boessenkool
> Date: Tue, 7 Jul 2020 01:42:47 +0200
TL;DR: recognize a parallel with a clobber of TARGET_FLAGS_REGNUM?
> Hi!
>
> On Mon, Jul 06, 2020 at 03:11:17AM +0200, Hans-Peter Nilsson wrote:
> > TL;DR: fixing a misdetection of what is a "simple
> From: Segher Boessenkool
> Date: Tue, 7 Jul 2020 01:42:47 +0200
(Regarding is_just_move in combine.c.)
> But it is *not* supposed to be the same as single_set.
>
> > I checked the original commit, c4c5ad1d6d1e1e a.k.a r263067 and
> > it seems parallels-as-sets were just overlooked and that th
The store to the whole of each volatile object was picked apart
like there had been an individual assignment to each of the
fields. Reads were added as part of that; see PR for details.
The reads from volatile memory were a clear bug; individual
stores questionable. A separate patch clarifies the
ething safe about aggregate
objects, but only for those that are the same size as a scalar
type.
There's an equal-sounding section (Volatiles) in extend.texi,
but this seems a more appropriate place, as specifying the
behavior of a standard qualifier.
gcc:
2020-12-02 Hans-Peter Nilsson
> From: Martin Sebor via Gcc-patches
> Date: Fri, 4 Dec 2020 01:49:51 +0100
> On 12/3/20 12:14 PM, Hans-Peter Nilsson via Gcc-patches wrote:
> > Belatedly, here's an updated version, using Martin Sebor's
> > suggested wording from
> > "https://gcc.gnu.
> From: Patrick Palka via Gcc-patches
> Date: Fri, 4 Nov 2022 16:05:25 +0100
> This patch moves the global object for constructing the standard streams
> out from and into the compiled library on targets that support
> the init_priority attribute. This means that no longer
> introduces a separ
How was r13-2619-g34b9a03353d3fd "gcov: Respect triplet when looking
for gcov" tested? I'm having a hard time believing it was tested with
a *cross-compiler* *in-build-tree*. I think it was only tested for
the special-case of an installed cross-compiler; not even with a
native build exercising th
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 was
meant. Maybe you could add some 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
>
&g
> 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."
> 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
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 a/gcc/recog.
> 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
d out. Or
something 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 {
> 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 ma
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 hav
> 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
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 "*
> 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 regressio
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 documentat
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 --
>
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.
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 them
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 includes
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, loos
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.
* con
Tested cris-elf and native x86_64-pc-linux-gnu.
Ok to commit?
-8< --
For targets where the ABI mandates structure layout that has
no padding, like cris-elf, this test started failing when
introduced as an add-on to the existing 1.cc, thereby
effectively causing a regression in testsuite r
> From: Jonathan Wakely
> Date: Wed, 1 Feb 2023 18:19:09 +0100
> On Wed, 1 Feb 2023 at 16:01, Jonathan Wakely wrote:
> >
> > On Wed, 1 Feb 2023 at 14:38, Hans-Peter Nilsson via Libstdc++
> > wrote:
> > >
> > > Tested cris-elf and native x86_64
Tested cris-elf, native x86_64-pc-linux-gnu.
Ok to commit?
--- 8< ---
These appear as regressions from a baseline before
r13-3761-ga239a63f868e29. See the PR trail.
Note that the warning for g++.dg/pr71488.C is for a *header*
file, thus we can't match the line number (sanely).
gcc/testsuite:
Tested cris-elf and native x86_64-pc-linux-gnu.
Ok to commit?
8<
The use of a "naked" int32_t (i.e. without a fitting #include:
stdint.h or cstdint or inttypes.h or an equivalent internal header),
in libstdc++-v3/include/pstl/unseq_backend_simd.h, caused an error for
cris-elf and apparen
(sort-of-ping:) Aldy, I missed CC:ing you on the similar
https://gcc.gnu.org/pipermail/gcc-patches/2023-February/611206.html
would you mind having a look?
Tested native x86_64-pc-linux-gnu (w/wo. -m32) and cris-elf.
Ok to commit?
8<
There was a commit r13-2082-gbf13a13c65bd06 "c++: remo
> From: Aldy Hernandez
> Date: Tue, 7 Feb 2023 17:52:02 +0100
> Up to the release managers, but I have no objections.
I take it that's for both patches. Thanks!
(Potential reviewers: these patches are local to the testsuite.)
brgds, H-P
>
> Aldy
>
> On 2/7/23
Tested native x86_64-pc-linux-gnu and cris-elf (non-LRA and
also hacked to switch to LRA).
Ok to commit?
--- 8< ---
The LRA target list is incomplete. Rather than syncing it with actual
LRA targets, better use existing infrastructure and look for a
LRA-specific pattern in the reload dump (which
> From: Richard Sandiford
> Date: Wed, 8 Feb 2023 17:54:15 +0100
> Hans-Peter Nilsson via Gcc-patches writes:
> > Tested native x86_64-pc-linux-gnu and cris-elf (non-LRA and
> > also hacked to switch to LRA).
>
> Since !LRA is hopefully not long for this world, I&#x
Sanity-checked for cris-elf with the
check_effective_target_lra correction in
https://gcc.gnu.org/pipermail/gcc-patches/2023-February/611531.html
Committed as obvious.
--- 8< ---
These tests spuriously lacked a "lra" limiter. Code using
"asm goto" with outputs gets a:
error: the target does not
> From: Vladimir Makarov via Gcc-patches
> Date: Thu, 9 Feb 2023 22:49:34 +0100
> The patch was successfully bootstrapped (--enable-languages=all) and
> tested on x86, x86-64, aarch64
Sorry, but this (also) caused test-suite regressions,
perhaps just for cris-elf. I've opened 108754 and will
a
When DWARF_FRAME_REGISTERS isn't defined, the default is
FIRST_PSEUDO_REGISTER which means that if you add faked
registers to the port, used for frame-context related
elimination, room is allocated for them in the register
context used for frame-unwinding, which is wasteful because
they're eliminat
Forgot to mention: no differences in cris-elf test-results at r11-7500.
Beware, tm.texi doesn't tell the whole story: a defined
HARD_FRAME_POINTER_REGNUM (different to FRAME_POINTER_REGNUM) is
supposed to make work easier for reload, being able to easily
tell actual frame-pointer-related addresses
See PR99212. Now, cris-elf isn't the only target for which this line
shows a failure; pru-unknown-elf and m68k-unknown-linux-gnu are two
others. I'll leave adjustments to the respective maintainers, but
trivially appending more triplets should work: no extra bracketing needed.
A specific effectiv
Unfortunately it appears that this PR is on nobody's radar.
Xfailing it to get an arguably artificial zero regression
state (since T0=2007-01-05) helps my autotester.
Caveat: the pass/fail state of this test, as long as stack
alignment isn't adjusted, is dependent on the alignment of
the stack at
> From: Richard Sandiford via Gcc-patches
> Date: Thu, 6 Jan 2022 15:48:01 +0100
> If an allocno A in an inner loop L spans a call, a parent allocno AP
> can choose to handle a call-clobbered/caller-saved hard register R
> in one of two ways:
>
> (1) save R before each call in L and restore R af
ck (error-prone) grep-and-eyeball in config/ shows this was the
only file missing the parenthesis. This lets cris-elf configured with
--enable-checking=yes,extra,rtl survive make all-gcc.
2022-01-11 Hans-Peter Nilsson
* config/cris/cris.c (cris_postdbr_cmpelim): Parenthesize
pa
hat I therefore agree that operators, identifiers and keywords
should have to be dressed up like this for internal error messages;
they were more readable without these garments, if only slightly so.
2022-01-11 Hans-Peter Nilsson
* config/cris/cris.c: Quote identifiers in parameters t
> From: Jeff Law via Gcc-patches
> Date: Wed, 12 Jan 2022 16:58:50 +0100
> On 1/12/2022 8:00 AM, Richard Biener wrote:
> > On Wed, Jan 12, 2022 at 3:26 PM Vladimir Makarov
> > wrote:
> >>
> >> On 2022-01-12 03:47, Richard Biener wrote:
> >>> On Tue, Jan 11, 2022 at 7:41 PM Vladimir Makarov via
> From: Jeff Law via Gcc-patches
> Date: Wed, 12 Jan 2022 16:58:50 +0100
> On 1/12/2022 8:00 AM, Richard Biener wrote:
> > On Wed, Jan 12, 2022 at 3:26 PM Vladimir Makarov
> > wrote:
> >>
> >> On 2022-01-12 03:47, Richard Biener wrote:
> >>> On Tue, Jan 11, 2022 at 7:41 PM Vladimir Makarov via
> From: Patrick Palka via Gcc-patches
> Date: Sun, 16 Jan 2022 19:06:48 +0100
> We're going to use the fast_float library in our (compiled-in)
> floating-point std::from_chars implementation for faster and more
> portable parsing of binary32/64 decimal strings.
>
> The single file fast_float.h
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
> 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 ex
> 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 small
> 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 dg-c
> 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
1101 - 1200 of 1212 matches
Mail list logo
