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 <fxcoud...@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
