* Many analyzer failures on non-Linux system (x86_64-apple-darwin) @ 2021-12-23 21:49 FX 2022-01-10 16:13 ` FX 0 siblings, 1 reply; 10+ messages in thread From: FX @ 2021-12-23 21:49 UTC (permalink / raw) To: gcc; +Cc: dmalcolm, Iain Sandoe 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 https://gcc.gnu.org/pipermail/gcc-testresults/2021-December/743901.html ## gcc.dg/analyzer/torture/asm-x86-linux-*.c Are these supposed to be run only on Linux (as the name implies)? Four of them fail on x86_64-apple-darwin, because they use assembly that is not supported: FAIL: gcc.dg/analyzer/torture/asm-x86-linux-cpuid-paravirt-1.c FAIL: gcc.dg/analyzer/torture/asm-x86-linux-cpuid-paravirt-2.c FAIL: gcc.dg/analyzer/torture/asm-x86-linux-rdmsr-paravirt.c FAIL: gcc.dg/analyzer/torture/asm-x86-linux-wfx_get_ps_timeout-full.c Should they be restricted to Linux targets? There is another one that has the same error, as well, although it doesn’t have linux in the name: FAIL: gcc.dg/analyzer/asm-x86-lp64-1.c ## Builtin-related failures Those four cases fail: gcc.dg/analyzer/data-model-1.c gcc.dg/analyzer/pr103526.c gcc.dg/analyzer/taint-size-1.c gcc.dg/analyzer/write-to-string-literal-1.c but pass if the function calls (memset and memcpy) are replaced by the built-in variant (__builtin_memset and __builtin_memcpy). The reason for that is the darwin headers, in <secure/_string.h> (included from <string.h>) does this: #if __has_builtin(__builtin___memcpy_chk) || defined(__GNUC__) #undef memcpy /* void *memcpy(void *dst, const void *src, size_t n) */ #define memcpy(dest, ...) \ __builtin___memcpy_chk (dest, __VA_ARGS__, __darwin_obsz0 (dest)) #endif where __darwin_obsz0 is defined thusly: #define __darwin_obsz0(object) __builtin_object_size (object, 0) Does the analyzer not handle the _chk builtin variants? Should it? I’m happy to investigate more, but I’m not sure what to do. Best, FX ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Many analyzer failures on non-Linux system (x86_64-apple-darwin) 2021-12-23 21:49 Many analyzer failures on non-Linux system (x86_64-apple-darwin) FX @ 2022-01-10 16:13 ` FX 2022-01-10 20:58 ` David Malcolm 0 siblings, 1 reply; 10+ messages in thread From: FX @ 2022-01-10 16:13 UTC (permalink / raw) To: GCC Mailing List; +Cc: dmalcolm, Iain Sandoe 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 <fxcoudert@gmail.com> 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 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 https://gcc.gnu.org/pipermail/gcc-testresults/2021-December/743901.html > > ## gcc.dg/analyzer/torture/asm-x86-linux-*.c > > Are these supposed to be run only on Linux (as the name implies)? Four of them fail on x86_64-apple-darwin, because they use assembly that is not supported: > > FAIL: gcc.dg/analyzer/torture/asm-x86-linux-cpuid-paravirt-1.c > FAIL: gcc.dg/analyzer/torture/asm-x86-linux-cpuid-paravirt-2.c > FAIL: gcc.dg/analyzer/torture/asm-x86-linux-rdmsr-paravirt.c > FAIL: gcc.dg/analyzer/torture/asm-x86-linux-wfx_get_ps_timeout-full.c > > Should they be restricted to Linux targets? There is another one that has the same error, as well, although it doesn’t have linux in the name: > > FAIL: gcc.dg/analyzer/asm-x86-lp64-1.c > > > ## Builtin-related failures > > Those four cases fail: > > gcc.dg/analyzer/data-model-1.c > > gcc.dg/analyzer/pr103526.c > gcc.dg/analyzer/taint-size-1.c > gcc.dg/analyzer/write-to-string-literal-1.c > > but pass if the function calls (memset and memcpy) are replaced by the built-in variant (__builtin_memset and __builtin_memcpy). The reason for that is the darwin headers, in <secure/_string.h> (included from <string.h>) does this: > > #if __has_builtin(__builtin___memcpy_chk) || defined(__GNUC__) > #undef memcpy > /* void *memcpy(void *dst, const void *src, size_t n) */ > #define memcpy(dest, ...) \ > __builtin___memcpy_chk (dest, __VA_ARGS__, __darwin_obsz0 (dest)) > #endif > > where __darwin_obsz0 is defined thusly: > > #define __darwin_obsz0(object) __builtin_object_size (object, 0) > > > Does the analyzer not handle the _chk builtin variants? Should it? > I’m happy to investigate more, but I’m not sure what to do. > > > Best, > FX ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Many analyzer failures on non-Linux system (x86_64-apple-darwin) 2022-01-10 16:13 ` FX @ 2022-01-10 20:58 ` David Malcolm 2022-01-15 14:19 ` FX 2022-01-16 1:35 ` Hans-Peter Nilsson 0 siblings, 2 replies; 10+ messages in thread From: David Malcolm @ 2022-01-10 20:58 UTC (permalink / raw) To: FX, GCC Mailing List; +Cc: Iain Sandoe 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 23 déc. 2021 à 22:49, FX <fxcoudert@gmail.com> 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 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 > > https://gcc.gnu.org/pipermail/gcc-testresults/2021-December/743901.html > > > > ## gcc.dg/analyzer/torture/asm-x86-linux-*.c > > > > Are these supposed to be run only on Linux (as the name implies)? > > Four of them fail on x86_64-apple-darwin, because they use assembly > > that is not supported: > > > > FAIL: gcc.dg/analyzer/torture/asm-x86-linux-cpuid-paravirt-1.c > > FAIL: gcc.dg/analyzer/torture/asm-x86-linux-cpuid-paravirt-2.c > > FAIL: gcc.dg/analyzer/torture/asm-x86-linux-rdmsr-paravirt.c > > FAIL: gcc.dg/analyzer/torture/asm-x86-linux-wfx_get_ps_timeout- > > full.c > > > > Should they be restricted to Linux targets? There is another one > > that has the same error, as well, although it doesn’t have linux in > > the name: > > > > 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 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 marked with "dg-do assemble" directives, which I'd hoped would mean it uses -S for the tests (to make a .s file), but looking at a log locally, it appears to be using -c (to make a .o file), so maybe that's what's going wrong for you as well? > > > > > > ## Builtin-related failures > > > > Those four cases fail: > > > > gcc.dg/analyzer/data-model-1.c > > > > gcc.dg/analyzer/pr103526.c > > gcc.dg/analyzer/taint-size-1.c > > gcc.dg/analyzer/write-to-string-literal-1.c > > > > but pass if the function calls (memset and memcpy) are replaced by > > the built-in variant (__builtin_memset and __builtin_memcpy). The > > reason for that is the darwin headers, in <secure/_string.h> > > (included from <string.h>) does this: > > > > #if __has_builtin(__builtin___memcpy_chk) || defined(__GNUC__) > > #undef memcpy > > /* void *memcpy(void *dst, const void *src, size_t n) */ > > #define memcpy(dest, ...) \ > > __builtin___memcpy_chk (dest, __VA_ARGS__, > > __darwin_obsz0 (dest)) > > #endif > > > > where __darwin_obsz0 is defined thusly: > > > > #define __darwin_obsz0(object) __builtin_object_size (object, 0) > > > > > > Does the analyzer not handle the _chk builtin variants? Should it? > > I’m happy to investigate more, but I’m not sure what to do. Can you file a bug about this and attach the preprocessed source from the test (using -E). Thanks Dave ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Many analyzer failures on non-Linux system (x86_64-apple-darwin) 2022-01-10 20:58 ` David Malcolm @ 2022-01-15 14:19 ` FX 2022-01-15 14:31 ` Iain Sandoe 2022-01-16 1:35 ` Hans-Peter Nilsson 1 sibling, 1 reply; 10+ messages in thread From: FX @ 2022-01-15 14:19 UTC (permalink / raw) To: David Malcolm; +Cc: GCC Mailing List, Iain Sandoe 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 marked with "dg-do assemble" directives, which I'd > hoped would mean it uses -S for the tests (to make a .s file), but > looking at a log locally, it appears to be using -c (to make a .o > file), so maybe that's what's going wrong for you as well? The tests even compiled with -S still fail: spawn -ignore SIGHUP /Users/fx/ibin/gcc/xgcc -B/Users/fx/ibin/gcc/ exceptions_enabled42475.cc -fdiagnostics-plain-output -S -o excep tions_enabled42475.s FAIL: gcc.dg/analyzer/torture/asm-x86-linux-cpuid-paravirt-1.c -O1 (test for excess errors) Excess errors: /Users/fx/gcc/gcc/testsuite/gcc.dg/analyzer/torture/asm-x86-linux-cpuid-paravirt-1.c:27:3: warning: 'asm' operand 6 probably does not match constraints /Users/fx/gcc/gcc/testsuite/gcc.dg/analyzer/torture/asm-x86-linux-cpuid-paravirt-1.c:27:3: error: impossible constraint in 'asm' It’s the same for the other four. gcc.dg/analyzer/asm-x86-lp64-1.c is slightly different, there it’s an assembler error: /var/folders/_8/7ft0tbns6_l87s21n4s_1sc80000gn/T//cc4b3ybm.s:160:20: error:unexpected token in '.section' directive .pushsection .text ^ /var/folders/_8/7ft0tbns6_l87s21n4s_1sc80000gn/T//cc4b3ybm.s:162:2: error: unknown directive .type add_asm, @function ^ /var/folders/_8/7ft0tbns6_l87s21n4s_1sc80000gn/T//cc4b3ybm.s:167:13: error: .popsection without corresponding .pushsection .popsection ^ >>> ## Builtin-related failures >>> >>> Those four cases fail: >>> >>> gcc.dg/analyzer/data-model-1.c >>> gcc.dg/analyzer/pr103526.c >>> gcc.dg/analyzer/taint-size-1.c >>> gcc.dg/analyzer/write-to-string-literal-1.c > > Can you file a bug about this and attach the preprocessed source from > the test (using -E). Done, it is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104042 FX ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Many analyzer failures on non-Linux system (x86_64-apple-darwin) 2022-01-15 14:19 ` FX @ 2022-01-15 14:31 ` Iain Sandoe 0 siblings, 0 replies; 10+ messages in thread From: Iain Sandoe @ 2022-01-15 14:31 UTC (permalink / raw) To: FX; +Cc: David Malcolm, GCC Mailing List Hi FX, > On 15 Jan 2022, at 14:19, FX via Gcc <gcc@gcc.gnu.org> 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 configured for a suitable target. >> >> These tests are marked with "dg-do assemble" directives, which I'd >> hoped would mean it uses -S for the tests (to make a .s file), but >> looking at a log locally, it appears to be using -c (to make a .o >> file), so maybe that's what's going wrong for you as well? > > The tests even compiled with -S still fail: I think the test should be “dg-do compile” to stop at assembler output … .. the stuff below indicates it is still trying to assemble the .s file. > > spawn -ignore SIGHUP /Users/fx/ibin/gcc/xgcc -B/Users/fx/ibin/gcc/ exceptions_enabled42475.cc -fdiagnostics-plain-output -S -o excep > tions_enabled42475.s > FAIL: gcc.dg/analyzer/torture/asm-x86-linux-cpuid-paravirt-1.c -O1 (test for excess errors) > Excess errors: > /Users/fx/gcc/gcc/testsuite/gcc.dg/analyzer/torture/asm-x86-linux-cpuid-paravirt-1.c:27:3: warning: 'asm' operand 6 probably does not match constraints > /Users/fx/gcc/gcc/testsuite/gcc.dg/analyzer/torture/asm-x86-linux-cpuid-paravirt-1.c:27:3: error: impossible constraint in 'asm' > > It’s the same for the other four. > > > gcc.dg/analyzer/asm-x86-lp64-1.c is slightly different, there it’s an assembler error: > > > /var/folders/_8/7ft0tbns6_l87s21n4s_1sc80000gn/T//cc4b3ybm.s:160:20: error:unexpected token in '.section' directive > .pushsection .text > ^ > /var/folders/_8/7ft0tbns6_l87s21n4s_1sc80000gn/T//cc4b3ybm.s:162:2: error: unknown directive > .type add_asm, @function > ^ > /var/folders/_8/7ft0tbns6_l87s21n4s_1sc80000gn/T//cc4b3ybm.s:167:13: error: .popsection without corresponding .pushsection > .popsection These ^^ are ELF-isms***, so will not work on Darwin (but if the test does not need to assemble, then that is academic). >>>> ## Builtin-related failures >>>> >>>> Those four cases fail: >>>> >>>> gcc.dg/analyzer/data-model-1.c >>>> gcc.dg/analyzer/pr103526.c >>>> gcc.dg/analyzer/taint-size-1.c >>>> gcc.dg/analyzer/write-to-string-literal-1.c >> >> Can you file a bug about this and attach the preprocessed source from >> the test (using -E). > > Done, it is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104042 I made a comment about how we might work around this for Darwin - but OTOH, perhaps they should work with _FORTIFY_SOURCE != 0 Iain *** no particular reason why Darwin could not have push/pop section but that’s not implemented in either cctools or LLVM-based assemblers for mach-o at present. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Many analyzer failures on non-Linux system (x86_64-apple-darwin) 2022-01-10 20:58 ` David Malcolm 2022-01-15 14:19 ` FX @ 2022-01-16 1:35 ` Hans-Peter Nilsson 2022-01-16 11:11 ` FX 1 sibling, 1 reply; 10+ messages in thread From: Hans-Peter Nilsson @ 2022-01-16 1:35 UTC (permalink / raw) To: David Malcolm; +Cc: FX, GCC Mailing List, Iain Sandoe 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 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 marked with "dg-do assemble" directives, which I'd > hoped would mean it uses -S for the tests (to make a .s file), No, that's "dg-do compile" (as in "compile but don't assemble"). Also, the default *is* actually "compile" - unless overridden in an ancestor .exp. Grep for dg-do-what-default in sibling .exp's (like dfp/dfp.exp) if you consider changing the default in analyzer.exp. brgds, H-P ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Many analyzer failures on non-Linux system (x86_64-apple-darwin) 2022-01-16 1:35 ` Hans-Peter Nilsson @ 2022-01-16 11:11 ` FX 2022-01-21 0:08 ` [PATCH] testsuite: avoid analyzer asm failures on non-Linux David Malcolm 0 siblings, 1 reply; 10+ messages in thread From: FX @ 2022-01-16 11:11 UTC (permalink / raw) To: Hans-Peter Nilsson; +Cc: David Malcolm, GCC Mailing List, Iain Sandoe > 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 --- a/gcc/testsuite/gcc.dg/analyzer/asm-x86-lp64-1.c +++ b/gcc/testsuite/gcc.dg/analyzer/asm-x86-lp64-1.c @@ -1,4 +1,4 @@ -/* { dg-do assemble { target x86_64-*-* } } */ +/* { dg-do compile { target x86_64-*-* } } */ /* { dg-require-effective-target lp64 } */ #include "analyzer-decls.h” fixes the gcc.dg/analyzer/asm-x86-lp64-1.c failure on x86_64-apple-darwin. The same is true of this one: diff --git a/gcc/testsuite/gcc.dg/analyzer/torture/asm-x86-linux-wfx_get_ps_timeout-full.c b/gcc/testsuite/gcc.dg/analyzer/torture/asm-x86-linux-wfx_get_ps_timeout-full.c index e90dccf58dd..4cbf43206dc 100644 --- a/gcc/testsuite/gcc.dg/analyzer/torture/asm-x86-linux-wfx_get_ps_timeout-full.c +++ b/gcc/testsuite/gcc.dg/analyzer/torture/asm-x86-linux-wfx_get_ps_timeout-full.c @@ -1,4 +1,4 @@ -/* { dg-do assemble { target x86_64-*-* } } */ +/* { dg-do compile { target x86_64-*-* } } */ /* { dg-require-effective-target lp64 } */ /* { dg-additional-options "-fsanitize=bounds -fno-analyzer-call-summaries" } */ /* { dg-skip-if "" { *-*-* } { "-O0" } { "" } } */ These other three: FAIL: gcc.dg/analyzer/torture/asm-x86-linux-cpuid-paravirt-1.c FAIL: gcc.dg/analyzer/torture/asm-x86-linux-cpuid-paravirt-2.c FAIL: gcc.dg/analyzer/torture/asm-x86-linux-rdmsr-paravirt.c still fail with dg-do compile, as explained, become the error comes from the C front-end, not the assembler: /Users/fx/gcc/gcc/testsuite/gcc.dg/analyzer/torture/asm-x86-linux-cpuid-paravirt-1.c:27:3: warning: 'asm' operand 6 probably does not match constraints /Users/fx/gcc/gcc/testsuite/gcc.dg/analyzer/torture/asm-x86-linux-cpuid-paravirt-1.c:27:3: error: impossible constraint in 'asm' FX ^ permalink raw reply [flat|nested] 10+ messages in thread
* [PATCH] testsuite: avoid analyzer asm failures on non-Linux 2022-01-16 11:11 ` FX @ 2022-01-21 0:08 ` David Malcolm 2022-02-07 17:08 ` FX 0 siblings, 1 reply; 10+ messages in thread From: David Malcolm @ 2022-01-21 0:08 UTC (permalink / raw) To: FX, Hans-Peter Nilsson; +Cc: GCC Mailing List, Iain Sandoe, David Malcolm On Sun, 2022-01-16 at 12:11 +0100, FX wrote: > > 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 > --- a/gcc/testsuite/gcc.dg/analyzer/asm-x86-lp64-1.c > +++ b/gcc/testsuite/gcc.dg/analyzer/asm-x86-lp64-1.c > @@ -1,4 +1,4 @@ > -/* { dg-do assemble { target x86_64-*-* } } */ > +/* { dg-do compile { target x86_64-*-* } } */ > /* { dg-require-effective-target lp64 } */ > > #include "analyzer-decls.h” > > > fixes the gcc.dg/analyzer/asm-x86-lp64-1.c failure on > x86_64-apple-darwin. The same is true of this one: > > diff --git > a/gcc/testsuite/gcc.dg/analyzer/torture/asm-x86-linux-wfx_get_ps_timeout-full.c > b/gcc/testsuite/gcc.dg/analyzer/torture/asm-x86-linux-wfx_get_ps_timeout-full.c > index e90dccf58dd..4cbf43206dc 100644 > --- > a/gcc/testsuite/gcc.dg/analyzer/torture/asm-x86-linux-wfx_get_ps_timeout-full.c > +++ > b/gcc/testsuite/gcc.dg/analyzer/torture/asm-x86-linux-wfx_get_ps_timeout-full.c > @@ -1,4 +1,4 @@ > -/* { dg-do assemble { target x86_64-*-* } } */ > +/* { dg-do compile { target x86_64-*-* } } */ > /* { dg-require-effective-target lp64 } */ > /* { dg-additional-options "-fsanitize=bounds > -fno-analyzer-call-summaries" } */ > /* { dg-skip-if "" { *-*-* } { "-O0" } { "" } } */ > > > > These other three: > FAIL: gcc.dg/analyzer/torture/asm-x86-linux-cpuid-paravirt-1.c > FAIL: gcc.dg/analyzer/torture/asm-x86-linux-cpuid-paravirt-2.c > FAIL: gcc.dg/analyzer/torture/asm-x86-linux-rdmsr-paravirt.c > > still fail with dg-do compile, as explained, become the error comes > from the C front-end, not the assembler: > > /Users/fx/gcc/gcc/testsuite/gcc.dg/analyzer/torture/asm-x86-linux-cpuid-paravirt-1.c:27:3: > warning: 'asm' operand 6 probably does not match constraints > /Users/fx/gcc/gcc/testsuite/gcc.dg/analyzer/torture/asm-x86-linux-cpuid-paravirt-1.c:27:3: > error: impossible constraint in 'asm' Thanks. I extended your patch as follows, which works successfully for me on x86_64-pc-linux-gnu. Does the following look OK for the analyzer asm failures on x86_64-apple-darwin? Dave gcc/testsuite/ChangeLog: * gcc.dg/analyzer/asm-x86-1.c: Use dg-do "compile" rather than "assemble". * gcc.dg/analyzer/asm-x86-lp64-1.c: Likewise. * gcc.dg/analyzer/asm-x86-lp64-2.c: Likewise. * gcc.dg/analyzer/torture/asm-x86-linux-array_index_mask_nospec.c: Likewise. * gcc.dg/analyzer/torture/asm-x86-linux-cpuid-paravirt-1.c: Likewise, and restrict to x86_64-pc-linux-gnu. * gcc.dg/analyzer/torture/asm-x86-linux-cpuid-paravirt-2.c: Likewise. * gcc.dg/analyzer/torture/asm-x86-linux-cpuid.c: Use dg-do "compile" rather than "assemble". * gcc.dg/analyzer/torture/asm-x86-linux-rdmsr-paravirt.c: Likewise, and restrict to x86_64-pc-linux-gnu. * gcc.dg/analyzer/torture/asm-x86-linux-rdmsr.c: Use dg-do "compile" rather than "assemble". * gcc.dg/analyzer/torture/asm-x86-linux-wfx_get_ps_timeout-full.c: Likewise. * gcc.dg/analyzer/torture/asm-x86-linux-wfx_get_ps_timeout-reduced.c: Likewise. Signed-off-by: David Malcolm <dmalcolm@redhat.com> --- gcc/testsuite/gcc.dg/analyzer/asm-x86-1.c | 2 +- gcc/testsuite/gcc.dg/analyzer/asm-x86-lp64-1.c | 2 +- gcc/testsuite/gcc.dg/analyzer/asm-x86-lp64-2.c | 2 +- .../analyzer/torture/asm-x86-linux-array_index_mask_nospec.c | 2 +- .../gcc.dg/analyzer/torture/asm-x86-linux-cpuid-paravirt-1.c | 2 +- .../gcc.dg/analyzer/torture/asm-x86-linux-cpuid-paravirt-2.c | 2 +- gcc/testsuite/gcc.dg/analyzer/torture/asm-x86-linux-cpuid.c | 2 +- .../gcc.dg/analyzer/torture/asm-x86-linux-rdmsr-paravirt.c | 2 +- gcc/testsuite/gcc.dg/analyzer/torture/asm-x86-linux-rdmsr.c | 2 +- .../analyzer/torture/asm-x86-linux-wfx_get_ps_timeout-full.c | 2 +- .../analyzer/torture/asm-x86-linux-wfx_get_ps_timeout-reduced.c | 2 +- 11 files changed, 11 insertions(+), 11 deletions(-) diff --git a/gcc/testsuite/gcc.dg/analyzer/asm-x86-1.c b/gcc/testsuite/gcc.dg/analyzer/asm-x86-1.c index f6026b7e288..a3f86e440b5 100644 --- a/gcc/testsuite/gcc.dg/analyzer/asm-x86-1.c +++ b/gcc/testsuite/gcc.dg/analyzer/asm-x86-1.c @@ -1,4 +1,4 @@ -/* { dg-do assemble { target x86_64-*-* } } */ +/* { dg-do compile { target x86_64-*-* } } */ #include "analyzer-decls.h" 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 --- a/gcc/testsuite/gcc.dg/analyzer/asm-x86-lp64-1.c +++ b/gcc/testsuite/gcc.dg/analyzer/asm-x86-lp64-1.c @@ -1,4 +1,4 @@ -/* { dg-do assemble { target x86_64-*-* } } */ +/* { dg-do compile { target x86_64-*-* } } */ /* { dg-require-effective-target lp64 } */ #include "analyzer-decls.h" diff --git a/gcc/testsuite/gcc.dg/analyzer/asm-x86-lp64-2.c b/gcc/testsuite/gcc.dg/analyzer/asm-x86-lp64-2.c index fa507395ec7..2864ab69d2a 100644 --- a/gcc/testsuite/gcc.dg/analyzer/asm-x86-lp64-2.c +++ b/gcc/testsuite/gcc.dg/analyzer/asm-x86-lp64-2.c @@ -1,4 +1,4 @@ -/* { dg-do assemble { target x86_64-*-* } } */ +/* { dg-do compile { target x86_64-*-* } } */ /* { dg-require-effective-target lp64 } */ /* Adapted from Linux x86: page_ref_dec_and_test.c (GPL-2.0). */ diff --git a/gcc/testsuite/gcc.dg/analyzer/torture/asm-x86-linux-array_index_mask_nospec.c b/gcc/testsuite/gcc.dg/analyzer/torture/asm-x86-linux-array_index_mask_nospec.c index 6201fdb498f..b2d615c22b9 100644 --- a/gcc/testsuite/gcc.dg/analyzer/torture/asm-x86-linux-array_index_mask_nospec.c +++ b/gcc/testsuite/gcc.dg/analyzer/torture/asm-x86-linux-array_index_mask_nospec.c @@ -1,4 +1,4 @@ -/* { dg-do assemble { target x86_64-*-* } } */ +/* { dg-do compile { target x86_64-*-* } } */ /* { dg-require-effective-target lp64 } */ /* { dg-skip-if "" { *-*-* } { "-fno-fat-lto-objects" } { "" } } */ diff --git a/gcc/testsuite/gcc.dg/analyzer/torture/asm-x86-linux-cpuid-paravirt-1.c b/gcc/testsuite/gcc.dg/analyzer/torture/asm-x86-linux-cpuid-paravirt-1.c index cf5cf97367d..9861c2d15ca 100644 --- a/gcc/testsuite/gcc.dg/analyzer/torture/asm-x86-linux-cpuid-paravirt-1.c +++ b/gcc/testsuite/gcc.dg/analyzer/torture/asm-x86-linux-cpuid-paravirt-1.c @@ -1,4 +1,4 @@ -/* { dg-do assemble { target x86_64-*-* } } */ +/* { dg-do compile { target x86_64-pc-linux-gnu } } */ /* { dg-require-effective-target lp64 } */ /* { dg-skip-if "" { *-*-* } { "-O0" } { "" } } */ /* { dg-skip-if "" { *-*-* } { "-fno-fat-lto-objects" } { "" } } */ diff --git a/gcc/testsuite/gcc.dg/analyzer/torture/asm-x86-linux-cpuid-paravirt-2.c b/gcc/testsuite/gcc.dg/analyzer/torture/asm-x86-linux-cpuid-paravirt-2.c index c4b365f1e6e..09fef5ddfcc 100644 --- a/gcc/testsuite/gcc.dg/analyzer/torture/asm-x86-linux-cpuid-paravirt-2.c +++ b/gcc/testsuite/gcc.dg/analyzer/torture/asm-x86-linux-cpuid-paravirt-2.c @@ -1,4 +1,4 @@ -/* { dg-do assemble { target x86_64-*-* } } */ +/* { dg-do compile { target x86_64-pc-linux-gnu } } */ /* { dg-require-effective-target lp64 } */ /* { dg-skip-if "" { *-*-* } { "-O0" } { "" } } */ /* { dg-skip-if "" { *-*-* } { "-fno-fat-lto-objects" } { "" } } */ diff --git a/gcc/testsuite/gcc.dg/analyzer/torture/asm-x86-linux-cpuid.c b/gcc/testsuite/gcc.dg/analyzer/torture/asm-x86-linux-cpuid.c index 243931aebc8..518fe8c286c 100644 --- a/gcc/testsuite/gcc.dg/analyzer/torture/asm-x86-linux-cpuid.c +++ b/gcc/testsuite/gcc.dg/analyzer/torture/asm-x86-linux-cpuid.c @@ -1,4 +1,4 @@ -/* { dg-do assemble { target x86_64-*-* } } */ +/* { dg-do compile { target x86_64-*-* } } */ /* { dg-require-effective-target lp64 } */ #include "../analyzer-decls.h" diff --git a/gcc/testsuite/gcc.dg/analyzer/torture/asm-x86-linux-rdmsr-paravirt.c b/gcc/testsuite/gcc.dg/analyzer/torture/asm-x86-linux-rdmsr-paravirt.c index d9947871235..ed807ab8fc8 100644 --- a/gcc/testsuite/gcc.dg/analyzer/torture/asm-x86-linux-rdmsr-paravirt.c +++ b/gcc/testsuite/gcc.dg/analyzer/torture/asm-x86-linux-rdmsr-paravirt.c @@ -1,6 +1,6 @@ /* Adapted from Linux: arch/x86/include/asm/paravirt.h */ -/* { dg-do assemble { target x86_64-*-* } } */ +/* { dg-do compile { target x86_64-pc-linux-gnu } } */ /* { dg-skip-if "" { *-*-* } { "-fno-fat-lto-objects" } { "" } } */ /* { dg-skip-if "" { *-*-* } { "-O0" } { "" } } */ diff --git a/gcc/testsuite/gcc.dg/analyzer/torture/asm-x86-linux-rdmsr.c b/gcc/testsuite/gcc.dg/analyzer/torture/asm-x86-linux-rdmsr.c index 69d0165aefe..3735d33444e 100644 --- a/gcc/testsuite/gcc.dg/analyzer/torture/asm-x86-linux-rdmsr.c +++ b/gcc/testsuite/gcc.dg/analyzer/torture/asm-x86-linux-rdmsr.c @@ -1,4 +1,4 @@ -/* { dg-do assemble { target x86_64-*-* } } */ +/* { dg-do compile { target x86_64-*-* } } */ /* { dg-skip-if "" { *-*-* } { "-fno-fat-lto-objects" } { "" } } */ #include "../analyzer-decls.h" diff --git a/gcc/testsuite/gcc.dg/analyzer/torture/asm-x86-linux-wfx_get_ps_timeout-full.c b/gcc/testsuite/gcc.dg/analyzer/torture/asm-x86-linux-wfx_get_ps_timeout-full.c index e90dccf58dd..4cbf43206dc 100644 --- a/gcc/testsuite/gcc.dg/analyzer/torture/asm-x86-linux-wfx_get_ps_timeout-full.c +++ b/gcc/testsuite/gcc.dg/analyzer/torture/asm-x86-linux-wfx_get_ps_timeout-full.c @@ -1,4 +1,4 @@ -/* { dg-do assemble { target x86_64-*-* } } */ +/* { dg-do compile { target x86_64-*-* } } */ /* { dg-require-effective-target lp64 } */ /* { dg-additional-options "-fsanitize=bounds -fno-analyzer-call-summaries" } */ /* { dg-skip-if "" { *-*-* } { "-O0" } { "" } } */ diff --git a/gcc/testsuite/gcc.dg/analyzer/torture/asm-x86-linux-wfx_get_ps_timeout-reduced.c b/gcc/testsuite/gcc.dg/analyzer/torture/asm-x86-linux-wfx_get_ps_timeout-reduced.c index a18c58c5e61..e046d8c03b1 100644 --- a/gcc/testsuite/gcc.dg/analyzer/torture/asm-x86-linux-wfx_get_ps_timeout-reduced.c +++ b/gcc/testsuite/gcc.dg/analyzer/torture/asm-x86-linux-wfx_get_ps_timeout-reduced.c @@ -1,4 +1,4 @@ -/* { dg-do assemble { target x86_64-*-* } } */ +/* { dg-do compile { target x86_64-*-* } } */ /* { dg-require-effective-target lp64 } */ /* Reproducer for false positive from -Wanalyzer-null-dereference seen -- 2.26.3 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] testsuite: avoid analyzer asm failures on non-Linux 2022-01-21 0:08 ` [PATCH] testsuite: avoid analyzer asm failures on non-Linux David Malcolm @ 2022-02-07 17:08 ` FX 2022-02-07 23:35 ` David Malcolm 0 siblings, 1 reply; 10+ messages in thread From: FX @ 2022-02-07 17:08 UTC (permalink / raw) To: David Malcolm; +Cc: Hans-Peter Nilsson, GCC Mailing List, Iain Sandoe Hi David, > Thanks. I extended your patch as follows, which works successfully for > me on x86_64-pc-linux-gnu. > > Does the following look OK for the analyzer asm failures on > x86_64-apple-darwin? Sorry for the late reply… yes it does! FX ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] testsuite: avoid analyzer asm failures on non-Linux 2022-02-07 17:08 ` FX @ 2022-02-07 23:35 ` David Malcolm 0 siblings, 0 replies; 10+ messages in thread From: David Malcolm @ 2022-02-07 23:35 UTC (permalink / raw) To: FX; +Cc: Hans-Peter Nilsson, GCC Mailing List, Iain Sandoe On Mon, 2022-02-07 at 18:08 +0100, FX wrote: > Hi David, > > > Thanks. I extended your patch as follows, which works successfully > > for > > me on x86_64-pc-linux-gnu. > > > > Does the following look OK for the analyzer asm failures on > > x86_64-apple-darwin? > > Sorry for the late reply… yes it does! Thanks. I've committed it to trunk as r12-7085-gf30e65e94d14a2. Dave ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2022-02-07 23:35 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-12-23 21:49 Many analyzer failures on non-Linux system (x86_64-apple-darwin) FX 2022-01-10 16:13 ` FX 2022-01-10 20:58 ` David Malcolm 2022-01-15 14:19 ` FX 2022-01-15 14:31 ` Iain Sandoe 2022-01-16 1:35 ` Hans-Peter Nilsson 2022-01-16 11:11 ` FX 2022-01-21 0:08 ` [PATCH] testsuite: avoid analyzer asm failures on non-Linux David Malcolm 2022-02-07 17:08 ` FX 2022-02-07 23:35 ` David Malcolm
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).