From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.gentoo.org (woodpecker.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) by sourceware.org (Postfix) with ESMTP id 5CCD93858CDB for ; Fri, 1 Dec 2023 08:28:35 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 5CCD93858CDB Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gentoo.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gentoo.org ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 5CCD93858CDB Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2001:470:ea4a:1:5054:ff:fec7:86e4 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1701419316; cv=none; b=h51F/UTnaTlJn9GNUfgAPxdRwQdhGnGRk4HFUcTkHf2m3PyAc+6hjQe6FthlocZvC+zgjcNnM81mn5Bsqp4yYuybynrLNf6VNX5k/K3PtYfLMjDUDzwzAviQ6QjQbSiG/FO6URGWG6zHSzwkcdx6fu9npCxz8gQpykqXYJeJt1M= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1701419316; c=relaxed/simple; bh=whSI/UAsh0ObVUtd2VlZwAhi+oZhdM/1EkAo8oMYVAQ=; h=From:To:Subject:Date:Message-ID:MIME-Version; b=HXybjQHp7clT53K2QoAz84FdRxdDFgB9u+aPCUJmd9rzviMnJuE8s9ltGvDSo2pdGTuI1Mv1GRoGCJF+ZVNheBvdfT2fK5KPgkja3ZRqIGWyIMgcgt3PiYAa1iUuX67mRmEXIrBvyJA8d+EZ8p7Blf+61+IE1krG7Id05GPaZek= ARC-Authentication-Results: i=1; server2.sourceware.org References: <87ttp3tek1.fsf@oldenburg.str.redhat.com> User-agent: mu4e 1.10.8; emacs 30.0.50 From: Sam James To: Florian Weimer Cc: gcc@gcc.gnu.org Subject: Re: Update on GCC 14 C type safety changes/warnings as errors Date: Fri, 01 Dec 2023 05:37:57 +0000 Organization: Gentoo In-reply-to: <87ttp3tek1.fsf@oldenburg.str.redhat.com> Message-ID: <87bkba8gy9.fsf@gentoo.org> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-4.0 required=5.0 tests=BAYES_00,JMQ_SPF_NEUTRAL,KAM_DMARC_STATUS,SPF_HELO_PASS,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Florian Weimer via Gcc writes: > [...] > Numbers do not tally up because one package can have multiple issues. > The autoconf column counts packages where file-name based heuristics > suggest the critical errors are in autoconf-style feature probes, where > they are ignored and could silently alter the results. My focus will be > on fixing those packages. incompatible-pointer-types at least suffers from some expected errors with e.g. strerror_r which you may want to just export the cache var for in a glibc environment at least for testing. Mine as well. > > These numbers include a certain amount of false positives, especially > for implicit-function-declaration and incompatible-pointer-types, but > the GCC instrumentation has improved somewhat and now uses unrelated > errors (e.g., about unknown types, or incorrect number of function > errors) to suppress logging of the critical errors. > > Looking at the numbers, everything seems quite doable except > incompatible-pointer-types. (Keep in mind that these numbers are based > on over 15,000 packages.) Instead of the incompatible-pointer-types > error, Clang only went with a subset (not yet implemented by GCC) called > incompatible-function-pointer-types, but I'm not sure if it would result > in a substantial amount of work reduction. The status as a warning for > non-function pointers definitely hides real bugs (for example, an > out-of-bounds write in PyTables on 32-bit architectures). > > I suggest we put in the incompatible-pointer-types upgrade for now > (pending review), and see how it goes in Fedora. I plan to backport > these changes to GCC 13 as used in our current development version, so > that we can gain some feedback from package maintainers before we import > GCC 14 (which is expected to happen well before the GCC upstream > release). If feedback is overly negative, I'm going to suggest that GCC > disables it again for the GCC 14 release, although that would run > counter to the request for one transition only. > > Thoughts? This sounds fair and in line with my observations. I lean towards us being able to pull it off but if needed, reverting that specific change later on in 14 development isn't the end of the world. Of course, you've added -fpermissive for a reason anyway, so we have that too. I hadn't considered exposing a patched GCC 13 to developers and might do the same, not sure how much take up there'd be on our end without some runtime toggle instead. Will have a think, but not really worried about it anyway, as the tinderboxes have great covergae & will run whatever version we want. > [...] Thank you again for doing this Florian. sam