search for: static_assert

...Clang fails with below errors: $ clang++ fail.cpp -std=c++11 -O0 -c In file included from fail.cpp:1: In file included from /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../include/c++/4.8/unordered_map:47: /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../include/c++/4.8/bits/hashtable.h:268:7: error: static_assert failed "Cache the hash code or make functors involved in hash code and bucket index computation default constructible" static_assert(__if_hash_not_cached< ^ ~~~~~~~~~~~~~~~~~~~~~ /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../include/c++/4.8/bits/unordered_map.h:...

...lity mode. On Tue, Sep 30, 2014 at 5:51 PM, Eric Mader <emader at gmx.us> wrote: > I did some more investigation of the size_t size error. I misunderstood > what was happening. It turns out that size_t is already defined before my > prefix header is included. I added the following static_asserts to the font > of the header: > > static_assert(sizeof(size_t) != 4, "sizeof(size_t) == 4"); > static_assert(sizeof(size_t) != 8, "sizeof(size_t) == 8"); > > The first static_assert fires: > > 1>Build started 9/30/2014 2:29:54 PM. > 1>clang-cl.ex...

Hi Reid, I copied the x64 toolsets by hand; they got installed to C:\Program Files (x86)\LLVM\tools\msbuild\x64; they just didn't get moved correctly by install.bat. I just verified that the LLVM-vs2013 toolset.props is correct. If it is a bitness problem, perhaps I'm failing to define something correctly? Regards, Eric On 9/30/14, 11:29 AM, Reid Kleckner wrote: > This looks

...ue, Sep 30, 2014 at 5:51 PM, Eric Mader <emader at gmx.us> wrote: > >> I did some more investigation of the size_t size error. I misunderstood >> what was happening. It turns out that size_t is already defined before my >> prefix header is included. I added the following static_asserts to the font >> of the header: >> >> static_assert(sizeof(size_t) != 4, "sizeof(size_t) == 4"); >> static_assert(sizeof(size_t) != 8, "sizeof(size_t) == 8"); >> >> The first static_assert fires: >> >> 1>Build started 9/30/2014 2...

Hi Devs, Consider below testcase. $cat test.cpp #include <vector> #include<type_traits> typedef int _int4 __attribute__((vector_size(16))); typedef union{ int data[4]; struct {int x, y, z, w;}; _int4 vec; } int4; typedef int4 int3; int main() { static_assert(std::alignment_of<int4>::value <= alignof(max_align_t), "over aligned!"); } $clang++ -m32 error: static_assert failed due to requirement 'std::alignment_of<int4>::value <= alignof(max_align_t)' "over aligned it goes smooth when compile for x86_64. Following...

...gt; Thoughts/suggestions: > - Adding the default seems very reasonable to me, and I think that 64 > bytes is a good default. I think you should change the behavior so that > SmallVector<LargeThing> defaults to a single inline element instead of zero > though. Perhaps generate a static_assert when it is crazy large. > That would work for me. Mehdi, would SmallVector<T>, defaulting to a minimum single inline element with static_assert(sizeof(T) < 512) address your concerns? -- Sean Silva > > - The name SmallVector has always been confusing, InlinedVector is more &...

This was v3 patch 2/22, reworked to address the confusion about how a structured reply header is read in two pieces before getting to the payload portion. I'm still working on rebasing the rest of my v3 series (patches 1, 3-22) from other comments given, but this seemed independent enough that it's worth posting now rather than holding it up for the rest of the series. Eric Blake (4):

...uteImpl.h<https://sdocc.itg.ti.com/ui#file:review=11893/version=393846>: - AvailableFunctionAttrs is part of the AttributeListImpl class, and - AvailableAttrs is part of the AttributeSetNode class Both of these assume that the number of available enum attributes is limited to 64. In fact, a static_assert in Attributes.cpp<https://sdocc.itg.ti.com/ui#file:review=11893/version=393848> enforces that the number of enum attributes stays at 64 or below. However, the bitcode writer and reader don't communicate enum attributes via bitmask anymore. Enum attributes are encoded in attribute groups....

On Sun, Jan 13, 2013 at 2:10 PM, Matthieu Monrocq <matthieu.monrocq at gmail.com> wrote: > gcc 4.5, MSVC 10, clang 3.1 > - decltype v1.0 [1] + late specified return type > - lambda v1.0 [2] > - local types as template arguments > - r-value 2.0 [3] > - static_assert > - built-in type traits This isn't very encouraging. Anecdotally from what I've seen in LLD (whose C++11 feature use is bounded only by MSVC 2012), the features that get the most mileage by a large margin are `auto`, range-for, and `nullptr`, along with library offerings like unique_pt...

...e really aggressive, it was just >> released in March 2012. Call me conservative, but I was thinking that >> a reasonable GCC baseline would be GCC 4.4 or something (which is ~3.5 >> years old). > > The feature intersection of GCC 4.4 and VS2010 leaves us with auto and > static_assert. Ok, that's too minor to be worth the trouble. Would the intersection of GCC 4.5 VS2010 be practical? -Chris

...eedback from David, here is an updated list of the profiles, taking into account deprecated versions of the specifications of the lambdas and r-values that might be of interest. As before, they are duly annotated with a remark. gcc 4.3, MSVC 10, clang 3.0 => main benefits are decltype v1.0 [1], static_assert and built-in type traits. gcc 4.4, MSVC 10, clang 3.0 => main additions: late specified return type. gcc 4.5, MSVC 10, clang 3.1 => main additions: lambda v1.0 [2], local types as template arguments, r-value v2.0 [3]. gcc 4.5, MSVC 11, clang 3.1 => main additions: atomic, lambda v1.1, r...

...r/states-reply.c > index bd6336a8..af5f6135 100644 > --- a/generator/states-reply.c > +++ b/generator/states-reply.c > @@ -70,14 +70,17 @@ REPLY.START: > * structs (an intentional design decision in the NBD spec when > * structured replies were added). > */ > - STATIC_ASSERT (offsetof (struct nbd_handle, sbuf.simple_reply.cookie) == > - offsetof (struct nbd_handle, sbuf.sr.structured_reply.cookie), > - cookie_aliasing); > + STATIC_ASSERT (offsetof (union reply_header, simple.cookie) == > + offsetof (union rep...

On Sun, Jan 13, 2013 at 10:26 AM, Tim Northover <t.p.northover at gmail.com> wrote: >> Good points David, I don't feel qualified to evaluate the differences >> between those versions though... Perhaps Richard or Doug could comment here? > > Unless I'm misreading the buildbots, we don't actually have anything > trying to build with MSVC. Have we considered how

...+ sudo sh -c echo "deb > http://apt.llvm.org/xenial/ llvm-toolchain-xenial-7 main" >> > /etc/apt/sources.list > ... > 2018-11-25T16:53:30.7836235Z > /home/vsts/work/1/s/src/zig_llvm.cpp:686:1: error: static assertion > failed > 2018-11-25T16:53:30.7837134Z > static_assert((Triple::OSType)ZigLLVM_LastOSType == > Triple::LastOSType, ""); > 2018-11-25T16:53:30.7837409Z ^~~~~~~~~~~~~ > full logs https://dev.azure.com/ziglang/zig/_build/results?buildId=229&view=logs > > The version on apt.llvm.org has > HermitCore, // HermitCore Uniker...

...s not > been instantiated yet > > Hi Richard, > > Is your position that tot clang/libc++ is in error for not producing a > diagnostic? > No, my position is the opposite. Trunk clang + libc++ still reject this: #include <type_traits> template<typename T> struct S { static_assert(sizeof(T) == 1, ""); }; bool b = std::is_assignable<S<int>*&, S<int>*>::value; ... because is_assignable triggers the instantiation of S<int>. I believe Clang is behaving correctly here. I don't know whether libc++'s implementation is valid (I don'...

...> > > Thoughts/suggestions: > - Adding the default seems very reasonable to me, and I think that 64 bytes is a good default. I think you should change the behavior so that SmallVector<LargeThing> defaults to a single inline element instead of zero though. Perhaps generate a static_assert when it is crazy large. > > That would work for me. > > Mehdi, would SmallVector<T>, defaulting to a minimum single inline element with static_assert(sizeof(T) < 512) address your concerns? I'd be a bit concerned about this for two reasons: - Adding a large inlined elem...

...nstantiated yet > > Hi Richard, > > Is your position that tot clang/libc++ is in error for not producing a diagnostic? > > No, my position is the opposite. Trunk clang + libc++ still reject this: > > #include <type_traits> > template<typename T> struct S { static_assert(sizeof(T) == 1, ""); }; > bool b = std::is_assignable<S<int>*&, S<int>*>::value; > > ... because is_assignable triggers the instantiation of S<int>. > > I believe Clang is behaving correctly here. I don't know whether libc++'s implement...

...D(int, 5, B1) // A::SubclassData bits [0,5) >> ADD_SUBCLASS_BITFIELD(bool, 1, B2) // A::SubclassData bits [5,6) >> ADD_SUBCLASS_BITFIELD(short, 6, B3) // A::SubclassData bits [6,12) >> // ADD_SUBCLASS_BITFIELD(int, 6, B4) // A::SubclassData bits [12,18) - >> triggers a static_assert, as it exceeds the 14 bits in A::SubclassData >> END_SUBCLASS_DATA() >> }; >> >> struct C : B { >> BEGIN_SUBCLASS_DATA() >> ADD_SUBCLASS_BITFIELD(bool, 1, C1) // A::SubclassData bits [12,13) >> END_SUBCLASS_DATA() >> }; >> >>...

...LASS_DATA() ADD_SUBCLASS_BITFIELD(int, 5, B1) // A::SubclassData bits [0,5) ADD_SUBCLASS_BITFIELD(bool, 1, B2) // A::SubclassData bits [5,6) ADD_SUBCLASS_BITFIELD(short, 6, B3) // A::SubclassData bits [6,12) // ADD_SUBCLASS_BITFIELD(int, 6, B4) // A::SubclassData bits [12,18) - triggers a static_assert, as it exceeds the 14 bits in A::SubclassData END_SUBCLASS_DATA() }; struct C : B { BEGIN_SUBCLASS_DATA() ADD_SUBCLASS_BITFIELD(bool, 1, C1) // A::SubclassData bits [12,13) END_SUBCLASS_DATA() }; I would appreciate your thoughts on the matter, before I submit a patch for review. C...

..., requiring GCC 4.7 would be really aggressive, it was just > released in March 2012. Call me conservative, but I was thinking that > a reasonable GCC baseline would be GCC 4.4 or something (which is ~3.5 > years old). The feature intersection of GCC 4.4 and VS2010 leaves us with auto and static_assert.