> 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 to
(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 PyO
> 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 chdir,
> 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
> 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:
>
> * con
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 recen
> 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
*c
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 misnome
> 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 proc
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 a/gcc/testsuite/
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 target/11
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
> w
> 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 return
> 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): U
> 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 repl
> 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 eff
> 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 t
> 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.
Absolute
> 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 interest
> 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 investigat
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 (nothing
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
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
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
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
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 define_peeph
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
> 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
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 hav
> 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
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 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 tric
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 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, y
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
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
> 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 br
> 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..
>
> tr
> 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
> li
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 (de
> 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 anoth
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 expo
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 "add.
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
--- a/gcc/config/cris
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
cris-el
> 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 ju
> 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
> 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 i
> 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 one-l
> 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 problem
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.
* gcc.dg/pr108117
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 fin
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 tar
> 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
c
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 not
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 b/gcc
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 targe
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
> though
CRIS defines DATA_ALIGNMENT such that alignment can be
applied differently to different data of the same type, when
"references to it must bind to the current definition"
(varasm.cc:align_variable). Here, it means that more
alignment is then applied to g, but not f, so the test-case
fails because
CRIS has no conditional execution and no conditional moves.
* gcc.dg/ifcvt-4.c: Add cris-*-* to skip list.
---
gcc/testsuite/gcc.dg/ifcvt-4.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/testsuite/gcc.dg/ifcvt-4.c b/gcc/testsuite/gcc.dg/ifcvt-4.c
index 46245f0d0
Committed as obvious.
-- >8 --
* g++.dg/cpp0x/pr84497.C: Handle USER_LABEL_PREFIX == "_" on
scan-assembler identifiers.
* gcc.dg/debug/btf/btf-enum64-1.c, gcc.dg/ipa/symver1.c: Ditto.
---
gcc/testsuite/g++.dg/cpp0x/pr84497.C | 6 +++---
gcc/testsuite/gcc.dg/debug/b
Committed as obvious. FWIW, I'm on the side that emitting
the warning when the reason is just that it's the default
layout, is bad. A discussion took place years ago when the
warning was added.
-- >8 --
For targets where the byte-wise structure element layout is
the same as for attribute-packed,
Trivia: I copied that ASMNAME construct from the
18-year-minus-a-month old commit of r0-66993-gc5221531453e02,
where it fixed a similar testsuite error. Committed as obvious.
-- >8 --
This fixes:
Running /x/gcc/testsuite/gcc.dg/dg.exp ...
...
FAIL: gcc.dg/attr-copy-6.c (test for excess errors)
> Date: Thu, 2 Mar 2023 01:37:12 +0100
> From: Bernhard Reutner-Fischer
> On Thu, 2 Mar 2023 00:54:33 +0100
> Hans-Peter Nilsson wrote:
>
> > > Date: Thu, 2 Mar 2023 00:23:36 +0100
> > > From: Bernhard Reutner-Fischer
> >
> > > On Wed, 1 Mar
> Date: Thu, 2 Mar 2023 00:23:36 +0100
> From: Bernhard Reutner-Fischer
> On Wed, 1 Mar 2023 17:02:31 +0100
> Hans-Peter Nilsson via Gcc-patches wrote:
>
> > > From: Hans-Peter Nilsson
> > > Date: Wed, 1 Mar 2023 16:36:46 +0100
> >
> >
> From: Hans-Peter Nilsson
> Date: Wed, 1 Mar 2023 16:36:46 +0100
> ... this is what I intend to commit later
> today, just keeping the added comment as brief as
> reasonable:
Except I see the hook for errno magic took care of
gcc.dg/analyzer/flex-without-call-summaries.c so I'll add
that to the
> From: David Malcolm
> Cc: gcc-patches@gcc.gnu.org
> Date: Wed, 01 Mar 2023 08:32:13 -0500
> Also, the analyzer uses region_model::set_errno in various
> known_function implementations, e.g. for functions that can succeed or
> fail, to set errno on the "failure" execution path to a new symbolic
> From: David Malcolm
> Date: Tue, 28 Feb 2023 21:25:34 -0500
> On Wed, 2023-03-01 at 01:59 +0100, Hans-Peter Nilsson wrote:
> > > From: David Malcolm
> > > Date: Tue, 28 Feb 2023 14:12:47 -0500
> >
> > > On Tue, 2023-02-28 at 19:47 +0100, Hans-Peter Nilsson wrote:
> > > > Ok to commit?
> > > >
> From: David Malcolm
> Date: Tue, 28 Feb 2023 14:12:47 -0500
> On Tue, 2023-02-28 at 19:47 +0100, Hans-Peter Nilsson wrote:
> > Ok to commit?
> > -- >8 --
> > Investigating analyzer tesstsuite errors for cris-elf. The same are
> > seen for pru-elf according to posts to gcc-testresults@.
> >
>
Ok to commit? (After this, there's
gcc.dg/analyzer/flex-without-call-summaries.c left to do.)
-- >8 --
Investigating analyzer testsuite errors for cris-elf. The same are
seen for pru-elf according to posts to gcc-testresults@.
The test fd-access-mode-target-headers.c uses the analyzer
"sm-fd" w
Ok to commit?
-- >8 --
Investigating analyzer tesstsuite errors for cris-elf. The same are
seen for pru-elf according to posts to gcc-testresults@.
For glibc, errno is #defined as:
extern int *__errno_location (void) __THROW __attribute_const__;
# define errno (*__errno_location ())
while for n
1 - 100 of 244 matches
Mail list logo
