Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[libc++][ranges] LWG4035: single_view should provide empty #87366

Conversation

H-G-Hristov
Copy link
Contributor

@H-G-Hristov H-G-Hristov commented Apr 2, 2024

@H-G-Hristov H-G-Hristov marked this pull request as ready for review April 2, 2024 16:37
@H-G-Hristov H-G-Hristov requested a review from a team as a code owner April 2, 2024 16:37
@llvmbot llvmbot added the libc++ libc++ C++ Standard Library. Not GNU libstdc++. Not libc++abi. label Apr 2, 2024
@llvmbot
Copy link

llvmbot commented Apr 2, 2024

@llvm/pr-subscribers-libcxx

Author: Hristo Hristov (H-G-Hristov)

Changes

Implements: https://wg21.link/LWG4035


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

2 Files Affected:

  • (modified) libcxx/include/__ranges/single_view.h (+2)
  • (added) libcxx/test/std/ranges/range.factories/range.single.view/empty.pass.cpp (+50)
diff --git a/libcxx/include/__ranges/single_view.h b/libcxx/include/__ranges/single_view.h
index f91c7c35263676..45244f34994d74 100644
--- a/libcxx/include/__ranges/single_view.h
+++ b/libcxx/include/__ranges/single_view.h
@@ -70,6 +70,8 @@ class _LIBCPP_ABI_LLVM18_NO_UNIQUE_ADDRESS single_view : public view_interface<s
 
   _LIBCPP_HIDE_FROM_ABI constexpr const _Tp* end() const noexcept { return data() + 1; }
 
+  _LIBCPP_HIDE_FROM_ABI static constexpr bool empty() noexcept { return false; }
+
   _LIBCPP_HIDE_FROM_ABI static constexpr size_t size() noexcept { return 1; }
 
   _LIBCPP_HIDE_FROM_ABI constexpr _Tp* data() noexcept { return __value_.operator->(); }
diff --git a/libcxx/test/std/ranges/range.factories/range.single.view/empty.pass.cpp b/libcxx/test/std/ranges/range.factories/range.single.view/empty.pass.cpp
new file mode 100644
index 00000000000000..ea462e820ec43b
--- /dev/null
+++ b/libcxx/test/std/ranges/range.factories/range.single.view/empty.pass.cpp
@@ -0,0 +1,50 @@
+//===----------------------------------------------------------------------===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===----------------------------------------------------------------------===//
+
+// UNSUPPORTED: c++03, c++11, c++14, c++17
+
+// static constexpr bool empty() noexcept;
+
+#include <cassert>
+#include <concepts>
+#include <ranges>
+#include <utility>
+
+#include "test_macros.h"
+
+struct Empty {};
+struct BigType {
+  char buffer[64] = {10};
+};
+
+template <typename T>
+constexpr void test_empty(T value) {
+  using SingleView = std::ranges::single_view<T>;
+  SingleView sv{value};
+
+  std::same_as<bool> decltype(auto) result = SingleView::empty();
+  assert(result == false);
+  static_assert(noexcept(SingleView::empty()));
+  static_assert(noexcept(std::ranges::empty(sv)));
+  static_assert(noexcept(std::ranges::empty(std::as_const(sv))));
+}
+
+constexpr bool test() {
+  test_empty<int>(92);
+  test_empty<Empty>(Empty{});
+  test_empty<BigType>(BigType{});
+
+  return true;
+}
+
+int main(int, char**) {
+  test();
+  static_assert(test());
+
+  return 0;
+}

@var-const var-const self-assigned this Apr 2, 2024
@var-const var-const added the ranges Issues related to `<ranges>` label Apr 2, 2024
@H-G-Hristov H-G-Hristov force-pushed the hgh/libcxx/LWG4035-single_view-should-provide-empty branch 2 times, most recently from b389b2f to 341d85b Compare April 5, 2024 20:21
c-rhodes and others added 22 commits July 9, 2024 09:06
…lvm#97584)

In convert-vector-to-llvm the first operand (vector of pointers holding
all memory addresses to read) to the masked.gather (and scatter)
intrinsic has a fixed vector type.

This may result in intrinsics where the scalable flag has been dropped:
```
  %0 = llvm.intr.masked.gather %1, %2, %3 {alignment = 4 : i32}
    : (!llvm.vec<4 x ptr>, vector<[4]xi1>, vector<[4]xi32>) -> vector<[4]xi32>
```
Fortunately the operand is overloaded on the result type so we end up
with the correct IR when lowering to LLVM, but this is still incorrect.
This patch fixes it by propagating scalability.
…ons (llvm#96778)

The vectorization of linalg.index operations doesn't support scalable
vectors when computing the index vector. This patch fixes this with the
vector.step operation.

Depends on llvm#96776
Try to get PointeeStorage.BS.Pointee only once and reuse that.
5221634 (Do not trigger UB during AffineExpr parsing) noticed that
divideCeilSigned and divideFloorSigned would overflow when Numerator =
INT_MIN, and Denominator = -1. This observation has already been made by
DynamicAPInt, and it has code to check this. To avoid checks in multiple
callers, centralize this query in MathExtras, and change
divideCeilSigned/divideFloorSigned to assert on overflow.
…rt (llvm#97812)

Adds `denormal-fp-math-f32`, `denormal-fp-math`, `fp-contract` to
llvmFuncOp attributes.

`denormal-fp-math-f32` and `denormal-fp-math` can enable the ftz, that
is , flushing denormal to zero.

`fp-contract` can enable the fma fusion such as `mul + add -> fma`
…allOperatorInstantiationRAII (llvm#97215)

Currently, `addInstantiatedParameters` is called from the innermost
lambda outward. However, when the function parameters of an inner lambda
depend on the function parameters of an outer lambda, it can lead to a
crash due to the inability to find a mapping for the instantiated decl.

This PR corrects this behavior by calling `addInstantiatedParameters`
from the outside in.

repro code: https://godbolt.org/z/KbsxWesW6

```cpp
namespace dependent_param_concept {
template <typename... Ts> void sink(Ts...) {}
void dependent_param() {
  auto L = [](auto... x) {
    return [](decltype(x)... y) { // `y` depends on `x`
      return [](int z)
        requires requires { sink(y..., z); }
      {};
    };
  };
  L(0, 1)(1, 2)(1);
}
} // namespace dependent_param_concept
```

This PR is a prerequisite for implmenting llvm#61426
Depending on the circumstances we visit variables in, we need to
be careful about when to destroy their temporaries and whether to
emit a Ret op at all or not.
This introduces opaque type `struct __llvm_libc_stdin` and a symbol
`__llvm_libc_stdin_read` that's intended to be provided by the vendor.

`__llvm_libc_stdin_read` intentionally has the same signature as
`cookie_read_function_t` so it can be used with `fopencookie` to
represent `stdin` as `FILE *` in the future.
This test is flaky and has been reporting irrelevant failures to PRs
on Github for example:
llvm#97829 (comment)
https://lab.llvm.org/buildbot/#/builders/66/builds/1159

Adding this to llvm#97712.
…vm#97016)

Add x87 G_LOAD/G_STORE selection support to existing C++ lowering.
Disables LSan in order to remove a 1% flake rate in this test.
There's some logic in LeakSanitizer and its integration into libFuzzer
that will disable LSan and re-run the input. This only happens when more
malloc()s are detected than free()s. Under high system load, this
appears to be possible as the "more mallocs than frees" is dependent on
walltime. In these instances, the number of runs ends up being `n + 1`,
which is undesirable.
…lvm#97566)

This patch splits the lowering for `omp.loop_nest` into its own function
and updates lowering for all supported loop wrappers to stop creating
this operation themselves.

Lowering functions for loop constructs are split into "wrapper" and
"standalone" variants, where the "wrapper" version only creates the
specific operation with nothing inside of it and the "standalone"
version calls the former and also handles clause processing and creates
the nested `omp.loop_nest`.

"Wrapper" lowering functions can be used by "composite" lowering
functions in follow-up patches, minimizing code duplication.

Tests broken as a result of reordering between the processing of the
loop wrapper's and the nested `omp.loop_nest`'s clauses are also
updated.
This just changes a dyn_cast to and isa call to check for type, which
avoids getting a warning in clang. The variable `ity` is not used in the
next block.

No functional change.
…nd. (llvm#96474)

Due to the current order of metadata in DISubprgram, `Type` is processed
before `Unit` by the Verifier. This can cause a race and
 use of garbage data. Consider the following code:

```
int test(int a[][5])
{
    return a[0][2];
}
```

when compiled with clang, the control reaches
`Verifier::visitDISubrange` first with `CurrentSourceLang` still equal
to dwarf::DW_LANG_lo_user (32768). The `Verifier::visitDICompileUnit`
which sets the value of `CurrentSourceLang` is reached later. So
`Verifier::visitDISubrange` ends up using a wrong value of
`CurrentSourceLang`.

This behavior does not effect C like language much but is a problem for
Fortran. There is special processing in `Verifier::visitDISubrange` when
`CurrentSourceLang` is Fortran. With this problem, that special handling
is missed and verifier fails for any code that has Fortran's assumed
size array in a global subroutine.

Various solutions were tried to solve this problem before it was decided that
best course of action is to remove these checks from Verifier.
The HeaderVPBB is retrieved in a similar fashion already.

This is in preparation for splitting up the very large
tryToBuildVPlanWithVPRecipes into several distinct functions, as
suggested multiple times, including in
llvm#94760
It's been nothing but a LocalScope for a while.
@H-G-Hristov
Copy link
Contributor Author

Oops, something bad happened when I tried merging main into this branch. Sorry about that.

@H-G-Hristov
Copy link
Contributor Author

Reuploaded here: #98371
I am sorry for the disturbance.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
libc++ libc++ C++ Standard Library. Not GNU libstdc++. Not libc++abi. ranges Issues related to `<ranges>`
Projects
None yet
Development

Successfully merging this pull request may close these issues.