C23 status on cppreference

[Jakub Jelinek via Gcc]

Hi!

https://en.cppreference.com/w/c/compiler_support
has a table with compiler support for C23.
I've added #embed and [[unsequenced]]/[[reproducible]] in there
yesterday, but am wondering about the accuracy of the rest.

Given the switch to -std=gnu23 preparation, I wonder what is still
unimplemented in GCC 15.
The cppreference page mentions as unimplemented on the GCC side
N2653 - Type change of u8 string literals
and as only partially implemented
N2341 - IEEE 754 decimal floating-point types
N2601 - IEEE 754 interchange and extended types
N2900 - Empty initializers
N2934 - New spelling of keywords
N3033 - __VA_OPT__
with following comments in the wiki source:
N2341: Only TR 24732 mentioned; some requirements in core language missing
N2601: Only TS 18661-3 mentioned; the status of conformance is unknown
N2900: missing support for scalars and VLAs

Are some of the papers/features known to be fully implemented (since which
version)?  E.g. for __VA_OPT__ I remember doing (and Jason too) various fixes
in the past few years, like PR89971, PR103415, PR101488.  Not really sure
what exactly C23 requires.

Jakub

Re: [RFC] Enabling SVE with offloading to nvptx

[Richard Biener via Gcc]

On Tue, 15 Oct 2024, Prathamesh Kulkarni wrote:

> Hi,
> Testing libgomp with SVE enabled (-mcpu=generic+sve2), results in ~60 
> UNRESOLVED errors with following error message:
> 
> lto1: fatal error: degree of 'poly_int' exceeds 'NUM_POLY_INT_COEFFS'
> compilation terminated.
> nvptx mkoffload: fatal error: 
> ../../install/bin/aarch64-unknown-linux-gnu-accel-nvptx-none-gcc returned 1 
> exit status
> compilation terminated. 
> 
> This behaviour can be reproduced with the following simple test-case with 
> -fopenmp -foffload=nvptx-none -mcpu=generic+sve2:
> 
> #define N 1000
> int main ()
> {
>   int i;
>   int A[N] = {0}, B[N] = {0};
> 
>   #pragma omp target map(i), map(tofrom: A), map(from: B)
>   #pragma omp simd
>   for (i = 0; i < N; i++)
> A[i] = A[i] + B[i];
>   return A[0];
> }
> 
> omplower pass lowers the above loop to the following:
> 
> D.4576 = .GOMP_USE_SIMT ();
> if (D.4576 != 0) goto ; else goto ;
> :
> {
>   unsigned int D.4586;
>   unsigned int D.4587;
>   int D.4588;
>   void * simduid.5;
>   void * .omp_simt.6;
>   int D.4596;
>   _Bool D.4597;
>   int D.4598;
>   unsigned int D.4599;
>   int D.4600;
>   int D.4601;
>   int * D.4602;
>   int i [value-expr: D.4588];
>   int i.0;
> 
>   simduid.5 = .GOMP_SIMT_ENTER (simduid.5, &D.4588);
>   .omp_simt.6 = .GOMP_SIMT_ENTER_ALLOC (simduid.5);
>   D.4587 = 0;
>   i.0 = 0;
>   #pragma omp simd safelen(32) _simduid_(simduid.5) _simt_ 
> linear(i.0:1) linear(i:1)
>   for (i.0 = 0; i.0 < 1000; i.0 = i.0 + 1)
>   ...
> }
> goto ;
> :
> {
>   unsigned int D.4603;
>   unsigned int D.4604;
>   int D.4605[0:POLY_INT_CST [15, 16]];
>   void * simduid.7;
>   unsigned int D.4612;
>   int * D.4613;
>   int D.4614;
>   int i [value-expr: D.4605[D.4604]];
>   int i.0;
> 
>   D.4604 = 0;
>   i.0 = 0;
>   #pragma omp simd safelen(POLY_INT_CST [16, 16]) 
> _simduid_(simduid.7) linear(i.0:1) linear(i:1)
>   ...
>  }
>  :
>  ...
> 
> For offloading to SIMT based device like nvptx, scan_omp_simd duplicates 
> lowering of simd pragma into if-else where the if-part contains simt 
> code-path,
> and else-part contains simd code-path. In lower_rec_simd_input_clauses, 
> max_vf is set to 16+16x for the above case as determined by omp_max_vf,
> and that becomes length of the omp simd array:
> int D.4605[0:POLY_INT_CST [15, 16]];
> 
> The issue here is that, the function containing above if-else condition gets 
> streamed out to LTO bytecode including the simd code-path and the omp simd 
> array, 
> whose domain is [0:POLY_INT_CST[15, 16]], and thus we get the above error 
> while streaming-in POLY_INT_CST in lto_input_ts_poly_tree_pointers on device 
> side.
> 
> Note that, the simd code-path is essentially dead-code on nvptx, since 
> .GOMP_USE_SIMT() resolves to 1 during omp_device_lower pass, and later 
> optimization passes (ccp2)
> remove the dead-code path and unused omp simd arrays while compiling to 
> device. So in this case, we aren't really mapping POLY_INT_CST from host to 
> device,
> but it gets streamed out to device as an artefact of omp simd lowering.
> 
> I suppose a proper fix here would be to (somehow) defer lowering of omp 
> pragma simd after streaming out to device, so the device only sees simt 
> code-path,
> and the host only sees simd code path ? Or perhaps clone each function in 
> offload region, one for host and one for SIMT device, and only stream the 
> device versions
> to avoid streaming out host-specific IR changes ?

There is currently no way to have the host compiler query offload target
capabilities so the only true fix is to delay OMP SIMD lowering to the
target.

Are we dependent on the early optimization pipeline being run on the
host to produce the offload IL?  There's some oddball OACC passes
in pass_ipa_oacc.

That said, I'd probably try to produce clones with unlowered IL and
skip those clones from all processing from that point and resume in
the offload compiler.

> I thought of following approaches as workarounds:

I don't think any workaround will fly in the end.  Can't you simply force
SVE to be off for offload clones on the host side and force OMP lowering
with ADVSIMD only?

Richard.

> [1] Set sctx.max_vf to constant_lower_bound(omp_max_vf ()) in 
> lower_rec_simd_input_clauses, if the function is going to

Re: [RFC] Return Value Propagation in IPA-CP

[Martin Jambor]

Hello,

first and foremost, sorry for a late reply.  I needed to take a larger
leave of absence for family reasons.

Comments inline:

On Thu, Aug 22 2024, Dhruv Chawla via Gcc wrote:
> * Table Of Contents *
>
> - Introduction
> - Motivating Test Cases
> - Proposed Solution
> - Other Options
> - Existing Solutions
> - Primary Optimizations To Be Improved
> - Front-End Attribute For Recording Return-Value Information
> - Future Work
> - References
> - Questions
>
> * Introduction *
>
> Return jump functions offer a way of modeling return values of a function in
> terms of its formal parameters, similar to how regular jump functions can be
> used to model the actual parameters of a callee at a callsite in terms of the
> formal parameters of the caller.
>
> By discovering this information and propagating it across the program 
> callgraph
> in LTO mode, various transformations like value-range propagation, 
> sibling-call
> and chaining-call optimization can be augmented to take advantage of it and
> potentially perform better optimizations.
>
> Currently, ipa-cp models parameters using jump functions, propagates the 
> values
> of those jump functions by iterating to a fixed-point using lattices, and
> clones functions by taking decisions from those lattice values.
>
> We propose extending ipa-cp with the analysis and propagation of return jump
> functions, starting with the basic case of a direct return of the form
> "return x;" where "x" is any formal parameter of the function.
>
> * Motivating Test Cases *
>
> * Optimizing tail calls:
>
> - PR92867
>
> char buf[128] = { 1 };
>
> char *foo (__SIZE_TYPE__ n)
> {
>return __builtin_memset (buf, ' ', n);
> }
>
> char *bar (__SIZE_TYPE__ n)
> {
>__builtin_memset (buf, ' ', n);
>return buf;
> }
>
> Here, the call to __builtin_memset in foo gets successfully converted to a
> tail-call, however the call in bar cannot be optimized to a tail-call. This is
> an optimization that LLVM is able to perform.
>
> Link to compiler explorer: https://godbolt.org/z/E81axqWTb
>
> - PR67797
>
> #include 
>
> void *my_func(void *s, size_t n)
> {
>  memset(s, 0, n);
>  return s;
> }
>
> This is a similar case to the above example. LLVM is able to optimize the call
> to memset to be a tail-call as well.
>
> Link to compiler explorer: https://godbolt.org/z/YzjGc59f8
>
> * Optimizing chaining calls:
>
> #include 
>
> void f (int x, int y)
> {
>std::cout << x;
>std::cout << y;
> }
>
> This function can be optimized to the following:
>
> #include 
>
> void f (int x, int y)
> {
>std::cout << x << y;
> }
>
> LLVM is able to perform this optimization as well:
> https://godbolt.org/z/MW75on1o5
>
> * Proposed Solution *
>
> * Extending IPA-CP:
>
> 1. Add return jump function data structures
>- This involves updating ipa_node_params to contain information regarding 
> the
>  return statements of the function, namely the lattice and the jump 
> function
>  describing the return value, where both use existing data structures.
>- The ipa_node_params class is reused to avoid introducing a new class and 
> a
>  corresponding function_summary type, though it is trivial to add if 
> deemed
>  a better solution. The ipa_return_value_summary class may also be a good
>  place for this information, however using it would involve moving it from
>  ipa-prop.cc to ipa-prop.h.

I believe that ipa_return_value_summary should become a member of
ipa_node_params (perhaps we could think of a better name) and
ipa_return_value_sum should be removed.  All infrastructure there is to
create ipa_return_value_summary should be re-used or extended to fulfill
also the new needs.


>- Additionally, ipa_edge_args is updated to track whether or not it is a
>  callgraph edge originating from a return statement. This enables the
>  propagation of information in the WPA phase.

I don't understand.  I have read your reply to Honza to his question
about this and I still don't understand what you mean by this.

I believe we want to have a return function for each call graph edge,
certainly for each one that calls a non-void function.

>
> 2. LGEN
>- Set up return jump functions for each function similar to the parameter
>  jump function. When it cannot be conclusively determined that one formal
>  parameter is always returned (such as conditionally returning either of
>  two), the jump function is marked as invalid.

I think we should have it for each function.  And it should not be
similar but rather exactly the same thing, capable of recording the fact
that we always return a constant or holding "arithmetic" jump functions.

Since I assume that at least initially we do not want to create
aggregate jump functions, we may want to split ipa_jump_func to a scalar
part and the aggregate part.  But perhaps not really, the memory
overhead is unlikely to be worth it.

>- This involves looking through phi nodes when return statements of
>   

Re: C23 status on cppreference

[Joseph Myers via Gcc]

On Wed, 16 Oct 2024, Jakub Jelinek via Gcc wrote:

> The cppreference page mentions as unimplemented on the GCC side
> N2653 - Type change of u8 string literals

commit 703837b2cc8ac03c53ac7cc0fb1327055acaebd2
Author: Tom Honermann 
Date:   Tue Aug 2 14:36:01 2022 -0400

C: Implement C2X N2653 char8_t and UTF-8 string literal changes

> and as only partially implemented
> N2341 - IEEE 754 decimal floating-point types

Various -pedantic and fixes done to reflect these being standard e.g.

commit 04a9b8d2f38573d0527edeea9e4fd9b7dfdc7983
Author: Joseph Myers 
Date:   Thu Oct 14 20:56:29 2021 +

c-family: Support DFP printf/scanf formats for C2X

commit f8e4c55cbc09fbbe136b2ba2da405d7bdced07ae
Author: Joseph Myers 
Date:   Tue Nov 17 00:27:06 2020 +

float.h: C2x decimal signaling NaN macros

commit 175a85b29718141d73230ed19efcfcf963a0d0b6
Author: Joseph Myers 
Date:   Fri Oct 11 23:22:52 2019 +0100

Support decimal floating-point constants in C2x.

commit fe2bc27cdb6d572da0163d77e787ba644b400753
Author: Joseph Myers 
Date:   Fri Oct 11 18:32:48 2019 +0100

Support _Decimal* keywords for C2x.

> N2601 - IEEE 754 interchange and extended types

C23 follows TS 18661-3 (support added in GCC 7).  There was a late 
-pedantic fix:

commit 80acabb6dd05090db67805cdd358fe974b45e2ed
Author: Jakub Jelinek 
Date:   Wed Sep 6 08:51:00 2023 +0200

c: Don't pedwarn on _FloatN{,x} or {f,F}N{,x} suffixes for C2X

But as a general principle, I think we should consider and externally 
document a feature as done in some GCC version if all the main pieces of 
that feature are available to users - rather than only declaring it to be 
done when every known corner case is fixed and all the -pedantic 
diagnostics are right.  That's the principle followed for the version 
numbers listed in c99status.html for C99 features.

We *don't* support the DFP parts of Annex H / TS 18661-3 (_Decimal64x 
type, dN / DN / dNx / DNx literal suffixes, etc.).

> N2900 - Empty initializers

GCC 13, like many C23 features.

commit 14cfa01755a66afbae2539f8b5796c960ddcecc6
Author: Joseph Myers 
Date:   Thu Aug 25 21:02:57 2022 +

c: Support C2x empty initializer braces

> N2934 - New spelling of keywords

commit 0a91bdaf177409a2a5e7895bce4f0e7091b4b3ca
Author: Joseph Myers 
Date:   Wed Sep 7 13:56:25 2022 +

c: New C2x keywords

> N3033 - __VA_OPT__

Implemented some time ago, and WG14 made sure to follow the same semantics 
as C++.  The -pedantic fix was

commit ce53cf7b61ea6bce05570e2fd1f8c10eee308ab0
Author: Joseph Myers 
Date:   Wed Dec 7 19:18:06 2022 +

preprocessor: Enable __VA_OPT__ for C2x



We do still need to update the documentation of implementation-defined 
behavior for C23, but that can't be done until C23 is actually published 
and we know the final subclause numbers (there were many subclause 
numbering changes since the last public working draft).  Other 
C23-relevant things such as making __int128 fully an integer type (bug 
113887, involves both compiler and library pieces) are properly optional.  
_BitInt support isn't optional (at least up to 64 bits), target 
architecture maintainers need to be chased up about adding support to 
their ABIs and back ends to get it done across more architectures.



Regarding the question of how we should document the status of support for 
standard features in GCC:

Marek posted a patch 
 trying to 
describe things by reference to WG14 paper numbers.  My overall objection 
 was that 
the list should be in a *user-oriented* arrangement rather than one 
oriented to the minutiae of how changes were added to the standard over a 
series of papers: it should list the actual features at the level of a 
language user, as in c99status.html, and describe what is implemented in 
terms of those features.  See also the rest of that thread.  The following 
is based on what I wrote off-list to Marek in February (but updated) - 
note I think user-oriented information covering glibc together with GCC 
makes sense rather than just ignoring library features:

Take the lists of logical features for C11 and C23 from Annex M in latest 
working draft.  Right now that's N3301.  Warning, that C2Y draft includes 
changes that *weren't* approved relating to imaginary literals as a git 
branch was wrongly merged with a mixture of approved and unapproved 
changes (a substantially different version was accepted in Minneapolis).  
So don't rely on it as reflecting the actual pre-Minneapolis C2Y accepted 
content, but for changes in older standard versions it's a reasonable 
source.  (In the private C standard git repository Annex M now has a more 
complete list of accepted changes in C2Y pre-Minneapolis, with many other 
mistakes in integration of those papers fixed - though there are several 
other pre-Minneapolis issues with merge requests to fix t

Re: Question about creating clones of ipcp clones

[Martin Jambor]

Hello,

On Wed, Sep 11 2024, Prachi Godbole via Gcc wrote:
> Hi,
>
> I am trying to generate out-of-line clones of ipcp clones for an IPA
> pass that runs after IPA inline, where the new clone has same function
> body and same updated signature as the ipcp clone. This fails or
> asserts based on how the clone is created:
>

Dealing with param_adjustements post-inlining might be a bit interesting
but hopefully not too much(?).  It is difficult to see what exactly the
issues you are facing might be but perhaps pass_ipa_sra, though it runs
before inlining, could be an inspiration because it also can create
clones of IPA-CP clones.

> 1. If param_adjustments and tree_map are not provided:
> fails in clone materialization (tree_function_versioning ()) when 
> updating signature and remapping calls because clone_of (i.e. ipcp clone) and 
> the new clone differ in param information, or
>
> 2. If param_adjustments and tree_map are provided:
> asserts in fnsummary duplication
>
> What are the possible approaches to make it work?
>

I'm not sure I can help knowing just the above.  Can you post the
back-traces?  But as I said, looking at how process_isra_node_results in
ipa-sra.cc deals with pre-existing clone_info might be the best thing to
look at.

Martin

Linaro CI new feature: skip precommit testing

[Christophe Lyon via Gcc]

Hi,

Following "popular request", we are happy to announce that users can
now request to skip Linaro CI precommit testing for some patches.

The current implementation skips testing in two cases:
1- there is [RFC] or [RFC v[0-9]] in the patch subject
2- the commit message contains a line starting with 'CI-tag: skip'

[1] Enables to avoid undesirable regression notifications when one
sends an incomplete patch to start discussing ideas.

[2] Aims at helping workflows where people submit patches for "master
files" and "regenerated files" as two patches to make review easier.
In such cases, the patch with only "master files" changes would
generally generate regression notifications, confusing both reviewers
and patch authors.  For instance:
- patch #1/3: introduce new code -> should pass CI
- patch #2/3: changes to "master files" -> skip CI
- patch #3/3: changes to "regenerated files" -> should pass CI


This change does NOT affect postcommit CI, where CI is always expected
to pass (otherwise regression notifications will be generated).


Technically, we use 'git am --keep' when applying the patches, so
that subject lines are untouched: this enables us to handle
standard markers such as [PATCH RFC] or [RFC PATCH] for instance.

This also means that a 'CI-tag: skip' after the usual '---' lines
will be ignored (git-am will consider it as part of the patch,
rather than the commit message).

People used to git am --scissors may find it convenient to put
the tag at the start of the commit message:

CI-tag: skip
-- >8 --
=

But it's fine to put that tag along with other tags (such as
Signed-Off-By, Co-authored-by, ...)

We hope this will be useful / helpful.

Thanks,

The Linaro Toolchain team.

Re: C23 status on cppreference

[Martin Uecker via Gcc]

Am Mittwoch, dem 16.10.2024 um 13:27 +0200 schrieb Jakub Jelinek via Gcc:
> Hi!
> 
> https://en.cppreference.com/w/c/compiler_support
> has a table with compiler support for C23.
> I've added #embed and [[unsequenced]]/[[reproducible]] in there
> yesterday, but am wondering about the accuracy of the rest.
> 
> Given the switch to -std=gnu23 preparation, I wonder what is still
> unimplemented in GCC 15.
> The cppreference page mentions as unimplemented on the GCC side
> N2653 - Type change of u8 string literals
> and as only partially implemented
> N2341 - IEEE 754 decimal floating-point types
> N2601 - IEEE 754 interchange and extended types
> N2900 - Empty initializers
> N2934 - New spelling of keywords
> N3033 - __VA_OPT__
> with following comments in the wiki source:
> N2341: Only TR 24732 mentioned; some requirements in core language missing
> N2601: Only TS 18661-3 mentioned; the status of conformance is unknown
> N2900: missing support for scalars and VLAs

N2900 should be supported since 13.1

Martin

> 
> Are some of the papers/features known to be fully implemented (since which
> version)?  E.g. for __VA_OPT__ I remember doing (and Jason too) various fixes
> in the past few years, like PR89971, PR103415, PR101488.  Not really sure
> what exactly C23 requires.
> 
>   Jakub
> 

Re: Is -Wtraditional obsolete?

[Sam James via Gcc]

Joseph Myers via Gcc  writes:

> One issue that showed up as test failures with a default of -std=gnu23 is 
> that -std=gnu23 -Wtraditional produces a "traditional C rejects ISO C 
> style function definitions" warning for function definitions with empty 
> parentheses, as they are treated like (void) in C23, so resulting in 
> failure of several -Wtraditional tests.
>
> Clearly that's a bug (that warning should only be given for literal 
> (void), not for () meaning (void)) and wouldn't be hard to fix.  But is 
> there actually any current use for the -Wtraditional option?  It seems 
> extremely unlikely now that compatibility with pre-C89 compilers would be 
> relevant.  So maybe it would make more sense to remove -Wtraditional 
> support (remove all the logic implementing the option, make it an option 
> marked with Ignore in c.opt to do nothing so as not to break any build 
> systems that hardcode this option) rather than fixing this bug with an 
> option that's probably no longer useful.

Given the other messages in the thread, I'd like to share some anecdotal
data:
* I see 0 instances of -Wtraditional appearing in my cache of build
logs;

* I see 0 non-trivial (e.g. comments or bundled autoconf macros)
references to -Wtraditional in my collection of repositories;

* There are some, but not many, references on Debian code search:
  .
  
  Note that a chunk of the references are the kind of macros I
  mentioned, copies of GCC, or NEWS/ChangeLogs;
  
* Not to say that such warnings are useless to ever attempt, but people
  who need compatibility with such compilers should really test with
  them anyway, so this is merely a convenience thing. It's not like it
  actually guarantees such compilers will work (to give another example,
  -std=gnu89 still lets you use headers which weren't in C89).

Re: Is -Wtraditional obsolete?

[Eli Zaretskii via Gcc]

> Date: Wed, 16 Oct 2024 17:12:29 + (UTC)
> From: Joseph Myers via Gcc 
> 
> One issue that showed up as test failures with a default of -std=gnu23 is 
> that -std=gnu23 -Wtraditional produces a "traditional C rejects ISO C 
> style function definitions" warning for function definitions with empty 
> parentheses, as they are treated like (void) in C23, so resulting in 
> failure of several -Wtraditional tests.
> 
> Clearly that's a bug (that warning should only be given for literal 
> (void), not for () meaning (void)) and wouldn't be hard to fix.  But is 
> there actually any current use for the -Wtraditional option?  It seems 
> extremely unlikely now that compatibility with pre-C89 compilers would be 
> relevant.  So maybe it would make more sense to remove -Wtraditional 
> support (remove all the logic implementing the option, make it an option 
> marked with Ignore in c.opt to do nothing so as not to break any build 
> systems that hardcode this option) rather than fixing this bug with an 
> option that's probably no longer useful.

Please don't remove the support for -Wtraditional if it's easy to fix.
Removing it runs risk of breaking someone's program, so unless keeping
it is a real dumper on GCC development, I hope you will keep it.

Re: C23 status on cppreference

[Florian Weimer]

* Jakub Jelinek via Gcc:

> Are some of the papers/features known to be fully implemented (since which
> version)?  E.g. for __VA_OPT__ I remember doing (and Jason too) various fixes
> in the past few years, like PR89971, PR103415, PR101488.  Not really sure
> what exactly C23 requires.

Can we add a warning if bool is defined to anything that isn't _Bool
(either as a macro or as a type)?  If we are serious about switching
to C23 by default, I think that warning needs to be enabled by
default, due to the ABI impact.

Re: Is -Wtraditional obsolete?

[Joseph Myers via Gcc]

On Wed, 16 Oct 2024, Eric Gallager via Gcc wrote:

> One thing about -Wtraditional is that it enables a lot of different
> messages, so I always thought it would make more sense as an umbrella
> warning that just enables a bunch of sub-warning flags. While many of
> the individual sub-warnings may no longer be relevant, some of them
> might still be useful for reasons besides compatibility with
> traditional C.

A few are also controlled by other options (I'm not proposing doing 
anything with -Wtraditional-conversion or -Wlong-long, for example).  I 
don't think any of the others are likely to be of use.

"non-static declaration of %q+D follows static declaration"
"traditional C lacks a separate namespace for labels, identifier %qE conflicts"
"traditional C rejects ISO C style function definitions"
"traditional C rejects string constant concatenation"
"traditional C rejects the unary plus operator"
"traditional C rejects automatic aggregate initialization"
"traditional C rejects initialization of unions"
"% switch expression not converted to % in ISO C"
"the meaning of %<\\%c%> is different in traditional C"
"the meaning of %<\\x%> is different in traditional C"
"the meaning of %<\\a%> is different in traditional C"
"suggest not using %<#elif%> in traditional C"
"traditional C ignores %<#%s%> with the %<#%> indented"
"suggest hiding %<#%s%> from traditional C with an indented %<#%>"
"traditional C rejects the %<%.*s%> suffix"
"function-like macro %qs must be used with arguments in traditional C"
"macro argument %qs would be stringified in traditional C"

If someone thinks one of these is desirable as a coding style warning 
without regard for traditional C, please explain why.  Or if you do have 
code you'd like to build with both GCC 15 or later, and a pre-C89 
compiler, please give details.  Such details are much more relevant than 
pure speculation that maybe something could be of use to someone.

-- 
Joseph S. Myers
josmy...@redhat.com

Re: Is -Wtraditional obsolete?

[Eric Gallager via Gcc]

On Wed, Oct 16, 2024 at 2:52 PM Arsen Arsenović via Gcc  wrote:
>
> Eli Zaretskii via Gcc  writes:
>
> > Please don't remove the support for -Wtraditional if it's easy to fix.
> > Removing it runs risk of breaking someone's program, so unless keeping
> > it is a real dumper on GCC development, I hope you will keep it.
>
> ISTM that it is proposed to ignore rather than reject Wtraditional, and
> as a warning option, it should be incosequential to parsing and codegen,
> so risk of breakage is minimal or nonexistent, save for the change in
> workflow caused by it not being effective.
> --
> Arsen Arsenović

One thing about -Wtraditional is that it enables a lot of different
messages, so I always thought it would make more sense as an umbrella
warning that just enables a bunch of sub-warning flags. While many of
the individual sub-warnings may no longer be relevant, some of them
might still be useful for reasons besides compatibility with
traditional C.

Re: Is -Wtraditional obsolete?

[Eric Gallager via Gcc]

On Wed, Oct 16, 2024 at 4:29 PM Joseph Myers  wrote:
>
> On Wed, 16 Oct 2024, Eric Gallager via Gcc wrote:
>
> > One thing about -Wtraditional is that it enables a lot of different
> > messages, so I always thought it would make more sense as an umbrella
> > warning that just enables a bunch of sub-warning flags. While many of
> > the individual sub-warnings may no longer be relevant, some of them
> > might still be useful for reasons besides compatibility with
> > traditional C.
>
> A few are also controlled by other options (I'm not proposing doing
> anything with -Wtraditional-conversion or -Wlong-long, for example).  I
> don't think any of the others are likely to be of use.
>
> "non-static declaration of %q+D follows static declaration"
> "traditional C lacks a separate namespace for labels, identifier %qE 
> conflicts"
> "traditional C rejects ISO C style function definitions"
> "traditional C rejects string constant concatenation"
> "traditional C rejects the unary plus operator"
> "traditional C rejects automatic aggregate initialization"
> "traditional C rejects initialization of unions"
> "% switch expression not converted to % in ISO C"
> "the meaning of %<\\%c%> is different in traditional C"
> "the meaning of %<\\x%> is different in traditional C"
> "the meaning of %<\\a%> is different in traditional C"
> "suggest not using %<#elif%> in traditional C"
> "traditional C ignores %<#%s%> with the %<#%> indented"
> "suggest hiding %<#%s%> from traditional C with an indented %<#%>"

This is one of the things I tested when adding gcc.dg/pragma-diag-7.c
in r8-787-g4287da829c9697:
https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=4287da829c9697c58131666447bf8f707bd8b635

> "traditional C rejects the %<%.*s%> suffix"

Some coding style guidelines dislike suffixed constants; for example,
see this passage from GCC's own README.Portability:

Suffixes on Integer Constants
-

You should never use a 'l' suffix on integer constants ('L' is fine),
since it can easily be confused with the number '1'.

> "function-like macro %qs must be used with arguments in traditional C"

This one just makes sense as a style guideline to me, and it would be
good if GCC's own fix-it hint system paid attention to it, as per bug
81419: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81419

> "macro argument %qs would be stringified in traditional C"

This one I added a test for in gcc.dg/pragma-diag-7.c due to having
seen it in real code; see r8-4796-g34b81eb96cd1df:
https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=34b81eb96cd1df28d7f878bc1f3df607746507da

>
> If someone thinks one of these is desirable as a coding style warning
> without regard for traditional C, please explain why.  Or if you do have
> code you'd like to build with both GCC 15 or later, and a pre-C89
> compiler, please give details.  Such details are much more relevant than
> pure speculation that maybe something could be of use to someone.
>
> --
> Joseph S. Myers
> josmy...@redhat.com
>

Re: C23 status on cppreference

[Joseph Myers via Gcc]

On Wed, 16 Oct 2024, Florian Weimer wrote:

> * Jakub Jelinek via Gcc:
> 
> > Are some of the papers/features known to be fully implemented (since which
> > version)?  E.g. for __VA_OPT__ I remember doing (and Jason too) various 
> > fixes
> > in the past few years, like PR89971, PR103415, PR101488.  Not really sure
> > what exactly C23 requires.
> 
> Can we add a warning if bool is defined to anything that isn't _Bool
> (either as a macro or as a type)?  If we are serious about switching
> to C23 by default, I think that warning needs to be enabled by
> default, due to the ABI impact.

In -std=gnu23 mode, defining bool as a typedef will result in an error 
anyway.  (Defining a macro with any of the names alignas, alignof, bool, 
false, static_assert, thread_local, true is undefined behavior in C23, so 
it's certainly OK to diagnose defining such a macro, even as a pedwarn / 
error, if we wish.)

I'm not sure such a warning particularly helps, however; any ABI 
incompatibility occurs at the point where someone changes their code to 
stop defining bool and to use the standard bool instead.  (And any problem 
code would already have been ABI-incompatible with C++.)

Several of the tests I added -std=gnu17 to had their own definitions of 
bool as an enum with values false and true, but I think that comes from 
reduction of preprocessed source from GCC 2.95 (which had such a 
definition, arising from older C9X drafts, in its ) rather than 
being something likely to occur in user code.  I expect "typedef char 
bool;" (or "#define bool char"), and similar with unsigned char, to be 
much more common in applications.

-- 
Joseph S. Myers
josmy...@redhat.com

Re: Is -Wtraditional obsolete?

[Arsen Arsenović via Gcc]

Eli Zaretskii via Gcc  writes:

> Please don't remove the support for -Wtraditional if it's easy to fix.
> Removing it runs risk of breaking someone's program, so unless keeping
> it is a real dumper on GCC development, I hope you will keep it.

ISTM that it is proposed to ignore rather than reject Wtraditional, and
as a warning option, it should be incosequential to parsing and codegen,
so risk of breakage is minimal or nonexistent, save for the change in
workflow caused by it not being effective.
-- 
Arsen Arsenović


signature.asc
Description: PGP signature

Is -Wtraditional obsolete?

[Joseph Myers via Gcc]

One issue that showed up as test failures with a default of -std=gnu23 is 
that -std=gnu23 -Wtraditional produces a "traditional C rejects ISO C 
style function definitions" warning for function definitions with empty 
parentheses, as they are treated like (void) in C23, so resulting in 
failure of several -Wtraditional tests.

Clearly that's a bug (that warning should only be given for literal 
(void), not for () meaning (void)) and wouldn't be hard to fix.  But is 
there actually any current use for the -Wtraditional option?  It seems 
extremely unlikely now that compatibility with pre-C89 compilers would be 
relevant.  So maybe it would make more sense to remove -Wtraditional 
support (remove all the logic implementing the option, make it an option 
marked with Ignore in c.opt to do nothing so as not to break any build 
systems that hardcode this option) rather than fixing this bug with an 
option that's probably no longer useful.

-- 
Joseph S. Myers
josmy...@redhat.com