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

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

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

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 memor

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

ope-from="jeffreya...@gmail.com"; > x-sender="postmas...@mail-il1-f172.google.com"; > x-conformance=sidf_compatible > Old-Content-Type: multipart/alternative; > boundary="_000_08d773b4a6cd248fc44aa1877542afabgmailcom_" > Content-Type: text/plain

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 compa

[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: [PATC

[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

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

[PATCH] doc/install.texi: CRIS: Remove gone websites. Adjust CRIS targets

I'm about to commit this to master. I'd like to also install this on the gcc-11 branch. Ok? -- 8< -- That is, support for cris-linux-gnu was removed in gcc-11, but install.texi wasn't adjusted accordingly. Also, unfortunately the developer-related sites are gone with no replacements. And, CRI

[PATCH] doc/invoke.texi: CRIS: Remove references to cris-axis-linux-gnu

I'm about to commit this to master. I'd like to also install this on the gcc-11 branch. Ok? -- 8< -- ...and related options. These stale bits were overlooked when support for "Linux/GNU" and CRIS v32 was removed, before the gcc-11 release. Resulting pdf, html and info inspected for sanity. g

Re: [PATCH] doc/invoke.texi: CRIS: Remove references to cris-axis-linux-gnu

> From: Hans-Peter Nilsson > gcc: > * doc/install.texi : Remove references to removed websites and > adjust for cris-*-elf being the only remaining toolchain. Oops, cutnpasto for the ChangeLog entry. :( This one fits better: * doc/invoke.texi : Remove reference

[COMMITTED] readings.html: Add replacement URL for CRIS Programmer's Manual

Also available through the wayback machine, but only a valid currently-working URL is appropriate on that page, IMHO. Thanks to Paul Koning for finding it. --- htdocs/readings.html | 1 + 1 file changed, 1 insertion(+) diff --git a/htdocs/readings.html b/htdocs/readings.html index 2467945b1cb6..

Re: [committed] libstdc++: Fix std::atomic> for AIX [PR104101]

> From: Jonathan Wakely via Gcc-patches > Date: Wed, 19 Jan 2022 02:03:58 +0100 > Tested powerpc64le-linux, powerpc-aix, pushed to trunk. > > > This fixes a testsuite failure I'm guessing the actual number is in the tens. > on AIX. ...and by the looks of it, some 60 regressions (as counted b

Re: [pushed] c++: layout of aggregate base with DMI [PR103681]

> From: Jason Merrill via Gcc-patches > Date: Fri, 17 Dec 2021 04:26:55 +0100 > C++14 changed the definition of 'aggregate' to allow default member > initializers, but such classes still need to be considered "non-POD for the > purpose of layout" for ABI compatibility with C++11 code. It seems r

[PATCH] libstdc++ testsuite: Increase lwg3464.cc timeout factors to 20

These tests have always been failing for my cris-elf autotester running a simulator; they take about 20 minutes each, compared to the timeout of 720 seconds, doubled because they timed out in another simulator setup. They are the *only* libstdc++ tests that timeout for my setup so I thought this'd

[PATCH] libstdc++ testsuite: Don't run lwg3464.cc tests on simulators to 20

(I had to add separation between your reply and mine in the quoted parts; you may be aware.) > From: Jonathan Wakely > Date: Sun, 30 Jan 2022 09:32:08 +0100 > On Sun, 30 Jan 2022, 01:37 Hans-Peter Nilsson via Libstdc++, > mailto:libstdc%2b...@gcc.gnu.org>> wrote: > >

Re: [PATCH] libstdc++ testsuite: Don't run lwg3464.cc tests on simulators to 20

> From: Jonathan Wakely > Date: Sun, 30 Jan 2022 18:06:28 +0100 > On Sun, 30 Jan 2022 at 16:54, Hans-Peter Nilsson wrote: > > > From: Jonathan Wakely > > > But there is nothing target-specific in that code, so it > > > should be fine to disable them f

[PATCH] reload: Adjust find_reloads to comment; test intersection, not subset

I'm not seriously submitting this patch for approval. I just thought it'd be interesting to some people, at least those maintaining ports still using reload; I know it's reload and major ports don't really care about that anymore. TL;DR: scroll down for the mystery part. The *benevolent* effects

[PATCH] reload: Adjust comment in find_reloads about subset, not intersection

> From: Richard Sandiford > Hans-Peter Nilsson via Gcc-patches writes: > > The mystery isn't so much that there's code mismatching comments or > > intent, but that this code has been there "forever". There has been a > > function reg_classes_i

[PATCH 0/5] A few CRIS port improvements

I'm taking advantage of CRIS being a lesser important target and as such not subject to the constraints of GCC being in stage 4. I'm applying this set of CRIS-specific changes that don't have much expected effect on generated code. 1: cris: Don't default to -mmul-bug-workaround Avoid the workaroun

[PATCH 1/5] cris: Don't default to -mmul-bug-workaround

This flips the default for the errata handling for an old version (TL;DR: workaround: no multiply instruction last on a cache-line). Newer versions of the CRIS cpu don't have that bug. While the impact of the workaround is very marginal (coremark: less than .05% larger, less than .0005% slower) it

[PATCH 2/5] cris: For expanded movsi, don't match operands we know will be reloaded

In a session investigating unexpected fallout from a change, I noticed reload needs one operand being a register to make an informed decision. It can happen that there's just a constant and a memory operand, as in: (insn 668 667 42 104 (parallel [ (set (mem:SI (plus:SI (reg/v/f:SI 347

[PATCH 3/5] cris: Remove CRIS v32 ACR artefacts

This is the change to which I alluded to this in r11-220 / d0780379c1b6 as "causes extra register moves in libgcc". It has unfortunate side-effects due to the change in register-class topology. There's a slight improvement in coremark numbers (< 0.07%) though also increase in code size total (< 0.

[PATCH 4/5] cris: Don't discriminate against ALL_REGS in TARGET_REGISTER_MOVE_COST

When the tightest class including both SPECIAL_REGS and GENERAL_REGS is ALL_REGS, artificially special-casing for *either* to or from, hits artificially hard. This gets the port back to the code quality before the previous patch ("cris: Remove CRIS v32 ACR artefacts") - except for_vfprintf_r and _

[PATCH 5/5] cris: Reload using special-regs before general-regs

On code where reload has an effect (i.e. quite rarely, just enough to be noticeable), this change gets code quality back to the situation prior to "Remove CRIS v32 ACR artefacts". We had from IRA a pseudoregister marked to be reloaded from a union of all allocatable registers (here: SPEC_GENNONACR

Re: [PATCH] reload: Adjust comment in find_reloads about subset, not intersection

> Date: Wed, 2 Feb 2022 16:16:14 +0100 > Old-Content-Type: multipart/alternative; boundary="_000_mpta6f9fge9fsfarmcom_" > Content-Type: text/plain; charset=iso-8859-1 > > Richard Sandiford writes: > > Hans-Peter Nilsson writes: > >>> From: Richard Sa

[PATCH] testsuite: Use attribute "noipa" in sibcall tests

...instead of attribute "noinline". For cris-elf, testsuite/gcc.dg/sibcall-3.c and sibcall-4.c "XPASS", without sibcalls being implemented. On inspection, recurser_void2 is set to be an assembly-level alias for recurser_void1 as in ".set _recurser_void2,_recurser_void1" for both these cases. IOW

Re: *PING* [PATCH 0/4] Use pointer arithmetic for array references [PR102043]

> From: Thomas Koenig via Gcc-patches > Date: Fri, 22 Apr 2022 15:59:45 +0200 > Hi Mikael, > > > Ping for the four patches starting at > > https://gcc.gnu.org/pipermail/fortran/2022-April/057759.html : > > https://gcc.gnu.org/pipermail/fortran/2022-April/057757.html > > https://gcc.gnu.org/pipe

Re: [PATCH] Remove GIMPLE restriction of ! using match.pd patterns

> From: Richard Biener via Gcc-patches > Date: Mon, 9 May 2022 13:42:27 +0200 > This removes #if GIMPLE guards around patterns using ! which is > now also provided in the GENERIC implementation. > > Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed. > > 2022-05-09 Richard Biener >

[PATCH] libstdc++-v3: Set 26_numerics/random/n.b.d./op./values.cc timeout-factor to 3

Also, how about shortening those test-suite file-paths? They're path sort-of overlong for any git (and ChangeLog) commit-line limit. 1/2 :-) Ok to commit (without renaming)? --- 8< --- I happened to run my cris-elf regression-tester and some large job in parallel when this test was running. Acc

Re: [PATCH] libstdc++-v3: Set 26_numerics/random/n.b.d./op./values.cc timeout-factor to 3

> From: Jonathan Wakely > Date: Fri, 20 May 2022 11:03:40 +0200 > > Ok to commit (without renaming)? > > I'm OK with the timeout factor, but we could also solve it differently > so that it doesn't take nearly 5 minutes, as in the attached patch. > The testDiscreteDist function can be parametrize

[Committed] Fix fatal typo in gcc.dg/no_profile_instrument_function-attr-2.c

(Committed as obvious.) Dejagnu is unfortunately brittle: a syntax error in a directive can abort the test-run for the current "tool" (gcc, g++, gfortran), and if you don't check for this condition or actually read the stdout log yourself, your tools may make you believe the test was successful wi

Re: [Committed] Fix fatal typo in gcc.dg/no_profile_instrument_function-attr-2.c

> From: Martin Liaka > Date: Wed, 8 Sep 2021 09:29:52 +0200 > On 9/7/21 22:41, Hans-Peter Nilsson wrote: > > With r12-3379, the testsuite got such a fatal syntax error, > > causing the gcc test-run to abort at (e.g.): > > Thank you for the fix! I haven't notice

Re: [PATCH] PR middle-end/103059: reload: Also accept ASHIFT with indexed addressing

> From: "Maciej W. Rozycki" > Date: Wed, 3 Nov 2021 14:53:58 +0100 > gcc/ > PR middle-end/103059 > * reload.c (find_reloads_address_1): Also accept the ASHIFT form > of indexed addressing. > (find_reloads): Adjust accordingly. > --- > gcc/reload.c |9 ++---

Re: [PATCH] PR middle-end/103059: reload: Also accept ASHIFT with indexed addressing

> From: "Maciej W. Rozycki" > Date: Wed, 3 Nov 2021 14:53:58 +0100 > gcc/ > PR middle-end/103059 > * reload.c (find_reloads_address_1): Also accept the ASHIFT form > of indexed addressing. > (find_reloads): Adjust accordingly. > --- > gcc/reload.c |9 ++---

[PATCH] libstdc++: Use GCC_TRY_COMPILE_OR_LINK for getentropy, arc4random

Since r12-5056-g3439657b0286, there has been a regression in test results; an additional 100 FAILs running the g++ and libstdc++ testsuite on cris-elf, a newlib target. The failures are linker errors, not finding a definition for getentropy. It appears newlib has since 2017-12-03 declarations of

[Committed] gcc.dg/uninit-pred-9_b.c: Correct last adjustment for cris-elf

The change at r12-4790 should have done the same change for CRIS as was done for powerpc64*-*-*. (Probably MMIX too but that may have to wait until the next weekend.) Committed. gcc/testsuite: * gcc.dg/uninit-pred-9_b.c: Correct last adjustment, for CRIS. --- gcc/testsuite/gcc.dg/uninit

Re: [PATCH 04/11] cris: Update unexpected empty split condition

> From: Kewen Lin > Date: Wed, 2 Jun 2021 07:04:54 +0200 > gcc/ChangeLog: > > * config/cris/cris.md (*addi_reload): Fix empty split condition. > --- > gcc/config/cris/cris.md | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/gcc/config/cris/cris.md b/gcc/config/cri

Re: [PATCH 04/11] cris: Update unexpected empty split condition

> From: Kewen.Lin > Date: Thu, 3 Jun 2021 07:45:57 +0200 > on 2021/6/2 Hans-Peter Nilsson wrote: > >> From: Kewen Lin > >> Date: Wed, 2 Jun 2021 07:04:54 +0200 > > > >> gcc/ChangeLog: > >> > >>* config/cris/cris.md (*addi_r

Re: [PATCH 04/11] cris: Update unexpected empty split condition

> From: Hans-Peter Nilsson > CC: "gcc-patches@gcc.gnu.org" > Date: Thu, 3 Jun 2021 18:12:25 +0200 > I'd > prefer to have the patch above committed sooner than the > conclusion of that discussion. (If you don't get to it, > I'll do it, after a round

reorg.c (fill_slots_from_thread): Reinstate code typoed out in "Remove CC0".

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

doc/tm.texi.in (Condition Code): Tweak post-cc0 wording.

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

Re: doc/tm.texi.in (Condition Code): Tweak post-cc0 wording.

> 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

build broke, cris-elf: [committed] libstdc++: Implement C++20 time zone support in

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

[committed] testsuite: Xfail gcc.dg/tree-ssa/update-threading.c for CRIS, PR110628

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

Re: Fix profile update in tree-ssa-reassoc

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

Re: [PATCH] libstdc++: Use GLIBCXX_CHECK_LINKER_FEATURES for cross-builds (PR111238)

> 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

Re: [PATCH] libstdc++: Use GLIBCXX_CHECK_LINKER_FEATURES for cross-builds (PR111238)

> 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

Re: [PATCH] analyzer: implement reference count checking for CPython plugin [PR107646]

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

Re: [RFC] libstdc++: Make --enable-libstdcxx-backtrace=auto default to yes

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

Re: [RFC] libstdc++: Make --enable-libstdcxx-backtrace=auto default to yes

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

Re: [RFC] libstdc++: Make --enable-libstdcxx-backtrace=auto default to yes

> 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

Re: [RFC] libstdc++: Make --enable-libstdcxx-backtrace=auto default to yes

> 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

Re: RFC: Introduce -fhardened to enable security-related flags

> 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

Re: RFC: Introduce -fhardened to enable security-related flags

> 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

Re: RFC: Introduce -fhardened to enable security-related flags

> 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

Re: RFC: make combine do as advertised (cheaper-than)?

(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

Re: RFA: Fix combine.c combining a move and a non-move into two non-moves, PR93372

> 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

gcc.dg/pr94600-5.c .. -8.c: Align struct t0 explictly, as a type, PR middle-end/94600

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

reorg.c (fill_slots_from_thread): Improve for TARGET_FLAGS_REGNUM targets

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

Re: reorg.c (fill_slots_from_thread): Improve for TARGET_FLAGS_REGNUM targets

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

Re: reorg.c (fill_slots_from_thread): Improve for TARGET_FLAGS_REGNUM targets

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

Re: reorg.c (fill_slots_from_thread): Improve for TARGET_FLAGS_REGNUM targets

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

Re: reorg.c (fill_slots_from_thread): Improve for TARGET_FLAGS_REGNUM targets

> 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); > > +

[PATCH 2/2] doc/implement-c.texi: About same-as-scalar-type volatile aggregate accesses, PR94600

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

Re: [PATCH 1/2] PR94600: fix volatile access to the whole of a compound object.

> 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

Re: [PATCH 2/2] doc/implement-c.texi: About same-as-scalar-type volatile aggregate accesses, PR94600

> 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

Re: [PATCH 2/2] doc/implement-c.texi: About same-as-scalar-type volatile aggregate accesses, PR94600

> 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

Re: RFA: Fix combine.c combining a move and a non-move into two non-moves, PR93372

> 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

Re: RFA: Fix combine.c combining a move and a non-move into two non-moves, PR93372

> 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

<    18   19   20   21   22   23   24   >