[Driver] Fix _XOPEN_SOURCE definition on Solaris

[rorth]

Since commit 613a077, flang doesn't build any longer on Solaris/amd64:

flang/lib/Evaluate/intrinsics-library.cpp:225:26:
error: address of overloaded function 'acos' does not match required type '__float128 (__float128)'
  225 |       FolderFactory<F, F{std::acos}>::Create("acos"),
      |                          ^~~~~~~~~

That patch led to the version of quadmath.h deep inside /usr/gcc/<N> to be found, thus HAS_QUADMATHLIB is defined. However, the struct HostRuntimeLibrary<__float128, LibraryVersion::Libm> template is guarded by _POSIX_C_SOURCE >= 200112L || _XOPEN_SOURCE >= 600, while clang only predefines _XOPEN_SOURCE=500.

This code dates back to commit 0c1941c back in 2012. Currently, this is long obsolete and gcc prefefines _XOPEN_SOURCE=600 instead since GCC 4.6 back in 2011.

This patch follows that.

Tested on amd64-pc-solaris2.11 and sparcv9-sun-solaris2.11.

[llvmbot]

@llvm/pr-subscribers-clang

Author: Rainer Orth (rorth)

Changes

Since commit 613a077, flang doesn't build any longer on Solaris/amd64:

flang/lib/Evaluate/intrinsics-library.cpp:225:26:
error: address of overloaded function 'acos' does not match required type '__float128 (__float128)'
  225 |       FolderFactory<F, F{std::acos}>::Create("acos"),
      |                          ^~~~~~~~~

That patch led to the version of quadmath.h deep inside /usr/gcc/<N> to be found, thus HAS_QUADMATHLIB is defined. However, the struct HostRuntimeLibrary<__float128, LibraryVersion::Libm> template is guarded by _POSIX_C_SOURCE >= 200112L || _XOPEN_SOURCE >= 600, while clang only predefines _XOPEN_SOURCE=500.

This code dates back to commit 0c1941c back in 2012. Currently, this is long obsolete and gcc prefefines _XOPEN_SOURCE=600 instead since GCC 4.6 back in 2011.

This patch follows that.

Tested on amd64-pc-solaris2.11 and sparcv9-sun-solaris2.11.

---

Full diff: https://github.com/llvm/llvm-project/pull/137141.diff

1 Files Affected:

• (modified) clang/lib/Basic/Targets/OSTargets.h (+1-8)

diff --git a/clang/lib/Basic/Targets/OSTargets.h b/clang/lib/Basic/Targets/OSTargets.h
index a88c851797aab..d148b38d03c7c 100644
--- a/clang/lib/Basic/Targets/OSTargets.h
+++ b/clang/lib/Basic/Targets/OSTargets.h
@@ -618,14 +618,7 @@ class LLVM_LIBRARY_VISIBILITY SolarisTargetInfo : public OSTargetInfo<Target> {
     DefineStd(Builder, "unix", Opts);
     Builder.defineMacro("__svr4__");
     Builder.defineMacro("__SVR4");
-    // Solaris headers require _XOPEN_SOURCE to be set to 600 for C99 and
-    // newer, but to 500 for everything else.  feature_test.h has a check to
-    // ensure that you are not using C99 with an old version of X/Open or C89
-    // with a new version.
-    if (Opts.C99)
-      Builder.defineMacro("_XOPEN_SOURCE", "600");
-    else
-      Builder.defineMacro("_XOPEN_SOURCE", "500");
+    Builder.defineMacro("_XOPEN_SOURCE", "600");
     if (Opts.CPlusPlus) {
       Builder.defineMacro("__C99FEATURES__");
       Builder.defineMacro("_FILE_OFFSET_BITS", "64");

[MaskRay]

(I have limited internet access between April 20th and May 4th, and my response time may be delayed..)

[rorth]

/cherry-pick e71c8ea

[rorth]

This patch is required to build flang on Solaris/amd64. Until very recently, a 2-stage build of main with flang included worked with clang-20 as build compiler since flang was only built in stage 2 and the freshly built clang-21 does include the patch.. However, now flang is built in stage 1 already, so the stage 1 compiler needs to include this patch, too, to avoid the build breaking again.

[tstellar]

Was there a backport PR created for this change?

[rorth]

No. However, I got an error for the /cherry-pick that looks like some weird internal error to me, not a failed merge attempt or some such.

[llvmbot]

Failed to cherry-pick: `

https://github.com/llvm/llvm-project/actions/runs/14947694098

Please manually backport the fix and push it to your github fork. Once this is done, please create a pull request

[rorth]

Drats, I'd hoped the markup would inhibit the cherry pick directive from being picked up.

I've now dropped the patch into local LLVM 20.1.5 builds on both amd64-pc-solaris2.11 and sparcv9-sun-solaris2.11. It applied cleanly and introduced no regressions. I'll try a regular cherry pick again: maybe it finally works this time.

[rorth]

/cherry-pick e71c8ea

[llvmbot]

/pull-request #140044