search for: remove_if

...is unsupported? It was added incidentally in r211350, even though it was added and removed by Doug back in r175538 / r175449. > I'm happy with it deleted or fixed (see WIP patch that fixes it w/o tests). For now, I'll fix it, and then David (or someone else) can migrate the code to `remove_if()`. FWIW, when it's fixed, it doesn't have to be "unsupported" -- it's just *slow*. -------------- next part -------------- A non-text attachment was scrubbed... Name: mapvector.patch Type: application/octet-stream Size: 1999 bytes Desc: not available URL: <http://lists.l...

...It erases from the middle of a vector. >> >> At the least, if erasing is kept (and fixed), someone needs to update the >> docs and add a unit test. >> >> One way of speeding this up would be to erase a set of values in bulk. I >> think we could easily add a `remove_if()` function that deleted a set of >> matching items in linear time, using a linear-size auxiliary array of >> indices to keep state. >> >> I'd be happy to implement this if there's a need (if you can easily design >> it out, that's better). > > Yeah...

...;>> >>>> At the least, if erasing is kept (and fixed), someone needs to update the >>>> docs and add a unit test. >>>> >>>> One way of speeding this up would be to erase a set of values in bulk. I >>>> think we could easily add a `remove_if()` function that deleted a set of >>>> matching items in linear time, using a linear-size auxiliary array of >>>> indices to keep state. >>>> >>>> I'd be happy to implement this if there's a need (if you can easily design >>>> it...

...ons to the use cases. Heh -- it's already linear. It erases from the middle of a vector. At the least, if erasing is kept (and fixed), someone needs to update the docs and add a unit test. One way of speeding this up would be to erase a set of values in bulk. I think we could easily add a `remove_if()` function that deleted a set of matching items in linear time, using a linear-size auxiliary array of indices to keep state. I'd be happy to implement this if there's a need (if you can easily design it out, that's better).

...hable. We would like to handle all cases together which also means coming up with a good system for reporting ICEs. See these code review comments<https://github.com/flang-compiler/f18/issues/966> for details. We propose to start fresh on this work after F18 becomes part of the monorepo. [3] remove_if vs RemoveCarriageReturns Whilst removing code that manipulated C-style strings we hit upon a case which seemed to show that std::remove_if was a regression on certain targets over the current algorithm using C standard memmove. This flang-dev thread<http://lists.llvm.org/pipermail/flang-dev/2020...

...hable. We would like to handle all cases together which also means coming up with a good system for reporting ICEs. See these code review comments<https://github.com/flang-compiler/f18/issues/966> for details. We propose to start fresh on this work after F18 becomes part of the monorepo. [3] remove_if vs RemoveCarriageReturns Whilst removing code that manipulated C-style strings we hit upon a case which seemed to show that std::remove_if was a regression on certain targets over the current algorithm using C standard memmove. This flang-dev thread<http://lists.llvm.org/pipermail/flang-dev/2020...

...> together which also means coming up with a good system for reporting ICEs. > See these code review comments > <https://github.com/flang-compiler/f18/issues/966> for details. We > propose to start fresh on this work after F18 becomes part of the monorepo. > > > > [3] remove_if vs RemoveCarriageReturns > > Whilst removing code that manipulated C-style strings we hit upon a case > which seemed to show that std::remove_if was a regression on certain > targets over the current algorithm using C standard memmove. This flang-dev > thread <http://lists.llvm.or...

The simplest way to run a clang test case that I know of is to clone both llvm and clang repos, run all the tests, then run an individual test. IIRC like so: git clone llvm ...... cd llvm/tools git clone clang ..... cd ../../ mkdir build cd build cmake ../llvm ninja check-clang ./bin/llvm-lit -v ./tools/clang/test/Sema/asm.c On Sun, May 6, 2018 at 7:10 AM, Sedat Dilek via llvm-dev <

Hi Oliver, There would be no problem if both the Map and the Vector indeed contained (Key,Value) pairs. To save space, Map entries do not contain Value but instead an unsigned index into the Vector: /// The values are kept in a std::vector and the /// mapping is done with DenseMap from Keys to indexes in that vector. After an element is erased from the Vector all indices greater than the

Hi, while experimenting with llvmlinux on Debian/testing AMD64 I wanted to run some x86-64 ASM tests. I fell over [1] and wanted to run it. So, I cloned clang from Git... $ git clone https://github.com/llvm-mirror/clang.git I looked through some docs where I have seen I need "llvm-lit" or "lit.py". The Debian package llvm-7-tools from <apt.llvm.org> does ship

...from /home/sdi/src/llvm/llvm/lib/Target/Hexagon/Hexagon.h:45, from /home/sdi/src/llvm/llvm/lib/Target/Hexagon/AsmParser/HexagonAsmParser.cpp:12: /home/sdi/src/llvm/llvm/include/llvm/ADT/STLExtras.h:948:6: warning: mangled name for ‘decltype (llvm::adl_begin(Range)) llvm::remove_if(R&&, UnaryPredicate) [with R = std::__cxx11::basic_string<char>&; UnaryPredicate = int (*)(int) throw ()]’ will change in C++17 because the exception specification is part of a function type [-Wnoexcept-type] auto remove_if(R &&Range, UnaryPredicate P) -> decltype(adl_...