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

> From: David Malcolm > Date: Thu, 16 Mar 2023 14:42:58 -0400 > I think I prefer the top one-liner dg-skip-if approach you mentioned in > your original email; it seems simplest. Ok then. There's also a choice between adding a target-specifier (i.e. "{ target { ! default_packed } }") to the

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

> From: Hans-Peter Nilsson > Date: Thu, 16 Mar 2023 19:25:05 +0100 > That doesn't seem like a good idea. At a glance the > *testcode* will be simpler, but the patch will be slightly > larger Bah, s/but the patch will be slightly larger/and the patch will certainly be smaller, b

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

> From: David Malcolm > Date: Thu, 16 Mar 2023 13:55:48 -0400 > On Thu, 2023-03-09 at 19:56 +0100, Hans-Peter Nilsson wrote: > > It's not obvious to me whether considered best to include or > > exclude these tests that depend on structure layout details. > > If excludi

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

Pinging this patch. > From: Hans-Peter Nilsson > Date: Thu, 9 Mar 2023 19:56:16 +0100 > > It's not obvious to me whether considered best to include or > exclude these tests that depend on structure layout details. > If excluding, the obvious alternative to this patch is then

[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

[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

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

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

Committed as obvious. -- >8 -- Targets that don't support scheduling get a warning: cc1: warning: instruction scheduling not supported on this target machine Do like other target-generic tests unconditionally passing -fschedule-insns: require effective target scheduling. *

[committed] testsuite: gcc.dg/pr106397.c: Add -w to options

Committed as obvious. -- >8 -- Targets that don't support prefetching get a warning: cc1: warning: '-fprefetch-loop-arrays' not supported for this target Align with other tests passing -fprefetch-loop-arrays for all targets: add "-w" to options. * gcc.dg/pr106397.c: Add -w to options.

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

It's not obvious to me whether considered best to include or exclude these tests that depend on structure layout details. If excluding, the obvious alternative to this patch is then to add a top one-liner (to dg-skip-if the test for default_packed targets or a similar excluding expression). I'm

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

Committed as obvious. -- >8 -- The recently added tests missed checking for "fopenmp" (see other tests where "-fopenmp" is passed), which makes them fail on non-openmp systems. * gcc.dg/analyzer/omp-parallel-for-get-min.c, gcc.dg/analyzer/omp-parallel-for-1.c: Require effective

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

> From: Mike Stump > Date: Mon, 6 Mar 2023 02:05:35 -0800 > Ok Thanks! The server-side hook didn't like my ChangeLog entry: * lib/multiline.exp (_build_multiline_regex): Map "{re:" to "(", ":re}" to ")" and ":re?}" to ")?". It seems I forgot to validate that patch by

[PATCH] testsuite: Support scanning tree-dumps

This is sort-of a spin-off from effective_target_tail_call: I thought that'd best be implemented by scanning a tree-dump, specifically -fdump-tree-optimized, but the "tail call" found there is emitted for *all* targets. Debugged and ready to apply, putting it out for consideration as someone will

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

Borderline obvious when tail_call is available, so I'll then apply. -- >8 -- While gcc.dg/plugin/must-tail-call-2.c passes for all targets even without this, the error message is, for a target like cris-elf that doesn't implement sibling calls: "error: cannot tail-call: machine description does

[PATCH 2/3] doc: Document testsuite check_effective_target_tail_call

Will commit as obvious, when the 1/3 tail_call is applied. -- >8 -- Spot-checked the PDF output for sanity. * doc/sourcebuild.texi: Document check_effective_target_tail_call. --- gcc/doc/sourcebuild.texi | 3 +++ 1 file changed, 3 insertions(+) diff --git a/gcc/doc/sourcebuild.texi

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

Ok to commit? -- >8 -- The RTL "expand" dump is the first RTL dump, and it also appears to be the earliest trace of the target having implemented sibcalls. Including the "," in the pattern searched for, to try and avoid possible false matches, but there doesn't appear to be any identifiers or

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

Ping... > From: Hans-Peter Nilsson > Date: Fri, 24 Feb 2023 20:16:03 +0100 > > Ok to commit? > -- >8 -- > Those multi-line-patterns are literal. Sometimes a regexp > needs to be matched. This is a start: just three elements > are supported: "(" &qu

[COMMITTED] testsuite: Skip gcc.dg/ipa/pr77653.c for CRIS

CRIS defines DATA_ALIGNMENT such that alignment can be applied differently to different data of the same type, when "references to it must bind to the current definition" (varasm.cc:align_variable). Here, it means that more alignment is then applied to g, but not f, so the test-case fails because

[COMMITTED] testsuite: Skip gcc.dg/ifcvt-4.c for CRIS

CRIS has no conditional execution and no conditional moves. * gcc.dg/ifcvt-4.c: Add cris-*-* to skip list. --- gcc/testsuite/gcc.dg/ifcvt-4.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/gcc/testsuite/gcc.dg/ifcvt-4.c b/gcc/testsuite/gcc.dg/ifcvt-4.c index

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

Committed as obvious. -- >8 -- * g++.dg/cpp0x/pr84497.C: Handle USER_LABEL_PREFIX == "_" on scan-assembler identifiers. * gcc.dg/debug/btf/btf-enum64-1.c, gcc.dg/ipa/symver1.c: Ditto. --- gcc/testsuite/g++.dg/cpp0x/pr84497.C | 6 +++---

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

Committed as obvious. FWIW, I'm on the side that emitting the warning when the reason is just that it's the default layout, is bad. A discussion took place years ago when the warning was added. -- >8 -- For targets where the byte-wise structure element layout is the same as for

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

Trivia: I copied that ASMNAME construct from the 18-year-minus-a-month old commit of r0-66993-gc5221531453e02, where it fixed a similar testsuite error. Committed as obvious. -- >8 -- This fixes: Running /x/gcc/testsuite/gcc.dg/dg.exp ... ... FAIL: gcc.dg/attr-copy-6.c (test for excess

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

> Date: Thu, 2 Mar 2023 01:37:12 +0100 > From: Bernhard Reutner-Fischer > On Thu, 2 Mar 2023 00:54:33 +0100 > Hans-Peter Nilsson wrote: > > > > Date: Thu, 2 Mar 2023 00:23:36 +0100 > > > From: Bernhard Reutner-Fischer > > > > > On Wed, 1 Mar

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

> Date: Thu, 2 Mar 2023 00:23:36 +0100 > From: Bernhard Reutner-Fischer > On Wed, 1 Mar 2023 17:02:31 +0100 > Hans-Peter Nilsson via Gcc-patches wrote: > > > > From: Hans-Peter Nilsson > > > Date: Wed, 1 Mar 2023 16:36:46 +0100 > > > >

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

> From: Hans-Peter Nilsson > Date: Wed, 1 Mar 2023 16:36:46 +0100 > ... this is what I intend to commit later > today, just keeping the added comment as brief as > reasonable: Except I see the hook for errno magic took care of gcc.dg/analyzer/flex-without-call-summarie

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

> From: David Malcolm > Cc: gcc-patches@gcc.gnu.org > Date: Wed, 01 Mar 2023 08:32:13 -0500 > Also, the analyzer uses region_model::set_errno in various > known_function implementations, e.g. for functions that can succeed or > fail, to set errno on the "failure" execution path to a new symbolic

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

> From: David Malcolm > Date: Tue, 28 Feb 2023 21:25:34 -0500 > On Wed, 2023-03-01 at 01:59 +0100, Hans-Peter Nilsson wrote: > > > From: David Malcolm > > > Date: Tue, 28 Feb 2023 14:12:47 -0500 > > > > > On Tue, 2023-02-28 at 19:47 +0100, Hans

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

> From: David Malcolm > Date: Tue, 28 Feb 2023 14:12:47 -0500 > On Tue, 2023-02-28 at 19:47 +0100, Hans-Peter Nilsson wrote: > > Ok to commit? > > -- >8 -- > > Investigating analyzer tesstsuite errors for cris-elf. The same are > > seen for pru-elf a

Re: [PATCH v3 04/11] riscv: thead: Add support for the XTheadBs ISA extension

On Tue, 28 Feb 2023, Christoph Müllner wrote: > On Sun, Feb 26, 2023 at 12:42 AM Hans-Peter Nilsson wrote: > > > > On Fri, 24 Feb 2023, Christoph Muellner wrote: > > > diff --git a/gcc/config/riscv/thead.md b/gcc/config/riscv/thead.md > > > inde

Re: [Patch] gcc.dg/overflow-warn-9.c: exclude from LLP64

On Tue, 28 Feb 2023, Jonathan Yong wrote: > On 2/28/23 03:06, Hans-Peter Nilsson wrote: > > > > On Mon, 27 Feb 2023, Jonathan Yong via Gcc-patches wrote: > > > > > This test is for LP64 only, exclude LLP64 too. > > > Patch OK? > > > > I may b

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

Ok to commit? (After this, there's gcc.dg/analyzer/flex-without-call-summaries.c left to do.) -- >8 -- Investigating analyzer testsuite errors for cris-elf. The same are seen for pru-elf according to posts to gcc-testresults@. The test fd-access-mode-target-headers.c uses the analyzer "sm-fd"

[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

Re: [Patch] gcc.dg/overflow-warn-9.c: exclude from LLP64

On Mon, 27 Feb 2023, Jonathan Yong via Gcc-patches wrote: > This test is for LP64 only, exclude LLP64 too. > Patch OK? I may be confused, but you're not making use of the "llp64" effective target, there instead excluding/including lp64 / ilp32 in sets that not obviously mean "exclude LLP64".

Re: [Patch] gcc.c-torture/compile/103818.c: enable for llp64 too

On Sun, 26 Feb 2023, Jonathan Yong via Gcc-patches wrote: > Patch OK for master branch? I did not see any obvious issues to exclude LLP64 > specifically. I see "lp64 || lp64" in that patch (which should preferably have been sent inline, as it's harder to quote an attached patch, QED). Sending

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

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

[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

[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

[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

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

Re: [PATCH v3 04/11] riscv: thead: Add support for the XTheadBs ISA extension

On Fri, 24 Feb 2023, Christoph Muellner wrote: > diff --git a/gcc/config/riscv/thead.md b/gcc/config/riscv/thead.md > index 158e9124c3a..2c684885850 100644 > --- a/gcc/config/riscv/thead.md > +++ b/gcc/config/riscv/thead.md > @@ -29,3 +29,14 @@ (define_insn "*th_addsl" >"th.addsl\t%0,%3,%1,%2"

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

[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

[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

[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

[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

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

ving 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's a failed assumptio

[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

[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

[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

[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

[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

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

Re: [PATCH] libstdc++: testsuite: Add char8_t to codecvt_unicode

Casual observation from a random reader that's sometimes hit by testresults acting up: On Thu, 9 Feb 2023, Dimitrij Mijoski via Gcc-patches wrote: > libstdc++-v3/ChangeLog: > > * testsuite/22_locale/codecvt/codecvt_unicode.cc: Rename > functions. > *

Re: [pushed] [PR103541] RA: Implement reuse of equivalent memory for caller saves optimization (version 2)

> From: Vladimir Makarov via Gcc-patches > Date: Thu, 9 Feb 2023 22:49:34 +0100 > The patch was successfully bootstrapped (--enable-languages=all) and > tested on x86, x86-64, aarch64 Sorry, but this (also) caused test-suite regressions, perhaps just for cris-elf. I've opened 108754 and will

[PATCH] testsuite: Fix asm-goto-with-outputs tests; limit to lra targets

Sanity-checked for cris-elf with the check_effective_target_lra correction in https://gcc.gnu.org/pipermail/gcc-patches/2023-February/611531.html Committed as obvious. --- 8< --- These tests spuriously lacked a "lra" limiter. Code using "asm goto" with outputs gets a: error: the target does not

Re: [PATCH] testsuite: Generalize check_effective_target_lra

> From: Richard Sandiford > Date: Wed, 8 Feb 2023 17:54:15 +0100 > Hans-Peter Nilsson via Gcc-patches writes: > > Tested native x86_64-pc-linux-gnu and cris-elf (non-LRA and > > also hacked to switch to LRA). > > Since !LRA is hopefully not long for this world, I'd

[PATCH] testsuite: Generalize check_effective_target_lra

Tested native x86_64-pc-linux-gnu and cris-elf (non-LRA and also hacked to switch to LRA). Ok to commit? --- 8< --- The LRA target list is incomplete. Rather than syncing it with actual LRA targets, better use existing infrastructure and look for a LRA-specific pattern in the reload dump (which

Re: [PATCH] testsuite: XFAIL bogus g++.dg/warn/Wstringop-overflow-4.C:144, PR106120

> From: Aldy Hernandez > Date: Tue, 7 Feb 2023 17:52:02 +0100 > Up to the release managers, but I have no objections. I take it that's for both patches. Thanks! (Potential reviewers: these patches are local to the testsuite.) brgds, H-P > > Aldy > > On 2/7/23 17:5

[PATCH] testsuite: XFAIL bogus g++.dg/warn/Wstringop-overflow-4.C:144, PR106120

(sort-of-ping:) Aldy, I missed CC:ing you on the similar https://gcc.gnu.org/pipermail/gcc-patches/2023-February/611206.html would you mind having a look? Tested native x86_64-pc-linux-gnu (w/wo. -m32) and cris-elf. Ok to commit? 8< There was a commit r13-2082-gbf13a13c65bd06 "c++:

[PATCH] libstdc++: Avoid use of naked int32_t in unseq_backend_simd.h, PR108672

Tested cris-elf and native x86_64-pc-linux-gnu. Ok to commit? 8< The use of a "naked" int32_t (i.e. without a fitting #include: stdint.h or cstdint or inttypes.h or an equivalent internal header), in libstdc++-v3/include/pstl/unseq_backend_simd.h, caused an error for cris-elf and

[PATCH] testsuite: XFAIL g++.dg/pr71488.C and warn/Warray-bounds-16.C, PR107561

Tested cris-elf, native x86_64-pc-linux-gnu. Ok to commit? --- 8< --- These appear as regressions from a baseline before r13-3761-ga239a63f868e29. See the PR trail. Note that the warning for g++.dg/pr71488.C is for a *header* file, thus we can't match the line number (sanely). gcc/testsuite:

Re: [PATCH] libstdc++ testsuite: Correct S0 in std/time/hh_mm_ss/1.cc

> From: Jonathan Wakely > Date: Wed, 1 Feb 2023 18:19:09 +0100 > On Wed, 1 Feb 2023 at 16:01, Jonathan Wakely wrote: > > > > On Wed, 1 Feb 2023 at 14:38, Hans-Peter Nilsson via Libstdc++ > > wrote: > > > > > > Tested cris-elf and native x86_64

[PATCH] libstdc++ testsuite: Correct S0 in std/time/hh_mm_ss/1.cc

Tested cris-elf and native x86_64-pc-linux-gnu. Ok to commit? -8< -- For targets where the ABI mandates structure layout that has no padding, like cris-elf, this test started failing when introduced as an add-on to the existing 1.cc, thereby effectively causing a regression in testsuite

Re: [PATCH] libsanitizer/mips: always build with largefile support

On Fri, 6 Jan 2023, YunQiang Su wrote: > -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 is always used for mips > when build libsanitizer in LLVM. Thus >FIRST_32_SECOND_64((_MIPS_SIM == _ABIN32) ? 176 : 160, 216); > instead of >FIRST_32_SECOND_64((_MIPS_SIM == _ABIN32) ? 160 : 144, 216); > in

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

Re: [PATCH] Add a new conversion for conditional ternary set into ifcvt [PR106536]

On Wed, 23 Nov 2022, HAO CHEN GUI via Gcc-patches wrote: > diff --git a/gcc/doc/tm.texi b/gcc/doc/tm.texi > index 92bda1a7e14..9823eccbe68 100644 > --- a/gcc/doc/tm.texi > +++ b/gcc/doc/tm.texi > @@ -7094,6 +7094,15 @@ the @code{POLY_VALUE_MIN}, @code{POLY_VALUE_MAX} and > implementation returns

[PATCH] testsuite: Fix mistransformed gcov

How was r13-2619-g34b9a03353d3fd "gcov: Respect triplet when looking for gcov" tested? I'm having a hard time believing it was tested with a *cross-compiler* *in-build-tree*. I think it was only tested for the special-case of an installed cross-compiler; not even with a native build exercising

Re: [PATCH 2/2] libstdc++: Move stream initialization into compiled library [PR44952]

> From: Patrick Palka via Gcc-patches > Date: Fri, 4 Nov 2022 16:05:25 +0100 > This patch moves the global object for constructing the standard streams > out from and into the compiled library on targets that support > the init_priority attribute. This means that no longer > introduces a

Re: [PATCH] Add condition coverage profiling

On Wed, 12 Oct 2022, Jørgen Kvalsvik via Gcc-patches wrote: > This patch adds support in gcc+gcov for modified condition/decision > coverage (MC/DC) with the -fprofile-conditions flag. I'd love improvements in this area. But this is a serious concern: > gcov --conditions: > > 3:

Re: [PATCH v6] LoongArch: add addr_global attribute

On Mon, 15 Aug 2022, Xi Ruoyao via Gcc-patches wrote: > Can we make a final solution to this soon? Now the merge window of > Linux 6.0 is closed and we have two Linux kernel releases not possible > to be built with Binutils or GCC with new relocation types. This is > just ugly... > > On Fri,

Re: [PATCH] Add pattern to convert vector shift + bitwise and + multiply to vector compare in some cases.

On Sat, 13 Aug 2022, mtsamis wrote: > When using SWAR (SIMD in a register) techniques a comparison operation within *within > such a register can be made by using a combination of shifts, bitwise and and > multiplication. If code using this scheme is vectorized then there is > potential > to

Re: Mips: Fix kernel_stat structure size

what should be done? > Should this be committed now, while the LLVM change is cherry-picked once > it's committed. > Best regards, > Dimitrije Milosevic > > > From: Hans-Peter Nilsson > Sent: Saturday, July 9, 2022 4:44 PM > To: Xi Ruoyao > Cc: Dimitrije Milosevic ; Djor

Re: Mips: Fix kernel_stat structure size

On Sat, 9 Jul 2022, Xi Ruoyao wrote: > On Fri, 2022-07-08 at 21:42 -0400, Hans-Peter Nilsson wrote: > > On Fri, 1 Jul 2022, Dimitrije Milosevic wrote: > > > > > Fix kernel_stat structure size for non-Android 32-bit Mips. > > > LLVM currently has this value f

Re: Mips: Fix kernel_stat structure size

On Fri, 1 Jul 2022, Dimitrije Milosevic wrote: > Fix kernel_stat structure size for non-Android 32-bit Mips. > LLVM currently has this value for the kernel_stat structure size, > as per compiler-rt/lib/sanitizer-common/sanitizer_platform_limits_posix.h. > This also resolves one of the build

Re: [PATCH v2 1/7] config: use $EGREP instead of egrep

On Mon, 27 Jun 2022, Xi Ruoyao via Gcc-patches wrote: > egrep has been deprecated in favor of grep -E for a long time, and the > next GNU grep release (3.8 or 4.0) will print a warning if egrep is used. > Unfortunately, old hosts with non-GNU grep may lack the support for -E > option. Use

[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

Re: [PATCH] aarch64: testsuite: symbol-range compile only

On Thu, 23 Jun 2022, Alexandre Oliva via Gcc-patches wrote: > +proc check_effective_target_two_plus_gigs { } { > +return [check_no_compiler_messages two_plus_gigs executable { > + int dummy[0x8000]; Don't you mean "char" as in "char dummy[0x8000]"? Or else the effective predicate

Re: [PATCH] Support multilib-aware target lib flags self-specs overriding

On Fri, 20 May 2022, Alexandre Oliva via Gcc-patches wrote: > > This patch introduces -multiflags, short for multilib TFLAGS, as an > option that does nothing by default, but that can be added to TFLAGS > and mapped to useful options by driver self-specs. > > I realize -m is reserved for

Re: [committed] exec-stack warning for test which wants executable stacks

> From: Hans-Peter Nilsson > Date: Thu, 26 May 2022 03:17:01 +0200 Regarding setting the default for the RWX-segment warning per-target: > How about the usual method, a line in the ld emulparams > file for the target? JFTR: no extra infrastructure bits needed. I found the righ

Re: [committed] exec-stack warning for test which wants executable stacks

> From: Jeff Law via Binutils > Date: Mon, 25 Apr 2022 17:30:59 +0200 > On 4/25/2022 9:26 AM, Nick Clifton wrote: > > Hi Jeff, > > > > Just FYI - I am also looking at adding in another warning. This > > time for > > when the linker creates a PT_LOAD segment which has all of the RWX > >

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

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

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 >

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

[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

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

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

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

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

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 tar

[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

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

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

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

Re: Benchmark recommendations needed

On Mon, 14 Feb 2022, Andras Tantos wrote: > Hello all! > > I'm working on porting GCC to a new processor architecture. I think > I've finally got to a fairly stable stage, so the next logical step > would be to test and optimize. For that, I would need some benchmarks, > and this is where I'm

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

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

Re: [committed] libstdc++: Fix test failures at -O0

On Fri, 11 Feb 2022, Jonathan Wakely via Gcc-patches wrote: > diff --git > a/libstdc++-v3/testsuite/20_util/unsynchronized_pool_resource/allocate.cc > b/libstdc++-v3/testsuite/20_util/unsynchronized_pool_resource/allocate.cc > index c81344a20e4..25e5ce63b58 100644 > ---

Re: [PATCH v3] Make `-Werror` optional in libatomic/libbacktrace/libgomp/libitm/libsanitizer

On Thu, 3 Feb 2022, David Seifert via Gcc-patches wrote: > On Thu, 2022-02-03 at 12:50 +0100, Jakub Jelinek wrote: > > On Thu, Feb 03, 2022 at 12:30:11PM +0100, David Seifert wrote: > > > * `-Werror` can cause issues when a more recent version of GCC > > > compiles > > > ? an older version: > > >

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

<    1   2   3   4   5   6   7   8   9   10   >