[flang] Fixed compiler build on glibc 2.17 systems after 3149c93.

[vzakhari]

No description provided.

[llvmbot]

@llvm/pr-subscribers-flang-semantics

Author: Slava Zakharin (vzakhari)

Changes

---

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

3 Files Affected:

• (modified) flang/include/flang/Evaluate/integer.h (+4)
• (modified) flang/include/flang/Evaluate/real.h (+4)
• (modified) flang/lib/Evaluate/fold-implementation.h (+4)

diff --git a/flang/include/flang/Evaluate/integer.h b/flang/include/flang/Evaluate/integer.h
index 31768c21daae62..7395645701265d 100644
--- a/flang/include/flang/Evaluate/integer.h
+++ b/flang/include/flang/Evaluate/integer.h
@@ -27,6 +27,10 @@
 #include <string>
 #include <type_traits>
 
+// Some environments, viz. glibc 2.17, allow the macro HUGE
+// to leak out of <math.h>.
+#undef HUGE
+
 namespace Fortran::evaluate::value {
 
 // Implements an integer as an assembly of smaller host integer parts
diff --git a/flang/include/flang/Evaluate/real.h b/flang/include/flang/Evaluate/real.h
index 5266bd0ef64bfd..d0da9634651f36 100644
--- a/flang/include/flang/Evaluate/real.h
+++ b/flang/include/flang/Evaluate/real.h
@@ -18,6 +18,10 @@
 #include <limits>
 #include <string>
 
+// Some environments, viz. glibc 2.17, allow the macro HUGE
+// to leak out of <math.h>.
+#undef HUGE
+
 namespace llvm {
 class raw_ostream;
 }
diff --git a/flang/lib/Evaluate/fold-implementation.h b/flang/lib/Evaluate/fold-implementation.h
index 6b3c9416724cb6..9dd8c3843465d5 100644
--- a/flang/lib/Evaluate/fold-implementation.h
+++ b/flang/lib/Evaluate/fold-implementation.h
@@ -39,6 +39,10 @@
 #include <type_traits>
 #include <variant>
 
+// Some environments, viz. glibc 2.17, allow the macro HUGE
+// to leak out of <math.h>.
+#undef HUGE
+
 namespace Fortran::evaluate {
 
 // Utilities

[luporl]

The headers in glibc 2.17 define HUGE when __USE_SVID is defined, which depends on _SVID_SOURCE being defined.
By default, _BSD_SOURCE and _SVID_SOURCE are defined, but not when _POSIX_C_SOURCE is defined.

So, if you want to try, defining _POSIX_C_SOURCE for all platforms may fix this issue without needing to #undef HUGE, which would be a more permanent solution, that doesn't depend on the order of the includes. But as it changes what is exposed by the C runtime, it also has the potential to break something else.

[vzakhari]

Thank you for the information, @luporl! I will try it.