From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from hamza.pair.com (hamza.pair.com [209.68.5.143]) by sourceware.org (Postfix) with ESMTPS id 17B19385782D for ; Fri, 16 Feb 2024 21:23:18 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 17B19385782D Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=pfeifer.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=pfeifer.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 17B19385782D Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=209.68.5.143 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1708118599; cv=none; b=g7yAQaXvzF5XCqW+uHcsRQFgkDD6tr2o+f5qnCaDaOkXs8Wo9nwMSGFr8WjBSTw4Cp0J28sVldiVCJURVOnDSAz2A5uBPZJKnKVd6KCSY2Z5L73NjTRgQXDd0PuOb/A9zte238Jiz3TewZRKuy0Xz5fGD/60xYezLMlkiorycw4= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1708118599; c=relaxed/simple; bh=4isjs1gHjoZCjpOmXDzYvpCSb/V+dWdMdW0nJ8EQoi8=; h=Date:From:To:Subject:Message-ID:MIME-Version; b=wexBWjaAhrOGgjN2Hx5OHRBV1VtWaebTO+WNgm1o6IswpunhvNkoBgOkIi9RIIW/fKCDsIi07XBX/Vr51QQeTfU6LAI8H3WQwgt1CwWrGFBR8ibUg5HNAMplnVKP66kKgHUvZzJvWH7qkJHs+cNfVi8xj/E41S4G4Z0YcmrzfPY= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from hamza.pair.com (localhost [127.0.0.1]) by hamza.pair.com (Postfix) with ESMTP id 82C7C33E9B; Fri, 16 Feb 2024 16:23:17 -0500 (EST) Received: from daya.localdomain (188-23-3-19.adsl.highway.telekom.at [188.23.3.19]) (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 hamza.pair.com (Postfix) with ESMTPSA id 034A333E9F; Fri, 16 Feb 2024 16:23:16 -0500 (EST) Date: Fri, 16 Feb 2024 22:23:14 +0100 (CET) From: Gerald Pfeifer To: Florian Weimer cc: gcc-patches@gcc.gnu.org Subject: Re: [PATCH] Notes on the warnings-as-errors change in GCC 14 In-Reply-To: <875xypad84.fsf@oldenburg.str.redhat.com> Message-ID: <179bf5de-140a-b0be-0a41-cf42f24d0a22@pfeifer.com> References: <87v876ssxg.fsf@oldenburg.str.redhat.com> <2058c7ba-20af-7cb5-f15d-ec0653f76903@pfeifer.com> <875xypad84.fsf@oldenburg.str.redhat.com> MIME-Version: 1.0 Content-Type: multipart/mixed; BOUNDARY="8323328-1815772389-1708076863=:5863" X-Scanned-By: mailmunge 3.11 on 209.68.5.143 X-Spam-Status: No, score=-1.6 required=5.0 tests=BAYES_00,KAM_DMARC_STATUS,KAM_NUMSUBJECT,KAM_SHORT,RCVD_IN_BARRACUDACENTRAL,SPF_HELO_NONE,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: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323328-1815772389-1708076863=:5863 Content-Type: text/plain; CHARSET=UTF-8 Content-Transfer-Encoding: 8BIT On Thu, 15 Feb 2024, Florian Weimer wrote: >>> +GCC no longer casts all pointer types to all other pointer types. >> >> Do you mean it no longer does so implicitly, or not at all? That is, >> there are now cases where even an explicit cast such as >> >> foo_p = (foo_type*) bar_p >> >> no longer works? Or just >> >> foo_p = bar_p >> >> no longer works for all combinations? > The latter, other reviewers noted it as well, and I've got this now: > “GCC no longer [allows implicitly casting] all pointer types to all” Ah, got it. The wording above nicely clarifies it to me. I am wondering whether "...every point type to every other pointer type" might be even more clear? (Open question, "no" being a very valid answer.) >> I *think* we may need to use > here instead of plain '>', though I may >> be wrong. > No, only < needs to be quoted. This is true even for XML, not just > HTML5. Do you want me to change these to >? No, no; if it validates, we're good. :-) > What about this? > > These failed probes tend to disable program features [together with] > their tests[], resulting in silently dropping features. > > This what I meant with “consistently”: implementations and tests are > gone, so the testsuite doesn't flag it. I like it! >>> +In cases where this is a concern, generated config.log, >>> +config.h and other source code files can be compared >>> +using diff, >>> +to ensure there are no unexpected differences. >> I wouldn't link to GNU diffutils here; just refer to the diff >> command - or even omit that aspect and leave it at "can be compared". > diff is really useful for that, manual comparison isn't. 8-) > I can drop the hyperlink. Yes, I never would compare manually myself. :) Let's drop the hyperlink then; people developing software would know diff. >>> +Some build systems do not pass the CFLAGS environment >>> +or make variable to all parts of the builds >> >> Is "make" a common variable? What is the context here? > Hmm, I meant to allude $(CFLAGS) here. > > “CFLAGS [] variable to all parts of the builds” should be > sufficient. Ah, reading this again I see it was "environment variable" or "make variable" - the beauty of natural languages and their ambiguity. Yes, your suggested edit looks good! > I need to add two more code examples to the Autoconf section, should I > post a v2 with that, or add that in a subsequent commit? Primarily as you prefer. My personal recommendation (not request) is to commit the current patch and then add on top. Thanks again for your work documenting all this! Gerald --8323328-1815772389-1708076863=:5863--