search for: enable_if

...' to 'const duration<[...], ratio<[...], 1000000>>' for 1st argument constexpr duration(const duration&) = default; ^ /usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../include/c++/4.6/chrono:237:19: note: candidate template ignored: disabled by 'enable_if' [with _Rep2 = std::chrono::duration<long, std::ratio<1, 1000000000> >] enable_if<is_convertible<_Rep2, rep>::value ^ /usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../include/c++/4.6/chrono:244:19: note: candidate template ignored:...

...duration<[...], ratio<[...], 1000000>>' for 1st argument > constexpr duration(const duration&) = default; > ^ > /usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../include/c++/4.6/chrono:237:19: > note: candidate template ignored: disabled by 'enable_if' [with _Rep2 = > std::chrono::duration<long, std::ratio<1, 1000000000> >] > enable_if<is_convertible<_Rep2, rep>::value > ^ > /usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../include/c++/4.6/chrono:244:19: > note: ca...

...tory (revision 234124). I ran configure as: $ ../llvm-gcc/configure --program-prefix=llvm- --enable-llvm=/home/draikes/src/llvm-obj --enable-languages=c,c++ --disable-multilib when I run: $ make I get the following errors: /home/draikes/src/llvm/include/llvm/ADT/StringRef.h:346:19: error: â EURO ~enable_ifâ EURO (tm) in namespace â EURO ~stdâ EURO (tm) does not name a template type typename std::enable_if<std::numeric_limits<T>::is_signed, bool>::type ^ /home/draikes/src/llvm/include/llvm/ADT/StringRef.h:346:28: error: expected unqualified-id before â EURO ~<â E...

...======================= --- include/llvm/Support/Casting.h (revision 168949) +++ include/llvm/Support/Casting.h (working copy) @@ -203,13 +203,27 @@ // // cast<Instruction>(myVal)->getParent() // -template <class X, class Y> +template <class X, class Y, class S = typename std::enable_if<!std::is_same<Y, typename simplify_type<Y>::SimpleType>::value>::type> inline typename cast_retty<X, Y>::ret_type cast(const Y &Val) { assert(isa<X>(Val) && "cast<Ty>() argument of incompatible type!"); return cast_convert_val<X...

On 15/10/13 22:22, C K Kashyap wrote: > Hi, > I'd like to try out the new c++11 features using clang. However, I am > running into some issue or the other on both Windows and Linux. In both > cases, it looks like the problem is due to headers from VC/g++. > I was wondering if someone can point me to some steps on setting up a > Windows or Linux(ubuntu 12.04 LTS) box for

Hi, I'd like to try out the new c++11 features using clang. However, I am running into some issue or the other on both Windows and Linux. In both cases, it looks like the problem is due to headers from VC/g++. I was wondering if someone can point me to some steps on setting up a Windows or Linux(ubuntu 12.04 LTS) box for exploring clang. I was able to successfully build clang on my ubuntu but

Moving to LLVM dev to discuss the possibility of extending the cast infrastructure to handle this. On Tue, Nov 20, 2012 at 5:51 PM, John McCall <rjmccall at apple.com> wrote: > On Nov 18, 2012, at 5:05 PM, David Blaikie <dblaikie at gmail.com> wrote: >> TypeLoc casting looks bogus. >> >> TypeLoc derived types return true from classof when the dynamic type >>

Thanks, Shahid. It is fixed now. On Fri, Apr 17, 2015 at 8:50 PM, Shahid, Asghar-ahmad < Asghar-ahmad.Shahid at amd.com> wrote: > Hi zhi, > > > > You have to also pass the value type to getDecalaration() API such as > > > > Value* sqrtv = Intrinsic::getDeclaration(M, Intrinsic::x86_sse2_sqrt_pd, > v->getType()); > > > > Regards, > >

The reason the ones in PPCInstrInfo.td don't have the patterns to match is the reason they are more analogous to your problem. Namely, tblgen does not have a way to produce nodes with more than one result. The load-with-update instructions do exactly that - one of the inputs is also an output, but the other output is independent (and necessarily a separate register). The FMA variants have

...wherein we can't write this particular kind of bug again, > > ideally. > > Attaching proof-of-concept solution which prevents this kind of bug. > (Ugly, and requires C++11 support as written, but potentially > interesting anyway.) The C++11 should be easy to remove (move the enable_if to the return type). This approach seems reasonable to me. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20121129/8288cfbc/attachment.html>

...articular kind of bug again, >> > ideally. >> >> Attaching proof-of-concept solution which prevents this kind of bug. >> (Ugly, and requires C++11 support as written, but potentially >> interesting anyway.) > > > The C++11 should be easy to remove (move the enable_if to the return type). > This approach seems reasonable to me. Thanks Eli - that does seem to do the trick (took me a little while to wrap my head around it, though). I've modified it, as Richard suggested, to use enable_if in the return type & it builds in C++98 and correctly catches the...

...;_ZL16NotUnderValgrind", "NotUnderValgrind"}, {"_ZN8Blizzard6Memory12voidp_returncvPT_IcEEv", "Blizzard::Memory::voidp_return::operator char*<char>()"}, {"_Z2f0PU3AS1c", "f0(char AS1*)"}, {"_ZN5Casts8implicitILj4EEEvPN9enable_ifIXleT_Li4EEvE4typeE", "void Casts::implicit<4u>(enable_if<(4u) <= (4), void>::type*)"}, {"_ZN5Casts6cstyleILj4EEEvPN9enable_ifIXleT_cvjLi4EEvE4typeE", "void Casts::cstyle<4u>(enable_if<(4u) <= ((unsigned int)(4)), void>::type*)"},...

...;>> > ideally. >>> >>> Attaching proof-of-concept solution which prevents this kind of bug. >>> (Ugly, and requires C++11 support as written, but potentially >>> interesting anyway.) >> >> >> The C++11 should be easy to remove (move the enable_if to the return type). >> This approach seems reasonable to me. > > Thanks Eli - that does seem to do the trick (took me a little while to > wrap my head around it, though). I've modified it, as Richard > suggested, to use enable_if in the return type & it builds in C++98 &g...

...questions to both cfe-dev and llvm-dev; usually one or the other is more appropriate (in this case, it’s llvm-dev, since there’s no clang code involved). > > > I think you meant to call ConstantArray::get, not ConstantDataArray::get. (We should probably fix ConstantDataArray::get() to use enable_if or something like that, so your example fails to compile instead of generating a weird runtime error.) > > -Eli > > From: cfe-dev <cfe-dev-bounces at lists.llvm.org> On Behalf Of Mustakimur Rahman Khandaker (Mustakim) via cfe-dev > Sent: Monday, January 28, 2019 12:12 PM > T...

Hi Good day. For the following function local static constant array: static const __attribute__((used)) __attribute__((section("data"))) void *codetable[] = { &&RETURN, &&INCREMENT, &&DECREMENT, &&DOUBLE, &&SWAPWORD}; I have the following in the LLVM IR. @sampleCode.codetable = internal global [5 x i8*] [i8* blockaddress(@sampleCode, %19), i8*

Sanjoy Das <sanjoy at playingwithpointers.com> writes: > Hi Justin, > > This SGTM generally, but please make the difference between > LLVM_NODISCARD and LLVM_UNUSED_RESULT clear in the code. :) Right, this is where it gets a little weird. LLVM_NODISCARD would be for types, whereas LLVM_UNUSED_RESULT would be for functions. Depending on your host compiler, using the wrong one

...is the appropriate type. I anticipate a standards fix for this one. The pair<T1, T2>::pair<U, V>(U&&, V&&) constructor should not participate in overload resolution unless U is implicitly convertible to T1 and V is implicitly convertible to T2 (easily implemented with enable_if and is_convertible). pair is still a hotbed of controversy on the committee, but I expect it to be greatly simplified over its current form prior to ratification. -Howard

On Tue, 30 May 2017, Nemanja Ivanovic wrote: > This is typically accomplished with something like PPC's `RegConstraint` and > `NoEncode`. You can see examples of it that are very similar to what you're after in > PPC's load/store with update forms (i.e. load a value and update the base register > with the effective address - these are used for pre-increment loads/stores).

Sorry, always end up not replying to the list: The main issue with dealing with next this way is that people adding new uses of next will probably not be using c++0x and therefore won't know it's ambiguous and that it needs to be qualified. There are also two issues with rvalue references and the STL: 1. EquivalenceClasses, in the insert and findLeader functions, it uses map functions

...it if someone more familiar with clang chimed in on this). So, is > the problem that we can accidentally use LLVM_UNUSED_RESULT on a type > and not know it? > > I think there is a dirty trick here -- we could: > > #define LLVM_UNUSED_RESULT __attribute__((warn_unused_result, > enable_if(true, ""))) > #define LLVM_NODISCARD_TYPE [[clang::warn_unused_result]] > > This breaks the (clang) build if LLVM_UNUSED_RESULT is used on a type. > > It would still be possible to not do the right thing on GCC or MSVC > and be able to build a binary, but I think as long...