Bug 85995 - GCC defines __STDC__ and __STDC_VERSION__ even when used with options that break C conformance
Summary: GCC defines __STDC__ and __STDC_VERSION__ even when used with options that br...
Status: UNCONFIRMED
Alias: None
Product: gcc
Classification: Unclassified
Component: c (show other bugs)
Version: 9.0
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-05-30 09:17 UTC by Vincent Lefèvre
Modified: 2018-06-01 23:05 UTC (History)
0 users

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Vincent Lefèvre 2018-05-30 09:17:23 UTC
According to "gcc -dM -E -xc /dev/null" with some additional options, GCC currently defines __STDC__ and __STDC_VERSION__ even when used with options that break C conformance, such as -fexcess-precision=fast (which is the default).

Since these options are known to break C conformance on purpose, __STDC__ and __STDC_VERSION__ should not be defined in such cases.
Comment 1 Richard Biener 2018-05-30 11:28:36 UTC
I guess that would break way more code than the current state (or force people
to use -std=cXX over -std=gnuXX).
Comment 2 Vincent Lefèvre 2018-05-31 00:09:13 UTC
I don't see the point of defining both __STDC__ and __STDC_VERSION__ if GCC cannot guarantee anything about standard conformance. With the current state, it is not possible to test these macros in order to write code based on the C standard, which could fail otherwise.
Comment 3 jsm-csl@polyomino.org.uk 2018-06-01 16:16:29 UTC
See trouble.texi, "Non-bugs" / "Certain Changes We Don't Want to Make", 
"Undefining @code{__STDC__} when @option{-ansi} is not used." (and the 
description of handling of base standards in invoke.texi).  This is as 
documented since GCC 2.0.
Comment 4 Vincent Lefèvre 2018-06-01 22:50:22 UTC
(In reply to joseph@codesourcery.com from comment #3)
> See trouble.texi, "Non-bugs" / "Certain Changes We Don't Want to Make", 
> "Undefining @code{__STDC__} when @option{-ansi} is not used."

which answers my request.

     Programmers normally use conditionals on '__STDC__' to ask whether
     it is safe to use certain features of ISO C, such as function
     prototypes or ISO token concatenation.

Precisely this is what I wish to do, with 2 versions of a macro: one that assumes C conformance (requiring -fexcess-precision=standard with GCC, in particular), and another one that doesn't but may be slower.

     Since plain 'gcc' supports all the features of ISO C, the correct
     answer to these questions is "yes".

This sentence is wrong by default, as it would imply -fexcess-precision=standard!
Comment 5 jsm-csl@polyomino.org.uk 2018-06-01 23:05:09 UTC
On Fri, 1 Jun 2018, vincent-gcc at vinc17 dot net wrote:

>      Programmers normally use conditionals on '__STDC__' to ask whether
>      it is safe to use certain features of ISO C, such as function
>      prototypes or ISO token concatenation.
> 
> Precisely this is what I wish to do, with 2 versions of a macro: one that
> assumes C conformance (requiring -fexcess-precision=standard with GCC, in
> particular), and another one that doesn't but may be slower.

The typical features people want to test are ones for which __STDC__ gives 
the correct answer.  Likewise if they use __STDC_VERSION__ with a view to 
testing for support for VLAs or compound literals, for example.

You can test for a conformance mode by testing __STRICT_ANSI__ (though 
someone can still use -f options affecting conformance together with a 
-std option that enables a conformance mode).  You can also test 
__GCC_IEC_559 > 0 if you wish to test that no options have been used that 
specifically disable IEEE 754 floating-point features and that 
floating-point exceptions and rounding modes are supported as far as GCC 
knows (the precise rules for __GCC_IEC_559 depend on whether an option 
such as -std=c11 is used as well).