From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id DA52779FE for ; Mon, 14 Nov 2022 18:30:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1668450653; 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=Z4nGA91w3pUt2TfKF9OaXhhJbic4g1JqRm5/PxaUW2cNtDwtgIgpybq+Wle9wv9C/SJ5kT +02M3qiLB5/a46tklm9W6dAcIfBaaug2vgZWJtCAQzqaa5dueqczVELuGFVg+2J6q3XUwJ YgtMDZHXSDqQm5TrXsZVe0KCnCCnYew= 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) Precedence: bulk X-Mailing-List: c-std-porting@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: 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 * 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