[PATCH] reload_cse_move2add: Handle trivial single_set:s

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

Build-break in libstdc++-v3 at r14-1442-ge1240bda3e0bb1 for non-float128 targets

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:

Re: Build-break in libstdc++-v3 at r14-1442-ge1240bda3e0bb1 for non-float128 targets

> 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 > >>

[committed] bootstrap rtl-checking: Fix XVEC vs XVECEXP in postreload.cc

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

Re: [PATCH] libstdc++: Use AS_IF in configure.ac

> 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

Re: [pushed] c++: allow NRV and non-NRV returns [PR58487]

> 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

Splitting up 27_io/basic_istream/ignore/wchar_t/94749.cc (takes too long)

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`.

Re: Splitting up 27_io/basic_istream/ignore/wchar_t/94749.cc (takes too long)

> 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

[PATCH] (Re: Splitting up 27_io/basic_istream/ignore/wchar_t/94749.cc (takes too long))

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

[Committed] gcc.dg/analyzer/allocation-size-1..5.c: Fix for 32-bit newlib targets

See gcc/config/newlib-stdint.h, where targets that have LONG_TYPE_SIZE == 32, get INT32_TYPE defined to "long int". INT32_TYPE ends up in the target int32_t. Thus the tests failed for 32-bit newlib targets due to related warning messages being matched to "aka int" where the emitted message for the

Re: [PATCH 2/3] ivopts: Call valid_mem_ref_p with code_helper [PR110248]

> 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 >

[PATCH] CRIS: Don't include tree.h in cris-protos.h, PR bootstrap/111021

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. --

Re: [PATCH] CRIS: Don't include tree.h in cris-protos.h, PR bootstrap/111021

> 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

[PATCH v2] CRIS: Don't include tree.h in cris-protos.h, PR bootstrap/111021

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

Re: [committed] libstdc++: Reuse double overload of __convert_to_v if possible

> 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

[committed] CRIS: Don't apply PATTERN to insn before validation (PR 110144)

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

[committed] testsuite: check_effective_target_lra: CRIS is LRA

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/

PR108672 re-fixed after [PATCH] libstdc++: Synchronize PSTL with upstream

> 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

[committed] dwarf2out.cc (mem_loc_descriptor): Handle BITREVERSE

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

[committed] CRIS: Replace unspec CRIS_UNSPEC_SWAP_BITS with rtx bitreverse

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

[PATCH] debug: Support "phrs" for dumping a HARD_REG_SET

Ok to commit? It survived both a cris-elf regtest and a x86_64-linux-gnu native regtest. :) 8< The debug-function in sel-sched-dump.cc that would be suitable for a hookup to a command in gdb is guarded by #ifdef INSN_SCHEDULING, thus can't be used for all targets. Better move the functi

[PATCH] gen_reload: Correct parameter for fatal_insn call

Committed as obvious. Also, I wrote the neighboring code - apparently including that line... -- >8 -- Observed when disabling LEGITIMIZE_RELOAD_ADDRESS for cris-elf: the current code doesn't handle the post-cc0 parallel-with-clobber-of-cc0 sets, dropping down into the fatal_insn call. Following

[PATCH] reload: Handle generating reloads that also clobbers flags

Regtested cris-elf with its LEGITIMIZE_RELOAD_ADDRESS disabled, where it regresses gcc.target/cris/rld-legit1.c; as expected, because that test guards proper function of its LEGITIMIZE_RELOAD_ADDRESS i.e., that there's no sign of decomposed address elements. LRA also causes a similar decomposition

[PATCH] testsuite: Handle "packed" targets in c-c++-common/auto-init-7.c and -8.c

Tested for cris-elf. Ok to commit? -- >8 -- Looks like there's a failed assumption that sizeof (union U { char u1[5]; int u2; float u3; }) == 8. However, for "packed" targets like cris-elf, it's 5. These two tests have always failed for cris-elf. I see from https://gcc.gnu.org/pipermail/gcc-tes

[PATCH] testsuite: Add CRIS to check_effective_target_lra non-LRA list

I'd much rather install https://gcc.gnu.org/pipermail/gcc-patches/2023-February/611531.html than this one, because obviously a general solution is better than a target list. But, that would require approval, and I got NAK. This change however, piling on to the target list, is within target mainta

[PATCH] objs-gcc.sh: Only bootstrap if source-directory contains gcc

TL;DR: committed as obvious. -- >8 -- I use objs-gcc.sh as a preparatory step before calling btest-gcc.sh in my scripts, for example my cris-elf autotester. I thought, why not use it for native builds too. Except that use, with binutils release-style tarballs and a x86_64-pc-linux-gnu host, was b

[PATCH] testsuite: Tweak gcc.dg/attr-aligned.c for CRIS

Asking for the lines outside the "#if __CRIS__" part. Ok to commit? -- >8 -- tm.texi says for BIGGEST_ALIGNMENT (from which __BIGGEST_ALIGNMENT__ is derived): "Biggest alignment that any data type can require on this machine, in bits." That is, using that value might be too strict for alignment o

Sort-of ping for [PATCH] testsuite: Handle "packed" targets in c-c++-common/auto-init-7.c and -8.c

> From: Qing Zhao > Date: Wed, 15 Feb 2023 20:30:00 +0100 > Thank you for fixing this issue. Thanks! Although you're not holding an approver position I'm tempted to take that as approval, as you're the author of that test. This being a patch of no particular significance and having seen no oth

[PATCH] testsuite: Add -fno-ivopts to gcc.dg/Wuse-after-free-2.c, PR108828

Ok to commit? I suggest that when committed I'll also set the bugzilla entry in SUSPENDED mode, as opposed to RESOLVED. I mean, the issue isn't really solved; that'd be a patch improving pointer tracking across ivopts. -- >8 -- For cris-elf before this patch, ever since it was added, this test g

[PATCH] testsuite: Don't include multiline regexps in the the pass/fail log

Ok to commit? -- >8 -- I see overlong lines in the output when a test fails, for example for a bug exposed for cris-elf and pru-elf in gcc.dg/analyzer/allocation-size-multiline-3.c: Running /x/gcc/testsuite/gcc.dg/analyzer/analyzer.exp ... FAIL: gcc.dg/analyzer/allocation-size-multiline-3.c expec

[PATCH 1/2] testsuite: Provide means to regexp in multiline patterns

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 thought, it can be argued that "(...)" alone is not useful). Note that Tcl "string map" is documen

[PATCH 2/2] testsuite: Fix gcc.dg/analyzer/allocation-size-multiline-3.c

I'll install this as obvious provided that the prerequisite multiline.exp patch is approved. -- >8 -- For 32-bit newlib targets (such as cris-elf and pru-elf), that int32_t is "long int". See other regexps in the testsuite matching "aka (long )?int" (with single-quotes where needed) where the patt

Re: [PATCH] testsuite: Don't include multiline patterns in the the pass/fail log

> From: David Malcolm > Date: Fri, 24 Feb 2023 14:07:02 -0500 > Old-Content-Type: text/plain; charset="UTF-8" > Old-Content-Transfer-Encoding: base64 > Content-Type: TEXT/plain; charset=iso-8859-1 > > On Fri, 2023-02-24 at 18:54 +0100, Hans-Peter Nilsson wrote: > > Ok to commit? > > Looks good t

Re: [PATCH] testsuite: Don't include multiline regexps in the the pass/fail log

> From: Mike Stump > Date: Mon, 27 Feb 2023 09:41:18 -0800 > > diff --git a/gcc/testsuite/lib/multiline.exp > > b/gcc/testsuite/lib/multiline.exp > > index 84ba9216642e..5eccf2bbebc1 100644 > > --- a/gcc/testsuite/lib/multiline.exp > > +++ b/gcc/testsuite/lib/multiline.exp > > > - ${maybe

[COMMITTED] testsuite: Add CRIS to targets not xfailing gcc.dg/attr-alloc_size-11.c:50, 51

Reacting to a long-standing XPASS for CRIS. Maybe better do as https://gcc.gnu.org/PR79356#c11 suggests: xfail it for x86 only ...except I see m68k also does not xpass. testsuite: PR testsuite/79356 * gcc.dg/attr-alloc_size-11.c: Add CRIS to the list of targets excluding x

[COMMITTED] testsuite: Remove xfail gcc.dg/tree-ssa/pr91091-2.c RHS ! natural_alignment_32

Committed as obvious. -- >8 -- Reacting to a long-standing XPASS for CRIS. This one is slightly brown paper-bag level; it was never the here-removed xfailed scan that failed and I didn't notice that XPASS when reporting success on the commit as a whole. It's not logical to re-read what was just-w

[COMMITTED] testsuite: Shorten multiline pattern message to the same for fail and pass

As recommended by testsuite maintainer: Regression analysis works only if the string is the same. testsuite: * lib/multiline.exp (handle-multiline-outputs): Shorten message to the same for fail and pass. --- gcc/testsuite/lib/multiline.exp | 4 ++-- 1 file changed, 2 insertions(+)

[COMMITTED] testsuite: No xfail infoleak-vfio_iommu_type1.c bogus for default_packed

Committed as obvious after sanity-checking cris-elf and native x86_64-linux. -- >8 -- There are no messages about padding for targets that don't pad, i.e. default_packed. Noticed for cris-elf, verified for pru-elf at gcc-testresults@. testsuite: * gcc.dg/plugin/infoleak-vfio_iommu_type1.c

Ping: [PATCH] testsuite: Tweak gcc.dg/attr-aligned.c for CRIS

Ping... > From: Hans-Peter Nilsson > Date: Thu, 16 Feb 2023 21:05:29 +0100 > Asking for the lines outside the "#if __CRIS__" part. > Ok to commit? > > -- >8 -- > tm.texi says for BIGGEST_ALIGNMENT (from which > __BIGGEST_ALIGNMENT__ is derived): "Biggest alignment that > any data type can requi

[PATCH 1/2] testsuite: Fix analyzer errors for newlib-errno

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

[PATCH 2/2] testsuite: Fix analyzer errors for newlib-fd

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

Re: [PATCH 1/2] testsuite: Fix analyzer errors for newlib-errno

> 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@. > > >

Re: [PATCH 1/2] testsuite: Fix analyzer errors for newlib-errno

> 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? > > > >

Re: [PATCH 1/2] testsuite: Fix analyzer errors for newlib-errno

> 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

Re: [PATCH 1/2] testsuite: Fix analyzer errors for newlib-errno

> 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

Re: [PATCH 1/2] testsuite: Fix analyzer errors for newlib-errno

> 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 > > > >

Re: [PATCH 1/2] testsuite: Fix analyzer errors for newlib-errno

> 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

[COMMITTED] testsuite: Fix gcc.dg/attr-copy-6.c for user-label-prefixed targets

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)

[COMMITTED] testsuite: Fix g++.dg/ext/attr-copy-2.C for default_packed targets

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,

[COMMITTED] testsuite: Fix various scan-assembler identifiers not handling _-prefix

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] testsuite: Skip gcc.dg/ifcvt-4.c for CRIS

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] testsuite: Skip gcc.dg/ipa/pr77653.c for CRIS

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

Ping: [PATCH 1/2] testsuite: Provide means to regexp in multiline patterns

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

[PATCH 1/3] testsuite: Add tail_call effective target

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

[PATCH 2/3] doc: Document testsuite check_effective_target_tail_call

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

[PATCH 3/3] testsuite: Gate gcc.dg/plugin/must-tail-call-1.c and -2.c on tail_call

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

[PATCH] testsuite: Support scanning tree-dumps

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

Re: Ping: [PATCH 1/2] testsuite: Provide means to regexp in multiline patterns

> 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

[PATCH] testsuite: Fix omp-parallel-for-get-min.c and -for-1.c for non-openmp

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

[PATCH] testsuite: Handle default_packed targets in gcc.dg/plugin

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] testsuite: gcc.dg/pr106397.c: Add -w to options

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. ---

[committed] testsuite: gcc.dg/pr108117.c: Require effective-target scheduling

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] testsuite: Tweak check_fork_available for CRIS

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. *

[PATCH] doc: md.texi (Insn Splitting): Tweak wording for readability.

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

[PATCH v2] doc: md.texi (Insn Splitting): Tweak wording for readability.

> 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

[committed] CRIS: Fix ccmode typo in cris_postdbr_cmpelim

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

Re: [committed] Convert xstormy16 to LRA

> 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

Re: [committed] Convert xstormy16 to LRA

> 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

Re: [committed] Convert xstormy16 to LRA

> 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

Re: [committed] Convert xstormy16 to LRA

> 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

Re: [committed] Convert xstormy16 to LRA

> 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

Re: [committed] Convert xstormy16 to LRA

> 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 > >

Committed: gcc.misc-tests/outputs.exp (outest): Fix typo "is_target"

Committed as obvious. Please be more careful; this typo should have been obvious in "make check" output as below. Commit-log: --- Fix typo for istarget in "is_target hppa*-*-hpux*", yielding an error running the test-suite for any target not matching powerpc*-*-aix* (p

Re: Committed: gcc.misc-tests/outputs.exp (outest): Fix typo "is_target"

> From: Bernd Edlinger > Date: Tue, 16 Feb 2021 08:35:04 +0100 > Oops, > > thanks for fixing this problem. > > To my excuse I would like to note, > that the script error does not happen on x86_64-pc-linux-gnu, > probably it would only happen when a file is left over. Sorry but that just sounds

[PATCH] match.pd: Restrict clz cmp 0 replacement by single_use, PR99142

If we're not going to eliminate the clz, it's better for the comparison to use that result than its input, so we don't extend the lifetime of the input. Also, an additional use of the result is more likely cheaper than a compare of the input, in particular considering that the clz may have made av

Re: [PATCH] match.pd: Restrict clz cmp 0 replacement by single_use, PR99142

> From: Richard Biener via Gcc-patches > Date: Thu, 18 Feb 2021 11:12:26 +0100 > On Thu, Feb 18, 2021 at 12:35 AM Hans-Peter Nilsson via Gcc-patches > wrote: > > > > If we're not going to eliminate the clz, it's better for the > > comparison to use

cris: Fix addi insn mult vs. shift canonicalization

Ever since the canonicalization clean-up of (mult X (1 << N)) into (ashift X N) outside addresses, the CRIS addi patterns have been unmatched. No big deal. Unfortunately, nobody thought of adjusting reloaded addresses, so transforming mult into a shift has to be a kludged for when reload decides

cris: testsuite/gcc.target/cris/biap-mul.c: New test.

Needed coverage for that *addi_mul pattern. Committed. gcc/testsuite: * gcc.target/cris/biap-mul.c: New test. --- gcc/testsuite/gcc.target/cris/biap-mul.c | 15 +++ 1 file changed, 15 insertions(+) create mode 100644 gcc/testsuite/gcc.target/cris/biap-mul.c diff --git a/gcc

cris: testsuite/gcc.target/cris/biap.c: Add a Y+=X*2 to the Y+=X*4.

Also, tweak the scan-assembler regexps to include a tab, lest they may spuriously match file-paths in the emitted assembly code, should some be added at some point. And, add "mul", "move" and (non-addi-)"add" to insns that shouldn't appear. Committed. gcc/testsuite: * gcc.target/cris/bia

Committed: g++.dg/warn/Warray-bounds-10..13: Fix for 32-bit newlib targets

See gcc/config/newlib-stdint.h, where targets that have LONG_TYPE_SIZE == 32, get __INT32_TYPE__ defined to "long int". All these tests have "typedef __INT32_TYPE__ int32_t;". Thus the tests fail for 32-bit newlib targets due to related warning messages being matched to "aka int" where the emitted

Committed: g++.dg/warn/Wplacement-new-size-1.C, -2, -6: Fix for default_packed targets

Looking at commit de05c19d5fd6, that adjustment to these tests apparently assumed that the testsuite is run (only) on targets where structure memory layout has padding as per "natural alignment". For cris-elf, a target with no padding in structure memory layout, these tests have been failing since

Re: Committed: g++.dg/warn/Wplacement-new-size-1.C, -2, -6: Fix for default_packed targets

> From: Martin Sebor > Date: Tue, 23 Feb 2021 02:07:59 +0100 > On 2/22/21 5:48 PM, Hans-Peter Nilsson wrote: > > Looking at commit de05c19d5fd6, that adjustment to these > > tests apparently assumed that the testsuite is run (only) on > > targets where structure memory layout has padding as per >

Committed: cris: support -fstack-usage

All the bits were there, used with a pre-existing -mmax-stackframe=SIZE which unfortunately seems to lack test-cases. Note that the early-return for -mno-prologue-epilogue (what some targets call -mnaked) is deliberately not clearing current_function_static_stack_size, as I consider that erroneous

[PATCH] outputs.exp: skip @file -save-temps if target has -L or -I

The outputs.exp tests check what temporary files are created and left behind with e.g. -save-temps. Additional files are created in presence of @file option. Adding an -I or -L option causes *another* temporary file to appear. I take it that's deliberate, as there are tests for that behavior. Fo

[PATCH] gcc.misc-tests/outputs.exp: assert unique test-names

The gcc.misc-tests/outputs.exp tests can take some effort to digest. Navigating and debugging causes for failing tests here isn't helped by the existence of tests with duplicate names. Let's stop that from happening. This requires that test-run output is actually reviewed, as Tcl errors don't sto

Committed, pr95690.f90: move error line for CRIS.

I don't know what it is that ix86, x86_64, Solaris and apparently CRIS has in common here. According to https://gcc.gnu.org/pipermail/gcc-testresults/2021-February/652763.html m68k-unknown-linux-gnu is also in that bunch, but since there's a *-*-solaris* in the target specifier and also m68k vs. m

[PATCH/RFA] libstdc++: provide conversion from day, month to unsigned long, PR99301

Since 97d6161f6a7fa712 / r11-7370 "libstdc++: More efficient days from date" I see an additional 81 testsuite-errors for cris-elf, with this in g++.log for one randomly picked regressing test: FAIL: g++.dg/cpp1y/pr57640.C -std=c++2a (test for excess errors) Excess errors: /x/gccobj/cris-elf/libst

Re: [PATCH] gcc.misc-tests/outputs.exp: assert unique test-names

; charset=iso-8859-1 > > > > On 2/24/21 10:17 PM, Hans-Peter Nilsson via Gcc-patches wrote: > > The gcc.misc-tests/outputs.exp tests can take some effort to > > digest. > > > > Navigating and debugging causes for failing tests here isn't > > helped by

gcc.misc-tests/outputs.exp: enumerate tests

> From: Hans-Peter Nilsson > Date: Tue, 2 Mar 2021 23:58:08 +0100 > > From: Jeff Law > > Date: Tue, 2 Mar 2021 23:39:27 +0100 > > On 2/24/21 10:17 PM, Hans-Peter Nilsson via Gcc-patches wrote: > > > Ok to commit? Or is a renaming patch appe

Committed: gcc.dg/debug/dwarf2/stacked-qualified-types-3.c: xfail for cris

Tested cris-elf and x86_64-linux to eliminate the edit being fatfingered. The test is still failing and is a regression on master for cris-elf: the remedy for (all) other targets wasn't sufficient. I'm not myself going to put any effort into it (debug-information being different enough for a test

Committed: gcc.target/cris/pr93372-1.c: Adjust expectations for eliminated stack-frame

See comment. * gcc.target/cris/pr93372-1.c: Adjust expected assembler result to allow an eliminated stack-frame. --- gcc/testsuite/gcc.target/cris/pr93372-1.c | 11 ++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/gcc/testsuite/gcc.target/cris/pr93372-1.c

Committed: cris: don't define MAX_FIXED_MODE_SIZE

It's been 32 ever since the CRIS port was committed. A TODO-item of mine has been to check whether the non-default setting of MAX_FIXED_MODE_SIZE makes sense wrt. performance and/or code-size with a modern gcc. It doesn't, so it goes. The setting is now the default, GET_MODE_BITSIZE (DImode) (def

Committed: gcc.dg/uninit-pred-9_b.c: Xfail for CRIS too

Adding to the growing list, for autotester accounting purposes. FWIW I see this fails for m68k too: https://gcc.gnu.org/pipermail/gcc-testresults/2021-August/712395.html and moxie: https://gcc.gnu.org/pipermail/gcc-testresults/2021-August/712389.html and pru: https://gcc.gnu.org/pipermail/gcc-test

gfortran.dg/PR82376.f90: Avoid matching a file-path.

I had a file-path to sources with the substring "new" in it, and (only) this test regressed compared to results from another build without "new" in the name. The test does ! { dg-final { scan-tree-dump-times "new" 4 "original" } } i.e. the contents of the tree-dump-file .original needs to match t

Re: gfortran.dg/PR82376.f90: Avoid matching a file-path.

> From: Bernhard Reutner-Fischer > Date: Thu, 12 Aug 2021 09:03:50 +0200 > On Thu, 12 Aug 2021 00:09:21 +0200 > Hans-Peter Nilsson via Fortran wrote: > > > I had a file-path to sources with the substring "new" in it, > > and (only) this test regressed compared to results from > > another build

[PATCH] toplevel: Makefile.def: Make configure-sim depend on all-readline

Tom Tromey ok'd this for the sourceware side, but thinks I need explicit approval on the gcc side. Ok to commit? --- Start of forwarded message --- From: Hans-Peter Nilsson To: "binut...@sourceware.org" , "gdb-patc...@sourceware.org" Subject: [PATCH] toplevel: Makefile.def: Make

[PATCH] libstdc++-v3 testsuite: Call fesetround(FE_DOWNWARD) only if defined

Ok to commit? - 8< - Without this, for a typical soft-float target such as cris-elf, after commit r12-7676-g5a4e208022e704 you'll see, in libstdc++.log: ... FAIL: 20_util/from_chars/6.cc (test for excess errors) Excess errors: /home/hp/tmp/auto0321/gcc/libstdc++-v3/testsuite/20_util/from_

[PATCH] libstdc++-v3 expected: Don't test ABI-variant properties in requirements.cc

Ok to commit? -- 8< -- Without this, for a target where alignment and structure-sizes are by default byte-aligned, such as cris-elf, you'll see, in libstdc++.log: /X/gcc/libstdc++-v3/testsuite/20_util/expected/requirements.cc:127: error: static assertion failed /X/gcc/lib

Re: [PATCH] libstdc++-v3 expected: Don't test ABI-variant properties in requirements.cc

> From: Jonathan Wakely > Date: Tue, 5 Apr 2022 20:47:58 +0200 > On Tue, 5 Apr 2022, 17:44 Hans-Peter Nilsson via > Libstdc++, > mailto:libstdc%2b...@gcc.gnu.org>> > wrote: > Ok to commit? > -- 8< -- > > Without this, for a target where alignment and structure-sizes are b

[COMMITTED] readings.html: developer.axis.com is gone, remove

Unfortunately I know of no replacement. --- htdocs/readings.html | 1 - 1 file changed, 1 deletion(-) diff --git a/htdocs/readings.html b/htdocs/readings.html index 8689eab8b2d1..2467945b1cb6 100644 --- a/htdocs/readings.html +++ b/htdocs/readings.html @@ -118,7 +118,6 @@ names. Manufacturer:

  1   2   3   >