search for: aligned_storage

Hello, For performance reasons, I would like to provide a way to skip construction/destruction of objects that are stack allocated. Typically, C-style arrays of std::complex create an initialization loops that is almost always unnecessary. I am thinking of providing an __attribute__((uninitialized)) that can be applied to an object declaration: { std::complex<float> foo[64][64]

..., does it make sense for us to do so and maybe potentially enforce it at build time? One of the policies I can think of is not to use *anything* from the C++ standard library even if they are templates anyway (e.g. std::unique_ptr<...>, std::shared_ptr<...>, std::tuple<...>, std::aligned_storage<...>, etc.). The downside to this would be myriad, where we'd need to implement analogues of these ourselves or resort to only things we can use from libc. I'm not sure how this could be automatically enforced, maybe potentially through a blacklist on `std::` types. A slightly more p...

在 2018-08-10 06:20, Kim Gräsman 写道: > On Fri, Aug 10, 2018 at 12:02 AM, Jonathan Wakely <jwakely.gcc at gmail.com> > wrote: >> >> If GCC 4.9.3 thinks there's an aliasing violation it might >> misoptimise. It doesn't matter if it's right or not, it matters if it >> treats the code as undefined or not. >> >> And apparently GCC does think

Hello, For the IWYU project, we have a buildbot on Ubuntu 16.04 and its bundled GCC (which I think is some GCC 5 variant). We're getting a number of -Wstrict-aliasing warnings from JSON.h on this line: https://github.com/llvm-mirror/llvm/blob/master/include/llvm/Support/JSON.h#L455 I'm not sure if GCC has a point here but GCC 7.2 does not complain, so I'm going to guess no. Would

On Wed, Mar 8, 2017 at 2:28 PM Tim Shen <timshen at google.com> wrote: > On Wed, Mar 8, 2017 at 1:49 PM David Blaikie <dblaikie at gmail.com> wrote: > > So I stumbled across an issue that I think is a bit fundamental: > > The xray runtime uses the C++ standard library. > > This seems like a problem because whatever C++ standard library is used to > compile the

...s.cpp libc++ :: std/re/re.traits/lookup_collatename.pass.cpp libc++ :: std/re/re.traits/transform_primary.pass.cpp libc++ :: std/re/re.traits/translate_nocase.pass.cpp libc++ :: std/strings/string.conversions/stof.pass.cpp libc++ :: std/utilities/meta/meta.trans/meta.trans.other/aligned_storage.pass.cpp Individual failures were typically of the form: FAIL: libc++ :: std/localization/locale.categories/category.monetary/locale.moneypunct.byname/thousands_sep.pass.cpp (27654 of 30312) ******************** TEST 'libc++ :: std/localization/locale.categories/category.monetary/locale.money...

...anup. I can do that. > > > > I don't know how hard it is to rewrite buffer queue and fdr logging > using compiler_rt infrastructure. > > > > The crucial things we need in FDR mode logging are: > > - Aligned storage (I suspect this could be done without > std::aligned_storage<...>) > - memcpy (we use std::memcpy there, but probably didn't need to) > - thread-local storage (using C++'s `thread_local` keyword) > > The buffer queue can be re-written to not use std::system_error in the > APIs (use XRay-specific enums instead), internally not use...

Unfortunately I'm having lots of trouble with rc1 at this point: * libcxxabi can't build, because it requires unwind.h, which we do not yet have on FreeBSD 10.x (Ed Maste is working on it for 11.x, but that is not ready for general consumption). * The test-release.sh script has no option to disable only libcxxabi, you can only disable libcxx, libcxxabi and libunwind together (maybe this