From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from cc-smtpout1.netcologne.de (cc-smtpout1.netcologne.de [89.1.8.211]) by sourceware.org (Postfix) with ESMTPS id 1A8D73858C2B for ; Tue, 9 May 2023 21:00:59 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 1A8D73858C2B Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=netcologne.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=netcologne.de Received: from cc-smtpin3.netcologne.de (cc-smtpin3.netcologne.de [89.1.8.203]) by cc-smtpout1.netcologne.de (Postfix) with ESMTP id 8A9F3126D5 for ; Tue, 9 May 2023 23:00:56 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=netcologne.de; s=nc1116a; t=1683666056; bh=Ps9rUKgPp1B3QCZLPRxbVeoagir8J3vIftX7kgjS4U4=; h=Message-ID:Date:Subject:To:References:From:In-Reply-To:From; b=N2LFRiK4VNrVwZiRrlxH+TTAgkXAu91dEpQOLPx+IX3lxE0ZhD0q4jjXFNlIBtewo UQrcFVt7RCOsC6JRRihILp9YPEjwyOHwyLyTtmhOgjrm9xOuYEFYE/Tl0HTEuY7lgp Ur55Tc5uNJH9pj/M8ZckLdVtBrtr9N2/1dLMYzJNNUYZfqapCeMkzhs1FdDZy8XCNz xL+B0bUImiDsOvfFsnOqDd4EfLLqjW7NmsrPeynsnG8v32WaqmFStQG2tL3rYRQWBJ 52IJTgdMyXgGmv87Sy0NYWoGhWj6q0tVnXLc/abM08XUNaA3NpG4M/u6crL/kPc7ti jQhwdxxRrxM6Q== Received: from [IPV6:2001:4dd6:3fec:0:7285:c2ff:fe6c:992d] (2001-4dd6-3fec-0-7285-c2ff-fe6c-992d.ipv6dyn.netcologne.de [IPv6:2001:4dd6:3fec:0:7285:c2ff:fe6c:992d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by cc-smtpin3.netcologne.de (Postfix) with ESMTPSA id 60A7611DC1 for ; Tue, 9 May 2023 23:00:56 +0200 (CEST) Message-ID: <8e51f57b-a1e0-508a-a69f-d5efdeaf814e@netcologne.de> Date: Tue, 9 May 2023 23:00:56 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0 Subject: Re: More C type errors by default for GCC 14 To: gcc mailing list References: <877cth66qb.fsf@oldenburg.str.redhat.com> <20230509102201.6aa2a7d14fdb2f1e7abff449@killthe.net> <87r0rp5uf8.fsf@aarsen.me> <83ttwla1ep.fsf@gnu.org> <83lehx9vix.fsf@gnu.org> <83fs859unu.fsf@gnu.org> Content-Language: en-US From: Thomas Koenig In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-NetCologne-Spam: L X-Spamd-Bar: ---- X-Rspamd-Action: no action X-Rspamd-Queue-Id: 60A7611DC1 X-Spam-Status: No, score=-3.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,KAM_NUMSUBJECT,NICE_REPLY_A,RCVD_IN_DNSWL_LOW,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_PASS,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: Not replying to anybody in particular, just a bit of history, with some potential parallels. In gfortran, we have had two major issues with interfaces. One was that code which had happily violated the compiler ABI started failing, due to a fix in the gfortran front end which meant that we were no longer mixing varargs and non-varargs calls (which led to code being correctly compiled for POWER which had been miscompiled for basically forewer). Among other things, this broke R, and was fixed by Jakub by applying a workaround. After a few years, people in core libraries like BLAS and Netlib are finally getting around to fixing their code. There is no knowing what codes still have that, so the workaround will probably stay around forever, although we don't promise that it does. Partially motivated by this, we then added a file-level check for argument list mismatches (type and rank), which issued an error. That error could be disabled by a new option, -fallow-argument-mismatch, but that caused problems for people using different versions of the compiler. So we added this option to -std=legacy, which is a catch-all kitchen sink, which accepts some not-so-nice things. Of course, as everybody on this list knows, mixing types like this is dangerous, and is liable to break sooner or later in future compiler release. Nonetheless, even a package like MPICH chose to use autoconf to set the -fallow-argument-mismatch flag rather than fix the code :-( Others, like the LAPACK maintainers, have reacted and installed patches. So... using an error message as a crowbar to change people's behavior failed, at least partially. And you only hear from the people who complain, not from those who are glad that they found errors that they would otherwise have missed. What does that mean for the case at hand? Based on past experience, I'd lean towards putting all the warnings about the special offending codes into one warning option (-Wsevere, or something) which could then be made into an error by -Werror=severe or such variant; maybe other warnings could be grouped in there as well. And if these severe warnings should then be made default or not, well... that (like the rest of my mail) is open for discussion. Best regards Thomas