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.129.124]) by sourceware.org (Postfix) with ESMTPS id BDF5A3857BB0 for ; Tue, 24 May 2022 22:31:08 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org BDF5A3857BB0 Received: from mail-qk1-f198.google.com (mail-qk1-f198.google.com [209.85.222.198]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-505-n0bCHVEbN1WCKoycFXZB5A-1; Tue, 24 May 2022 18:31:06 -0400 X-MC-Unique: n0bCHVEbN1WCKoycFXZB5A-1 Received: by mail-qk1-f198.google.com with SMTP id o13-20020a05620a0d4d00b0069f47054e58so14453231qkl.13 for ; Tue, 24 May 2022 15:31:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=6KlbR1MsS8YxrRTY+t9hi+royaX+BWnk1usl7JiwAfk=; b=BbQjH309eqW2GNwgl9HLfuLPCxVGN8q4U6A/t7zismNghAblh2eZ1bETvwlcUz20VY F2/8rTiscPzQa9ToWBWHH8+CUoqbuOnwjKGzsTSDd6REM957NhYscfWPgsL+Xp5GDgXT 2jv/GpxvJRYElXNEOIj9kkQZRlelQ81K3I2j0kixq5gJ/9MSAmpf1yUo3TukzKBQ6O7t jRV0ABTSQ7nRmAf9mkbX67yoDn3EqzaKRdbm/C8+itMsX/4mUl2nfYP1+SgNQ0F19yJ3 MvLsHBlE7yzY44T1y55SHO9V7I0G7x76NGoZbIZcmIZSFgklMqyp9RfM/nMiyL5cL7ok l5UA== X-Gm-Message-State: AOAM532M0OdJNbwXNm+j7J9o1gSHlYS0lAEScBFqu4p0KN3wvtzMeQjM TUC7ZPvgw8n91CsdpjDLzxPgB/vbjSKEDgMyP54YfsNpiL4GcE18Kp9BscHOTQb/eEcjoMk9Ig0 9+Hq5HyCM9RhZojx8Bg== X-Received: by 2002:a05:622a:313:b0:2f3:b9a1:dd4a with SMTP id q19-20020a05622a031300b002f3b9a1dd4amr22724171qtw.536.1653431465810; Tue, 24 May 2022 15:31:05 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyhVgf9bg+D5YjY+HRSxd+X1pLt1PePC6qi7N96qyFg/5jbgHVQxKeO4z6rvaooK6IBtxUawg== X-Received: by 2002:a05:622a:313:b0:2f3:b9a1:dd4a with SMTP id q19-20020a05622a031300b002f3b9a1dd4amr22724151qtw.536.1653431465442; Tue, 24 May 2022 15:31:05 -0700 (PDT) Received: from redhat.com ([2601:184:4780:4310::9979]) by smtp.gmail.com with ESMTPSA id cm21-20020a05622a251500b002f39b99f67csm344613qtb.22.2022.05.24.15.31.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 24 May 2022 15:31:04 -0700 (PDT) Date: Tue, 24 May 2022 18:31:02 -0400 From: Marek Polacek To: Joseph Myers Cc: GCC Patches Subject: Re: [wwwdocs] Add C status page Message-ID: References: MIME-Version: 1.0 In-Reply-To: User-Agent: Mutt/2.2.1 (2022-02-19) X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, score=-7.0 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, KAM_SHORT, RCVD_IN_DNSWL_LOW, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2022 22:31:10 -0000 On Tue, May 24, 2022 at 06:11:09PM +0000, Joseph Myers wrote: > On Tue, 24 May 2022, Marek Polacek via Gcc-patches wrote: > > > I thought it'd be nice to have a table that documents our C support > > status, like we have https://gcc.gnu.org/projects/cxx-status.html for C++. > > We have https://gcc.gnu.org/c99status.html, but that's C99 only. > > > > So here's a patch to add just that. For C99, I used c99status.html but > > added paper numbers (taken from https://clang.llvm.org/c_status.html). > > For C11, see https://gcc.gnu.org/wiki/C11Status (note: I haven't checked > the accuracy of that page). Ah, nice (I almost never use our wiki). One more reason to have a single place for such overviews. > Listing in terms of features is more useful than listing in terms of > papers. Referring to the original paper, even if it's the version that > got accepted into the standard, is liable to be actively misleading to > anyone working on the implementation; sometimes the paper has multiple > choices of which only one was accepted into the standard, or only some of > the listed changes were accepted, or there were various subsequent > features or fixes from various subsequent papers. Right, so I think it would make sense to have one line for a feature, and add related papers to the second column, as we do in the C++ table: https://gcc.gnu.org/projects/cxx-status.html (see e.g. concepts). > (By way of example, it > would make more sense to list _BitInt as a single entry for a missing > feature than to separately list N2763 and N2775 (accepted papers), while > N2960, to be considered at the July meeting of WG14, makes further wording > fixes but can't exactly be considered a feature in a sense that should be > listed in such a table.) OK, so I think we should have one feature ("_BitInt") and have those three papers in the "Proposal" column. > Lots of papers are just cleanups, or > clarification of wording, or fixes to issues with previous papers, such > that it doesn't make sense to list them as implemented or not at all. For those either we could say "N/A" (gray color), or not mention them at all, though I'd perfer the former. > As usual there are also cases where a feature is implemented to the extent > relevant for conformance but e.g. more optimizations (such as built-in > functions) could be added. Notes like these could go to the "Notes" column. > And cases where some support in GCC should > definitely be done to consider the feature implemented, even when not > needed for conformance (e.g. the %wN, %wfN printf/scanf formats need > implementing in glibc, and corresponding format checking support needs > implementing in GCC). These could be marked as "partially implemented" (yellow color). Except I often don't know which features need extensions like that. > There are also cases where a feature is > substantially there but a more detailed review should be done for how it > matches up to the standard version (e.g. the DFP support based on TR > 24732-2009 could do with such a detailed review for how it matches C2x > requirements). Indeed, and that's a hard problem. I for one could never figure out this one. So I'd leave it in the "?" (red color) state. > > + > > + Binary literals > > + N2549 > > + GCC 11 > > + > > + > > This is an example of cases where the version where a feature was > supported in GCC as an extension is long before the version where > -pedantic knows about it being supported in a given standard version; > listing the version with the -pedantic change in such cases may not be > very helpful without noting when it was originally implemented. Probably here we could just say "Yes" (green color) and make a note in the "Notes" column. > There are > probably other examples in the list. (There are also examples where GCC > supports the feature but hasn't yet had -pedantic updated accordingly, > e.g. #warning. And cases where it's largely supported but there are small > differences in the standard version that still need implementing, e.g. > typeof.) Yeah, I bet. It's tricky to decide :/. > > + > > + What we think we reserve > > + N2572 > > + ? > > + > > + > > This is an example of the many cases where it doesn't make sense to > consider something as a feature with an "implemented" or "not implemented" > state at all - so it doesn't belong in such a table at all. There are > many other such examples in the list. Maybe it's just me, but I find some value in having proposals like that in the table too (but it should be "N/A" and gray). This is what I did for N2641. What I like about having a table like this is that it makes it clear what remains to be implemented, and unimplemented features have a linked PR, which makes it easy to see if someone is already planning to implement the feature, or if it still unassigned. Please let me know if you (dis)agree and I can give this another shot (using your notes you provided in the other email). Thanks, Marek