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.133.124]) by sourceware.org (Postfix) with ESMTPS id EA645385B53A for ; Thu, 30 Nov 2023 16:02:27 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org EA645385B53A Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org EA645385B53A Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1701360158; cv=none; b=unDK/8rULofoS7h0ZOXi+uylvSsiHKNnOCJA0cixC3g0lsMHe8rSp/MCkJclx1ltq9CIFoC84qnZDz6l1jWC4YMubQDX6nwIZmoPjutRpgWzjkehlkctytbNtCND4yxVMAdWcznjFf/1OEVQ6gmXp2beKdfkGmcB5k1s7aApp+E= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1701360158; c=relaxed/simple; bh=lLT/ksuWJSyIi5BvZ9bPhbg7PUTB5hqaKdfih0+6324=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=CTp1A5UZjFVfvJR7y529+D31EsPjYapVuE1XTBJNdLyPLNKzAuhkQjkUJmN9eVkTfKIl6huWWXdt9bJx8jUCsMSpYF3WbOG35B13RMGseSQ/ZVvX6x4dHo+hXaPFoCO+vhPfRD4lP65/AY3JNGewq5nzKFzgjoZvnFFPEZk/oDI= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1701360147; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=vDukD/npYTI0P8oQ1BNe5zydPsdGKgszD3wHjHBlUUI=; b=OS3d4xTG7u98FER5Bub4V/x81+CWiT+b3+cLcyLP2/NY4hwZNTYb25eWjS/eouatxM6Xoa JvFquWMLrAD44e3FBq1TMZ3NoFTyXNxW7dK4mQAL8JuAdACPTvSw9w2o2mfGxDh9BRH+OF Gwl0to3hwjPVuKboeUDbP5nfkWC1fz0= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-54-avCvpjKINA6TaIQfrkD2yw-1; Thu, 30 Nov 2023 11:02:26 -0500 X-MC-Unique: avCvpjKINA6TaIQfrkD2yw-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.rdu2.redhat.com [10.11.54.5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id A530080D720 for ; Thu, 30 Nov 2023 16:02:24 +0000 (UTC) Received: from oldenburg.str.redhat.com (unknown [10.2.16.45]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 0BFB410F44 for ; Thu, 30 Nov 2023 16:02:23 +0000 (UTC) From: Florian Weimer To: gcc@gcc.gnu.org Subject: Update on GCC 14 C type safety changes/warnings as errors Date: Thu, 30 Nov 2023 17:02:22 +0100 Message-ID: <87ttp3tek1.fsf@oldenburg.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.3 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.5 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-4.6 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: The patch series is currently under review: [PATCH v3 00/11] : More warnings as errors by default Jeff as a global reviewer has delegated review to Marek. The current series is based on an earlier suggestion to do as much as possible in one transition. The full list of upgraded warnings is: -Wimplicit-function-declaration -Wimplicit-int -Wint-conversion -Wreturn-mismatch (new, previously part of -Wreturn-types) -Wdeclaration-missing-parameter-type (new, previously unnamed) -Wincompatible-pointer-types Fedora has a set of about 15,000 source packages which are built with a GCC compiler in the buildroot. Until recently, we only had experience with dealing with -Wimplicit-function-declaration and -Wimplicit-int issues. We have implemented fixes or workaround in about 860 packages for those two warnings. Where possible, these fixes have been sent upstream, but of course in many cases, upstream has been dormant for a while or not around at all anymore. We now have Fedora test builds with an instrumented GCC that covers all the warnings listed above. The data is skewed somewhat because we underwent an unscheduled libxml2 API transition at the same time, and also had a glibc crypt declaration regression initially. I'm going with the numbers I have today. They include cleanups for about 50 packages for various issues (most prominent ones being bash and xterm). autoconf all only implicit-function-declaration 53 21 implicit-int 2 0 int-conversion 99 33 return-mismatch 13 2 declaration-missing-parameter-type 0 0 incompatible-pointer-types 374 50 497 89 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. 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? Excluded above are systemic issues related to Vala, which does not produce valid C in many cases. I will probably have to look into teaching Vala to emit diagnostic pragmata in the generated C sources because they are not expected to be valid C (although again, this really seems to be hiding application bugs in some cases). Thanks, Florian