Introduce the idea of a minimum libc version

[compnerd]

Summary

Add the -mmin-libc-version= flag to the driver and encode this into the module
level metadata. This will permit the backend to make certain code generation
choices with the knowledge that the target code will run on a minimum libc
version.

On Windows, this will enable us to enable a number of C99 math routines that are
available in MSVCRT 12.0+, though this is certainly not limited to Windows.
There have been cases where code generation on the Linux targets could do
something slightly different if it knew what version of libc it was targeting.

The module level metadata is needed to ensure that LTO does not break down.
When combining modules targeting differing minimum version, the selection of the
highest version should prevail (since older versions should work on newer, but
not vice-versa).

[majnemer]

Er, I don't see how "libc version" is a meaningful thing on linux. The presumption of which libc implementation is not baked into the triple.

[compnerd]

-gnu implies GLIBC. Traditionally, -uclibc is used instead of -gnu for uclibc environments, and many (most?) Linux distros use -musl to indicate a MUSL environment. For Android, the environment is -android, and thus, assumed to be bionic. If the OS is BSD, usually, the assumption is that it is using the BSD libc. I guess that we can disable this for Linux, but I think that this would be useful to have for non-Windows environments, particularly Android, where you do have differences between versions (IIRC L fixed issues with PIC).

[majnemer]

We already support a version for the environment in the triple, can we just use that?

[compnerd]

Yes, we *could*. Its just a matter of how it is being specified. I find that having the separate option is potentially cleaner than stuffing it in the triple (which does get pushed into the metadata), and then parsing it back out as a value. I think that this is something that longer term could be more easily merged into some of the ideas floated about on the thread regarding the future of triples. Is there a strong reason to stuff this into the triple and parse it back out?

[majnemer]

I think it would be inconsistent with the other platforms which have this version information. The platforms which have an environment version stick it in the triple (Android, MSVC) and the platforms which have an OS version also stick it in the triple (Darwin, iOS, OS X).

Furthermore, it is possible to specify the MSVC version and the Darwin OS version in clang without specifying the entire triple. The -fms-compatibility-version flag (and the corresponding flags for Darwin-based operating systems) update the version.

[compnerd]

Okay, if thats the general pattern, then we can stick it in the triple. Though, that means that the use of the triple for determining the MS compatibility needs to be undone. If the version in the triple is the libc version, then it can differ from the MS compatibility version. The target platform may be different from the compiler version (IIRC, thats the terminology that Visual Studio uses).

[majnemer]

In D7642#223489, @compnerd wrote:

Okay, if thats the general pattern, then we can stick it in the triple. Though, that means that the use of the triple for determining the MS compatibility needs to be undone. If the version in the triple is the libc version, then it can differ from the MS compatibility version. The target platform may be different from the compiler version (IIRC, thats the terminology that Visual Studio uses).

Before VS 2013, Visual C++ shiped a msvcrt and compiler in tandem which would mean that the version of the compiler and library should be the same, no?

After VS 2013, things get a bit more confusing. There is ucrt which lives in the PSDK + msvcrt which lives in the MSVC SDK.

If I understand things correctly, the following are true:

• ucrt forms a stable interface, no exported functions can be removed
• ucrt could, in theory, grow additional functionality
• msvcrt will continue to change but must assume a base line ucrt, it might have to work with the ucrt included with Windows 10 many years after the fact

AFAICT, the compiler is only concerned about the version-to-version contents of msvcrt and not ucrt because ucrt is essentially unchanging. This indicates, to me, that we are still concerned with the compiler version.

[compnerd]

AIUI, ucrt is absolutely relevant since msvcrt itself has been split out into the ucrt. msvcrt is the "shared" common bits, while the ucrt is more "platform" specific bits.

But really, the point is: supporting an older version with a newer compiler is what doing this the way I suggest enables. You can use a newer compiler but still allow the generated binary to target an alternative environment.

[rnk]

We could support that by allowing the MSVC version in the triple to be
different from the -fms-compatibility-version on the command line. Today,
this might even with with --target.

That said, I don't imagine many people are doing this. Microsoft makes it
hard for you to do this, and lots of code assumes that the _MSC_VER macro
correlates with the CRT version.

[majnemer]

In D7642#224225, @compnerd wrote:

AIUI, ucrt is absolutely relevant since msvcrt itself has been split out into the ucrt. msvcrt is the "shared" common bits, while the ucrt is more "platform" specific bits.

But really, the point is: supporting an older version with a newer compiler is what doing this the way I suggest enables. You can use a newer compiler but still allow the generated binary to target an alternative environment.

Er, I see it a bit differently. UCRT is the boring, unchanging part of the CRT which is supposed to provide binary compatibility across versions. It has everything it needs to make junk like FILE * stable through time and the definition of fopen. AFAICT, UCRT provides functionality equivalent to C99 + some random MS-specific stuff.

Correct me if I'm wrong but VS 2013 seemed to have provided all of the functions that TLI cares about and 2015 refactored those functions into UCRT. The UCRT's interface can never shrink which means we can rely on this support indefinitely for all future versions of _MSC_VER.

I think an argument could be made if we believed it to be likely that further interesting library functionality might be exposed through UCRT that the compiler might care about. I'd rather cross that bridge when we get there.

include/clang/Driver/Options.td

   Flags<[HelpHidden]>;
 def mglibc : Flag<["-"], "mglibc">, Group<m_libc_Group>, Flags<[HelpHidden]>;
 def muclibc : Flag<["-"], "muclibc">, Group<m_libc_Group>, Flags<[HelpHidden]>;
+def mmin_libc_version_EQ : Joined<["-"], "mmin-libc-version=">,
+                           Group<m_libc_Group>,
+                           Flags<[ DriverOption, CC1Option ]>;
 def module_file_info : Flag<["-"], "module-file-info">, Flags<[DriverOption,CC1Option]>, Group<Action_Group>;
 def mthumb : Flag<["-"], "mthumb">, Group<m_Group>;
 def mtune_EQ : Joined<["-"], "mtune=">, Group<m_Group>;

include/clang/Frontend/CodeGenOptions.def

 /// The default TLS model to use.
 ENUM_CODEGENOPT(DefaultTLSModel, TLSModel, 2, GeneralDynamicTLSModel)
 
+/// minimum libc version
+VALUE_CODEGENOPT(MinCLibVer, 32, 0)
+
 #undef CODEGENOPT
 #undef ENUM_CODEGENOPT
 #undef VALUE_CODEGENOPT

lib/CodeGen/CodeGenModule.cpp

     getModule().addModuleFlag(llvm::Module::Warning, "Debug Info Version",
                               llvm::DEBUG_METADATA_VERSION);
 
+  if (CodeGenOpts.MinCLibVer)
+    getModule().addModuleFlag(llvm::Module::Warning, "minimum libc version",
+                              CodeGenOpts.MinCLibVer);
+
   // We need to record the widths of enums and wchar_t, so that we can generate
   // the correct build attributes in the ARM backend.
   llvm::Triple::ArchType Arch = Context.getTargetInfo().getTriple().getArch();

lib/Driver/Tools.cpp

       CmdArgs.push_back(Args.MakeArgString("-fms-compatibility-version=" + Ver));
   }
 
+  // -mmin-libc-version
+  if (const Arg *A = Args.getLastArg(options::OPT_mmin_libc_version_EQ)) {
+    std::string Version = A->getValue();
+    CmdArgs.push_back(Args.MakeArgString("-mmin-libc-version=" + Version));
+  }
+
   // -fno-borland-extensions is default.
   if (Args.hasFlag(options::OPT_fborland_extensions,
                    options::OPT_fno_borland_extensions, false))

lib/Frontend/CompilerInvocation.cpp

     }
   }
 
+  if (Arg *A = Args.getLastArg(OPT_mmin_libc_version_EQ)) {
+    StringRef Version = A->getValue();
+
+    unsigned VC[3] = {0};
+    SmallVector<StringRef, 3> Components;
+
+    Version.split(Components, ".", llvm::array_lengthof(VC));
+    for (unsigned CI = 0,
+                  CE = std::min(Components.size(), llvm::array_lengthof(VC));
+         CI < CE; ++CI) {
+      if (Components[CI].getAsInteger(10, VC[CI])) {
+        Diags.Report(diag::err_drv_invalid_value) << A->getAsString(Args)
+                                                  << Version;
+        memset(VC, 0, sizeof(VC));
+        break;
+      }
+    }
+
+    Opts.MinCLibVer = VC[0] * 10000 + VC[1] * 100 + VC[2];
+  }
+
   if (Arg *A = Args.getLastArg(OPT_ffp_contract)) {
     StringRef Val = A->getValue();
     if (Val == "fast")

test/CodeGen/libc-version.c

+// RUN: %clang_cc1 -triple thumbv7-windows-itanium -mmin-libc-version=12.0 -emit-llvm -o - %s \
+// RUN:    | FileCheck %s -check-prefix CHECK-WINDOWS
+// RUN: %clang_cc1 -triple thumbv7-windows-itanium -emit-llvm -o - %s \
+// RUN:    | FileCheck %s
+// RUN: %clang_cc1 -triple i686-linux-gnu -mmin-libc-version=2.21.0 -emit-llvm -o - %s \
+// RUN:    | FileCheck %s -check-prefix CHECK-LINUX
+// RUN: %clang_cc1 -triple i686-linux-gnu -emit-llvm -o - %s \
+// RUN:    | FileCheck %s
+
+// CHECK-LINUX: !"minimum libc version", i32 22100}
+// CHECK-WINDOWS: !"minimum libc version", i32 120000}
+// CHECK-NOT: !"minimum libc version"
+