Set C99 as default C Standard for PS4 target

[dyung]

Summary

On the PS4, the default C standard is C99 which differs from the current default of C11. This patch makes the default C99 when targeting the PS4. This change also renames the test ps4-cpu-defaults.cpp to ps4-misc-defaults.cpp so that the test I added for this makes more sense given the test filename.

[ygao]

test/Driver/ps4-misc-defaults.cpp

10 ↗

(On Diff #52406)

It seems to me that this part of the test, exercising "-E", should be placed under test/Preprocessor, instead of test/Driver.

[rsmith]

What's the motivation for this change? Clang's C11 mode should accept all code accepted by its C99 mode (and conversely, most or perhaps all of the C11 language features are accepted by default in C99 mode as an extension). Is the problem the C11 standard library extensions?

[dyung]

In D18708#390132, @rsmith wrote:

What's the motivation for this change? Clang's C11 mode should accept all code accepted by its C99 mode (and conversely, most or perhaps all of the C11 language features are accepted by default in C99 mode as an extension). Is the problem the C11 standard library extensions?

From my understanding, there are 2 issues that block us. The first is that we currently do not ship all of the header files for C11. The second is that we do not yet fully have C11 library support yet for our platform.

[rsmith]

In D18708#390150, @dyung wrote:

From my understanding, there are 2 issues that block us. The first is that we currently do not ship all of the header files for C11. The second is that we do not yet fully have C11 library support yet for our platform.

How do things go wrong if Clang is used in C11 mode against a C99 library? Do you have code that conditionally uses C11 library features if they're available? (And thanks for explaining, by the way; this is useful information for when we next consider changing the default language mode -- we'll likely be changing the default C++ language mode soon.)

Anyway, it seems reasonable for the PS4 toolchain to control its defaults here, and the patch itself LGTM.

[dyung]

In D18708#390166, @rsmith wrote:

In D18708#390150, @dyung wrote:

From my understanding, there are 2 issues that block us. The first is that we currently do not ship all of the header files for C11. The second is that we do not yet fully have C11 library support yet for our platform.

How do things go wrong if Clang is used in C11 mode against a C99 library? Do you have code that conditionally uses C11 library features if they're available? (And thanks for explaining, by the way; this is useful information for when we next consider changing the default language mode -- we'll likely be changing the default C++ language mode soon.)

Anyway, it seems reasonable for the PS4 toolchain to control its defaults here, and the patch itself LGTM.

My understanding is that we currently do not ship all of the headers required for C11, so if users tried to use anything from those, they would be unable to do so. I am also under the impression that C11 requires some library support which we do not yet provide.

Thanks for the quick review!

[dyung]

Moved the test to test/Preprocessor as suggested by Gao and found a nice place to add it.

[ygao]

The test LGTM. Thanks!

[cfe-commits]

• msg-21051-113.txt159 BDownload

[wristow]

In D18708#390183, @dyung wrote:

In D18708#390166, @rsmith wrote:

In D18708#390150, @dyung wrote:

From my understanding, there are 2 issues that block us. The first is that we currently do not ship all of the header files for C11. The second is that we do not yet fully have C11 library support yet for our platform.

How do things go wrong if Clang is used in C11 mode against a C99 library? Do you have code that conditionally uses C11 library features if they're available? (And thanks for explaining, by the way; this is useful information for when we next consider changing the default language mode -- we'll likely be changing the default C++ language mode soon.)

Anyway, it seems reasonable for the PS4 toolchain to control its defaults here, and the patch itself LGTM.

My understanding is that we currently do not ship all of the headers required for C11, so if users tried to use anything from those, they would be unable to do so. I am also under the impression that C11 requires some library support which we do not yet provide.

To confirm and more directly answer your questions, we haven't encountered any situations where things have gone wrong when compiling in C11 mode against a C99 library. As far as we're aware, Clang doesn't have any problems in that area (e.g., we don't know of any situations where Clang in C11 mode is rejecting valid C99 code). We're just being conservative, in that since we don't provide C11 libraries and headers (and therefore we officially tell our customers we don't support C11), we don't want to run into situations where customers might conditionally enable a C11 library feature. We may revisit that approach sometime in the future depending on customer demand for C11 features, but at this point, we're defaulting to C99 just to be conservative.

[probinson]

In D18708#390166, @rsmith wrote:

we'll likely be changing the default C++ language mode soon.)

Privately, PS4 defaults to C++11; we haven't sent that patch upstream because it would make tests fail on the PS4 bot. :-) This is the work Charles Li has been doing, to get the tests ready for the dialect change.

cfe/trunk/include/clang/Frontend/CompilerInvocation.h

public:
   /// executable), for finding the builtin compiler path.
   static std::string GetResourcesPath(const char *Argv0, void *MainAddr);
 
   /// \brief Set language defaults for the given input language and
   /// language standard in the given LangOptions object.
   ///
   /// \param Opts - The LangOptions object to set up.
   /// \param IK - The input language.
+  /// \param T - The target triple.
   /// \param LangStd - The input language standard.
   static void setLangDefaults(LangOptions &Opts, InputKind IK,
+                   const llvm::Triple &T,
                    LangStandard::Kind LangStd = LangStandard::lang_unspecified);
   
   /// \brief Retrieve a module hash string that is suitable for uniquely 
   /// identifying the conditions under which the module was built.
   std::string getModuleHash() const;
   
   /// @}
   /// @name Option Subgroups

cfe/trunk/lib/Frontend/CompilerInvocation.cpp

for (const Arg *A :
     Opts.AddSystemHeaderPrefix(
         A->getValue(), A->getOption().matches(OPT_system_header_prefix));
 
   for (const Arg *A : Args.filtered(OPT_ivfsoverlay))
     Opts.AddVFSOverlayFile(A->getValue());
 }
 
 void CompilerInvocation::setLangDefaults(LangOptions &Opts, InputKind IK,
+                                         const llvm::Triple &T,
                                          LangStandard::Kind LangStd) {
   // Set some properties which depend solely on the input kind; it would be nice
   // to move these to the language standard, and have the driver resolve the
   // input kind + language standard.
   if (IK == IK_Asm) {
     Opts.AsmPreprocessor = 1;
   } else if (IK == IK_ObjC ||
              IK == IK_ObjCXX ||
if (LangStd == LangStandard::lang_unspecified) {
     case IK_PreprocessedCuda:
       LangStd = LangStandard::lang_cuda;
       break;
     case IK_Asm:
     case IK_C:
     case IK_PreprocessedC:
     case IK_ObjC:
     case IK_PreprocessedObjC:
+      // The PS4 uses C99 as the default C standard.
+      if (T.isPS4())
+        LangStd = LangStandard::lang_gnu99;
+      else
         LangStd = LangStandard::lang_gnu11;
       break;
     case IK_CXX:
     case IK_PreprocessedCXX:
     case IK_ObjCXX:
     case IK_PreprocessedObjCXX:
       LangStd = LangStandard::lang_gnucxx98;
       break;
     }
if (const Arg *A = Args.getLastArg(OPT_cl_std_EQ)) {
     if (OpenCLLangStd == LangStandard::lang_unspecified) {
       Diags.Report(diag::err_drv_invalid_value)
       << A->getAsString(Args) << A->getValue();
     }
     else
       LangStd = OpenCLLangStd;
   }
 
-  CompilerInvocation::setLangDefaults(Opts, IK, LangStd);
+  llvm::Triple T(TargetOpts.Triple);
+  CompilerInvocation::setLangDefaults(Opts, IK, T, LangStd);
 
   // We abuse '-f[no-]gnu-keywords' to force overriding all GNU-extension
   // keywords. This behavior is provided by GCC's poorly named '-fasm' flag,
   // while a subset (the non-C++ GNU keywords) is provided by GCC's
   // '-fgnu-keywords'. Clang conflates the two for simplicity under the single
   // name, as it doesn't seem a useful distinction.
   Opts.GNUKeywords = Args.hasFlag(OPT_fgnu_keywords, OPT_fno_gnu_keywords,
                                   Opts.GNUKeywords);
#include "clang/Frontend/LangStandards.def"
   Opts.OpenMPUseTLS =
       Opts.OpenMP && !Args.hasArg(options::OPT_fnoopenmp_use_tls);
   Opts.OpenMPIsDevice =
       Opts.OpenMP && Args.hasArg(options::OPT_fopenmp_is_device);
 
   // Provide diagnostic when a given target is not expected to be an OpenMP
   // device or host.
   if (Opts.OpenMP && !Opts.OpenMPIsDevice) {
-    llvm::Triple T(TargetOpts.Triple);
     switch (T.getArch()) {
     default:
       break;
     // Add unsupported host targets here:
     case llvm::Triple::nvptx:
     case llvm::Triple::nvptx64:
       Diags.Report(clang::diag::err_drv_omp_host_target_not_supported)
           << TargetOpts.Triple;

cfe/trunk/test/Preprocessor/init.c

 // PS4:#define __SIZEOF_WCHAR_T__ 2
 // PS4:#define __SIZEOF_WINT_T__ 4
 // PS4:#define __SIZE_TYPE__ long unsigned int
 // PS4:#define __SIZE_WIDTH__ 64
 // PS4:#define __SSE2_MATH__ 1
 // PS4:#define __SSE2__ 1
 // PS4:#define __SSE_MATH__ 1
 // PS4:#define __SSE__ 1
+// PS4:#define __STDC_VERSION__ 199901L
 // PS4:#define __UINTMAX_TYPE__ long unsigned int
 // PS4:#define __USER_LABEL_PREFIX__
 // PS4:#define __WCHAR_MAX__ 65535
 // PS4:#define __WCHAR_TYPE__ unsigned short
 // PS4:#define __WCHAR_UNSIGNED__ 1
 // PS4:#define __WCHAR_WIDTH__ 16
 // PS4:#define __WINT_TYPE__ int
 // PS4:#define __WINT_WIDTH__ 32