Re: scan-*-dump-times across multiple functions considered harmful

On 02/07/2025 18:59, David Malcolm wrote: ... Brainstorming some ideas on other possible approaches on making our tests less brittle; for context I did some investigation back in 2018 about implementing "optimizations remarks" like clang does: diagnostics about optimization decisions, so you

P.S. to: scan-*-dump-times across multiple functions considered harmful

P.S.: to get get the specifity of linenumbers without the brittleness, we could have a pragma for the extra dump line tag instead. Either till the next such pragme / EOF, or (if before next such pragma), till the end of function. Disadvantages: Not actually more specific when the source describ

scan-*-dump-times across multiple functions considered harmful

Quite often I see a test quickly written to test some new feature (bug fix, extension or optimization) that has a couple of functions to cover various aspects of the feature, checked all together with a single scan-tree-dump-times, scan-rtl-dump-times etc. check, using the expected value for th

Re: RFD: switch/case statement dispatch using hash

On 23/06/2025 12:31, Florian Weimer wrote: Also carry-less multiply persumably. It's challenging to use those instructions for compiling switch statements because they would then be used all over the place. Not necessarily; you can hide them in an UNSPEC if you are worried that exposing the

RFD: switch/case statement dispatch using hash

This has come up several time over the years: https://gcc.gnu.org/legacy-ml/gcc/2006-07/msg00158.html https://gcc.gnu.org/legacy-ml/gcc/2006-07/msg00155.html https://gcc.gnu.org/pipermail/gcc/2010-March/190234.html , but maybe now (or maybe a while ago) is the right time to do this, considering

Re: c-c++-common/analyzer/out-of-bounds-diagram-11.c written type vs toolchain

On 22/07/2024 17:13, Joern Wolfgang Rennecke wrote: > I guess you could reduce the differences between platforms if you didn't use types as defined by headerfiles directly, as they might be #defines or typedefs or whatever, and instead used your own typedef or struct types. It

Re: c-c++-common/analyzer/out-of-bounds-diagram-11.c written type vs toolchain

On 22/07/2024 16:44, David Malcolm wrote: Does it help to hack this change into prune.exp: diff --git a/gcc/testsuite/lib/prune.exp b/gcc/testsuite/lib/prune.exp index d00d37f015f7..f467d1a97bc6 100644 --- a/gcc/testsuite/lib/prune.exp +++ b/gcc/testsuite/lib/prune.exp @@ -109,7 +109,7 @@ proc

c-c++-common/analyzer/out-of-bounds-diagram-11.c written type vs toolchain

While on x86_64-pc-linux-gnu, the second diagram shows the type written as 'int', as expected, on a 16 and 32 bit newlib based toolchain, it is being output as int32_t . And all the formatting is also a bit different, probably due to the change in how the int32_t is displayed. What do other p

tsvc test iteration count during check-gcc

The tsvc tests take just too long on simulators, particularly if there is little or no vectorization of the test because of compiler limitations, target limitations, or the chosen options. Having 151 tests time out at a quarter of an hour is not fun, and making the time out go away by upping th

gcc bootstrap failure with libcody

I'm seeing a boostrap failure when I try to build the latest gcc version ( 8833eab4461b4b7050f06a231c3311cc1fa87523 ) : checking whether time.h and sys/time.h may both be included... checking whether gcc supports -Wmissing-prototypes... i686-pc-linux-gnu checking host system type... make[3]: *** [

Garbage collection bugs

We've been running builds/regression tests for GCC 8.2 configured with --enable-checking=all, and have observed some failures related to garbage collection. First problem: The g++.dg/pr85039-2.C tests (I've looked in detail at -std=c++98, but -std=c++11 and -std=c++14 appear to follow the sam

Re: Suitable regression test for vectorizer patches? - (need {u,}madd* pattern)

On 30/10/18 08:36, Richard Biener wrote: On Mon, Oct 29, 2018 at 7:03 PM Joern Wolfgang Rennecke wrote: I want to submit some vectorizer patches, what would be a suitable regression test? I am sure you have testcases, no? For new features please make them dg-do run ones by checking

Suitable regression test for vectorizer patches?

I want to submit some vectorizer patches, what would be a suitable regression test? Preferably some native or cross test that can run on an i7 x86_64 GNU/Linux machine. To give an idea what code I'm patching, here are the patches I got so far: * tree-vect-patterns.c (vect_recog_dot_pro

Re: ARC length attribute patch

On 20/03/15 16:02, Claudiu Zissulescu wrote: Hi Joern, I have a small patch for ARC backend that fixes the value of instruction length attribute when the instruction is predicated. Ok to apply? Assuming you tested it, this patch is OK.

Re: ARC length attribute patch

On 20/03/15 16:02, Claudiu Zissulescu wrote: Hi Joern, I have a small patch for ARC backend that fixes the value of instruction length attribute when the instruction is predicated. Ok to apply? Why would the arc_bdr_iscond test have any effect? arc_predicate_delay_insns should render the iss