[clang] Implement CWG2851: floating-point conversions in converted constant expressions #90387

MitalAshok · 2024-04-28T08:58:19Z

https://cplusplus.github.io/CWG/issues/2851.html

The only time the target type for a converted constant expression is a floating-point type is in a NTTP, so this only affects C++20+.

llvmbot · 2024-04-28T08:58:49Z

@llvm/pr-subscribers-clang

Author: Mital Ashok (MitalAshok)

Changes

https://cplusplus.github.io/CWG/issues/2851.html

The only time the target type for a converted constant expression is a floating-point type is in a NTTP, so this only affects C++20+.

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

4 Files Affected:

(modified) clang/docs/ReleaseNotes.rst (+3)
(modified) clang/include/clang/Basic/DiagnosticSemaKinds.td (+4)
(modified) clang/lib/Sema/SemaOverload.cpp (+35-3)
(modified) clang/test/CXX/drs/dr28xx.cpp (+35)

diff --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index a1390d6536b28c..7c8d83bd73613b 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -164,6 +164,9 @@ Resolutions to C++ Defect Reports
 - Clang now diagnoses declarative nested-name-specifiers with pack-index-specifiers.
   (`CWG2858: Declarative nested-name-specifiers and pack-index-specifiers <https://cplusplus.github.io/CWG/issues/2858.html>`_).
 
+- Allow floating-point promotions and conversions in converted constant expressions.
+  (`CWG2851 Allow floating-point conversions in converted constant expressions <https://cplusplus.github.io/CWG/issues/2851.html>`_).
+
 C Language Changes
 ------------------
 
diff --git a/clang/include/clang/Basic/DiagnosticSemaKinds.td b/clang/include/clang/Basic/DiagnosticSemaKinds.td
index fdca82934cb4dc..08ebb28ff17b25 100644
--- a/clang/include/clang/Basic/DiagnosticSemaKinds.td
+++ b/clang/include/clang/Basic/DiagnosticSemaKinds.td
@@ -85,6 +85,10 @@ def err_expr_not_cce : Error<
   "%select{case value|enumerator value|non-type template argument|"
   "array size|explicit specifier argument|noexcept specifier argument|"
   "call to 'size()'|call to 'data()'}0 is not a constant expression">;
+def err_float_conv_cant_represent : Error<
+  "non-type template argument evaluates to %0 which can not be "
+  "represented in type %1"
+>;
 def ext_cce_narrowing : ExtWarn<
   "%select{case value|enumerator value|non-type template argument|"
   "array size|explicit specifier argument|noexcept specifier argument|"
diff --git a/clang/lib/Sema/SemaOverload.cpp b/clang/lib/Sema/SemaOverload.cpp
index 04cd9e78739d20..c35517db946b1c 100644
--- a/clang/lib/Sema/SemaOverload.cpp
+++ b/clang/lib/Sema/SemaOverload.cpp
@@ -6072,6 +6072,10 @@ static bool CheckConvertedConstantConversions(Sema &S,
   case ICK_Integral_Promotion:
   case ICK_Integral_Conversion: // Narrowing conversions are checked elsewhere.
   case ICK_Zero_Queue_Conversion:
+  // Per CWG2851, floating-point promotions and conversions are allowed.
+  // The value of a conversion is checked afterwards.
+  case ICK_Floating_Promotion:
+  case ICK_Floating_Conversion:
     return true;
 
   case ICK_Boolean_Conversion:
@@ -6091,9 +6095,7 @@ static bool CheckConvertedConstantConversions(Sema &S,
     // only permitted if the source type is std::nullptr_t.
     return SCS.getFromType()->isNullPtrType();
 
-  case ICK_Floating_Promotion:
   case ICK_Complex_Promotion:
-  case ICK_Floating_Conversion:
   case ICK_Complex_Conversion:
   case ICK_Floating_Integral:
   case ICK_Compatible_Conversion:
@@ -6229,7 +6231,37 @@ static ExprResult BuildConvertedConstantExpression(Sema &S, Expr *From,
   if (Result.isInvalid())
     return Result;
 
-  // Check for a narrowing implicit conversion.
+  if (SCS->Second == ICK_Floating_Conversion) {
+    // Unlike with narrowing conversions, the value must fit
+    // exactly even if it is in range
+    assert(CCE == Sema::CCEKind::CCEK_TemplateArg &&
+           "Only non-type template args should use floating-point conversions");
+
+    // Initializer is From, except it is a full-expression
+    const Expr *Initializer =
+        IgnoreNarrowingConversion(S.Context, Result.get());
+
+    // If it's value-dependent, we can't tell whether it will fit
+    if (Initializer->isValueDependent())
+      return Result;
+
+    if (!Initializer->isCXX11ConstantExpr(S.Context, &PreNarrowingValue)) {
+      S.Diag(Initializer->getBeginLoc(), diag::err_expr_not_cce) << CCE;
+      return Result;
+    }
+
+    llvm::APFloat PostNarrowingValue = PreNarrowingValue.getFloat();
+    bool LosesInfo = true;
+    PostNarrowingValue.convert(S.Context.getFloatTypeSemantics(T),
+                               llvm::APFloat::rmNearestTiesToEven, &LosesInfo);
+    if (LosesInfo)
+      S.Diag(From->getBeginLoc(), diag::err_float_conv_cant_represent)
+          << PreNarrowingValue.getAsString(S.Context, From->getType()) << T;
+
+    return Result;
+  }
+
+  // Check for a narrowing integer conversion.
   bool ReturnPreNarrowingValue = false;
   QualType PreNarrowingType;
   switch (SCS->getNarrowingKind(S.Context, Result.get(), PreNarrowingValue,
diff --git a/clang/test/CXX/drs/dr28xx.cpp b/clang/test/CXX/drs/dr28xx.cpp
index 4d9b0c76758d53..cf9676ddb73385 100644
--- a/clang/test/CXX/drs/dr28xx.cpp
+++ b/clang/test/CXX/drs/dr28xx.cpp
@@ -59,6 +59,41 @@ void B<int>::g() requires true;
 
 } // namespace cwg2847
 
+namespace cwg2851 { // cwg2851: 19
+
+#if __cplusplus >= 202002L
+template<typename T, T v> struct Val { static constexpr T value = v; };
+
+// Floating-point promotions
+static_assert(Val<long double, 0.0>::value == 0.0L);
+static_assert(Val<long double, 0.0f>::value == 0.0L);
+static_assert(Val<double, 0.0f>::value == 0.0);
+static_assert(Val<long double, -0.0>::value == -0.0L);
+static_assert(!__is_same(Val<long double, -0.0>, Val<long double, 0.0L>));
+static_assert(__is_same(Val<long double, 0.5>, Val<long double, 0.5L>));
+static_assert(__is_same(Val<long double, __builtin_nan("")>, Val<long double, __builtin_nanl("")>));
+static_assert(__is_same(Val<long double, __builtin_inf()>, Val<long double, __builtin_infl()>));
+
+// Floating-point conversions where the source value can be represented exactly in the destination type
+static_assert(Val<float, 0.0L>::value == 0.0L);
+static_assert(__is_same(Val<float, 0.0>, Val<float, 0.0L>));
+static_assert(__is_same(Val<float, 0.0>, Val<float, 0.0f>));
+static_assert(!__is_same(Val<float, -0.0L>, Val<float, 0.0f>));
+static_assert(__is_same(Val<float, 0.5L>, Val<float, 0.5f>));
+static_assert(__is_same(Val<float, 0.5L>, Val<float, 0.5f>));
+static_assert(__is_same(Val<float, double{__FLT_DENORM_MIN__}>, Val<float, __FLT_DENORM_MIN__>));
+Val<float, double{__FLT_DENORM_MIN__} / 2.0> _1;
+// since-cxx20-error-re@-1 {{non-type template argument evaluates to {{.+}} which can not be represented in type 'float'}}
+Val<float, static_cast<long double>(__FLT_DENORM_MIN__) / 2.0L> _2;
+// since-cxx20-error-re@-1 {{non-type template argument evaluates to {{.+}} which can not be represented in type 'float'}}
+Val<float, __DBL_MAX__> _3;
+// since-cxx20-error-re@-1 {{non-type template argument evaluates to {{.+}} which can not be represented in type 'float'}}
+static_assert(__is_same(Val<float, __builtin_nan("")>, Val<float, __builtin_nanf("")>));
+static_assert(__is_same(Val<float, __builtin_inf()>, Val<float, __builtin_inff()>));
+#endif
+
+}
+
 namespace cwg2858 { // cwg2858: 19
 
 #if __cplusplus > 202302L

Endilll

I'm fine with the way DR test is written, but I'm not qualified to review the contents on the test, unfortunately.

I'd like to point to related Core issues CWG2836 and CWG2864.

You also need to run clang/www/make_cxx_dr_status to update the DR status page.

MitalAshok · 2024-04-28T13:31:59Z

Waiting on #90352 because it's not on the cxx_dr_status page yet (make_dr_status doesn't do anything)

Sirraide

The approach here looks correct, but I’m not sure it’s in the right place.

clang/lib/Sema/SemaOverload.cpp

Endilll · 2024-04-29T11:03:43Z

#90352 has been merged.

…nstant expressions

shafik · 2024-04-29T23:59:39Z

clang/test/CXX/drs/dr28xx.cpp

+// Payload is shifted right so these payloads will be preserved
+static_assert(__is_same(Val<float, __builtin_nan("0xFF00000000")>, Val<float, static_cast<float>(__builtin_nan("0xFF00000000"))>));
+static_assert(__is_same(Val<float, __builtin_nans("0xFF00000000")>, Val<float, static_cast<float>(__builtin_nans("0xFF00000000"))>));
+static_assert(__is_same(Val<float, __builtin_nanl("0x1")>, Val<float, static_cast<float>(__builtin_nanl("0x1"))>));


Why does nanl fail but nans does not? I am not sure this is consistent with CWG2864, which is not final yet either.

I'm not sure how exactly we plan to deal with NaN. How APFloat::convert seems to work is that when converting to a smaller type, only the most significant bits of the payload are used, so that 1 is cut off (thus lossy).

This has the side effect that Val<float, (long double) __builtin_nansf(payload)> and Val<float, (long double) __builtin_nanf(payload)> always work, because (long double) __builtin_nanf(payload) is like __builtin_nanl(payload << (difference in number of fraction bits between long double and float)), and anything with the lower bits set counts as "lossy". Anything implicitly converted to a larger type can be converted back in a converted constant expression. See also: IEEE754 6.2.3 "NaN propagation"

CWG2864 is about narrowing conversions. For sure float{__builtin_nanl("0x1")} isn't a narrowing conversion because it's not finite, but it does lose the payload entirely (float{__builtin_nanl("0x1")} and float{__builtin_nanl("0x0")} have the same bit pattern, even though the source long doubles don't). But maybe we should consider all NaNs to have the same "value" and this should work?

I discussed this with @jensmaurer offline and he felt similarly as well. So let's go with that for now but I will make sure we discuss that next we discuss cwg2864.

shafik · 2024-06-20T22:36:14Z

Is this ready to land?

MitalAshok · 2024-06-21T20:01:23Z

@shafik Yeah, just waiting on the tests after the merge

MitalAshok requested a review from Endilll as a code owner April 28, 2024 08:58

llvmbot added clang Clang issues not falling into any other category clang:frontend Language frontend issues, e.g. anything involving "Sema" labels Apr 28, 2024

Endilll reviewed Apr 28, 2024

View reviewed changes

Endilll requested a review from cor3ntin April 28, 2024 09:07

MitalAshok force-pushed the cwg2851 branch 2 times, most recently from a87399f to 13e2943 Compare April 28, 2024 13:26

Sirraide reviewed Apr 29, 2024

View reviewed changes

clang/lib/Sema/SemaOverload.cpp Show resolved Hide resolved

MitalAshok force-pushed the cwg2851 branch from 13e2943 to 0b8176c Compare April 29, 2024 11:33

[clang] Implement CWG2851: floating-point conversions in converted co…

77cb28e

…nstant expressions

MitalAshok force-pushed the cwg2851 branch from 0b8176c to 77cb28e Compare April 29, 2024 13:40

shafik reviewed Apr 30, 2024

View reviewed changes

MitalAshok added 2 commits June 21, 2024 20:33

Merge branch 'main' into cwg2851

75029f5

namespace comment

cdb77d3

MitalAshok added 2 commits July 26, 2024 08:46

Merge branch 'main' into cwg2851

95576d0

Retarget clang 20

2ae71ab

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

[clang] Implement CWG2851: floating-point conversions in converted constant expressions #90387

[clang] Implement CWG2851: floating-point conversions in converted constant expressions #90387

Uh oh!

MitalAshok commented Apr 28, 2024

Uh oh!

llvmbot commented Apr 28, 2024

Uh oh!

Endilll left a comment

Uh oh!

MitalAshok commented Apr 28, 2024

Uh oh!

Sirraide left a comment

Uh oh!

Uh oh!

Endilll commented Apr 29, 2024

Uh oh!

shafik Apr 29, 2024

Uh oh!

MitalAshok Apr 30, 2024

Uh oh!

shafik Apr 30, 2024

Uh oh!

shafik commented Jun 20, 2024

Uh oh!

MitalAshok commented Jun 21, 2024

Uh oh!

Uh oh!

[clang] Implement CWG2851: floating-point conversions in converted constant expressions #90387

Are you sure you want to change the base?

[clang] Implement CWG2851: floating-point conversions in converted constant expressions #90387

Uh oh!

Conversation

MitalAshok commented Apr 28, 2024

Uh oh!

llvmbot commented Apr 28, 2024

Uh oh!

Endilll left a comment

Choose a reason for hiding this comment

Uh oh!

MitalAshok commented Apr 28, 2024

Uh oh!

Sirraide left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Endilll commented Apr 29, 2024

Uh oh!

shafik Apr 29, 2024

Choose a reason for hiding this comment

Uh oh!

MitalAshok Apr 30, 2024

Choose a reason for hiding this comment

Uh oh!

shafik Apr 30, 2024

Choose a reason for hiding this comment

Uh oh!

shafik commented Jun 20, 2024

Uh oh!

MitalAshok commented Jun 21, 2024

Uh oh!

Uh oh!