search for: initializer_list

...nitializerList constructor of ArrayRef (under normal use-case) hit undefined behavior. The test does the following: ArrayRef<int> A = { 0, 1, 2, 3, 4 }; for (int i = 0; i < 5; ++i) EXPECT_EQ(i, A[i]); For those unfamiliar, ArrayRef is a T* Data/size_t Length pair-type with a std::initializer_list Ctor that simply copies the initializer_list::begin into Data. The issue is that after the assignment, the initializer-list temporary goes out of scope (since it is a temporary), creating a dangling pointer. This doesn't seem to be an issue for the most part, however compiling the test with -...

Hi, Building LLVM with a newer GCC version seems to generate several compiler warnings, some of which look like false positives. For example, the '-Winit-list-lifetime' warning added in GCC9 triggers for one of the constructors for ArrayRef, the one taking an initializer_list. How are false positive warnings dealt with in LLVM in general? It's of course possible to just ignore them or use compiler flags to disable them, but with that I think you would risk missing other actual meaningful warnings. Would it make sense to add explicit diagnostic pragmas in the code f...

...ctor of ArrayRef (under normal use-case) hit undefined behavior. The test does the following: > ArrayRef<int> A = { 0, 1, 2, 3, 4 }; > for (int i = 0; i < 5; ++i) > EXPECT_EQ(i, A[i]); > > For those unfamiliar, ArrayRef is a T* Data/size_t Length pair-type with a std::initializer_list Ctor that simply copies the initializer_list::begin into Data. > > The issue is that after the assignment, the initializer-list temporary goes out of scope (since it is a temporary), creating a dangling pointer. This doesn't seem to be an issue for the most part, however compiling the t...

.../home/davidbolvansky/trunk/llvm/include/llvm/Analysis/LazyCallGraph.h:38, from /home/davidbolvansky/trunk/llvm/unittests/Analysis/LazyCallGraphTest.cpp:10: /home/davidbolvansky/trunk/llvm/include/llvm/ADT/ArrayRef.h: In instantiation of ‘llvm::ArrayRef<T>::ArrayRef(const std::initializer_list<_Tp>&) [with T = llvm::LazyCallGraph::Node*]’: /home/davidbolvansky/trunk/llvm/unittests/Analysis/LazyCallGraphTest.cpp:1169:52: required from here /home/davidbolvansky/trunk/llvm/include/llvm/ADT/ArrayRef.h:102:37: warning: initializing ‘llvm::ArrayRef<llvm::LazyCallGraph::Node*>:...

Hi, a downstream consumer of llvm I'm currently working provides the following two functions: static bool StringHasAllOf(const llvm::StringRef &s, const char *which); static bool StringHasAnyOf(const llvm::StringRef &s, std::initializer_list<const char *> which, size_t &where); https://github.com/apple/swift-lldb/blob/stable/source/Target/SwiftLanguageRuntime.cpp#L691 https://github.com/apple/swift-lldb/blob/stable/source/Target/SwiftLanguageRuntime.cpp#L699 I'm under the impression these could be member functions of St...

...interesting logic in the constructor, it takes an initializer list. - This should work with 'v.push_back({a, b, c})' - If it doesn't today, we can fix the type's constructors so that it does. - Using 'emplace_back' doesn't help much -- you still need {}s to form the std::initializer_list in many cases. Pair and tuple are somewhat unusual in not requiring them. Case 2b: A specific constructor needs to be called with an argument list. These arguments are not merely being aggregated but are inputs to a constructor that contains logic. - This is analogous to a case called out w.r.t. &...

Hi Tim, Thanks for the hint. I tried the following, (it's a C interface since that's what I need it for) where a and b are the top and bottom halves of the 128 bit value, LLVMValueRef TestConst(LLVMContextRef C, uint64_t a, uint64_t b) { Type *ty = Type::getFP128Ty(*unwrap(C)); ArrayRef<uint64_t> ar[2] = {a,b}; APInt ai(128,*ar); APFloat quad(APFloat::IEEEquad(), ai);

Dear testers, 8.0.0-rc2 has been tagged from the release_80 branch at r353413. Please run the test script, share your results, and upload binaries. I'll get the source tarballs and docs published as soon as possible, and binaries as they become available. Thanks, Hans

...constructor, it takes > an initializer list. > - This should work with 'v.push_back({a, b, c})' > - If it doesn't today, we can fix the type's constructors so that it does. > - Using 'emplace_back' doesn't help much -- you still need {}s to form the > std::initializer_list in many cases. Pair and tuple are somewhat unusual in > not requiring them. > > This sounds extremely reasonable. > Case 2b: A specific constructor needs to be called with an argument list. > These arguments are not merely being aggregated but are inputs to a > constructor that...

...constructor, it takes > an initializer list. > - This should work with 'v.push_back({a, b, c})' > - If it doesn't today, we can fix the type's constructors so that it does. > - Using 'emplace_back' doesn't help much -- you still need {}s to form the > std::initializer_list in many cases. Pair and tuple are somewhat unusual in > not requiring them. > > This sounds extremely reasonable. > > Case 2b: A specific constructor needs to be called with an argument list. > These arguments are not merely being aggregated but are inputs to a > constructor t...

...e/c++/v1/string_view:176: > In file included from > (...)/sysroot-x86_64-linux-gnu/usr/include/c++/v1/__string:56: > In file included from > (...)/sysroot-x86_64-linux-gnu/usr/include/c++/v1/algorithm:640: > In file included from > (...)/sysroot-x86_64-linux-gnu/usr/include/c++/v1/initializer_list:47: > In file included from > (...)/sysroot-x86_64-linux-gnu/usr/include/c++/v1/cstddef:110: > > (...)/sysroot-x86_64-linux-gnu/usr/include/c++/v1/type_traits:740:56: > error: _Float16 is not supported on this target > template <> struct __libcpp_is_floating_point&l...

Thanks for very accurate responses. - I totally agree what Dave and Chandler said about explicit and implicit operations, this is what I meant my first email. I believe there are places like v.emplace_back(A, B); istead of v.push_back(make_pair(A, B));b That can make code simpler. I think in cases like this we can leave it for judgement of contributor. Having said that I think the

tl;dr: I think we have too many different set classes. They have incompatible APIs and surprising behavior. I think we can reduce their number substantially. Dear all, The following is a subset of the set classes we have in ADT: * DenseSet * SmallDenseSet (https://reviews.llvm.org/D25628) * SetVector * SmallSetVector * SmallSet * SmallPtrSet * StringSet * FoldingSet *

On 10-Oct-16 06:45, Aki Tuomi wrote: > Does your build end at some particular point? See **** DETAILS **** for in depth (I hope enough!) study/report. > > Aki I would guess this is not "c99" way... Making all in lib-http source='test-http-auth.c' object='test-http-auth.o' libtool=no DEPDIR=.deps depmode=xlc /bin/sh ../../depcomp xlc_r

I agree that the ArrayRef is likely the issue. I've debugged a crash caused by a temporary ArrayRef like that a couple times. Either do what David suggested or use a normal array: Metadata *mdArray[] = {ConstantInt::get(Int64Ty, 0), newMD}; ~Craig On Thu, Apr 30, 2020 at 9:56 AM David Blaikie via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > > On Thu, Apr 30, 2020 at

...> > $ g++-8 test.cpp -std=c++2a -fsyntax-only > $ g++-8 test.cpp -std=c++2a -fsyntax-only -D_GLIBCXX_CONCEPT_CHECKS > In file included from /usr/include/c++/8/algorithm:62, > from test.cpp:1: > test.cpp:3:27: in ‘constexpr’ expansion of ‘std::min<int>(std::initializer_list<int>{((const int*)(& ._61)), 6})’ > /usr/include/c++/8/bits/stl_algo.h:3451:31: error: ‘constexpr _FIter std::min_element(_FIter, _FIter) [with _FIter = const int*]’ called in a constant expression > { return *std::min_element(__l.begin(), __l.end()); } > ~~~~...

...a -fsyntax-only >> > $ g++-8 test.cpp -std=c++2a -fsyntax-only -D_GLIBCXX_CONCEPT_CHECKS >> > In file included from /usr/include/c++/8/algorithm:62, >> > from test.cpp:1: >> > test.cpp:3:27: in ‘constexpr’ expansion of ‘std::min<int>(std::initializer_list<int>{((const int*)(& ._61)), 6})’ >> > /usr/include/c++/8/bits/stl_algo.h:3451:31: error: ‘constexpr _FIter std::min_element(_FIter, _FIter) [with _FIter = const int*]’ called in a constant expression >> > { return *std::min_element(__l.begin(), __l.end()); } >&g...

...ebug::vector<unsigned int, std::allocator<unsigned int> >*, std::__debug::vector<long unsigned int, std::allocator<long unsigned int> >*>()’ /home/jayfoad2/git/llvm-project/llvm/include/llvm/ADT/PointerUnion.h:64:25: in ‘constexpr’ expansion of ‘std::min<int>(std::initializer_list<int>{((const int*)(& ._125)), 4})’ /usr/include/c++/8/bits/stl_algo.h:3451:31: error: ‘constexpr _FIter std::min_element(_FIter, _FIter) [with _FIter = const int*]’ called in a constant expression { return *std::min_element(__l.begin(), __l.end()); } ~~~~~~~~~~~~~~~~^~...

...s/out-arm/include/c++/v1/./cstring > -- Installing: > /home/cschen/test/libcxx-scripts/out-arm/include/c++/v1/./ctgmath > -- Installing: > /home/cschen/test/libcxx-scripts/out-arm/include/c++/v1/./csetjmp > -- Installing: > /home/cschen/test/libcxx-scripts/out-arm/include/c++/v1/./initializer_list > -- Installing: > /home/cschen/test/libcxx-scripts/out-arm/include/c++/v1/./__functional_base_03 > -- Installing: > /home/cschen/test/libcxx-scripts/out-arm/include/c++/v1/./new > -- Installing: > /home/cschen/test/libcxx-scripts/out-arm/include/c++/v1/./__functional_base > --...

On 10/3/14 10:16 AM, Dan Albert wrote: >> >> I try to build libc++ and libc++abi for host x86_64(linux) and target >> arm(linux) but fail. >> > > Failing in what way? If this isn't working out of the box, we've done > something wrong. Yeah, it would help to know more specifics about where you're getting stuck. > > jroelofs might know more... For