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 A191A3858D20 for ; Sat, 10 Feb 2024 11:00:38 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org A191A3858D20 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 A191A3858D20 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=1707562840; cv=none; b=VKZZ2E4WBV4rN8x7H2MSOWDa0qDiw90RCaYijHf4onTU1kvBYQG9ZJJrhxx7hLE1byh8o2oez2Ju2n085bbdsv397Rulf8G7IzV2S8auy0Q/oz3GrA+LK3gs6L+DtYVN2YYW7Irfl5qHk1Tb94wcpI7fgueSdA5FNBl1TSdwRYg= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1707562840; c=relaxed/simple; bh=pbjKHnrskqJJowgqVnG3Ihv2R9skVYUOrGLKnkwJ+Fo=; h=Date:From:To:Subject:Message-ID:MIME-Version; b=TZXzejQ3da0HgqbKhzZFG8vzztu21FETIH4++SYHkr6PNAGKREItgsHhw7STQvGfRGDzF+apX7d4R5QgPJYTeL5k0KI8o1VzX3ZWiYmbTbZui2YICK/0fajxkj3aYIKeZmp4ZEyiWoP/INm+e0ZGzQmav79V58OGGaBfCgwt6Ts= 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 12DF633EBA; Sat, 10 Feb 2024 06:00:38 -0500 (EST) Received: from [192.168.203.87] (ip-109-43-112-188.web.vodafone.de [109.43.112.188]) (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 420E633ECB; Sat, 10 Feb 2024 06:00:37 -0500 (EST) Date: Sat, 10 Feb 2024 12:00:34 +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: <87v876ssxg.fsf@oldenburg.str.redhat.com> Message-ID: <2058c7ba-20af-7cb5-f15d-ec0653f76903@pfeifer.com> References: <87v876ssxg.fsf@oldenburg.str.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Scanned-By: mailmunge 3.11 on 209.68.5.143 X-Spam-Status: No, score=0.2 required=5.0 tests=BAYES_00,KAM_DMARC_STATUS,KAM_NUMSUBJECT,KAM_SHORT,RCVD_IN_BARRACUDACENTRAL,RCVD_IN_SBL_CSS,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: Hi Florian, that's been quite a bit. Thank you for putting this together so comprehensively and thoughtfully, with examples and background! Note many of my points are suggestions or questions, especially if phrased as questions or using maybe or similar, so for your consideration. On Fri, 2 Feb 2024, Florian Weimer wrote: > htdocs/gcc-14/porting_to.html | 465 ++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 465 insertions(+) > + > +

Using pointers as integers and vice versa (-Werror=int-conversion)

> +It makes sense to address missing int type, implicit Should this be plural here ("int types") or some adding a word such as "declaration"? Genuine question. > +Some of them will be caused by missing types resulting > +in int, and the default int return type of > +implicitly declared functions. ...resulting in implicit int... or something like that? Not sure how to be phrase it. > +

Note that in some cases, it may be more appropriate to pass the > +address of an integer variable instead of a cast of the variable's > +value. I'd omit the comma here since I don't feel the added emphasis is necessary. (And maybe simply say "In some cases it may..."?) > +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? > +To fix the compilation errors resulting from that, you can add the "To fix compilation errors..." > +appropriate casts, and maybe consider using code void * > +in more places (particularly for old programs that predate the > +introduction of void into the C language). Here I got confused. At first I thought I was reading that void * should be used for cases where void did not exist yet. Now I think I understand: this is about programs where void * was not used since it was not part of the language yet - and the encouragement is to update such old code by using it. If so, how about making the second case void *, too? > +Programs that do not carefully track pointer types are likely to > +contain aliasing violations, so consider building > +with -fno-strict-aliasing as well. I suggest omitting "as well" here. > (Whether the casts > +are written manually or performed by GCC automatically does not make a > +difference in terms of strict aliasing violations.) Here I'd just say "Whether casts are", omitting "the". > +#include <stddef.h> I *think* we may need to use > here instead of plain '>', though I may be wrong. > +To correct this, the callback function should be defined with the > +correct type "To address this ... be defined with the correct type" (To avoid the double "correct"ion.) > +

> +int
> +compare (const void *a1, const void *b1)
> +{
> +  char *const *a = a1;
> +  char *const *b = b1;
> +  return strcmp (*a, *b);
> +}
> +
Great that you include this example here, that really helps! Just why "const void *a1" versus "char *const *a", that is, the different placement of const? And should it be "const void **a1" and similarly for "b1"?? > +As mentioned initially, adding the cast here would not eliminate any > +strict aliasing violation in the implementation of > +the operate function. Really great you are pointing this out explicitly; thank you! > +It may be possible to avoid writing manual casts with > +the -fplan9-extensions options and unnamed ...option... (singular) > +unrelated to the actual objective of the probe. These failed probes > +tend to consistently disable program features and their tests, which > +means that an unexpected probe failure may result in silently dropping > +features. Omit "consistently"? I'm not sure what it adds here. And simplify the second half, something like These failed probes tend to disable program features (and their tests), resulting in silently dropping features. > +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". > +This phenomenon also impacts similar procedures part of CMake, Meson, > +and various build tools for C extension modules of scripting > +languages. "...procedures in CMake..."? > +

> +Autoconf has supported C99 compilers since at least version 2.69 in > +its generic, core probes. (Specific functionality probes may have > +issues addressed in more recent versions.) Versions before 2.69 may > +have generic probes (for example for standard C support) that rely on > +C features that were removed in 1999 and thus fail with GCC 14. "...removed in C99..."? As opposed to compilers removing them in 1999? > +Sources that cannot be ported to standard C can be compiled > +with -fpermissive, -std=gnu89, > +or -std=c89. Despite their names, the latter two options > +turn on support for pre-standard C constructs, too. With the > +-fpermissive options "option" (singular) > +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? > +Not listed here are -Wimplicit-int > +and -Wdeclaration-missing-parameter-type because they > +should be straightforward to address in a code generator. More personal style, I'd say "Not included here..." which makes it more specific to the script as opposed to the overall section. To me at least. :-) > +This section concerns potential future changes related to language > +features from the C standard and other backwards compatibility > +hazards. These plans may change and are mentioned here only to give > +guidance which source-level changes to prioritize for future compiler > +compatibility. "compiler compatibility" or "standards compatibility"? Maybe just "compatibility"? > +

> +It is unclear at which point GCC can enable the C23 bool > +keyword by default (making the bool type available > +without including #include <stdbool.h> explicitly). Does C every include some header files implicitly? If not, I'd omit "explicitly" above. > +Many programs define their own bool types, sometimes with > +a different size of the already-available _Bool type. "different size than" And "already available" or maybe "built-in"? For the benefit of the doubt: Okay, and thank you, modulo feedback from Jonathan and my two responses. Gerald