From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id 9EEB23857C4D for ; Mon, 10 Jan 2022 20:58:54 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 9EEB23857C4D Received: from mail-qk1-f199.google.com (mail-qk1-f199.google.com [209.85.222.199]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-479-G3OSATgGN52BMZS4nx4NkQ-1; Mon, 10 Jan 2022 15:58:48 -0500 X-MC-Unique: G3OSATgGN52BMZS4nx4NkQ-1 Received: by mail-qk1-f199.google.com with SMTP id n8-20020a05620a152800b00477e85843edso2338142qkk.9 for ; Mon, 10 Jan 2022 12:58:48 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:user-agent:mime-version:content-transfer-encoding; bh=X7sm2oqYMyEgI/SxcAnKiQoNe3c/HamQ4xUHv66YdXs=; b=kBtAZe8QQmfZutQ44CASYLoVR1qLxS9eDNSqrLsJQ7sEZr9N9vkkyHf//3MRyOuuPG cM5dAQOxZ27TlU7qwaUthgPtqiWMx+NgXpOKTMOgjD8e7Y1zE+FUbF138ORFMubEUO64 k65odavENb+Lp9SPi3w/aW/HpzWJySqi7g0FyBpupkg0qpwy313XclrgREyeSrcxPiDy Uf7SlZTMq9BfTb1rRrY1WLmBbD17w5mIw5KmStM4gSXoBP9FfrOrK3ha8nUsOibr7VgZ ltWTIiyh8ax8S9yofxaGRnyDQyNlGsKqYvpkrZpK3S4VxuH0sSxnTHOz3/7WSBuumBgq 58qA== X-Gm-Message-State: AOAM5306/ILY5zVke3IEeDNMMh3GNTTMoOXo5jaF+BJliSMNmuFSNpxI VFnbq5J9Qg+nDpWWBnJ0yxdwk23mZJT3654Mu+9X5UTkqu56+n8JKuDS4awYsQQcOL3enaItCV8 SX+7bu7U= X-Received: by 2002:a37:54d:: with SMTP id 74mr1162147qkf.664.1641848327265; Mon, 10 Jan 2022 12:58:47 -0800 (PST) X-Google-Smtp-Source: ABdhPJzv0ylmcvJoDg/rB7jh02nitqta9DIczvwT0CfN9ciL6u2xW7tOfVWJyX7V9nhjpc4eQxUwtw== X-Received: by 2002:a37:54d:: with SMTP id 74mr1162135qkf.664.1641848326986; Mon, 10 Jan 2022 12:58:46 -0800 (PST) Received: from t14s.localdomain (c-73-69-212-193.hsd1.ma.comcast.net. [73.69.212.193]) by smtp.gmail.com with ESMTPSA id t15sm5549401qta.45.2022.01.10.12.58.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 10 Jan 2022 12:58:46 -0800 (PST) Message-ID: Subject: Re: Many analyzer failures on non-Linux system (x86_64-apple-darwin) From: David Malcolm To: FX , GCC Mailing List Cc: Iain Sandoe Date: Mon, 10 Jan 2022 15:58:45 -0500 In-Reply-To: <237CA1D3-29E0-4252-8EDC-DC562BA042A2@gmail.com> References: <3BD093C3-178E-4B11-BDA1-9604ADCA4B04@gmail.com> <237CA1D3-29E0-4252-8EDC-DC562BA042A2@gmail.com> User-Agent: Evolution 3.38.4 (3.38.4-1.fc33) MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.6 required=5.0 tests=BAYES_00, BODY_8BITS, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, KAM_SHORT, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2022 20:58:56 -0000 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 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 > > (included from ) 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