> No, that's "dg-do compile" (as in "compile but don't assemble").
I can confirm that this patch:
diff --git a/gcc/testsuite/gcc.dg/analyzer/asm-x86-lp64-1.c
b/gcc/testsuite/gcc.dg/analyzer/asm-x86-lp64-1.c
index c235e22fd01..4730255bb3c 100644
---
Not seeing anyone doing the obvious one-up, so JFTR:
On Mon, 10 Jan 2022, David Malcolm via Gcc wrote:
> On Mon, 2022-01-10 at 17:13 +0100, FX wrote:
> > > FAIL: gcc.dg/analyzer/asm-x86-lp64-1.c
>
> The purpose of these asm tests is to verify that the analyzer doesn't
> get confused by various
Hi FX,
> On 15 Jan 2022, at 14:19, FX via Gcc wrote:
>
>> The purpose of these asm tests is to verify that the analyzer doesn't
>> get confused by various inline assembler directives used in the source
>> of the Linux kernel. So in theory they ought to work on any host, with
>> a gcc
Hi David,
> The purpose of these asm tests is to verify that the analyzer doesn't
> get confused by various inline assembler directives used in the source
> of the Linux kernel. So in theory they ought to work on any host, with
> a gcc configured for a suitable target.
>
> These tests are
On Mon, 2022-01-10 at 17:13 +0100, FX wrote:
> Hi David,
>
> May I kindly ping you on that? Or anyone with knowledge of the static
> analyzer?
Sorry about the delay in responding; I was on vacation and am still
getting caught up.
Various answers inline below...
>
> Thanks,
> FX
>
>
> > Le
Hi David,
May I kindly ping you on that? Or anyone with knowledge of the static analyzer?
Thanks,
FX
> Le 23 déc. 2021 à 22:49, FX a écrit :
>
> Hi David, hi everone,
>
> I’m trying to understand how best to fix or silence the several failures in
> gcc.dg/analyzer that occur on
Hi David, hi everone,
I’m trying to understand how best to fix or silence the several failures in
gcc.dg/analyzer that occur on x86_64-apple-darwin. Some of them, according to
gcc-testresults, also occur on other non-Linux targets. See for example, the
test results at
