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 BDE78382EF0C for ; Mon, 14 Nov 2022 18:30:56 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org BDE78382EF0C Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1668450656; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=DSCzkB7yn98Ag+w6MWaYKl3QonzCXugwRKmPistd2y4=; b=XYtSJKFtXHiW8d1SQS+VbxoFXcVcRhlmsCzc8TX4avKfXKeCe2HK0PFHGuNw97naeueI67 hnIVcbmvst14wgQ30HjD9NrBn/qZxoJzSO4IP7dHwY+EC8b8i3AGmFWvnZjkubqYcAd+WT hP4dRtiA72fEChm54cOU7c9gPf69BM4= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-92-4CRwiCl9PvabV0C3B2996w-1; Mon, 14 Nov 2022 13:30:52 -0500 X-MC-Unique: 4CRwiCl9PvabV0C3B2996w-1 Received: from smtp.corp.redhat.com (int-mx09.intmail.prod.int.rdu2.redhat.com [10.11.54.9]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 7FF5F858F13; Mon, 14 Nov 2022 18:30:51 +0000 (UTC) Received: from oldenburg.str.redhat.com (unknown [10.2.16.5]) by smtp.corp.redhat.com (Postfix) with ESMTPS id DD74849BB60; Mon, 14 Nov 2022 18:30:49 +0000 (UTC) From: Florian Weimer To: Paul Eggert Cc: Aaron Ballman , Zack Weinberg , c-std-porting@lists.linux.dev, autoconf@gnu.org, gcc@gcc.gnu.org, cfe-commits@lists.llvm.org, Gnulib bugs Subject: Re: How can Autoconf help with the transition to stricter compilation defaults? References: <24ed5604-305a-4343-a1b6-a789e4723849@app.fastmail.com> <251923e7-57be-1611-be10-49c3067adf0d@cs.ucla.edu> <7ef0ce03-d908-649a-a6ee-89fea374d2b1@cs.ucla.edu> Date: Mon, 14 Nov 2022 19:30:46 +0100 In-Reply-To: (Paul Eggert's message of "Mon, 14 Nov 2022 10:14:07 -0800") Message-ID: <87y1sdtmll.fsf@oldenburg.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.1 on 10.11.54.9 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-4.5 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_H2,SPF_HELO_NONE,SPF_NONE,TXREP 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: * Paul Eggert: > On 2022-11-14 04:41, Aaron Ballman wrote: >> it's generally a problem when autoconf relies on invalid >> language constructs > > Autoconf *must* rely on invalid language constructs, if only to test > whether the language constructs work. And Clang therefore must be > careful about how it diagnoses invalid constructs. Clang shouldn't > willy-nilly change the way it reports invalid constructs, as that can > break Autoconf. This is only true for the status quo. We could finally band together and define an interface between autoconf and the toolchain that avoids feature probing through source code fragments for common cases. It might make configure scripts to run quite a bit faster, too. That being said, system compilers need to be careful when turning warnings into errors by default, but that doesn't mean we should never do such changes, particularly when we know based on interactions with programmers that the warnings are not sufficient for avoiding wasted time. Thanks, Florian