[PATCH] Fix makeinfo error from recently-added nodes missing in menu

The 6.7 version is what's in Debian 11. I'll commit this as obvious in a few hours. -- >8 -- Commit r16-833-gfbb7f1cb5d3c8b appears to have broken builds with makeinfo from texinfo 6.7 (Debian: 6.7.0.dfsg.2-6) - but not 6.8 (6.8-6+b1). With 6.7, I see (linebreaks manually added): if [ xinfo = x

Re: [PATCH] strlen: Handle empty constructor as memset for combining with malloc to calloc [PR87900]

Random-typo-spotting-mode activated: On Sat, 19 Apr 2025, Andrew Pinski wrote: > +++ b/gcc/testsuite/gcc.dg/tree-ssa/calloc-10.c > +/* zeroing out via a CONSTRUCTOR should be treated similarly as a msmet and "memset" > diff --git a/gcc/testsuite/gcc.dg/tree-ssa/calloc-11.c > b/gcc/testsuite/gc

[COMMITTED v2] combine: Correct comments about combine_validate_cost

> From: Richard Sandiford > Date: Tue, 15 Apr 2025 09:23:21 +0100 > > Ok to commit? > > OK, thanks. Thanks! Though, I noticed another "cheaper" in the function header. Fixing that one was a more obvious correction (thus committed as such), as per the commit message: what the function determine

Re: [PATCH] testsuite: Add support for GCOV_UNDER_TEST

> From: Christophe Lyon > Date: Wed, 16 Apr 2025 14:41:17 +0200 > ping? Since you directed it at me and CC:ed the list; in case that was deliberate: I can only repeat "still ok", but I don't have approval rights to the testsuite parts. > > On Thu, 10 Apr 202

Re: [PATCH] libstdc++: Fix constraint recursion in basic_const_iterator operator- [PR115046]

On Tue, 8 Apr 2025, Patrick Palka wrote: > Tested on x86_64-pc-linux-gnu, does this look OK for trunk/14? It's not mentioned very often, but is a general rule: Pretty please, add new files for new tests, don't just edit existing files. (For one: if they start failing, they look like regressio

[PATCH] combine: Correct comment about combine_validate_cost

Noticed while investigating a regression for cris-elf with r15-9239-g4d7a634f6d4102 "combine: Allow 2->2 combinations, but with a tweak [PR116398]" (to-be-reported). The comment was introduced when breaking out the combine_validate_cost function, in r0-59417-g64b8935d4809f3. I thought about words

Re: [PATCH] testsuite: Add support for GCOV_UNDER_TEST

> From: Christophe Lyon > Date: Thu, 10 Apr 2025 15:38:48 +0200 > On Thu, 10 Apr 2025 at 15:29, Hans-Peter Nilsson wrote: > > > > > From: Christophe Lyon > > > Date: Thu, 10 Apr 2025 15:21:23 +0200 > > > > Not sure why I'm CC:ed on this o

Re: [PATCH] testsuite: Add support for GCOV_UNDER_TEST

> From: Christophe Lyon > Date: Thu, 10 Apr 2025 15:21:23 +0200 Not sure why I'm CC:ed on this one, not being a maintainer of the testsuite or targets where gcov tests are exercised, but FWIW: LGTM except for the two nits: > ping? > > On Tue, 1 Apr 2025 at 22:37, Christophe Lyon > wrote: > >

Re: [PATCH] [testsuite] [riscv] xfail update-threading on riscv [PR110628]

> From: Alexandre Oliva > Date: Mon, 31 Mar 2025 20:59:23 -0300 > On Mar 31, 2025, Jeff Law wrote: > > >> PR tree-optimization/110628 > >> * gcc.dg/tree-ssa/update-threading.c: XFAIL on riscv. > > ?!? This is passing on my tester: > > Indeed, despite the lack of any activity in the PR that cou

[COMMITTED] libgfortran/intrinsics: Fix build for targets with int32_t=long int

Not many newlib targets (AFAIK the only targets where GFC_INTEGER_4 alias int32_t is a typedef of long int) build libgfortran. These breaks happen from time to time. I wish there was a method to stop int32_t (and its typedef-alias GFC_INTEGER_4) being type-compatible with int. The commit message

Re: [PATCH v2] reassoc: Optimize CMP/XOR expressions [PR116860]

On Thu, 13 Mar 2025, Konstantinos Eleftheriou wrote: > Testcases for match.pd patterns > `((a ^ b) & c) cmp d | a != b -> (0 cmp d | a != b)` and > `(a ^ b) cmp c | a != b -> (0 cmp c | a != b)` were failing on some targets, > like PowerPC. > > This patch adds an implemenetation for the optimizati

Re: [PATCH][v3] Simple cobol.dg testsuite

On Wed, 12 Mar 2025, Jakub Jelinek wrote: > On Tue, Mar 11, 2025 at 10:06:27PM -0500, Robert Dubner wrote: > On Linux at least when not cross-compiling, exit(1) (or this > STOP RUN ERROR 1) will work as well, I believe the reason is for some > bare metal targets which just don't propagate return

[PATCH] c-pretty-print.cc (pp_c_tree_decl_identifier): Strip private name encoding, PR118303

Regtested native x86_64-linux. Also tested mmix-knuth-mmixware, where it fixes ONE testcase, but one which is a regression on master. The PR component is currently ipa, changed from the original middle-end. IIUC this bug-fix doesn't fit the ipa category IMHO, but rather more general tree-opt

[COMMITTED] testsuite: Replace MMIX-specific adjustments with TARGET_CALLEE_COPIES-adjustments

Also tested that the pattern also matches a TARGET_CALLEE_COPIES-false target. -- >8 -- With the dump now emitting "privatized symbols" in the default "%s.%lu" format also for MMIX, there's still a difference for MMIX. This time it's because numbers have changed (copies introduced before this poin

[COMMITTED] MMIX: Replace format for private symbol output by output-time adjustment

All this started with belated MMIX regression patrol in observance of the holidays, looking at gcc.dg/Wstringop-overflow-27.c as a regression for target mmix. That's because of a single message not matched, where there is "note: destination object 'vla::22'" instead of the expected "note: destinat

Re: [patch 1/2] Add new target hook to assemble a variable

On Thu, 19 Dec 2024, Georg-Johann Lay wrote: > This patch adds a new target hook that allows the backend to asm output > a variable definition in its own way. This hook is needed because > varasm.cc imposes a very restrictive layout for all variable definitions > which will be basically ELF style

[COMMITTED] MMIX: Correct handling of C23 (...) functions, PR117618

This commit fixes a MMIX C23 (...)-handling bug; failing gcc.dg/c23-stdarg-[46789].c execution tests. But, this isn't about a missing "|| arg.type != NULL_TREE" in the PORT_setup_incoming_varargs function like most other PR114175 port bugs exposed by the gcc.dg/c23-stdarg-6.c .. -9.c tests; the M

[COMMITTED, v2] libstdc++-v3/testsuite/.../year_month_day/3.cc, 4.cc: Cut down forsimulators

v2: With Jonathan Wakely's feedback, centering the simulator range on days(0). Different changes than v1, but supposedly minimally intrusive. Committed after testing native x86_64-linux and cross to mmix. -- >8 -- These two long-running tests happened to fail for me when run in parallel (nprocs

Re: [PATCH] libstdc++-v3/testsuite/.../year_month_day/3.cc, 4.cc: Cut down for simulators

On Sat, 28 Dec 2024, Hans-Peter Nilsson wrote: > Hopefully exiting the loop after a million runs ... Correction, FAOD: that'd be "a hundred thousand" for the value in the patch. brgds, H-P

[PATCH] libstdc++-v3/testsuite/.../year_month_day/3.cc, 4.cc: Cut down for simulators

I can't think of a straightforward way to prune these two similar tests to a more meaningful subset: there's no easy pruning to each Nth iteration instead of every iteration. Hopefully exiting the loop after a million runs at the beginning of the tested range of dates, will catch the gist of the te

[COMMITTED] libgfortran: Fix build for targets with int32_t=long int

Not many newlib targets (IIRC the only targets where int32_t is a typedef of long int) build libgfortran. Building and testing fortran testsuite is usually a cheap way to get additional coverage for a port, except that a couple of times a year, there are these silly type-related breakages. Maybe

[PATCH] testsuite/gcc.dg/memcmp-1.c: Cut down a factor of 7 for simulators

I could do it just for target mmix, but that wouldn't help other simulator targets. Using different primes is deliberate. Ok to commit? -- >8 -- Running tests in parallel on my 4.5y+ old laptop made this test time out: the test itself runs in 9m20s, the timeout being 10 minutes with the 2x facto

[Committed] testsuite: Force max-completely-peeled-insns=300 for CRIS, PR118055

Committed. An alternative would have been to restrict the scan-tree-dump-times lines in the tests to a list of known targets, but that's more of a testsuite maintainer-level change (not actually a valid excuse). CC to m68k maintainers, who might want to check that 300 fits and add m68k to the lis

[PATCH] testsuite/gcc.dg/tree-ssa/pr117973-1.c: New test

I could probably assume that this is what you had in mind, but anyway: Ok to commit? -- >8 -- PR117973 covers the aspect of non-LOGICAL_OP_NON_SHORT_CIRCUIT targets for PR111456, for which the test-case gcc.dg/tree-ssa/pr111456-1.c started failing as described in PR117954. * gcc.dg/tree-s

[PATCH v3] testsuite/gcc.dg/tree-ssa/pr111456-1.c: Handle fallout

> From: Richard Biener > Date: Mon, 9 Dec 2024 10:06:49 +0100 > As Andrew said the fix the testcase was written for was targeting > --param logical-op-non-short-circuit=1 it makes more sense to force > that so we continue to check it works. 'k, that's a valid argument. > We should simply track

Re: [PATCH v2] testsuite/gcc.dg/tree-ssa/pr111456-1.c: Handle fallout

> From: Sam James > Date: Sun, 08 Dec 2024 19:06:12 +0000 > Hans-Peter Nilsson writes: > > > v2: oops, typo: component is tree-optimization, not tree-ssa. > > Resent for the benefit of autotesters that don't yet > > understand natural language. > > &

[PATCH v2] testsuite/gcc.dg/tree-ssa/pr111456-1.c: Handle fallout

v2: oops, typo: component is tree-optimization, not tree-ssa. Resent for the benefit of autotesters that don't yet understand natural language. Forcing a fail and marking as xfail is IMHO better than passing --param=logical-op-non-short-circuit=0 or #pragma GCC unroll, making the test pass. To wi

[PATCH] testsuite/gcc.dg/tree-ssa/pr111456-1.c: Handle fallout

Forcing a fail and marking as xfail is IMHO better than passing --param=logical-op-non-short-circuit=0 or #pragma GCC unroll, making the test pass. To wit, this makes it observable when it's fixed. Ok to commit? -- >8 -- This is expected fallout from r15-5646-gd1cf0d7a0f27fd as described by that

Re: [PATCH v3] zero_extend(not) -> xor optimization [PR112398]

On Sat, 30 Nov 2024, Jeff Law wrote: > > > On 11/28/24 5:26 AM, Alexey Merzlyakov wrote: > > This patch adds optimization of the following patterns: > > > >(zero_extend:M (subreg:N (not:O==M (X:Q==M -> > >(xor:M (zero_extend:M (subreg:N (X:M)), mask)) > >... where the mask is GE

Re: [PATCH] PR target/117669 - RISC-V:The 'VEEWTRUNC4' iterator 'RVVMF2BF' type condition error

On Wed, 20 Nov 2024, Feng Wang wrote: > This patch fix the wrong condition for RVVMF2BF. It should be > TARGET_VECTOR_ELEN_BF_16. > gcc/ChangeLog: > > PR target/117669 > * config/riscv/vector-iterators.md: > > Signed-off-by: Feng Wang There's missing text after the ":", where one w

Re: [PATCH v2 10/14] Support for 64-bit location_t: gimple parts

On Sat, 16 Nov 2024, Lewis Hyatt wrote: > The size of struct gimple increases by 8 bytes with the change in size of > location_t from 32- to 64-bit Half-way scrolling through the patches, this seems a good time for a possibly disruptive comment from the side-line: ;-) For the size-critical types

[PATCH] libstdc++-v3: Fix signed-overflow warning for newlib/ctype_base.h, PR116895

FWIW, I see "typedef char mask;" also for bionic and openbsd. Tested for cris-elf. Ok to commit? -- >8 -- There are 100+ regressions when running the g++ testsuite for newlib targets (probably excepting ARM-based ones) e.g cris-elf after commit r15-3859-g63a598deb0c9fc "libstdc++: #ifdef out #pr

[committed] testsuite/gfortran.dg/open_errors_2.f90: Remove now-redundant file deletion

Only because I wrote earlier that I'd do this patch. Committed as obvious. Sanity-checked by running the test in a native tree as "make check-gcc-fortran RUNTESTFLAGS=dg.exp=open_errors_2.f90" -- >8 -- Now that fort.N files are removed by the testsuite framework, remove this single "manual" file

Re: RFC PATCH: contrib/test_summary mode for submitting testsuite results to bunsen

On Mon, 23 Sep 2024, Frank Ch. Eigler wrote: > Hi, HP - > > > I'd love for (something like) gcc-testresults@ to be usefully > > searchable (it can be done but... lacks), so please allow me: > > Certainly! > > > > +: ${bunsengit=ssh://sourceware.org/git/bunsendb.git/}; > > > +: ${bunsentag=`who

Re: [PATCH v2] gfortran testsuite: Remove unit-files in files having open-statements, PR116701

> Date: Wed, 25 Sep 2024 13:51:07 +0200 > From: Andre Vehreschild > Hi Hans-Peter, > > preface: I am not a testsuite nor an m4 expert. Neither am I. Luckily, this has nothing to do with m4, and not really that much to do with tcl or dejagnu either, being just basic code, no language-specific t

[PATCH v2] gfortran testsuite: Remove unit-files in files having open-statements, PR116701

Changes since v1: - Rename gfortran-dg-rmunits to fortran-delete-unit-files. - Move it to lib/fortran-modules.exp. - Tweak commit message accordingly and mention cause of placement of the proc. - Tweak proc comment to mention why keeping removals unique despite comment. Here's a general approa

Re: [PATCH] gfortran testsuite: Remove unit-files in files having open-statements, PR116701

Thanks for the review! > Date: Tue, 24 Sep 2024 17:10:27 -0700 > Cc: Jerry D > From: Jerry D > On 9/23/24 11:21 PM, Hans-Peter Nilsson wrote: > > I hope the inclusion of gfortran-dg.exp in > > fortran-torture.exp is not controversial, but there's no > > fortra

[PATCH] gfortran testsuite: Remove unit-files in files having open-statements, PR116701

Here's a general approach to handle PR116701. I considered adding manual deletions as quoted below and mentioned in the PR, but seeing the handling of "integer 8" in fortran-torture-execute I decided to follow that example: better scan the source for open-statements than relying on manual annotati

[committed] testsuite/gfortran.dg/unsigned_22.f90: Add missing close with delete, PR116701

Committed as pre-approved in the bugzilla PR. Heads-up: I intend to also submit for approval a patch that adds (the equivalent of) ! { dg-final { remote_file target delete "fort.10" } } to all running fortran test-cases that has an open-unit- statement (i.e. can create one of those "anonymous" f

Re: RFC PATCH: contrib/test_summary mode for submitting testsuite results to bunsen

I'd love for (something like) gcc-testresults@ to be usefully searchable (it can be done but... lacks), so please allow me: On Fri, 13 Sep 2024, Frank Ch. Eigler wrote: > diff --git a/contrib/test_summary b/contrib/test_summary > index 5760b053ec27..867ada4d6b81 100755 > --- a/contrib/test_summar

Ping: [PATCH] testsuite/gcc.dg/pr84877.c: Add machinery to stabilize stack aligmnent

Ping... > From: Hans-Peter Nilsson > Date: Thu, 5 Sep 2024 17:44:52 +0200 > > Tested adding 0..more-than-four environment variables, > running cris-sim+cris-elf. I also checked that foo stays > the same generated code regardless of the new code: this is > not obviously

[PATCH] testsuite/gcc.dg/pr84877.c: Add machinery to stabilize stack aligmnent

Tested adding 0..more-than-four environment variables, running cris-sim+cris-elf. I also checked that foo stays the same generated code regardless of the new code: this is not obviously true as foo is "just" noinline, not __noipa__. Ok to commit? -- >8 -- This test awkwardly "blinks"; xfails and

[committed] CRIS: Add new peephole2 "lra_szext_decomposed_indir_plus"

I thought I had already committed this, but it looks like it was left dangling when the make_more_copies patch (now committed) was in limbo and I disabled late-combine for (coremark) performance reasons. FWIW that's still a reason at r15-3386-gaf1500dd8c00 (2.6% regression). Tested cris-elf with/

Ping: [PATCH] testsuite: Prune compilation messages for modules tests

Ping... > From: Hans-Peter Nilsson > Date: Mon, 19 Aug 2024 00:28:30 +0200 > > As noticed when verifying the dejagnu fix. Tested cris-elf > with a new newlib that arranges to emit the mentioned > warning, with/without the update in dejagnu to handle the > miniscul

[PATCH v2] combine.cc (make_more_copies): Copy attributes from the original pseudo, PR115883

The only thing that's changed with the patch in v2 since the first version (pinged once) is the commit message. CC to the nexts-of-kin as a heads-up. Regtested cross to cris-elf and native x86_64-linux-gnu at r15-3043-g64028d626a50. The gcc.dg/guality/pr54200.c magically being fixed was also not

[PATCH] testsuite: Prune compilation messages for modules tests

As noticed when verifying the dejagnu fix. Tested cris-elf with a new newlib that arranges to emit the mentioned warning, with/without the update in dejagnu to handle the miniscule "in". Ok to commit? -- >8 -- All testsuite compiler-calls pass default_target_compile in the dejagnu installation (

Re: [PATCH] libstdc++-v3: testsuite: Prune uncapitalized "in function" linker warning

> Date: Wed, 14 Aug 2024 22:12:23 -0500 > From: Jacob Bachmeyer > Done and pushed to Savannah as commit > ed301dbd6a3d769670503ccfda1ea31b58d02547. Please confirm that this > solves the problem. Confirmed*... > (Also note that you can now run DejaGnu from a Git checkout, simply use > the "r

Re: [PATCH] libstdc++-v3: testsuite: Prune uncapitalized "in function" linker warning

> Date: Wed, 14 Aug 2024 20:58:04 -0500 > From: Jacob Bachmeyer > Reply-To: jcb62...@gmail.com > Hans-Peter Nilsson wrote: > > (CC to the dejagnu project as a heads-up) > > > > Regtested cris-elf with a fresh newlib checkout where 2640 > > libstdc++-v3 tes

[PATCH] libstdc++-v3: testsuite: Prune uncapitalized "in function" linker warning

(CC to the dejagnu project as a heads-up) Regtested cris-elf with a fresh newlib checkout where 2640 libstdc++-v3 tests otherwise fail due to the stubbed newlib _getentropy. Ok to commit? -- >8 -- Newer newlib trigger warnings about certain functions not implemented (_getentropy) when testing li

[PATCH] libstdc++-v3: Handle iconv as optional for newlib builds [PR116362]

Regtested cris-elf, both an older newlib (FWIW: before the getentropy issue that I hoped to investigate before summer...maybe next summer) and a fresh checkout, both with/without --enable-newlib-iconv. I'm pleasantly surprised that it works (there are no regressions) with newlib iconv enabled comp

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

__________ > From: Libstdc++ on behalf of > Jonathan Wakely via Libstdc++ > Sent: 10 June 2023 08:12 > To: Hans-Peter Nilsson > Cc: Jonathan Wakely; libstdc++; gcc-patches > Subject: Re: [PATCH] (Re: Splitting up > 27_io/basic_istream/ignore/wchar_t/94749.c

Re: Ping: [PATCH] testsuite: Fix struct size check [PR116155]

> From: Sam James > Date: Tue, 13 Aug 2024 18:17:29 +0100 > Hans-Peter Nilsson writes: > > > I stumbled on this being a regression for cris-elf as well; > > the patch expectedly fixes the test-case for CRIS as well. > > It's been a week since the patch was

Ping: [PATCH] testsuite: Fix struct size check [PR116155]

I stumbled on this being a regression for cris-elf as well; the patch expectedly fixes the test-case for CRIS as well. It's been a week since the patch was posted and as I see no replies, I'm pinging this in behalf of Dimitar. > From: Dimitar Dimitrov > Date: Mon, 5 Aug 2024 21:29:35 +0300 > Th

Ping: [PATCH] combine.cc (make_more_copies): Copy attributes from the original pseudo, PR115883

I verified that the patch still works around the issue at r15-2881-g4bcb480d103b. brgds, H-P > From: Hans-Peter Nilsson > Date: Fri, 12 Jul 2024 03:17:39 +0200 > > CC to both the combine maintainer and the RA maintainer for > verdict on whether this is the true correction or

Re: [COMMITTED] CRIS: Adjust gcc.dg/tree-ssa/loop-1.c

> From: Hans-Peter Nilsson > Date: Mon, 15 Jul 2024 05:06:43 +0200 > With r15-1619-g3b9b8d6cfdf593, there's a XPASS and a FAIL > for this test-case for cris-elf. Looking at the generated > code, _foo is indeed no longer saved in a register for CRIS. > While that

[COMMITTED] CRIS: Adjust gcc.dg/tree-ssa/loop-1.c

Committed. -- >8 -- With r15-1619-g3b9b8d6cfdf593, there's a XPASS and a FAIL for this test-case for cris-elf. Looking at the generated code, _foo is indeed no longer saved in a register for CRIS. While that looks like a regression, coremark results are the same around this revision, so simply adj

Re: [committed] Fix previously latent bug in reorg affecting cris port

> From: Hans-Peter Nilsson > Date: Fri, 12 Jul 2024 02:11:45 +0200 > > > Date: Wed, 3 Jul 2024 12:46:46 -0600 > > From: Jeff Law > > > The late-combine patch has triggered a previously latent bug in reorg. > > > > Basically we have a sequence

[COMMITTED] CRIS: Fix up last comment.

Regarding shortening it: no need to duplicate what's in the git commit log, just keep it at the minimum for at-a-glance use. -- >8 -- * config/cris/cris.cc (cris_option_override_after_change): Fix up comment regarding disabling late_combine. --- gcc/config/cris/cris.cc | 7 +++

[COMMITTED] CRIS: Disable late-combine by default, related PR115883

Heads-up to xtensa maintainers, who might similarly want to move the option-override to TARGET_OVERRIDE_OPTIONS_AFTER_CHANGE (and call it from TARGET_OPTION_OVERRIDE). Regarding disabling that optimization: with the brief description per the below, I think I've done due diligence when it comes to

[PATCH] combine.cc (make_more_copies): Copy attributes from the original pseudo, PR115883

CC to both the combine maintainer and the RA maintainer for verdict on whether this is the true correction or just a "fix"; whether REG_POINTER must be present or is just an optimization hint. And I almost forgot, the late-combine author! At least I hope to clarify the commit log based on your re

Re: [committed] Fix previously latent bug in reorg affecting cris port

> Date: Wed, 3 Jul 2024 12:46:46 -0600 > From: Jeff Law > The late-combine patch has triggered a previously latent bug in reorg. > > Basically we have a sequence like this in the middle of reorg before we > start relaxing delay slots (cris-elf, gcc.dg/torture/pr98289.c) [...] > Pushing to the

Re: Reverted recent patches to resource.cc

> Date: Sat, 8 Jun 2024 11:10:21 -0600 > From: Jeff Law > >>>resource.cc: Replace calls to find_basic_block with cfgrtl > >>> BLOCK_FOR_INSN > >>>resource.cc (mark_target_live_regs): Remove check for bb not found > >>>resource.cc: Remove redundant conditionals > >> > >> I had to

Re: [PATCH 23/52] mmix: Remove macros {FLOAT,DOUBLE,LONG_DOUBLE}_TYPE_SIZE

On Sun, 2 Jun 2024, Kewen Lin wrote: > This is to remove macros {FLOAT,{,LONG_}DOUBLE}_TYPE_SIZE > defines in mmix port. This is fine once prerequisites are in place. If I may add a nit: In these target change commit messages, add a hint as to which defaulted hook or macro the removed macro now

Re: Reverted recent patches to resource.cc

> Date: Wed, 29 May 2024 21:23:58 -0600 > Cc: gcc-patches@gcc.gnu.org > I don't bother with qemu.exp at all. I've set up binfmt handlers so > that I can execute foreign binaries. > > So given a root filesystem, I can chroot into it and do whatever I need. > As far as dejagnu is concerned it

Re: Reverted recent patches to resource.cc

> Date: Wed, 29 May 2024 20:07:22 -0600 > From: Jeff Law > > There appears to be only a single supported SPARC machine in > > cfarm: cfarm216, and I currently can't reach it due to what > > appears to be issues at my end. I guess I'll either fix > > that or breathe life into sparc-elf+sim. > Or

Reverted recent patches to resource.cc

> From: Hans-Peter Nilsson > Date: Mon, 27 May 2024 19:51:47 +0200 > 2: Does not depend on 1, but corrects an incidentally found wart: > find_basic_block calls fails too often. Replace it with "modern" > insn-to-basic-block cross-referencing. > > 3: Just a

Re: [PATCH 2/4] resource.cc: Replace calls to find_basic_block with cfgrtl BLOCK_FOR_INSN

> Date: Mon, 27 May 2024 12:57:53 -0600 > From: Jeff Law > > * resource.cc: Include cfgrtl.h. Use BLOCK_FOR_INSN (insn)->index > > instead of calling find_basic_block (insn). Assert for not -1. > > (find_basic_block): Remove function. > > (init_resource_info): Call compute_bb_fo

[PATCH 4/4] resource.cc: Remove redundant conditionals

Regtested cris-elf. Ok to commit? -- >8 -- No functional change. - We always have a target_hash_table and bb_ticks because init_resource_info is always called. These conditionals are an ancient artifact: it's been quite a while since resource.cc was used elsewhere than exclusively from reorg.cc

[PATCH 3/4] resource.cc (mark_target_live_regs): Remove check for bb not found

Regtested cris-elf. Ok to commit? -- >8 -- No functional change. A "git diff -wb" (ignore whitespace diff) shows that this commit just removes a "if (b != -1)" after a "gcc_assert (b != -1)" and also removes the subsequent "else" clause. * resource.cc (mark_target_live_regs): Remove red

[PATCH 2/4] resource.cc: Replace calls to find_basic_block with cfgrtl BLOCK_FOR_INSN

Regtested cris-elf. Ok to commit? -- >8 -- ...and call compute_bb_for_insn in init_resource_info and free_bb_for_insn in free_resource_info. I put a gcc_unreachable in that else-clause for a failing find_basic_block in mark_target_live_regs after the comment that says: /* We didn't find the

[PATCH 1/4] resource.cc (mark_target_live_regs): Don't look past target insn, PR115182

Regtested cris-elf. Ok to commit? -- >8 -- The PR115182 regression is that a delay-slot for a conditional branch, is no longer filled with an insn that has been "sunk" because of r15-518-g99b1daae18c095, for cris-elf w. -O2 -march=v10. There are still sufficient "nearby" dependency-less insns th

Re: [PATCH V3] report message for operator %a on unaddressible operand

On Mon, 20 May 2024, Jiufu Guo wrote: > Hi, > > For PR96866, when printing asm code for modifier "%a", an addressable > operand is required. While the constraint "X" allow any kind of > operand even which is hard to get the address directly. e.g. extern > symbol whose address is in TOC. > An err

Re: [PATCH] tree-optimization/114589 - remove profile based sink heuristics

> Date: Wed, 15 May 2024 11:38:58 +0200 (CEST) > From: Richard Biener > The following removes the profile based heuristic limiting sinking > and instead uses post-dominators to avoid sinking to places that > are executed under the same conditions as the earlier location which > the profile based

[COMMITTED] Revert "Revert "testsuite/gcc.target/cris/pr93372-2.c: Handle xpass from combine improvement"" combine improvement

> From: Hans-Peter Nilsson > Date: Thu, 11 Apr 2024 01:16:32 +0200 I committed this revert of a revert, as r15-311, as the prerequisite was also revert-reverted, in r15-268. -- >8 -- This reverts commit 39f81924d88e3cc197fc3df74204c9b5e01e12f7. --- gcc/testsuite/gcc.target/cris/pr

Re: [PATCH v4 2/3] [RFC] ifcvt: Allow more operations in multiple set if conversion

On Tue, 23 Apr 2024, Manolis Tsamis wrote: > diff --git a/gcc/testsuite/gcc.target/aarch64/ifcvt_multiple_sets_arithm.c > b/gcc/testsuite/gcc.target/aarch64/ifcvt_multiple_sets_arithm.c ... > +/* { dg-final { scan-rtl-dump-times "if-conversion succeeded through > noce_convert_multiple_sets" 6 "ce

Re: enable sqrt insns for cdce3.c

On Mon, 22 Apr 2024, Alexandre Oliva wrote: > [Revamped version of this patch, combined with others, to follow] > > On Mar 10, 2021, Hans-Peter Nilsson wrote: Time flies... > > On Wed, 10 Mar 2021, Alexandre Oliva wrote: > Is mmix a sqrt_insn effec

[REVERTED] testsuite/gcc.target/cris/pr93372-2.c: Handle xpass from combine improvement

s; it is greedy. It would be nice to see > written out what happens in this example though :-) Yes it would, but I have other things on my plate. Besides, it's your patch, can't rob you of the fun. I committed the revert below, but hope to re-apply (re-revert) it in stage 1, when as per

Re: [PATCH 2/9] wwwdocs: gcc-14: add URLs to some options

On Thu, 4 Apr 2024, David Malcolm wrote: > Signed-off-by: David Malcolm > --- > htdocs/gcc-14/changes.html | 23 --- > 1 file changed, 16 insertions(+), 7 deletions(-) > > diff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html > index 5cc729c5..397458d5 100644

[COMMITTED] testsuite/gcc.target/cris/pr93372-2.c: Handle xpass from combine improvement

The xpassing change in generated code was as follows, at r14-9788-gb7bd2ec73d66f7 (where I locally applied a revert to verify that this suspect was the cause). That was so much of an improvement that I had to share it! Worth the testsuite churn anyway. :) Segher, if you end up reverting r14-9692

[COMMITTED] testsuite/gcc.dg/debug/btf/btf-datasec-1.c: Handle leading-underscore

Committed as obvious. -- >8 -- I noticed my autotester for cris-elf flagging this as a regression. * gcc.dg/debug/btf/btf-datasec-1.c: Adjust pattern for targets with symbols having a leading underscore. --- gcc/testsuite/gcc.dg/debug/btf/btf-datasec-1.c | 2 +- 1 file changed, 1

Re: [PATCH] testsuite: Fix up lra effective target

> Date: Fri, 16 Feb 2024 11:16:22 +0100 > From: Jakub Jelinek > Given the recent discussions on IRC started with Andrew P. mentioning that > an asm goto outputs test should have { target lra } and the lra effective > target in GCC 11/12 only returning 0 for PA and in 13/14 for PA/AVR, while > we

Re: [PATCH v4]: testcases for "ICE for unknown parameter to constexpr'd switch-statement, PR113545"

TPTR_TYPE__) &foo); // { dg-error "conversion from pointer type" } + xyzzy(e); + unsigned constexpr char f = ifbar((__UINTPTR_TYPE__) &foo); // { dg-error "conversion from pointer type" } + xyzzy(f); +} -- 2.30.2 > From: Hans-Peter Nilsson > CC: , > Content

[PATCH v3]: testcases for "ICE for unknown parameter to constexpr'd switch-statement, PR113545"

Bah. Linaro's CI didn't like that there were UNRESOLVEDs due to this patch. Running it "as usual" didn't show anything suspicious. Sure, there were "# of unresolved testcases 3" in the summary (see v2), but no error or other special message from dejagnu. Perhaps there could be a way to have dg-

[PATCH v2]: testcases for "ICE for unknown parameter to constexpr'd switch-statement, PR113545"

> Date: Wed, 7 Feb 2024 16:32:57 -0500 > From: Jason Merrill > Incidentally, these testcases seem to require C++14; you can't have a > switch in a constexpr function in C++11. Update, v2 (from v1 that had a few requests from Marek resolved from v0 that was posted together with my patch^Whack):

Re: [PATCH] c++: Don't ICE for unknown parameter to constexpr'd switch-statement, PR113545

> Date: Thu, 8 Feb 2024 11:22:47 -0500 > From: Marek Polacek > I'm confused; are you planning to use the dg-ice directive I invented > some years ago? Please, let's keep the discussion about the test-cases in that thread. brgds, H-P

Re: [PATCH] c++: Don't ICE for unknown parameter to constexpr'd switch-statement, PR113545

> Date: Thu, 8 Feb 2024 10:44:31 -0500 > From: Marek Polacek > Cc: ja...@redhat.com, gcc-patches@gcc.gnu.org > Content-Type: text/plain; charset=us-ascii > Content-Disposition: inline > > On Thu, Feb 08, 2024 at 04:40:40PM +0100, Hans-Peter Nilsson wrote: > > >

Re: [PATCH] c++: Don't ICE for unknown parameter to constexpr'd switch-statement, PR113545

> Date: Wed, 7 Feb 2024 21:11:59 -0500 > From: Marek Polacek > On Wed, Feb 07, 2024 at 04:32:57PM -0500, Jason Merrill wrote: > > On 2/6/24 19:23, Hans-Peter Nilsson wrote: > > > > Date: Mon, 22 Jan 2024 14:33:59 -0500 > > > > From: Marek Polacek >

Re: [PATCH] c++: Don't ICE for unknown parameter to constexpr'd switch-statement, PR113545

> Date: Mon, 22 Jan 2024 14:33:59 -0500 > From: Marek Polacek > On Mon, Jan 22, 2024 at 06:02:32PM +0100, Hans-Peter Nilsson wrote: > > I don't really know whether this is the right way to treat > > CONVERT_EXPR as below, but... Regtested native > > x86_64-linux

Ping*2 PATCH: testcase for "ICE for unknown parameter to constexpr'd switch-statement, PR113545"

> From: Hans-Peter Nilsson > Date: Tue, 30 Jan 2024 06:18:45 +0100 > Ping for the xfailed testsuite patch below the review > (actual constexpr.cc patch to be handled separately): Ping*2. Again, this is for the xfailed test-case only. > > > From: Hans-Peter Nilsson >

Re: [PATCH 1/2] libstdc++: Replace padding bits with a bit-field in __format::_Spec

> From: Jonathan Wakely > Date: Thu, 1 Feb 2024 19:24:49 + > I think I'd prefer to keep the reserved bits together, but a simpler > way to avoid 'unsigned long' making a difference for > PCC_BITFIELD_TYPE_MATTERS targets would be to use no more than 16 bits > but do: > >unsigned _M_r

Re: [PATCH 1/2] libstdc++: Replace padding bits with a bit-field in __format::_Spec

> From: Hans-Peter Nilsson > Date: Thu, 1 Feb 2024 17:16:47 +0100 > Not speaking for other platforms with default-packed layout > or where ABI structure layout alignment implies a change due > to PCC_BITFIELD_TYPE_MATTERS and the "unsigned long" > bitfield type. &

Re: [PATCH 1/2] libstdc++: Replace padding bits with a bit-field in __format::_Spec

> From: Jonathan Wakely > Cc: Hans-Peter Nilsson > Date: Thu, 1 Feb 2024 15:36:50 + > I plan to push this to trunk soon. > > CC HP for visibility of the change affecting cris-elf. In practice it > shouldn't make any difference to any sensible code. It only affec

Ping PATCH: testcase for "ICE for unknown parameter to constexpr'd switch-statement, PR113545"

Ping for the xfailed testsuite patch below the review (actual constexpr.cc patch to be handled separately): > From: Hans-Peter Nilsson > Date: Tue, 23 Jan 2024 05:55:00 +0100 > > > Date: Mon, 22 Jan 2024 14:33:59 -0500 > > From: Marek Polacek > > > The

[PATCH v2] c/c++: Tweak warning for 'always_inline function might not be inlinable'

Change from v1: The message is changed as per the review. The powerpc test-case is dropped from the changes as the part quoted in a comment now does not change and so cannot cause further confusion. The commit message is tweaked. It now also mentions clang. I intend to commit this on Thursday 202

Re: [PATCH] c++: Don't ICE for unknown parameter to constexpr'd switch-statement, PR113545

> Date: Mon, 22 Jan 2024 14:33:59 -0500 > From: Marek Polacek > The problem seems to be more about conversion so > g++.dg/conversion/reinterpret5.C > or g++.dg/cpp0x/constexpr-reinterpret3.C seems more appropriate. > > > @@ -0,0 +1,49 @@ > > Please add > > PR c++/113545 > > + unsigned const

Re: [PATCH] c++: Don't ICE for unknown parameter to constexpr'd switch-statement, PR113545

I was about to write "aren't C++ hackers" but then again, C++ happened to gcc, and c++11 at that.) > On Mon, Jan 22, 2024 at 06:02:32PM +0100, Hans-Peter Nilsson wrote: > The problem seems to be more about conversion so > g++.dg/conversion/reinterpret5.C > or g++.dg/cp

Re: [PATCH] c++: Don't ICE for unknown parameter to constexpr'd switch-statement, PR113545

> Date: Mon, 22 Jan 2024 14:33:59 -0500 > From: Marek Polacek > On Mon, Jan 22, 2024 at 06:02:32PM +0100, Hans-Peter Nilsson wrote: > > I don't really know whether this is the right way to treat > > CONVERT_EXPR as below, but... Regtested native > > x86_64-linux

[PATCH] c++: Don't ICE for unknown parameter to constexpr'd switch-statement, PR113545

I don't really know whether this is the right way to treat CONVERT_EXPR as below, but... Regtested native x86_64-linux-gnu. Ok to commit? brgds, H-P -- >8 -- That gcc_unreachable at the default-label seems to be over the top. It seems more correct to just say "that's not constant" to whatever'

Re: [PATCH] c/c++: Tweak warning for 'always_inline function might not be inlinable'

> From: Richard Biener > Date: Mon, 22 Jan 2024 08:33:47 +0100 > > - "% function might not be inlinable"); > > + "% function is not always inlined" > > + " unless also declared %"); > > I don't like the "is not always inlined", maybe simply r

[PATCH] c/c++: Tweak warning for 'always_inline function might not be inlinable'

Tested x86_64-linux-gnu. Ok to commit? Or, does the message need more tweaking? (If so, suggestions from native speakers?) FWIW, I found no PR for just the message being bad. -- >8 -- When you're not regularly exposed to this warning, it is easy to be misled by its wording, believing that there'

  1   2   3   4   5   6   7   8   9   10   >