Re: [testsuite] note pitfall in how outputs.exp sets gld
On Jun 22, 2023, at 10:35 PM, Alexandre Oliva wrote: > > This patch documents a glitch in gcc.misc-tests/outputs.exp: it checks > whether the linker is GNU ld, and uses that to decide whether to > expect collect2 to create .ld1_args files under -save-temps, but > collect2 bases that decision on whether HAVE_GNU_LD is set, which may > be false zero if the linker in use is GNU ld. Configuring > --with-gnu-ld fixes this misalignment. Without that, atsave tests are > likely to fail, because without HAVE_GNU_LD, collect2 won't use @file > syntax to run the linker (so it won't create .ld1_args files). > > Long version: HAVE_GNU_LD is set when (i) DEFAULT_LINKER is set during > configure, pointing at GNU ld; (ii) --with-gnu-ld is passed to > configure; or (iii) config.gcc sets gnu_ld=yes. If a port doesn't set > gnu_ld, and the toolchain isn't configured so as to assume GNU ld, > configure and thus collect2 conservatively assume the linker doesn't > support @file arguments. > > But outputs.exp can't see how configure set HAVE_GNU_LD (it may be > used to test an installed compiler), and upon finding that the linker > used by the compiler is GNU ld, it will expect collect2 to use @file > arguments when running the linker. If that assumption doesn't hold, > atsave tests will fail. > > Does it make sense to put this in? I'd like to preserve this knowledge > somehow, and I suppose this would be most useful for someone observing > these failures and trying to figure out why they come about, so this > seems the best place for them. Ok to install? Ok.
Re: PING^2: Re: [PATCH 1/3] testsuite: move handle-multiline-outputs to before check for blank lines
On Jun 20, 2023, at 10:21 AM, David Malcolm wrote: > Does this testsuite patch look OK? > > https://gcc.gnu.org/pipermail/gcc-patches/2023-May/620275.html > > Thanks > David > > On Mon, 2023-06-12 at 19:11 -0400, David Malcolm wrote: >> Please can someone review this testsuite patch: >> https://gcc.gnu.org/pipermail/gcc-patches/2023-May/620275.html >> >> Thanks >> Dave >> >> On Wed, 2023-05-31 at 14:06 -0400, David Malcolm wrote: >>> I have followup patches that require checking for multiline >>> patterns >>> that have blank lines within them, so this moves the handling of >>> multiline patterns before the check for blank lines, allowing for >>> such >>> multiline patterns. >>> >>> Doing so uncovers some issues with existing multiline directives, >>> which >>> the patch fixes. Ok.
Re: Splitting up 27_io/basic_istream/ignore/wchar_t/94749.cc (takes too long)
On Jun 12, 2023, at 1:35 AM, Bernhard Reutner-Fischer wrote: > > On Sat, 10 Jun 2023 11:29:36 -0700 > Mike Stump wrote: > >> On Jun 9, 2023, at 2:47 PM, Bernhard Reutner-Fischer >> wrote: > >>>But well. Either way, what >>> should we do about remote env, if there is one? If the target >>> supports it, send it and skip otherwise? > >> So, to focus a >> conversation, which target, which host, canadian? Which part of the >> environment? What part is missing you want to fix? Want to unify >> between targets... and so on. >> > > The most recent target where this came up again was GCN i think. > See the last block in > https://inbox.sourceware.org/gcc-patches/20230508195217.4897009f@nbbrfq/ > and Thomas' reference therein to Tobias' > https://inbox.sourceware.org/gcc-patches/018bcdeb-b3bb-1859-cd0b-a8a92e26d...@codesourcery.com/ > > thoughts? I kinds like the remote_setenv approach, but the low level details when one gets in there and wires up all they need to make it work are important. If someone wants to tilt at the problem, I'm inclined to let them find the incantation they like and approve it. I'd rather approve a patch that takes us a step closer to perfection then go another 10 years. For quoting. I like quite using ' if there is no ' in the string. For each ' in the string, replace it with '\'', inelegant, but easier to reason about and don't have to worry about as many meta characters if you try and go the "" route. This assumes something like sh is taking in commands. This isn't always the case. One can canadian into a windows box or some other weird thing so the mechanism used has to be next to the thing that knows what it is talking to. Just because someone contributes code for talking to sh, doesn't mean they have to bother with windows or other weird stuff. The next person to come along can tilt at that.
Re: Splitting up 27_io/basic_istream/ignore/wchar_t/94749.cc (takes too long)
On Jun 9, 2023, at 2:47 PM, Bernhard Reutner-Fischer wrote: > > On 9 June 2023 19:18:45 CEST, Mike Stump via Gcc-patches > wrote: >> simulation ports. Maybe a 20-100x speedup? If you want to go this way I'd >> say do it in python at the bottom as it would be nice to switch over to >> python in the next 5-20 years and away from tcl. > > Yes, i guess we have all pondered this for way long enough, but it is a lot > of work still. > > The nice side effect would be that we see such hogs easier and earlier, at > least more comfortable. But well. Either way, what should we do about remote > env, if there is one? If the target supports it, send it and skip otherwise? Testing is a large barrel of monkeys with a ton of small points, each of which is critical in some one. It is hard to talk about generalities when those details are very specific. So, to focus a conversation, which target, which host, canadian? Which part of the environment? What part is missing you want to fix? Want to unify between targets... and so on.
Re: Splitting up 27_io/basic_istream/ignore/wchar_t/94749.cc (takes too long)
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 simulator" I'd let the libstdc++ people comment on specific things. I'll comment on general things. We could let line count (or word count or character count) scale the timeout in part, we could record times in a db and put an expected run time into test cases or in an along side db. We could have factors for slow systems, slow simulators. A 5 GHz x86_64 will likely be faster that a 40 year old pdp11. We can have these scale factors trigger off OS, cpu statically, and/or we can do a quick bogomips calculation and let that scale it and record that scaling factor in the build tree. A wealth of possibilities. Solutions that require maintenance or test case modification are annoying. Solutions that need port work are annoying. I'd be tempted to say bogomips into the build (test) tree. There are two parts, time to compile test cases and time to run them. I'd be fine with a half solution that only does what you need. The other part can be done by someone that has a need. I'd invite comments by others on other solutions or commentary on downsides. For example, having a 208 thread count machine that takes 2-3 minutes to run the full testsuite is nice. A problem arises when 4-10 test cases suddenly start timing out. You then go to around 10-53 minutes to test, which is annoying. Anything that boosts the timeouts can hinder early port bring up, which, we'd like to avoid. I mention it without much a solution other than a db approach in the test tree that records each test case and can identify test cases that timeout and trim the timeout for them to something nicer like base + 50% once they timeout with a larger allotment of time. We could entertain wild thoughts. For example, make a run cache that caches run results given an object. See an object in the future, just look it up in a hash cache for the object and return those results instead of running it. This can give you a large speedup in testing and would simultaneously advantage all slow simulation ports. Maybe a 20-100x speedup? If you want to go this way I'd say do it in python at the bottom as it would be nice to switch over to python in the next 5-20 years and away from tcl. A object cache in python, should be fairly small wether it is used for remembering run times from previous runs and setting a timeout based upon it, or as a does it run and pass or run and fail cache. The caches are likely only part of the problem, one still needs to have a timeout when no cache entry it present. They can speed testing for the day to day grind of people that run 1-200 times a week.
Re: Tighten 'dg-warning' alternatives in 'c-c++-common/Wfree-nonheap-object{,-2,-3}.c' (was: [PATCH] correct -Wmismatched-new-delete (PR 98160, 98166))
On Jun 7, 2023, at 8:01 AM, Thomas Schwinge wrote:
> On 2020-12-08T13:46:32-0700, Martin Sebor via Gcc-patches
> wrote:
>> The attached changes [...]
>
> ... eventually became commit fe7f75cf16783589eedbab597e6d0b8d35d7e470
> "Correct/improve maybe_emit_free_warning (PR middle-end/98166, PR c++/57111,
> PR middle-end/98160)".
>
>> * c-c++-common/Wfree-nonheap-object-2.c: New test.
>> * c-c++-common/Wfree-nonheap-object-3.c: New test.
>> * c-c++-common/Wfree-nonheap-object.c: New test.
>
> OK to push the attached
> "Tighten 'dg-warning' alternatives in
> 'c-c++-common/Wfree-nonheap-object{,-2,-3}.c'"?
Ok.
Re: Remove 'gcc/testsuite/g++.dg/warn/Wfree-nonheap-object.s' (was: [PATCH] add -Wmismatched-new-delete to middle end (PR 90629))
On Jun 7, 2023, at 7:54 AM, Thomas Schwinge wrote: > > On 2020-11-03T16:56:48-0700, Martin Sebor via Gcc-patches > wrote: >> Attached is a simple middle end implementation of detection of >> mismatched pairs of calls to C++ new and delete, along with >> a substantially enhanced implementation of -Wfree-nonheap-object. > > This eventually became commit dce6c58db87ebf7f4477bd3126228e73e497 > "Add support for detecting mismatched allocation/deallocation calls". > Already in this original patch submission: > >> diff --git a/gcc/testsuite/g++.dg/warn/Wfree-nonheap-object.s >> b/gcc/testsuite/g++.dg/warn/Wfree-nonheap-object.s >> new file mode 100644 >> index 000..e69de29bb2d > > OK to push the attached > "Remove 'gcc/testsuite/g++.dg/warn/Wfree-nonheap-object.s'"? Ok.
Re: [testsuite] bump some tsvc timeouts
On Jun 7, 2023, at 1:12 AM, Alexandre Oliva wrote: > > Several tests are timing out when targeting x86-*-vxworks with qemu. > > Bump their timeout factor. Ok. I think these are obvious to people that have to work with simulators and the testsuite so if you want to self approve you can.
Re: [PATCH] [i386] Support type _Float16/__bf16 independent of SSE2.
LLM, machine learning and AI likes coding with data types that are weird, float16, bf16, 8 bit float and 4 bit floats. Longer term, would be nice to natively support these everywhere. Would be nice to trial run them in the compiler, sort it all out, so that the implementation experience can drive language adoption. A little speculative and a little narrow focus for the field, but, AI isn't going away in the next 20 years I don't think. Anyway, I like the direction. On Apr 19, 2023, at 12:15 AM, liuhongt via Gcc-patches wrote: > That said, these fundamental types whose presence/absence depends on ISA flags > are quite problematic IMHO, as they are incompatible with the target > attribute/pragmas. Whether they are available or not available depends on > whether in this case SSE2 is enabled during compiler initialization (aka after > parsing command line options) and then they are available or unavailable to > everything else based on that. > -comments end-- > > Enable _Float16 and __bf16 all the time but issue errors when the
Re: 'g++.dg/modules/modules.exp': don't leak local 'unsupported' proc [PR108899]
On Mar 30, 2023, at 6:51 AM, Alexandre Oliva wrote: > > On Mar 30, 2023, Alexandre Oliva wrote: > >> If we're dropping the renaming, I suppose we could also revert Jakub's >> change. I suppose this patch will take care of it, pending testing... > > Regstrapped on x86_64-linux-gnu and also tested on arm-vx7r2 (with > gcc-12), where I used to get fails after an unsupported modules.exp > test, but there are no curly braces in the log files after the patch. > Ok to install? Ok.
Re: [Patch] c-c++-common/Warray-bounds.c: fix excess warnings on LLP64
On Feb 27, 2023, at 2:29 AM, Jonathan Yong via Gcc-patches wrote: > > Attached patch OK? Ok. >* c-c++-common/Warray-bounds.c: Fix excess warnings on > > LLP64.<0001-c-c-common-Warray-bounds.c-fix-excess-warnings-on-LL.patch>
Re: [PATCH] [testsuite] enable -maltivec like vect_int for signbit-2.c
On Mar 25, 2023, at 1:33 AM, Alexandre Oliva wrote: > > Explicitly enable altivec if it's supported. vect_int tests for > powerpc_altivec_ok, but without the explicit option, if altivec is not > enabled by default, we end up expecting vectorization that doesn't > occur. > > Regstrapped on ppc64-linux-gnu. Also tested with ppc64-vxworks7r2 > (gcc-12). Ok to install? Ok. > for gcc/testsuite/ChangeLog > > * gcc.dg/signbit-2.c: Add -maltivec if supported.
Re: [PATCH] testsuite: always use UTF-8 in scan-sarif-file[-not] [PR105959]
On Mar 20, 2023, at 3:06 PM, David Malcolm via Gcc-patches wrote: > > c-c++-common/diagnostic-format-sarif-file-4.c is a test case for > quoting non-ASCII source code in a SARIF diagnostic log. > > The SARIF standard mandates that .sarif files are UTF-8 encoded. > > PR testsuite/105959 notes that the test case fails when the system > encoding is not UTF-8, such as when the "make" invocation is prefixed > with LC_ALL=C, whereas it works with in a UTF-8-locale. > > The root cause is that dg-scan opens the file for reading using the > "system" encoding; I believe it is falling back to treating all files as > effectively ISO 8859-1 in a non-UTF-8 locale. > > This patch fixes things by adding a mechanism to dg-scan to allow > callers to (optionally) specify an encoding to use when reading the > file, and updating scan-sarif-file (and the -not variant) to always > use UTF-8 when calling dg-scan, fixing the test case with LC_ALL=C. > OK for trunk? Ok.
Re: [PATCH] [testsuite] test for weak_undefined support and add options
On Mar 15, 2023, at 11:40 PM, Alexandre Oliva wrote: > > On Mar 15, 2023, Alexandre Oliva wrote: > >> Regstrapped on ppc64-linux-gnu. Also tested (with gcc-12) on multiple >> *-vxworks7r2 targets (arm, aarch64, ppc64, x86, x86_64). Ok to install? > > Further testing revealed a problem in my attempted use of lappend in > aapcs64.exp, in the previous version of the patch. Fixed in this one, > retested on aarch64-vxworks7r2. Ok to install? Ok.
Re: [PATCH] testsuite: Support scanning tree-dumps
On Mar 6, 2023, at 10:52 AM, Hans-Peter Nilsson via Gcc-patches wrote: > > Ok to apply? Ok. > * lib/target-supports.exp (check_compile): Support scanning tree-dumps.
Re: [PATCH 1/3] testsuite: Add tail_call effective target
On Mar 6, 2023, at 10:45 AM, Hans-Peter Nilsson via Gcc-patches wrote: > > Ok to commit? Ok. > -- >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 target names nearby so this is just belts and suspenders. Using > "tail_call" as a shorter and more commonly used term than a derivative > of "sibling calls", and expecting only gcc folks to have heard of > "sibcalls". > > * lib/target-supports.exp (check_effective_target_tail_call): New.
Re: Ping: [PATCH 1/2] testsuite: Provide means to regexp in multiline patterns
Ok On Mar 3, 2023, at 5:58 PM, Hans-Peter Nilsson wrote: > > Ping... > >> From: Hans-Peter Nilsson >> Date: Fri, 24 Feb 2023 20:16:03 +0100 >> >> Ok to commit?
Re: [PATCH 0/2] LoongArch: testsuite: Fix tests related to stack
On Mar 3, 2023, at 12:40 AM, Xi Ruoyao via Gcc-patches wrote: > > Some trivial test case fixes. Ok for trunk? Ok.
Re: Ping: [PATCH] testsuite: Tweak gcc.dg/attr-aligned.c for CRIS
On Feb 27, 2023, at 5:54 PM, Hans-Peter Nilsson via Gcc-patches wrote: > > Ping... Ok. > >> From: Hans-Peter Nilsson >> Date: Thu, 16 Feb 2023 21:05:29 +0100 > >> Asking for the lines outside the "#if __CRIS__" part. >> Ok to commit? >> >> -- >8 -- >> tm.texi says for BIGGEST_ALIGNMENT (from which >> __BIGGEST_ALIGNMENT__ is derived): "Biggest alignment that >> any data type can require on this machine, in bits." >> >> That is, using that value might be too strict for alignment >> of *functions* and CRIS requires at least 16-bit alignment >> for functions. But, one purpose of the test is to test that >> alignment can be set to a large but valid value, so pick >> 512, which has some use as a historically required alignment >> for certain I/O descriptors. >> >> * gcc.dg/attr-aligned.c: Adjust comment for ALIGN_MAX_STATIC. >> (ALIGN_MAX_STATIC): Set to 512 for CRIS. >> --- >> gcc/testsuite/gcc.dg/attr-aligned.c | 8 +++- >> 1 file changed, 7 insertions(+), 1 deletion(-) >> >> diff --git a/gcc/testsuite/gcc.dg/attr-aligned.c >> b/gcc/testsuite/gcc.dg/attr-aligned.c >> index 887bdd0f3799..4f0c885dc812 100644 >> --- a/gcc/testsuite/gcc.dg/attr-aligned.c >> +++ b/gcc/testsuite/gcc.dg/attr-aligned.c >> @@ -18,6 +18,10 @@ >> # else >> # define ALIGN_MAX_STATIC ALIGN_MAX_HARD >> # endif >> +#elif __CRIS__ >> +/* __BIGGEST_ALIGNMENT__ doesn't cover functions (16 bits for CRIS). */ >> +# define ALIGN_MAX_STATIC 512 >> +# define ALIGN_TOO_BIG_OFILE (ALIGN_MAX_HARD << 1) >> #elif pdp11 >> # define ALIGN_MAX_STATIC 2 >> /* Work around a pdp11 ICE (see PR target/87821). */ >> @@ -29,7 +33,9 @@ >> /* Is this processor- or operating-system specific? */ >> # define ALIGN_MAX_STATIC ALIGN_MAX_HARD >> #else >> - /* Guaranteed to be accepted regardless of the target. */ >> + /* Guaranteed to be accepted regardless of the target for objects. >> + This might not be true for alignment of functions though, so >> + may need to be set to a target-specific value above. */ >> # define ALIGN_MAX_STATIC __BIGGEST_ALIGNMENT__ >>/* Guaranteed to be rejected regardless of the target. */ >> # define ALIGN_TOO_BIG_OFILE (ALIGN_MAX_HARD << 1) >> -- >> 2.30.2 >>
Re: [PATCH] testsuite: Don't include multiline regexps in the the pass/fail log
On Feb 27, 2023, at 9:59 AM, Hans-Peter Nilsson wrote:
>
>> 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_x}pass "$title was found: \"$escaped_regex\""
>>> + ${maybe_x}pass "$title was found"
>>> } else {
>>> - ${maybe_x}fail "$title not found: \"$escaped_regex\""
>>> + ${maybe_x}fail "$title not found"
>>
>> Side remark:
>>
>> So, the string on pass and the string on fail are supposed
>> to be exactly the same. Regression analysis works only if
>> the string is the same. "regexp test", might be
>> suggestive enough and can be the same spelling for both.
>
> Right. Should I changed it now?
Sure. Not required, but would be nice.
> (Pro: see above. Con: again meddling with regression-test history.)
Only new tests that don't have any polish do this sort of thing. :-)
> Like (editing on the fly here) as the "found" part seems
> redundant:
>
>>> - ${maybe_x}pass "$title was found"
>>> + ${maybe_x}pass "$title"
>>> } else {
>>> - ${maybe_x}fail "$title not found"
>>> + ${maybe_x}fail "$title"
Yes, same difference. Both strings should be identical.
Thanks.
Re: [PR100127] Test for coroutine header in clang-compatible tests
On Feb 22, 2023, at 12:04 PM, Alexandre Oliva wrote: > > That would change what gets tested with clang, I suppose, but I hope > that's for the better. I wondered what to do at the #else above, and > decided to spell it a little differently. Retested on x86_64-linux-gnu > (trunk) and arm-vxworks7r2 (gcc-12), ok to install? Ok.
Re: [PATCH] testsuite: Don't include multiline regexps in the the pass/fail log
On Feb 24, 2023, at 9:54 AM, Hans-Peter Nilsson via Gcc-patches
wrote:
>
> Ok to commit?
Ok. Thanks.
> 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_x}pass "$title was found: \"$escaped_regex\""
> + ${maybe_x}pass "$title was found"
> } else {
> - ${maybe_x}fail "$title not found: \"$escaped_regex\""
> + ${maybe_x}fail "$title not found"
Side remark:
So, the string on pass and the string on fail are supposed to be exactly the
same. Regression analysis works only if the string is the same. "regexp
test", might be suggestive enough and can be the same spelling for both.
Re: [PATCH] Drop need for constant I in ctf test
On Feb 16, 2023, at 10:59 PM, Alexandre Oliva wrote: > > Though I is supposed to be a constant expression, this is not the case > on vxworks, but this is not what this debug information format test is > testing for, so use real constants to initialize complex variables. > > Regstrapped on x86_64-linux-gnu. > Tested on arm-vxworks7 (gcc-12) and arm-eabi (trunk). Ok to install? Ok.
Re: [PATCH] [arm] xfail fp-uint64-convert-double-* on all arm targets
On Feb 16, 2023, at 10:20 PM, Alexandre Oliva wrote: > > It wasn't long ago that I xfailed these tests on arm-*-eabi, but the > fail is expected on all other arm targets: even when hard float is > available, conversions between 64-bit integers and double are always > emulated on ARM, and the emulation disregards rounding modes. So, > bump the xfail to all of arm-*-*. > > Regstrapped on x86_64-linux-gnu. > Tested on arm-vxworks7 (gcc-12) and arm-eabi (trunk). Ok to install? Ok.
Re: [arm] [testsuite] asm-flag-4.c: match quotes in expected message
On Feb 16, 2023, at 10:15 PM, Alexandre Oliva wrote: > > Quotes were added around the "asm" keyword in the message expected by > the test, so the test needs adjusting. > > Regstrapped on x86_64-linux-gnu. > Tested on arm-vxworks7 (gcc-12) and arm-eabi (trunk). > Ok to install? Ok.
Re: testsuite: Fix pr55569.c excess errors
On Dec 20, 2022, at 1:22 AM, Jonathan Yong via Gcc-patches wrote: > > This fixes the following: > > Excess errors: > > gcc/testsuite/gcc.c-torture/compile/pr55569.c:13:12: warning: overflow in > conversion from 'long long unsigned int' to 'long int' changes value from > '4611686018427387903' to '-1' [-Woverflow] > > gcc/testsuite/gcc.c-torture/compile/pr55569.c:13:34: warning: iteration > 2147483647 invokes undefined behavior [-Waggressive-loop-optimizations] > > Patch OK? Ok.
Re: [PATCH] testsuite: btf: Fix btf-datasec-1.c for RISC-V
On May 10, 2022, at 6:31 PM, Kito Cheng via Gcc-patches wrote: > > LGTM, that's only added a new option for RISC-V and won't affect all > other targets, so I assume I can approve that. Yes. Usual and customary for ports.
Re: [PATCH Rust front-end v2 02/37] gccrs: Add nessecary hooks for a Rust front-end testsuite
Ok. > On Aug 24, 2022, at 4:59 AM, herron.phi...@googlemail.com wrote: > > From: Philip Herron > > This copy's over code from other front-end testsuites to enable testing > for the rust front-end specifically. > > Co-authored-by: Marc Poulhiès > Co-authored-by: Thomas Schwinge > --- > gcc/testsuite/lib/rust-dg.exp | 49 + > gcc/testsuite/lib/rust.exp| 186 ++
Re: Rust frontend patches v1
On Aug 10, 2022, at 11:56 AM, Philip Herron wrote: > > For my v2 of the patches, I've been spending a lot of time ensuring > each patch is buildable. It would end up being simpler if it was > possible if each patch did not have to be like this so I could split > up the front-end in more patches. Does this make sense? In theory, > when everything goes well, does this still mean that we can merge in > one commit, or should it follow a series of buildable patches? I've > received feedback that it might be possible to ignore making each > patch an independent chunk and just focus on splitting it up as small > as possible even if they don't build. It is a waste of time to make each build. The all go in together, or not at all. The patches are split for review only. You can then maintain approval status for each individually and perform adjustments and updates for each patch. Once all pieces have been approved in their final form, you can then commit the whole at once. It is this commit, before you commit, that you regression test, integration test, and ensure that final form is good. If not, you bounce back to update for all the pieces that need it, approval for those edits, and lather, rinse, repeat. It is handy for larger work (like this) to be on a git branch so that followers can see the totality of the work and experiment with it in the large. I'd usually do the commit to the main branch as a squashed commit without the review edit histories or the "bad stuff" the reviewers had you change or the merge records even.
Re: [PATCH] i386 testsuite: cope with --enable-default-pie
On Jul 11, 2022, at 6:47 PM, Alexandre Oliva wrote: > > Running the testsuite on a toolchain build with --enable-default-pie > had some unexpected fails. > Regstrapped on x86_64-linux-gnu, and also tested on i686-linux-gnu, with > and without --enable-default-pie on both platforms. Ok to install? Ok. > PS: There's at least one additional FAIL with --enable-default-pie in > the trunk, namely gcc.target/i386/mvc7.c > WDYT? Seems reasonable.
Re: [PATCH] testsuite: add missing dg-require-effective-target fpic
Ok.
On May 5, 2022, at 2:35 AM, Marc Poulhies via Gcc-patches
wrote:
>
> Marc Poulhiès writes:
>
>> Require effective target fpic for newly added test.
>>
>> gcc/testsuite/
>> * g++.dg/ext/visibility/visibility-local-extern1.C: Add missing
>> dg-require-effective-target fpic.
>>
>> Tested on x86_64-linux. Ok for master?
>>
>> ---
>> gcc/testsuite/g++.dg/ext/visibility/visibility-local-extern1.C | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/gcc/testsuite/g++.dg/ext/visibility/visibility-local-extern1.C
>> b/gcc/testsuite/g++.dg/ext/visibility/visibility-local-extern1.C
>> index 40c20199d0c..6fb1cc7f381 100644
>> --- a/gcc/testsuite/g++.dg/ext/visibility/visibility-local-extern1.C
>> +++ b/gcc/testsuite/g++.dg/ext/visibility/visibility-local-extern1.C
>> @@ -1,6 +1,7 @@
>> // PR c++/103291
>> // { dg-additional-options -fpic }
>> // { dg-final { scan-assembler-not "@GOTPCREL" } }
>> +// { dg-require-effective-target fpic }
>>
>> #pragma GCC visibility push(hidden)
>
> ping ?
Re: [PATCH] testsuite/s390: Adapt test expections.
On Apr 4, 2022, at 4:52 AM, Robin Dapp via Gcc-patches wrote: > OK for trunk? > +/* Since r12-4475-g247c407c83f001 the following immediates are being > + converted and directly stored in the literal pool so no explicit > + conversion is necessary. */ Not fan of git revision numbers in the source code. Also, having historical behaviors most of the time isn't useful/interesting, so I'd generally omit such descriptions.
Re: [PATCH v6 11/12] LoongArch Port: gcc/testsuite
On Jan 28, 2022, at 5:49 AM, chenglulu wrote: > > gcc/testsuite/ > >* g++.dg/cpp0x/constexpr-rom.C: Add build options for LoongArch. >* g++.old-deja/g++.abi/ptrmem.C: Add LoongArch support. >* g++.old-deja/g++.pt/ptrmem6.C: xfail for LoongArch. >* gcc.dg/20020312-2.c: Add LoongArch support. >* gcc.dg/loop-8.c: Skip on LoongArch. >* gcc.dg/torture/stackalign/builtin-apply-2.c: Likewise. >* gcc.dg/tree-ssa/ssa-fre-3.c: Likewise. >* go.test/go-test.exp: Define the LoongArch target. >* lib/target-supports.exp: Like wise. >* gcc.target/loongarch/loongarch.exp: New file. >* gcc.target/loongarch/tst-asm-const.c: Like wise. Ok.
Re: [PATCH] testsuite: Fix up tree-ssa/divide-7.c testcase [PR95424]
On Jan 29, 2022, at 8:26 AM, Jakub Jelinek via Gcc-patches wrote: > > This test fails everywhere, because ? doesn't match literal ?. > It should use \\? instead. I've also changed those .s in there. > Tested on x86_64-linux (-m32/-m64) and powerpc64le-linux, ok for trunk? Ok.
Re: [PATCH] Fix spelling of ones' complement.
On Nov 15, 2021, at 5:48 PM, Marek Polacek via Gcc-patches wrote: > > Nitpicking time. It's spelled "ones' complement" rather than "one's > complement". I didn't go into config/. > > Ok for trunk? So, is it two's complement or twos' complement then? Seems like it should be the same, but wikipedia suggests it is two's complement, as does google. If that is wrong, you should go edit it as well. :-)
Re: [PATCH] testsuite, Darwin : Do not claim 'GAS' for cctools assembler.
On Aug 19, 2021, at 1:02 PM, Iain Sandoe wrote: > > Although the cctools assembler is based of GNU GAS, it is from a > very old version (1.38) which does not support many of the features > that the target supports test is expecting***. > > tested on i686 and x86_64 darwin versions using the cctools as. > OK for master? Ok.
Re: [PATCH] wwwdocs: Clarify meaning of "not issued by" in bugs web page
On Jul 27, 2021, at 10:30 AM, Martin Sebor via Gcc-patches wrote: > On 7/27/21 9:16 AM, Jonathan Wakely via Gcc-patches wrote: >> Secondly, releases are not issued by the GNU Project at all, they're >> issued by the GCC release managers. > > I (and I suspect most users unfamiliar with the inner workings of > the project) think of release managers as acting on behalf of > the whole project, so even though they technically cut the release > it's still put out by the project as a whole. I agree. The GCC releases we put out are GCC project releases, and GNU project software releases.
Re: Add '__OPTIMIZE__' DejaGnu selector
On May 18, 2021, at 9:02 AM, Thomas Schwinge wrote: > Is the attached "Add '__OPTIMIZE__' DejaGnu selector" OK to push after > testing? Ok.
Re: [GOVERNANCE] Where to file complaints re project-maintainers?
This isn't a patch to gcc, please stop posting non-technical content to this
list. Please review what this list is for and the rules for this list before
you post again, thanks.
> On May 14, 2021, at 7:47 AM, abebeos via Gcc-patches
> wrote:
>
> Hi there IT-fascists, clowns, master-clowns,
> totally-confused-incompetent-code-plumbers,
> activity-trapped-silent-high-performers,
> stay-out-of-trouble-silent-high-performers! (Guess where G.J. Lay fits in
> the collection...).
>
> Please be aware that I do not read any messages here (including the one I'm
> replying to), in this unregulated circus-show ("The GCC Project"). I've
> polluted my mind enough with your nonsense justifications, to be honest it
> is becoming quite disgusting.
>
> If any serious person from the FSF (as to my tiny research, the FSF is in
> the end legally and ethically responsible for what happens on GCC) want to
> comment on this, please send me additionally a copy of your message.
>
> FSF:
>
> Copyright: https://www.fsf.org/about/dmca-notice
> Privacy: https://www.fsf.org/about/free-software-foundation-privacy-policy
> IT-fascists, Bullying, discrimination, workers-abuse, rigged voting
> processes: ???
Re: fix asm-not pattern in dwarf2/inline5.c
On Apr 27, 2021, at 8:32 AM, Alexandre Oliva wrote: > > The test is supposed to check that the abstract lexical block of a > function that was inlined doesn't have attributes, and that the > concrete inlined lexical block does. > The problem is that '[.../...]+ +[^(].*' matches '/ (DIE...', because > '[^(]' may match the second blank, and after that anything goes. > Ok to install? Ok.
Re: add rv64im{,c,fc} multilibs
On Feb 24, 2021, at 1:10 AM, Alexandre Oliva wrote: > > On Feb 23, 2021, Jim Wilson wrote: >> If we add default multilibs for you > > *nod*, it's a very familiar issue to me, I know where that's coming > from, no worries. So, what I'd do is if you have a triplet component that isn't used much, say, the middle one, you can embed the vendor there, and use the vendor to trigger which multilib set you want. i386-unknown-linux becomes i386-telcovendor2-linux and then telcovendor2 selects new multilib set. The generic port, selects the base multilib set, and no one, other then a vendor build would select the vendor set. That's one solution, there are others. For example, on a system, you can smell the previously installed multilib set, and default to building those.
Re: c++: Macros need to be GTY-reachable [PR 99023]
On Feb 18, 2021, at 6:15 AM, Jakub Jelinek via Gcc-patches wrote: > > On Wed, Feb 17, 2021 at 01:46:37PM -0500, Nathan Sidwell wrote: >> I'd missed that macros were allocated from GC storage, and that they can >> become unattached from an identifier, and therefore not GC-reachable. >> And then bad things happen. Fixed by making the module machinery's >> reference vector a GC root. >> >> PR c++/99023 >>gcc/cp/ >>* module.cc (struct macro_export): Add GTY markers. >>(macro_exports): Likewise, us a va_gc Vector. >>gcc/testsuite/ >>* g++.dg/modules/pr99023_a.H: New. >>* g++.dg/modules/pr99023_b.H: New. > > I must say I don't know much about modules, but seeing the second set > of > 100KB g++.dg/modules/ testcases Indeed, a test case that shows a memory error, likely is misguided at any size as we don't have a system to reliably detect when we are wondering outside the GTY sandbox.
Re: [PATCH][testsuite] (committed) Fix sed script errors in complex tests
On Jan 15, 2021, at 1:13 AM, Tamar Christina via Gcc-patches wrote: > I ran sed script late over the tests which accidentally > introduced a syntax error in the tests. > > This fixes it. > > Committed under the obvious rule. > > Ok for master? :-) Which is it? Anyway, Ok.
Re: Fix testsuite/g++.dg/cpp1y/constexpr-66093.C execution failure...
On Jan 1, 2021, at 6:41 PM, Alexandre Oliva wrote:
>
> On Jan 1, 2021, Mike Stump wrote:
>
>> On Jan 1, 2021, at 3:37 PM, Alexandre Oliva wrote:
>>>
>>> On Dec 29, 2020, Mike Stump wrote:
>>>
a[i-1] = i;
>>>
>>> 'fraid that won't pass:
>>>
>>> for (int i = 0; i < n; i++) {
>>> assert (a[i] == i);
>>> }
>
>> Ok, how about your version with the comment updated?
>
> Err, are we talking about the same testcase?
> There aren't any comments in this one.
Oh, It's possible the comments were stripped from the bug report or initial
email. Never mind then about the comment part.
Re: Fix testsuite/g++.dg/cpp1y/constexpr-66093.C execution failure...
On Jan 1, 2021, at 3:37 PM, Alexandre Oliva wrote:
>
> On Dec 29, 2020, Mike Stump wrote:
>
>> a[i-1] = i;
>
> 'fraid that won't pass:
>
>for (int i = 0; i < n; i++) {
>assert (a[i] == i);
>}
Ok, how about your version with the comment updated?
Re: disable some aapcs/vfp*.c test if not arm_fp16_alternative_ok
On Dec 22, 2020, at 1:47 PM, Alexandre Oliva wrote: > > The tests use -mfp16-format=alternative, and so should not be run > if that option isn't supported. > > Regstrapped on x86_64-linux-gnu, and tested with -x-arm-wrs-vxworks7r2. > Ok to install? Ok.
Re: fix testsuite/g++.dg/init/new26.C for C++-14 and later
On Dec 22, 2020, at 1:40 PM, Alexandre Oliva wrote: > > This test fails during the execution on VxWorks 7 when using > C++-14 and C++-17. > > Regstrapped on x86_64-linux-gnu, and tested with -x-arm-wrs-vxworks7r2. > Ok to install? Ok.
Re: g++.dg/tls/pr79288.C: Skip on vxworks_kernel (TLS model not supported)
On Dec 22, 2020, at 1:57 PM, Alexandre Oliva wrote: > > The only TLS model supported in VxWorks kernel mode is local-exec. > > Regstrapped on x86_64-linux-gnu, and tested with -x-arm-wrs-vxworks7r2. > Ok to install? Ok.
Re: compile gcc.target/arm/{pr78255-2.c, memset-inline-2.c} with -mno-long-calls
On Dec 22, 2020, at 1:56 PM, Alexandre Oliva wrote: > > This change adds -mno-long-calls to the list of compiler options > to make sure we generate short call code, allowing the assembly > matching to pass. > > This is added unconditionally to the dg-options (as opposed to using > dg-additional-options) because this test is already specific to ARM > targets, and -mno-long-calls is available on all ARM targets. > > Regstrapped on x86_64-linux-gnu, and tested with -x-arm-wrs-vxworks7r2. > Ok to install? Ok.
Re: Fix testsuite/g++.old-deja/g++.mike/p658.C build failure on VxWorks RTP
On Dec 22, 2020, at 1:45 PM, Alexandre Oliva wrote: > > The conflicting definition of OK is present in VxWorks RTP headers too. > > Regstrapped on x86_64-linux-gnu, and tested with -x-arm-wrs-vxworks7r2. > Ok to install? Ok. Ok to stylize all the #undef in the same way. This is one happens to use a slightly different stye then the others as I recall.
Re: Fix testsuite/g++.dg/opt/20050511-1.C compilation error on VxWorks 7
On Dec 22, 2020, at 1:44 PM, Alexandre Oliva wrote: > > In VxWorks 7, UINT32 is defined in both modes, kernel and rtp. Adjust > the work around accordingly. > > Regstrapped on x86_64-linux-gnu, and tested with -x-arm-wrs-vxworks7r2. > Ok to install? Ok.
Re: Fix testsuite/g++.dg/cpp1y/constexpr-66093.C execution failure...
On Dec 22, 2020, at 1:44 PM, Alexandre Oliva wrote:
>
> The constexpr iteration dereferenced an array element past the end of
> the array.
>
> Regstrapped on x86_64-linux-gnu, and tested with -x-arm-wrs-vxworks7r2.
> Ok to install?
How about:
a[i-1] = i;
instead? This I think better matches the comment in the code, and preserves
the expected output as well.
If you like that and that works, Ok for that version.
> from Jerome Lambourg
> for gcc/testsuite/ChangeLog
>
>* g++.dg/cpp1y/constexpr-66093.C: Fix bounds issue.
> ---
> gcc/testsuite/g++.dg/cpp1y/constexpr-66093.C |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/gcc/testsuite/g++.dg/cpp1y/constexpr-66093.C
> b/gcc/testsuite/g++.dg/cpp1y/constexpr-66093.C
> index ad3169210d29a..3d742cfebd83d 100644
> --- a/gcc/testsuite/g++.dg/cpp1y/constexpr-66093.C
> +++ b/gcc/testsuite/g++.dg/cpp1y/constexpr-66093.C
> @@ -19,7 +19,7 @@ private:
>
> constexpr A f() {
> A a{};
> -for (int i = 1; i <= n; i++) {
> +for (int i = 0; i < n; i++) {
> a[i] = i;
> }
> return a;
Re: Skip testsuite/g++.old-deja/g++.pt/const2.C on vxworks_kernel
On Dec 22, 2020, at 1:43 PM, Alexandre Oliva wrote:
>
> Linking in vxworks kernel-mode is partial linking, so missing symbols
> are not detected.
>
> Regstrapped on x86_64-linux-gnu, and tested with -x-arm-wrs-vxworks7r2.
> Ok to install?
Ok.
Generally nicer to bunch all like ones ("partial link" for example) together.
Re: Remove VxWorks-specific test directives in g++.dg/warn/miss-format-1.C
On Dec 22, 2020, at 1:42 PM, Alexandre Oliva wrote: > > These are no longer applicable. > > Regstrapped on x86_64-linux-gnu, and tested with -x-arm-wrs-vxworks7r2. > Ok to install? Ok.
Re: Undefine ERROR in g++.dg/tree-ssa/copyprop.C
On Dec 22, 2020, at 1:41 PM, Alexandre Oliva wrote: > > VxWorks headers define ERROR as a macro, which conflicts with the use > in the test. > > Regstrapped on x86_64-linux-gnu, and tested with -x-arm-wrs-vxworks7r2. > Ok to install? Ok.
Re: skip testsuite/g++.dg/other/anon5.C on vxworks_kernel targets
On Dec 22, 2020, at 1:40 PM, Alexandre Oliva wrote: > > The vxworks kernel-mode linking is partial linking, so it cannot > detect missing symbols. > > Regstrapped on x86_64-linux-gnu, and tested with -x-arm-wrs-vxworks7r2. > Ok to install? Ok.
Re: Add conditions on VxWorks versions for gcc.dg/vxworks/initpri?.c
On Dec 22, 2020, at 1:37 PM, Alexandre Oliva wrote: > > Adjust vxworks initpri expectations, given that vxworks7 has switched > to .init_array. > > Regstrapped on x86_64-linux-gnu, and tested with -x-arm-wrs-vxworks7r2. > Ok to install? Ok. I suppose I should say that if the port maintainers want to chime in and recommend a different solution or have different idea on how to do things, I'd encourage them to chime in. I'm kicking in only because no one else has yet, and thats roughly what I do.
Re: gcc.dg/intmax_t-1.c compiles without error on VxWorks 7 SR06x0
On Dec 22, 2020, at 1:36 PM, Alexandre Oliva wrote: > > This test currently fails on VxWorks 7 SR06x0 targets when in kernel > mode, because it expects a discrepancy between built-in and system > intmax_t for all VxWorks targets when in kernel mode. Fortunately, > this has now been fixed when targetting VxWorks 7 SR06x0, so this > commit adjusts the "dg-error" condition to exclude newer versions of > VxWorks 7. > > Regstrapped on x86_64-linux-gnu, and tested with -x-arm-wrs-vxworks7r2. > Ok to install? Ok. fix includes or making the builtin agree with the system is a nicer longer term solution.
Re: Fix VxWorks xfail filters on pthread-init-?.c
On Dec 22, 2020, at 1:34 PM, Alexandre Oliva wrote: > Match xfail on kernel instead of rtp mode. > > Regstrapped on x86_64-linux-gnu, and tested with -x-arm-wrs-vxworks7r2. > Ok to install? Ok. Longer term, would be nice to fix includes the relevant file to have the relevant definition.
Re: Add conditional include of vxWorks.h for kernel mode
On Dec 22, 2020, at 1:14 PM, Alexandre Oliva wrote: > > In kernel mode, an application must include vxWorks.h before any other > system header, this patch adds exactly that to the test that were > failing due to a missing declaration that was found in vxWorks.h. I'm inclined to rather have a -include vxWorks.h method where you figure out when this should be done and add it to the command line flags as necessary, that, or have the gcc includes mechanism automatically include the file itself when those conditions are present. Although, yet more possibilities exist, like knowing what from that file is necessary, and builtinizing that content so that the tests pass anyway. Thoughts?
Re: [committed] Fix non-unique testnames
On Nov 30, 2020, at 8:00 AM, Jeff Law via Gcc-patches wrote: > > This patch fixes a handful of tests with non-unique names which confuse > the living hell out of compare_tests, particularly if one of two tests > [x]fail while the other is [x]pass which compare_tests will flag as a > regression each and every run. Thanks. The other way to fix the issue is to fix the tools so that they never fail. :-)
Re: [00/32] C++ 20 Modules
On Nov 3, 2020, at 1:12 PM, Nathan Sidwell wrote: > > Here is the implementation of C++20 modules that I have been developing on > the devel/c++-modules branch over the last few years. I was just recently wondering about this. Congratulations. > It is some 25K new lines of code (plus testsuite). > Definitely the most important event of today :) I agree. > don't forget to vote. I vote yes; although, I didn't know we had switched to voting patches in. :-)
Re: [PATCH][testsuite] Don't overwrite compiler_flags in check_compile
On Oct 14, 2020, at 6:46 AM, Tom de Vries wrote: > > OK for trunk? Ok.
Re: [PATCH][testsuite] Add effective target ident_directive
On Sep 24, 2020, at 2:38 AM, Tom de Vries wrote: > > Fix this by adding an effective target ident_directive, and requiring > it in both test-cases. > OK for trunk? Ok.
Re: [PATCH][testsuite, nvptx] Add effective target sync_int_long_stack
On Aug 12, 2020, at 6:57 AM, Tom de Vries wrote: > > The nvptx target currently doesn't support effective target sync_int_long, > although it has support for 32-bit and 64-bit atomic. > > When enabling sync_int_long for nvptx, we run into a failure in > gcc.dg/pr86314.c: > ... > nvptx-run: error getting kernel result: operation not supported on \ > global/shared address space > ... > due to a ptx restriction: accesses to local memory are illegal, and the > test-case does an atomic operation on a stack address, which is mapped to > local memory. > > Fix this by adding a target sync_int_long_stack, wich returns false for nvptx, > which can be used to mark test-cases that require sync_int_long support for > stack address. > > Build on nvptx and tested with make check-gcc. > > OK for trunk? Ok.
Re: RFC: Monitoring old PRs, new dg directives [v2]
On Aug 10, 2020, at 2:30 PM, Marek Polacek via Gcc-patches wrote: > > Thanks a lot. Here's the latest version of my patch, which only adds dg-ice > at this point. > > So, um, OK? Ok.
Re: RFC: Monitoring old PRs, new dg directives
On Aug 7, 2020, at 6:16 AM, Nathan Sidwell wrote: > > On 8/6/20 8:01 PM, Mike Stump wrote: >> On Aug 6, 2020, at 7:01 AM, Nathan Sidwell wrote: >>> XFAIL: g++.dg/foo.C -std=c++17 (internal compiler error) PASS: g++.dg/foo.C -std=c++17 (test for excess errors) Which one of these would you not like to see? >>> >>> Neither of these is solving the issue. How do I find the ICES that are >>> unexpected, without tripping over the ICEs that are expected? >> Don't you already have this issue for current xfailed ICEs? ^FAIL.*internal >> compiler error I think finds them, doesn't it? > > Are there xfailed ICEs? I've not run into them? I certainly have seen them in various forms and in various places over the years; though, you do raise the interesting point, it may only be theory if things work well on all the platforms of interest. So, yeah, adding new ICEs can make the search regex longer in practice.
Re: RFC: Monitoring old PRs, new dg directives
On Aug 6, 2020, at 7:01 AM, Nathan Sidwell wrote: > >> XFAIL: g++.dg/foo.C -std=c++17 (internal compiler error) >> PASS: g++.dg/foo.C -std=c++17 (test for excess errors) >> Which one of these would you not like to see? > > Neither of these is solving the issue. How do I find the ICES that are > unexpected, without tripping over the ICEs that are expected? Don't you already have this issue for current xfailed ICEs? ^FAIL.*internal compiler error I think finds them, doesn't it?
Re: [PATCH][testsuite] Add gcc.dg/ia64-sync-5.c
On Aug 6, 2020, at 5:23 AM, Tom de Vries wrote: > > There currently is no sync_char_short-enabled run test that tests > __sync_val_compare_and_swap. > > OK for trunk? Ok.
Re: RFC: Monitoring old PRs, new dg directives
On Aug 4, 2020, at 5:54 PM, Marek Polacek wrote:
>> As you find it difficult to express a test using the existing mechanisms,
>> let's talk about those and see if anyone has a good idea on how to express
>> it. I think ICEs are the most annoying to manage, but, I think excess and
>> prune should be able to handle them. I think should get an error or
>> warning, or should not get an error or warning are more trivial to manage.
>
> I experimented with
> // { dg-prune-output ".*internal compiler error.*" }
> // { dg-xfail-if "" { *-*-* } }
> but it's a mouthful and the results were poor (when the ICE is fixed but we
> generate errors instead). dg-ice is convenient, handles even the different
> kind of ICE (when the diagnostic routines were re-entered), and generates
> nice XPASSes when the ICE goes away.
>
> I've also played games with dg-regexp but it was too ugly.
>
> (I honestly don't see why new directives are such a big deal, if they're
> properly documented.)
I don't see a bogus here? I think that can't be skipped.
Re: RFC: Monitoring old PRs, new dg directives
On Aug 5, 2020, at 5:56 AM, Marek Polacek wrote:
>
> Sorry for being unclear. Say you have
>
> // PR c++/55408
>
> struct foo {
>template
>void bar();
> };
>
> template
> void foo::bar() {}
>
> int main()
> {
>extern int i;
>foo {}.bar<&i>();
> }
>
> which we wrongly accept. It might be unclear
Sure, one might think it goes on line 12... could be wrong. But, if one wants
to do better, one can run clang on it, an it says that the error goes on line 7.
> what line to put that dg-error
> on. So you put it at the end of the file. Then when we start issuing an
> error
> for the testcase, you will just get a FAIL, not an XPASS. That might be
> confusing if that file isn't in unfixed/.
The people that fix bugs should be able to sort it out.
Re: RFC: Monitoring old PRs, new dg directives
On Aug 4, 2020, at 3:16 PM, Marek Polacek via Gcc-patches wrote: > > The benefit of dg-accepts-invalid was that you would > get an XPASS even for a test that should not be accepted, but you didn't know > what line to expect an error on, so you put a dg-error at the end of the test. I think for most cases it's easy enough to figure out where the error goes. I do see the subtly of the dg-accepts-invalid directive now in the harder cases. A change of state of them by the new error message I'd like to think is enough to get the people to look at the test case and the corresponding bug report. I'd propose seeing if people don't also push along the bug in that sort of complex case, I think they will.
Re: RFC: Monitoring old PRs, new dg directives
On Aug 4, 2020, at 3:08 PM, Marek Polacek via Gcc-patches
wrote:
>
> That works well if you know where to expect an error. But if you don't, it's
> worse. E.g.,
>
> // { dg-xfail-if "" { *-*-* } }
> int i = nothere; // demonstrates something that errors out
> // { dg-error "" } didn't know where to put this
>
> only prints unexpected failures, but no unexpected successes. I guess that's
> OK though, at least for now, so I'll drop dg-accepts-invalid.
There are two cases, either you get an error message that is wrong, and you can
use:
strncpy (p, s, 60); /* { dg-bogus "-Wstringop-truncation" } */
or, you don't get an error, but you should:
A foo(void i = 0); // { dg-error "incomplete type|invalid use" }
? Do you have an example of a specific case that doesn't work? I'm not sure
I'm following.
Re: RFC: Monitoring old PRs, new dg directives
I think the read of the room is that people think it would be generally useful, so let approve the general plan. So, now we are down to the fine details. Please do see just how far you can stretch the existing mechanisms to cover what you need to do. I think the existing mechanisms should be able to cover it all; but the devil is in the details and those matter. For the suggestion to isolate the tests into their own area easily distinguished by filename, I think it is better to choose an original home for them using the existing naming scheme as much as possible, that way when fixed, they are already in the right spot. We in theory can move them around, but, there is a beauty in having a long term stable name that just doesn't change any. You can look through time to see all state changes. git log file.C, show you all the history nicely, and so on. You can experiment with dg-prms-id and see if that lets you tag in bug report numbers in a more meaningful way. Anyway, would be good to always include the bug report number in the test case, and in the bug report, add the name of the added test case (so others don't add yet another instance of the bug). So with that as a backdrop, I think it's reasonable to self-approve additions of this sort to the test suite. If you have test cases that can go in with existing mechanisms, feel free to start adding them in. As you find it difficult to express a test using the existing mechanisms, let's talk about those and see if anyone has a good idea on how to express it. I think ICEs are the most annoying to manage, but, I think excess and prune should be able to handle them. I think should get an error or warning, or should not get an error or warning are more trivial to manage. A word of caution, if we produce core files, before you add tons of core file producing test cases, you'll want to submit a, ulimit -c 0 patch that can avoid the issue. corefile writing is slow and consumes disk. I can't recall at the moment if the current infrastructure will reliably avoid core files. If test cases infinitely loop, timeout, consume all available ram, fill the disk, crash the host machine, or do other really nasty stuff, please, let's avoid those for now. It is mazing host fast testing goes on a 200 thread count box, and how slow it can go if a single test case needs to time out. If you start with the idea that any individual test case should only take 2-10 seconds, you won't go wrong.
Re: RFC: Monitoring old PRs, new dg directives
I'll punt to the the C++ front-end folks to chime in. Usually we only check in
bugs that are fixed, as they are fixed, this is what makes it a regression
suite. Doing this does have advantages, like, the testsuite is small and
doesn't have duplicates and doesn't test anything that is known to fail that
isn't an actual regression.
Ideally, it would be nice to have a way to test bugs out of bugzilla, and
report on those fixed bugs as they are fixed. If people want to keep the test
suite a regression suite, then my counter proposal would be to have a branch
with the non-regression bugs on it and then people can checkout and test that
branch. Most of the people don't (saving the testing time, which is handy),
and then more sporadically, the old bugs branch can be test and BZ state can be
moved along as bugs as fixed. A run once a week or even once a month would
seem to be plenty often.
You in general don't need to check in fixes from bug reports that have been
fixed in the past, as those fixes generally already have a test case for the
fix that went in with the fix.
As for how old is old, we'd leave that to the contributor of work to decide.
In theory, bugs can be added as soon as they come in, no need to wait. To the
extent that waiting saves work, well, that's a personal choice, for the person
doing the work to choose.
Why not just use xfail and xpass? Seems less work than doing a setup_xfail.
Also, why not just use the existing directives instead of adding new
directives? I'm suspicious of expect_ice and accepts_invalid. You set them to
1 all the time, but almost never set them to 0? I'm wondering if it should be
more like shouldfail?
On Jul 28, 2020, at 2:44 PM, Marek Polacek via Gcc-patches
wrote:
>
> In Bugzilla, for the c++ component, we currently have over 3200 open bugs. In
> my experience, a good amount of them have already been fixed; my periodical
> sweeps always turn up a bunch of PRs that had already been fixed previously.
> Sometimes my sweeps are more or less random, but more often than not I'm just
> looking for duplicates of an existing PR. Sometimes the reason the already
> fixed PRs are still open is because a PR that was fixed had duplicates that we
> didn't catch earlier when confirming the PR. Sometimes a PR gets fixed as a
> side-effect of fixing another PR. Manual sweeps are tedious and
> time-consuming
> because often you need to grab the test from the Bugzilla yet again (and
> sometimes there are multiple tests). Even if you find a PR that was fixed,
> you
> still need to bisect the fix and perhaps add the test to our testsuite.
> That's
> draining and since the number of bugs only increases, never decreases, it is
> not
> sustainable.
>
> So I've started a personal repo where I've gathered dozens of tests and wrote
> a
> script that just compiles every test in the repo and reports if anything
> changed. One line from it:
>
> pr=59798; $cxx $o -c $pr.C 2>&1 | grep -qE 'internal compiler error' || echo
> -e "$pr: ${msg_ice}"
>
> This has major drawbacks: you have to remember to run this manually, keep
> updating it, and it's yet another repo that people interested in this would
> have to clone, but the worst thing is that typically you would only discover
> that a patch fixed a different PR long after the patch was committed. And
> quite likely it wasn't even your patch. We know that finding problems earlier
> in the developer workflow reduces costs; if we can catch this before the
> original developer commits & pushes the changes, it's cheaper, because the
> developer already understands what the patch does.
>
> A case in point: https://gcc.gnu.org/PR58156 which has been fixed recently
> by an unrelated (?) patch. Knowing that the tsubst_pack_expansion hunk in
> the patch had this effect would probably have been very useful. More testing
> will lead to a better compiler.
>
> Another case: https://gcc.gnu.org/35098 which was fixed 12 years (!) after
> it was reported by a different change.
>
> Or another: https://gcc.gnu.org/91525 where the patch contained a test, but
> that was ice-on-invalid, whereas the test in PR91525 was ice-on-valid.
>
> To alleviate some of these problems, I propose that we introduce a means to
> our
> DejaGNU infrastructure that allows adding tests for old bugs that have not
> been
> fixed yet, and re-introduce the keyword monitored (no longer used for anything
> -- I think Volker stepped away) to the GCC Bugzilla to signal that a PR is
> tracked in the testsuite. I don't want any unnecessary moving tests around,
> so
> the tests would go where they would normally go; they have to be reduced and
> have proper targets, etc. Having such tests in the testsuite means that when
> something changes, you will know immediately, before you push any changes.
>
> My thinking is that for:
>
> * rejects-valid: use the existing dg-xfail-if
> * accepts-valid: use the new dg-accepts-invalid
> * ICEs: use
Re: gcc.dg/Wno-frame-address.c: Skip for cris and mmix.
On Jul 18, 2020, at 8:19 PM, Hans-Peter Nilsson wrote:
>
> Long-standing FAIL remedied; committed. Maybe better to list
> the targets that *do* support arbitrary frame access?
Yes, it would be better if test cases that fall way to low in portability are
listed instead against what platforms the test is expected to work on, instead
of having everyone else join a long list in the exceptions clause.
Another way to handle this is to expose the ability to do such a thing in the
first place and expose that via a .h or a preprocessing condition, then the
test itself will only test on machines that claim it should work in the first
place.
In this case, and with this feature specifically, it isn't portable and
reliable enough.
> gcc/testsuite:
> * gcc.dg/Wno-frame-address.c: Skip for cris and mmix.
>
> --- gcc/gcc/testsuite/gcc.dg/Wno-frame-address.c.orig Mon Jan 13 22:30:47 2020
> +++ gcc/gcc/testsuite/gcc.dg/Wno-frame-address.c Sun Jul 19 05:05:49 2020
> @@ -1,5 +1,5 @@
> /* { dg-do compile } */
> -/* { dg-skip-if "Cannot access arbitrary stack frames" { arm*-*-* amdgpu-*-*
> avr-*-* hppa*-*-* ia64-*-* visium-*-* csky-*-* msp430-*-* } } */
> +/* { dg-skip-if "Cannot access arbitrary stack frames" { arm*-*-* amdgpu-*-*
> avr-*-* hppa*-*-* ia64-*-* visium-*-* csky-*-* msp430-*-* cris-*-* mmix-*-* }
> } */
> /* { dg-options "-Werror" } */
> /* { dg-additional-options "-mbackchain" { target { s390*-*-* } } } */
Re: [PATCH 4/6] Testsuite: Make it easier to debug environment setting functions
On Jul 9, 2020, at 2:56 AM, Tamar Christina wrote: > This adds verbose output to dg-set-compiler-env-var and dg-set-target-env-var > so you can actually see what they're setting when you add -v -v. > > Bootstrapped Regtested on aarch64-none-linux-gnu and no issues. > > Ok for master? Ok.
Re: PING Re: testsuite: clarify scan-dump file globbing behavior
On Jun 2, 2020, at 10:37 PM, Frederik Harwath wrote: > > Frederik Harwath writes: > > ping :-) Ok. >> Frederik Harwath writes: >> >> Hi Rainer, hi Mike, >> ping: https://gcc.gnu.org/pipermail/gcc-patches/2020-May/545803.html >> >> Best regards, >> Frederik >> >>> Hi Thomas, >>> >>> Thomas Schwinge writes: >>> I can't formally approve testsuite patches, but did a review anyway: >>> >>> Thanks for the review! >>> On 2020-05-15T12:31:54+0200, Frederik Harwath wrote: >>> > The dump > scanning procedures are changed to make the test unresolved > if globbing matches more than one file. (The code changes look good, but I have not tested that specific aspect.) >>> >>> We do not have automated tests for the testsuite commands :-), but I >>> have of course tested this manually. >>> As I said, not an approval, and minor comments (see below), but still: Reviewed-by: Thomas Schwinge Do we have to similarly also audit/alter other testsuite infrastructure files, anything that uses '[glob [...]]'? (..., and then generalize 'glob-dump-file' into 'glob-one-file', or similar.) That can be done incrementally, as far as I'm concerned. >>> >>> I also think it would make sense to adapt similar test commands as well. >>> May also make this more useful/explicit: This is useful if, for example, if a pass has several static instances [correct terminology?], and depending on torture testing command-line flags, a different instance executes and produces a dump file, and so in the test case you can use a generic [put example here] to scan the varying dump files names. (Or similar.) >>> >>> I have moved the explanation below the description of the individual >>> commands and added an example. See the attached revised patch. >>> >>> Best regards, >>> Frederik >>> >>> From 2a17749d6dbcac690d698323240438722d6119ef Mon Sep 17 00:00:00 2001 >>> From: Frederik Harwath >>> Date: Fri, 15 May 2020 10:35:48 +0200 >>> Subject: [PATCH] testsuite: clarify scan-dump file globbing behavior >>> >>> The test commands for scanning optimization dump files >>> perform globbing on the argument that specifies the suffix >>> of the dump files to be scanned. This behavior is currently >>> undocumented. Furthermore, the current implementation of >>> "scan-dump" and similar procedures yields an error whenever >>> the file name globbing matches more than one file (due to an >>> attempt to call "open" on multiple files) while a failure to >>> match any file results in an unresolved test. >>> >>> This commit documents the globbing behavior. The dump >>> scanning procedures are changed to make the test unresolved >>> if globbing matches more than one file. >>> >>> gcc/ChangeLog: >>> >>> 2020-05-19 Frederik Harwath >>> >>> * doc/sourcebuild.texi: Describe globbing of the >>> dump file scanning commands "suffix" argument. >>> >>> gcc/testsuite/ChangeLog: >>> >>> 2020-05-19 Frederik Harwath >>> >>> * lib/scandump.exp (glob-dump-file): New proc. >>> (scan-dump): Use glob-dump-file for file name expansion. >>> (scan-dump-times): Likewise. >>> (scan-dump-dem): Likewise. >>> (scan-dump-dem-not): Likewise.
Re: BRIG FE testsuite: Fix all dump-scans (Was: Re: drop -aux{dir,base}, revamp -dump{dir,base})
On Jun 11, 2020, at 7:28 AM, Martin Jambor wrote: > > On Tue, Jun 09 2020, Mike Stump wrote: >> I think I'd prefer the fix on the other side, if reasonable. I'd give >> them some time to see about a fix there before selecting this patch. > > given Alexandre's email, are you OK with the patch? Yeah, if that's the change dumpbase is going, then we can follow along with it. Ok.
Re: BRIG FE testsuite: Fix all dump-scans (Was: Re: drop -aux{dir,base}, revamp -dump{dir,base})
I think I'd prefer the fix on the other side, if reasonable. I'd give them
some time to see about a fix there before selecting this patch.
On Jun 9, 2020, at 5:42 AM, Martin Jambor wrote:
> On Tue, Jun 09 2020, Thomas Schwinge wrote:
>> On 2020-05-26T04:08:44-0300, Alexandre Oliva wrote:
>>> Thanks, here's the combined patch I'm checking in.
>>>
>>> revamp dump and aux output names
>>
>> For BRIG (HSAIL) front end testing, I'm see a lot of failures like:
>>
>>Running [...]/source-gcc/gcc/testsuite/brig.dg/dg.exp ...
>>PASS: brig.dg/test/gimple/variables.hsail (test for excess errors)
>>[-PASS:-]{+UNRESOLVED:+} variables.hsail.brig scan-tree-dump original
>> "__group_base_addr \\+ \\(0 \\+"
>>[-PASS:-]{+UNRESOLVED:+} variables.hsail.brig scan-tree-dump original
>> "__group_base_addr \\+ 0"
>>[-PASS:-]{+UNRESOLVED:+} variables.hsail.brig scan-tree-dump gimple "[
>> ]*prog_global = s204;"
>>[-PASS:-]{+UNRESOLVED:+} variables.hsail.brig scan-tree-dump gimple
>> ".module.mod_global;"
>>[...]
>>
>> That's:
>>
>>spawn -ignore SIGHUP [...]/build-gcc/gcc/xgcc -B[...]/build-gcc/gcc/
>> [...]/build-gcc/gcc/testsuite/brig/variables.hsail.brig -fdump-tree-gimple
>> -fdump-tree-original -S -o variables.s
>>PASS: brig.dg/test/gimple/variables.hsail (test for excess errors)
>>variables.hsail.brig: dump file does not exist
>>dump file: variables.hsail.brig.original
>>UNRESOLVED: variables.hsail.brig scan-tree-dump original
>> "__group_base_addr \\+ \\(0 \\+"
>>
>> We're trying to scan 'variables.hsail.brig.*', but for input file name
>> 'variables.hsail.brig', we're now creating:
>>
>>$ ls -1 build-gcc/gcc/testsuite/brig/variables.*???t.*
>>build-gcc/gcc/testsuite/brig/variables.brig.004t.original
>>build-gcc/gcc/testsuite/brig/variables.brig.005t.gimple
>>
>> Before your changes, GCC produced the expected:
>>
>>$ ls -1 build-gcc/gcc/testsuite/brig/variables.*???t.*
>>build-gcc/gcc/testsuite/brig/variables.hsail.brig.004t.original
>>build-gcc/gcc/testsuite/brig/variables.hsail.brig.005t.gimple
>>
>> Are you able to easily create a patch for that? How/where to adjust:
>> producer-side (GCC driver, or BRIG (HSAIL) front end?), or consumer-side
>> (testsuite: tree scanning machinery, or have to put some '-dumpbase' into
>> all test case files?)?
>
>
> I looked into the issue yesterday and decided the simplest fix is
> probably the following. I am going to use my BRIG maintainer hat to
> commit the patch in a day or two unless someone thinks it is a bad idea.
> Tested by running make check-brig on an x86_64-linux.
>
> Martin
>
>
>
> Since Alexandre's revamp of dump files handling in
> r11-627-g1dedc12d186, BRIG FE has been receiving slightly different
> -dumpbase (e.g. smoke_test.brig instead of smoke_test.hsail.brig when
> compiling file smoke_test.hsail.brig) and the testsuite then could not
> find the generated dump files it wanted to scan. I have not really
> looked into why that changed, the easiest fix seems to me to remove
> the hsail part already when generating the binary brig file from the
> textual HSAIL representation.
>
> gcc/testsuite/ChangeLog:
>
> 2020-06-09 Martin Jambor
>
> * lib/brig.exp (brig_target_compile): Strip hsail extension when
> gnerating the name of the binary brig file.
> ---
> gcc/testsuite/lib/brig.exp | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/gcc/testsuite/lib/brig.exp b/gcc/testsuite/lib/brig.exp
> index fbfb1da947a..de47f13e42c 100644
> --- a/gcc/testsuite/lib/brig.exp
> +++ b/gcc/testsuite/lib/brig.exp
> @@ -29,7 +29,7 @@ proc brig_target_compile { source dest type options } {
> # We cannot assume all inputs are .hsail as the dg machinery
> # calls this for a some c files to check linker plugin support or
> # similar.
> - set brig_source ${tmpdir}/[file tail ${source}].brig
> + set brig_source ${tmpdir}/[file rootname [file tail ${source}]].brig
> exec HSAILasm $source -o ${brig_source}
> set source ${brig_source}
> # Change the testname the .brig.
> --
> 2.26.2
>
Re: [PATCH 1/8] testsuite: Fix -mfloat-abi order in arm_v8_2a_bf16_neon_ok and arm_v8_2a_i8mm_ok_nocache
On Apr 27, 2020, at 12:43 PM, Christophe Lyon via Gcc-patches wrote: > It seems it's not possible to write these tests so that they works in > all combinations of toolchain configuration and options used for testing :-( So, generally, you can have each change in configuration reflected in a preprocessor symbol and each command line change also reflected. Then, in the test case you merely interrogate all the state as necessary to decide. If that weren't enough, then, we'd have some other mechanism that we could interrogate with if, and then you'd be off and running. [ ducks ] Think if (__builtin_arm_have_featurea()) // test case for featurea. else ... I can appreciate if the support necessary for the if or the #ifdef is missing, but, it could be added.
Re: [PATCH v3 2/4] libffi/test: Fix compilation for build sysroot
On Mar 26, 2020, at 3:00 PM, Maciej W. Rozycki wrote: > > I have actually considered extracting the bits already, but I hesitated > putting that forward that as having looked at the part that we require I > have thought it to be very messy: Yeah, sometimes it's like that. I glanced at the work, if you think it's a step forward, I'd support importing it, my take, import from upstream isn't a bad way to go. > So I am in favour of retaining the mechanism rather than using my earlier > proposal, however I'm in two minds as to how to proceed. Integrating the > change as it is will make us having clutter left in the tree after `make > distclean', but we can do it right away. I'd support this. distclean is one rm -rf away from being clean enough. I'd not let that gate or hold up the import. If there is work that we want that's more to do with in tree building and testing (sys root fun, multilibs), while not ideal, we can deviate from upstream to support that. Though, if there is a way to naturally support that, that upstream can accept, that'd be better.
Re: [PATCH v3 2/4] libffi/test: Fix compilation for build sysroot
On Mar 17, 2020, at 2:52 PM, Maciej W. Rozycki wrote: > > On Fri, 28 Feb 2020, H.J. Lu wrote: >> >> Libffi 3.4 ABI was changed to support CET. But it isn't the first >> time ABI change for libffi, > > Have we made any conclusions WRT the way to move forward with this stuff? > Things remain broken and I'd prefer to get the issues off the plate while > the stuff is hot, or at least mildly warm. I'm about to get distracted > with other work. It's unfortunate that upstream has anything that prevents it from us just importing it all and calling it done. Anyway, if you see a path forward for grabbing all the Makefile/config stuff and leaving the abi changing stuff out, and just important that, we can do a partial import. I say this without reviewing the diffs from upstream and how many there are and what's in them. I'm hoping things are nicely segregated and reasonably small otherwise. That could unblock your concerns and you can leave the rest for some else that can play with the abi.
