On Tue, 24 May 2022, Marek Polacek via Gcc-patches wrote: > > 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.
I think something like how c99status.html lists wide character library support is appropriate for the Notes (so along the lines of "Library feature, no compiler support required. GCC doesn't have %wN, %wfN format checking support."). > > 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. I think the approach taken in c99status.html - list the version where there is substantial support so code written with the new syntax will generally work - is appropriate as regards the choice of version number to list. So that would list GCC 4.3 as the version with DFP support (i.e. the entry for TS 18661-2 integration - I don't think listing all the TS 18661 parts in a single row is right). And then it might be marked as partially implemented. And the Notes would say (in some order) that (a) support based on TR 24732-2009 may not have been fully updated to C2X requirements, (b) both language and library features are involved, and library support is in libdfp (link to libdfp) but might not be complete, (c) there are issues with correct rounding of conversions between binary and decimal DFP in some cases (link to bugs 97635, 105669), and issues with exceptions and rounding modes similar to those that apply with binary floating point, (d) DFP is only supported for a few architectures. (I don't think the versions in which I made -std=c2x -pedantic allow DFP features need to be mentioned at all.) > > > + <tr> > > > + <td>Binary literals</td> > > > + <td><a > > > href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2549.pdf";>N2549</a></td> > > > + <td class="supported"><a href="../gcc-11/changes.html">GCC > > > 11</a></td> > > > + <td></td> > > > + </tr> > > > > 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. Following the same principle as c99status.html for chosing versions to list says that the version number should be listed as GCC 4.3. > > 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 :/. (In the case of typeof, "partially implemented" is probably right anyway, simply because of the remove_quals variant in C2x (for which there is a proposal of renaming to be considered in July). And then note that typeof itself, with some semantic differences, but not remove_quals, was implemented in GCC 1.21 or before - similar to how c99status.html handles complex numbers, noting that __complex__ was supported in GCC 2.5 but _Complex not until GCC 3.0 which is the version listed in the version column there.) > 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. I don't object to having non-features listed as N/A, but I think you'll have a lot of rows like that. Library features (that don't need compiler support) should be explicitly noted as such when marking them as N/A. I have rough notes on C2x features needing implementing in GCC and glibc (sorted approximately by the relevant commits in the (private) C standard git repository), but that isn't a straightforward checklist intended to be more widely comprehensible or to map to corresponding PRs, includes cases of possible future improvements not actually needed to consider a feature implemented, and doesn't distinguish whether something needs implementing in GCC, glibc or both. -- Joseph S. Myers jos...@codesourcery.com
