From patchwork Sun Oct 27 15:45:16 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Joseph Myers X-Patchwork-Id: 286344 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTPS id 264162C00AB for ; Mon, 28 Oct 2013 02:45:39 +1100 (EST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:date :from:to:cc:subject:message-id:mime-version:content-type; q=dns; s=default; b=RrFtQaYSS+0TPSv+5SYPdtx9p9NSBDxb1p3bqJRUtN5N2XEF6Y Fh4BWDIne7CeH+4QoYe+UtlBqZR2RhfNjhe8VnVcNQBZglr9L+qY2h6rG1BaiIcp TGFPCqPN+QmsFtMps67cizlXR3gWxu8CJ9LAiywOIjUPo7ow+4QIGh618= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:date :from:to:cc:subject:message-id:mime-version:content-type; s= default; bh=3HpFqrlPkcvgclQmN+4WNtM/2Ww=; b=b9j2ThExEsbiy+lWJlMO mhPlYYEJg68SPU401yR6rG8fToHEND4mBu8EanTIB164iW+hKYFy9fjO0nKG4gr8 To4a9fCZI5MvJ+G204Fkxisp2Uu6ZYVspzU22lgnadk6szgVNB9W4DjtnzD3IcZf 4n31g3dDv7YSToPEOZATqdY= Received: (qmail 18807 invoked by alias); 27 Oct 2013 15:45:31 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Received: (qmail 18793 invoked by uid 89); 27 Oct 2013 15:45:30 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=AWL, BAYES_00 autolearn=ham version=3.3.2 X-HELO: relay1.mentorg.com Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sun, 27 Oct 2013 15:45:24 +0000 Received: from svr-orw-fem-01.mgc.mentorg.com ([147.34.98.93]) by relay1.mentorg.com with esmtp id 1VaSWm-0002Ib-7p from joseph_myers@mentor.com ; Sun, 27 Oct 2013 08:45:20 -0700 Received: from SVR-IES-FEM-01.mgc.mentorg.com ([137.202.0.104]) by svr-orw-fem-01.mgc.mentorg.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Sun, 27 Oct 2013 08:45:20 -0700 Received: from digraph.polyomino.org.uk (137.202.0.76) by SVR-IES-FEM-01.mgc.mentorg.com (137.202.0.104) with Microsoft SMTP Server id 14.2.247.3; Sun, 27 Oct 2013 15:45:17 +0000 Received: from jsm28 (helo=localhost) by digraph.polyomino.org.uk with local-esmtp (Exim 4.76) (envelope-from ) id 1VaSWi-0003VB-38; Sun, 27 Oct 2013 15:45:16 +0000 Date: Sun, 27 Oct 2013 15:45:16 +0000 From: "Joseph S. Myers" To: CC: Subject: Rework c99status.html Message-ID: MIME-Version: 1.0 GCC's c99status.html seem persistently to confuse people into thinking the state of C99 support is worse than it is, by listing things as "Missing" or "Broken" when in fact what's missing or broken isn't needed to implement C99 but is some optional extra for ideal support, or is only broken or missing on obscure platforms, or only relates to obscure corner cases most users are unlikely to encounter; people also seem to get confused by what "Library Issue" means, despite the explanation above the table. Readers don't generally seem to pay attention to the notes below the table that then explain exactly what is broken or missing for a particular entry. I've committed this patch to rework the page so it starts with a summary of the overall C99 state, then describes each feature by listing the GCC version in which it was substantially supported (not necessarily obscure corner cases), or "N/A" if no compiler support required, with further notes then directly included in the table where reasonable. Hopefully this will be less confusing to readers than the previous version. I think it would be appropriate to redirect all the c99status.html files for particular GCC versions to this file, now it covers all versions. Index: c99status.html =================================================================== RCS file: /cvs/gcc/wwwdocs/htdocs/c99status.html,v retrieving revision 1.59 retrieving revision 1.62 diff -u -r1.59 -r1.62 --- c99status.html 28 Oct 2012 11:05:08 -0000 1.59 +++ c99status.html 27 Oct 2013 15:41:51 -0000 1.62 @@ -7,306 +7,363 @@

Status of C99 features in GCC

+

C99 is substantially completely supported as of GCC 4.5 +(with -std=c99 -pedantic-errors used), modulo bugs, +extended identifiers (supported except for corner cases +when -fextended-identifiers is used), and floating-point +issues (mainly but not entirely relating to optional C99 features from +Annexes F and G). The following table gives more details of the C99 +support in different GCC versions.

+

This table is based on the list in the foreword to N1256 (ISO/IEC 9899:1999 (E), consolidated with ISO/IEC 9899:1999/Cor.1:2001 (E), ISO/IEC 9899:1999/Cor.2:2004 (E) and ISO/IEC 9899:1999/Cor.3:2007 (E)).

-

Where "Library Issue" is listed in conjunction with some other -status, this means that some compiler support is needed for the -library support, or desirable in conjunction with it. Note that the -headers required of conforming freestanding implementations (clause 4 -paragraph 6) do not count as library issues.

- -

This page describes the C99 support in mainline GCC, not in any -particular release. Information is also available on C99 support in GCC 4.7, C99 support in GCC 4.6, C99 support in GCC 4.5, C99 support in GCC 4.4, C99 support in GCC 4.3, C99 support in GCC 4.2, C99 support in GCC 4.1, C99 support in GCC 4.0, C99 support in GCC 3.4, C99 support in GCC 3.3, C99 support in GCC 3.1 and 3.2 and on C99 support in GCC 3.0, but not on -the much more limited support in GCC 2.95.

+

The "Version" column indicates the first GCC version in which +support for the relevant feature was substantially present; some bugs +or corner cases may have been fixed in later versions; this column is +"N/A" if nothing is needed from the compiler for the feature to be +substantially supported (for example, if the feature refers to +addition of new library functions rather than language features), even +if additional compiler features could be useful in conjunction with +it. It is assumed that GCC is used with -std=c99 +-pedantic-errors (for versions 3.0 and later), as well +as -fextended-identifiers in the case of that feature. +Where library cooperation is required, it is assumed that a recent +version of the GNU C Library is in use, and support with other C +libraries may be less good. Where the version listed is before GCC +3.0, it should not be assumed that all corner cases follow C99 before +GCC 3.0, even if there is no specific note regarding corner cases.

See below the table for further notes on some issues.

- - - - + + + <iso646.h> (originally specified in AMD1) + - - - + + - - + + - - + + - - - + + + - + + - - + + + - + + - - + + - - + + - - + + - - - + + + - - + + - + + - + + - + + - - + + - - + + - - + + - - - - - - - + + - - - + + + - - + + - - + + + - + + - - + + + - + + - + + - - + + - - + in <stdio.h> and <wchar.h> + + - - + + - - + + - - - + + + - - + + + - - + + - - + + + - - + + - - + + - - + + - + + - + + - - + + + - + + - + + - + + - - + + - + + - + + - - - + + + - - - + + + + + + + + - - + + - - - + + + - - + + - - + in function that returns a value (and vice versa) + + - - - - - -
FeatureLibrary IssueDoneBrokenMissingVersionNotes
restricted character set support via digraphs and -
<iso646.h> (originally specified in AMD1)		GCC 2.7 Done
wide character library support in - <wchar.h>
and <wctype.h> + <wchar.h> and <wctype.h> (originally specified in AMD1)		Library IssueMissingN/ALibrary feature, no compiler support required. GCC doesn't + have wprintf, wscanf and + wcsftime format checking support.
more precise aliasing rules via effective typeDoneN/AOptimization, no compiler support required. GCC has + optimized based on aliasing rules since GCC 2.95.
restricted pointersDoneGCC 2.95
variable-length arraysDone
variable length arraysGCC 0.9Various corner cases fixed in GCC 4.5.
flexible array membersDoneGCC 3.0
static and type qualifiers
in parameter array declarators		Done
static and type qualifiers in parameter array declaratorsGCC 3.1
complex (and imaginary) support in <complex.h>DoneGCC 3.0New functions are a library issue not requiring much compiler + support (some built-in functions present). Complex numbers are + supported with __complex__ since GCC 2.5, and with + C99 _Complex since GCC 3.0. Complex multiplication + and division support C99 special cases since GCC 4.0. Various + corner cases were fixed in GCC 4.5. GCC does not support the + Annex G imaginary types, but this support is optional, and complex + multiplication and division have excess overflows at runtime + (although not beyond those permitted by C99).
type-generic math macros in <tgmath.h>Library IssueDoneN/ALibrary feature; GCC built-in functions may be used in + implementing it.
the long long int type and library functionsDone≤ GCC 1.27New functions are a library issue not requiring much compiler + support (some built-in functions present).
increased minimum translation limitsDoneGCC 0.9GNU policy has always avoided arbitrary limits.
additional floating-point characteristics
in <float.h>		Done
additional floating-point characteristics in <float.h>GCC 3.0
remove implicit intDoneGCC 3.0
reliable integer divisionDoneGCC 0.9
universal character names (\u and \U)DoneGCC 3.1
extended identifiersMissingGCC 4.1Requires -fextended-identifiers and some corner + cases may be broken.
hexadecimal floating-point constants and - %a
and %A + %a and %A printf/scanf conversion specifiers		Library IssueDoneGCC 2.8Conversion specifiers are a library issue (format checking + support present).
compound literalsDoneGCC 3.1The syntax was supported by GCC by version 1.21, but with + significant differences from C99 requirements until GCC 3.1.
designated initializersDoneGCC 3.0The syntax was supported since GCC 2.5, but with significant + differences from C99 requirements until GCC 3.0.
// commentsDone
library functions in <inttypes.h>Library IssueGCC 2.7
extended integer types in <stdint.h>Missing
extended integer types and library functions + in <inttypes.h> + and <stdint.h>N/AAll of this can be provided by the library rather than the + compiler (some built-in function support also + present). <stdint.h> is provided by GCC (as of + version 4.5), or fixed where the system headers provide a + nonconforming version, on some but not yet all systems. On + systems where types in this header have been defined + as char, GCC retains this definition although it is + not permitted by C99.
remove implicit function declarationDoneGCC 3.0
preprocessor arithmetic
done in intmax_t/uintmax_t		Done
preprocessor arithmetic done in intmax_t/uintmax_tGCC 3.3
mixed declarations and codeDoneGCC 3.0
new block scopes for selection
and iteration statements		Done
new block scopes for selection and iteration statementsGCC 3.0
integer constant type rulesDoneGCC 3.3
integer promotion rulesDoneGCC 4.0
macros with a variable number of argumentsDoneGCC 2.95
the vscanf family of functions - in
<stdio.h> and <wchar.h>		Library IssueDoneN/ALibrary feature, no compiler support required (format checking + support present).
additional math library functions in <math.h>Library IssueN/ALibrary feature, no compiler support required (various + built-in functions present).
treatment of error conditions by math library functions (math_errhandling)Library IssueMissingN/ALibrary feature, no compiler support required.
floating-point environment access
in <fenv.h>		Library Issue
floating-point environment access in <fenv.h>N/ALibrary feature, no compiler support required.
IEC 60559 (also known as
IEC 559 or IEEE arithmetic) support		Broken
IEC 60559 (also known as IEC 559 or IEEE arithmetic) supportOptional feature, not properly supported in GCC.
trailing comma allowed in enum declarationDoneGCC 0.9
%lf conversion specifier
allowed in printf		Library IssueDone
%lf conversion specifier allowed in printfN/ALibrary feature, no compiler support required (format checking + support present).
inline functionsDoneGCC 4.3Inline function support present since at least GCC 1.21, but + with major differences from C99 semantics until 4.3.
the snprintf family of functions in <stdio.h>Library IssueDoneN/ALibrary feature, no compiler support required (format checking + support present).
boolean type in <stdbool.h>DoneGCC 3.0GCC 2.95 had <stdbool.h>, but based on an + early draft with major differences from C99 semantics.
idempotent type qualifiersDoneGCC 3.0Always has been allowed, with a warning as required by C90 + depending on GCC version.
empty macro argumentsDoneGCC 0.9Undefined behavior in C90, but GCC not known ever to have + handled them contrary to C99.
new struct type compatibility
rules (tag compatibility)		Done
new structure type compatibility rules (tag compatibility)GCC 0.9This relates to compatibility between translation units.
additional predefined macro namesMissingGCC 3.0Support for the compiler to implicitly preinclude a + file stdc-predef.h provided by the C library, and so + predefine macros relating to library properties for the whole + translation unit, is new in GCC 4.8.
_Pragma preprocessing operatorDoneGCC 3.0
standard pragmasMissingNot implemented. Associated command-line options to control + the state of the pragmas for the whole translation unit are + available.
__func__ predefined identifierDoneGCC 2.95
va_copy macroDoneGCC 3.0
additional strftime conversion specifiersLibrary IssueDoneN/ALibrary feature, no compiler support required (format checking + support present).
deprecate ungetc at the
beginning of a binary file		Library Issue
LIA compatibility annexN/AThis annex describes how C relates to another standard, and + does not impose any requirements on C implementations.
remove deprecation of
aliased array parameters		Done
deprecate ungetc at the beginning of a binary fileN/ALibrary feature, no compiler support required.
remove deprecation of aliased array parametersGCC 0.9GCC has never done anything regarding this deprecation.
conversion of array to pointer not limited to lvaluesDoneGCC 3.1Some support since GCC 2.0, but with major differences from + C99 requirements before GCC 3.1.
relaxed constraints on aggregate
and union initialization		Done
relaxed constraints on aggregate and union initialization≤ GCC 1.21
relaxed restrictions on portable header namesDoneGCC 0.9GCC has never had such restrictions itself.
return without expression not permitted - in
function that returns a value (and vice versa)		DoneGCC 3.0
FeatureLibrary IssueDoneBrokenMissing

Further notes

@@ -344,25 +401,6 @@ support that only conforms as long as the above options are not used anywhere in the program. -
  • GCC doesn't have wprintf, wscanf and -wcsftime format checking support.
    • - -
  • GCC does not support the Annex G imaginary types and complex -multiplication and division have excess overflows at runtime (although -not beyond those permitted by C99).
    • - -
  • <stdint.h> is provided by GCC, or fixed where -the system headers provide a nonconforming version, on some but not -yet all systems. On systems where types in this header have been -defined as char, GCC retains this definition although it -is not permitted by C99.
    • - -
  • Some of the C99 predefined macros represent properties of the -compiler and library together and so defining them for the whole -translation unit requires cooperation with the library; -a GNU -C Library patch for this is pending review.
    • -
  • const-qualified compound literals could share storage with each other and with string literals, but currently don't.
    • @@ -371,13 +409,6 @@ it in future in conjunction with work on prefetching. -
  • The list above differs from that in N1256 as follows: -"LIA compatibility annex" is removed, since it refers to C99's -conformance to another standard rather than something for C -implementations to do. The <stdint.h> and -<inttypes.h> entries have been separated, but are a -single entry in C99.
    • -