Re: [MMIX] Hookize PRINT_OPERAND, PRINT_OPERAND_ADDRESS and PRINT_OPERAND_PUNCT_VALID_P

On Mon, 25 Jul 2011, Anatoly Sokolov wrote: > Hi. > > This patch removes obsolete PRINT_OPERAND, PRINT_OPERAND_ADDRESS and > PRINT_OPERAND_PUNCT_VALID_P macros from MMIX back end in the GCC and > introduces equivalent TARGET_PRINT_OPERAND, TARGET_PRINT_OPERAND_ADDRESS and > TARGET_PRINT_OPERAND_P

Re: Split insn-attr.h

On Tue, 28 Jun 2011, Joseph S. Myers wrote: > (In checking for such files - > there aren't that many - I also noticed that the target macro > DELAY_SLOTS_FOR_EPILOGUE is used and documented but not defined by any > target, so the code relating to that macro is ripe for removal and > poisoning of th

Fix PR48675: 20_util/hash/chi2_quality.cc timeout for simulator targets

See PR48675 for details. It also mentions a secondary issue, a performance regression introduced in 172607:172613 after an improvement introduced in 172417:172431. If you look at the test, it has this nice line, // { dg-options "-std=gnu++0x -DSAMPLES=1" { target simulator } } (the default SA

Re: [testsuite]: Skip some tests for avr

On Tue, 19 Apr 2011, Georg-Johann Lay wrote: > This patchlet skips some tests for avr because int is just 16 bits there. > 2011-04-19 Georg-Johann Lay > > * gcc.c-torture/compile/pr43191.c: Skip avr due to 16-bit int. > * gcc.dg/torture/pr43165.c: Ditto. > * gcc.dg/torture/pr4

Re: [pph] Macro Validation Correction (issue4425041)

On Sat, 16 Apr 2011, Diego Novillo wrote: > On Thu, Apr 14, 2011 at 22:01, Lawrence Crowl wrote: > > +unsigned char too_many_directives_for_bitfield[ > > +        N_DIRECTIVES <= (1 << CPP_HASHNODE_INDEX_BITS) > > +        ? 1 : -1]; > > Heh, I'm not sure what to think of this trick. I think I lik

Re: Get rid of warning in dwarf2out.c

On Mon, 18 Apr 2011, Eric Botcazou wrote: > Compiling dwarf2out.c with older versions of GCC yields a warning because > is_redundant_typedef has a prototype without the 'inline' keyboard and a > declaration with it, and is called from another function in-between. Shouldn't there be a warning from

Re: [patch gimplifier]: Do folding on truth and/or trees

On Wed, 27 Apr 2011, Jakub Jelinek wrote: > You don't need to build cross binutils, all that is needed is > configure the cross and build just cc1, don't mind that the build > fails afterwards and just run it on your testcases by hand to see > what is in the dumps. FWIW "make all-gcc" doesn't fail

Committed: fd_truncate test-cases updated for recent libgfortran changes

Once or twice a year some regression results from changed I/O in libgfortran, such that some existing test-case starts calling libgfortran/io/unix.c:raw_truncate, which on limited-I/O-bare-iron targets will emit "required ftruncate or chsize support not present" and fail. After a while, I get to i

Re: Committed: fd_truncate test-cases updated for recent libgfortran changes

> Date: Thu, 5 May 2011 19:36:47 +0300 > From: Janne Blomqvist > On Thu, May 5, 2011 at 00:52, Hans-Peter Nilsson > wrote: > > This time, it happened in 173155:173168. > > > > Usually, there's also a brief question whether all changes were > > intende

Re: [PATCH] Cleanup expand_shift

On Thu, 5 May 2011, Richard Guenther wrote: > On Wed, 4 May 2011, Richard Guenther wrote: > > On Wed, 4 May 2011, Eric Botcazou wrote: > > Hm. I guess people will scream if something breaks (I can't imagine > > what though). AAAaaarghh! Building cris-elf is now broken. > I have applied the foll

Re: [v3] typeinfo tuning

On Mon, 14 Mar 2011, Benjamin Kosnik wrote: > This is versioned for 4.6.0, but I'll wait a day or two to see how it > goes before I plead with the RMs. It broke build, hopefully for trivial reasons. It seems like your bugzilla options are set to not receive email, so I'll have to bug you like thi

Re: [v3] regex versioned namespaces

On Mon, 14 Mar 2011, Benjamin Kosnik wrote: > > Ugh. While doing other things I realized that the namespace versioning > for regex header files is off: it's not on the inner-most nested > namespace. > > Fixed thusly. But it seems like it's not committed? brgds, H-P

Re: [wwwdocs] gcc-4.6/porting_to.html

On Wed, 16 Mar 2011, Benjamin Kosnik wrote: > Needs some more work, here's a rough draft. s/Porting to the new tools/Porting to the new version/ ? brgds, H-P

Re: RFA: patch to solve IRA PR48336, PR48342, PR48345

On Tue, 29 Mar 2011, Vladimir Makarov wrote: > 2011-03-29 Vladimir Makarov > > PR target/48336 > PR middle-end/4834 (A typo here, 48342. Or maybe also needed for 48334?) > PR rtl-optimization/48345 > * ira-color.c (setup_conflict_profitable_regs): Exclude prohib

Re: RFA: patch to solve IRA PR48336, PR48342, PR48345

On Tue, 29 Mar 2011, Hans-Peter Nilsson wrote: > FWIW, I have a five regressions for cris-elf too appearing at > that RA change, but as they're wrong-code and noticed only at > execution, I'm going to wait analyzing further until this is > committed and caught by my autote

Re: Continue toplevel cleanup (GCC library handling for unsupported targets etc.)

On Tue, 29 Mar 2011, Joseph S. Myers wrote: > Other cleanups here: > cris*-*-none acts just like cris*-*-elf in > config.gcc so it's appropriate to make the "*" subcase of cris*-*-* act > like the -elf case; 'k. > mmix-*-* disabled "libgloss", i.e. libgloss for the > host, which is never built a

Re: [patch, ARM] Make 128 bits the default vector size for NEON

> Date: Thu, 31 Mar 2011 13:39:05 +0200 > From: Ira Rosen > This patch changes NEON's default vector size from 64 to 128 bits. I'm wondering, are there NEON-specific measurements to support this change? A colleague of mine implemented support for 64- and 128-bit NEON for RAPP

Re: Target header etc. cleanup patch

On Sat, 2 Apr 2011, Joseph S. Myers wrote: > * cris-protos.h had an unused STDIO_INCLUDED definition, which I > removed. Been there since the first commit, it seems. Certainly this bit is ok. A nit: you had several lines consisting of "*." (with the obvious expansion) in the changelogs you post

Re: Simple enhancement to -dA dump

On Sun, 3 Apr 2011, Xinliang David Li wrote: > 2011-04-03 Xinliang David Li > > * final.c (dump_basic_block_info): New function. + fprintf (file, "# BLOCK %d", bb->index); Random spotting: please use ASM_COMMENT_START instead of the naked "#". brgds, H-P

Re: Add a mode argument to LEGITIMATE_CONSTANT_P, and make it a hook

On Mon, 4 Apr 2011, Richard Sandiford wrote: > Pretty much as the subject says. > OK to install? CRIS and MMIX parts are ok. brgds, H-P PS. FWIW anyone: for "my" targets, a CC to me usually gets a faster response.

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

[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

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

[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

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

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

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

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

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

[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

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

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

[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

[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

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

[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/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] 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

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

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

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

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

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

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

[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

[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

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

[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

cance and having seen no other comments, I'll do that, but delay another week. brgds, H-P > > Qing > > > On Feb 15, 2023, at 2:19 PM, Hans-Peter Nilsson wrote: > > > > Tested for cris-elf. Ok to commit? > > > > -- >8 -- > > Looks like there&

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

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): "

[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

<    5   6   7   8   9   10   11   12   13   >