search for: max_align_t

...w 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 changes fixes this. diff --git a/clang/lib/Headers/__stddef_m...

...lude/llvm/ADT/APInt.h:19: In file included from /tmp/llvm/include/llvm/ADT/ArrayRef.h:14: In file included from /tmp/llvm/include/llvm/ADT/SmallVector.h:17: In file included from /tmp/llvm/include/llvm/Support/AlignOf.h:19: /usr/lib64/[...]/c++/4.9.0/cstddef:51:11: error: no member named 'max_align_t' in the global namespace using ::max_align_t; ~~^ 1 error generated. As the fixes got merged to the release_34 branch, I went to check the local configure options and noticed I was passing --enable-cxx11. If I omit that, there's no max_align_t error. I don't remember when I a...

Using gcc 4.9 to build the llvm 3.4 branch fails with the following error: llvm[1]: Compiling APFloat.cpp for Release build [...] /usr/lib64/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../include/c++/4.9.0/cstddef:51:11: error: no member named 'max_align_t' in the global namespace using ::max_align_t; ~~^ gcc 4.8.2's caused no such issue, so it must be a change in 4.9.0/cstddef. To be clear, I have no idea who's at fault (gcc 4.9.0 header or llvm sources), assuming any code is to be blamed (at all).

...oubt this was tested > much since LLVM 3.4 was released several months before gcc 4.9. I suspect that pulling in clang header fixes r201729, r202911 and r207606 to 3.4.1 will resolve libstdc++ / glibc compatibility issues people have been having with 3.4: r201729: Teach Clang to provide ::max_align_t in C11 and C++11 modes) r202911: Headers: Provide an ABI compatible max_align_t when _MSC_VER is defined) r207606: Let stddef.h respect __need_{wchar_t, size_t, NULL, ptrdiff_t, wint_t}. The changes look safe to merge but I'd like to hear a second opinion from Chandler or Nico. Alp....

...luded from /tmp/llvm/include/llvm/ADT/ArrayRef.h:14: >> In file included from /tmp/llvm/include/llvm/ADT/SmallVector.h:17: >> In file included from /tmp/llvm/include/llvm/Support/AlignOf.h:19: >> /usr/lib64/[...]/c++/4.9.0/cstddef:51:11: error: >> no member named 'max_align_t' in the global namespace >> using ::max_align_t; >> ~~^ >> 1 error generated. >> > Is this trunk or the 3.4 branch? > >> As the fixes got merged to the release_34 branch, I went to check the >> local configure options and noticed I was passi...

...> following error: > > > > > > > > > > > > llvm[1]: Compiling APFloat.cpp for Release build > > > > > > [...] > > > > > > /usr/[...]/include/c++/4.9.0/cstddef:51:11: > > > > > > error: no member named 'max_align_t' in the global namespace > > > > > > using ::max_align_t; > > > > > > ~~^ > > > > > > > > > > > > gcc 4.8.2's caused no such issue, so it must be a change > > > > > > in 4.9.0/cstddef. > &...

Hello there, I'm building a Linux distribution based on musl and LLVM as default toolchain (including lld/libc++/libc++abi/libunwind rather than GNU). For most of the time this works pretty well. However I'm having troubles with few packages, webkit for instance fails because of max_align_t being redeclared in musl's stddef.h I see that stddef.h is provided by both musl and in the private clang include directories. /include/stddef.h /lib/clang/8.0.0/include/stddef.h Usually, compiling a sample program works: $ cat test.cpp #include <stddef.h> #include <limits&...

..., Alp Toker <alp at nuanti.com> wrote: > >> I suspect that pulling in clang header fixes r201729, r202911 and r207606 >> to 3.4.1 will resolve libstdc++ / glibc compatibility issues people have >> been having with 3.4: >> >> r201729: Teach Clang to provide ::max_align_t in C11 and C++11 modes) >> r202911: Headers: Provide an ABI compatible max_align_t when _MSC_VER >> is defined) >> r207606: Let stddef.h respect __need_{wchar_t, size_t, NULL, ptrdiff_t, >> wint_t}. >> >> The changes look safe to merge but I'd like to hea...

Tom, now that 3.4.1 is out, any chance of a 3.4.2 with just the three fixes or at least merging them to the 3.4 branch?

...e: > > > > I suspect that pulling in clang header fixes r201729, r202911 > > and r207606 to 3.4.1 will resolve libstdc++ / glibc > > compatibility issues people have been having with 3.4: > > > > r201729: Teach Clang to provide ::max_align_t in C11 and > > C++11 modes) > > r202911: Headers: Provide an ABI compatible max_align_t when > > _MSC_VER is defined) > > r207606: Let stddef.h respect __need_{wchar_t, size_t, NULL, > > ptrdiff_t, wint_t}. > > > &gt...

...m/ADT/ArrayRef.h:14: >>>> In file included from /tmp/llvm/include/llvm/ADT/SmallVector.h:17: >>>> In file included from /tmp/llvm/include/llvm/Support/AlignOf.h:19: >>>> /usr/lib64/[...]/c++/4.9.0/cstddef:51:11: error: >>>> no member named 'max_align_t' in the global namespace >>>> using ::max_align_t; >>>> ~~^ >>>> 1 error generated. >>>> >>> Is this trunk or the 3.4 branch? >>> >>>> As the fixes got merged to the release_34 branch, I went to check the...

On 02/05/2014 20:45, Tuncer Ayaz wrote: > Bump. > > Is it really unsupported to build llvm from scratch with gcc 4.9 and > libstdc++ 4.9? Should I file a bugzilla ticket instead? Obviously LLVM/clang should compile out of the box using the current stable GCC version, and failure to do so would be a potential release blocker. Please file a PR Tom, do you know about this issue? Alp.

...see a function for target maximum. I'm just trying to pack two structures together in memory, one following the other. The offset to the second one should be constant (not depending on its type), thus I'd like to figure out what the maximum alignment for the platform is. That is, C++'s max_align_t. -- edA-qa mort-ora-y -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- Sign: Please digitally sign your emails. Encrypt: I'm also happy to receive encrypted mail. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type:...

...had the time for it. There are only so much hours in a day... For example, recently with trunk r256945, I saw these: Failing Tests (39): libc++ :: std/depr/depr.c.headers/stddef_h.pass.cpp libc++ :: std/depr/depr.c.headers/wchar_h.pass.cpp libc++ :: std/language.support/support.types/max_align_t.pass.cpp libc++ :: std/localization/locale.categories/category.collate/locale.collate.byname/compare.pass.cpp libc++ :: std/localization/locale.categories/category.collate/locale.collate.byname/transform.pass.cpp libc++ :: std/localization/locale.categories/category.ctype/locale.ctype.b...

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

...ocation_short_name is declared... (cached) no checking for raise... yes checking for sigprocmask... yes checking for volatile sig_atomic_t... yes checking for sighandler_t... no checking for stdint.h... (cached) yes checking for SIZE_MAX... yes checking for ssize_t... (cached) yes checking for good max_align_t... yes checking whether NULL can be used in arbitrary expressions... yes checking which flavor of printf attribute matches inttypes macros... system checking for working strndup... yes checking for working strnlen... yes checking for strtoll... yes checking for strtoull... yes checking for ptrdiff_...

See this bug for background information: https://bugzilla.redhat.com/show_bug.cgi?id=1350465 Thanks: Tomáš Golembiovský --- v2v/virt-v2v.pod | 38 ++++++++++++++++++++++++++------------ 1 file changed, 26 insertions(+), 12 deletions(-) diff --git a/v2v/virt-v2v.pod b/v2v/virt-v2v.pod index e68d75cf8..0943bf305 100644 --- a/v2v/virt-v2v.pod +++ b/v2v/virt-v2v.pod @@ -1909,18 +1909,32 @@ that

See this bug for background information: https://bugzilla.redhat.com/show_bug.cgi?id=1350465 --- v2v/virt-v2v.pod | 39 +++++++++++++++++++++++++++------------ 1 file changed, 27 insertions(+), 12 deletions(-) diff --git a/v2v/virt-v2v.pod b/v2v/virt-v2v.pod index e68d75cf8..93d1a9ecd 100644 --- a/v2v/virt-v2v.pod +++ b/v2v/virt-v2v.pod @@ -1909,18 +1909,33 @@ that guest through the RHV-M UI,

If the connection is not local, paths of disks will refer to the remote host, which were mistakenly handled as local paths (in the best case failing to open a non-existing disk, and in the worst case opening a different disk!). In case the disks are remote resources like ssh or ceph, nothing guarantees that the hostname can be reached from the local machine, or even that it is actually the same on

Hopefully this time ...