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