Re: [Mingw-w64-public] _mm_set1_epi64 and friends not declared in this scope for dvec.h
On 02/12/14 08:57, Adrien Nader wrote: Hi, I recently stumbled on an issue where dvec.h gets included from intrin.h and triggers around 140 different not declared in this scope errors. Basically, there is an #include dvec.h (which is a C++-only header) near the top of intrin.h and the function declarations for non-SSE2 bulds come later on (I guess that if SSE2 is used, the compiler already has declarations for them?). Since dvec.h uses functions which are declared later on, compilation errors out. Jacek told me over IRC that dvec/fvec/ivec .h probably shouldn't be included from intrin.h. I've tried remove them and my build issues went away. Should that change be commited? Should it also be backported to the stable branch? IMO we should remove them in trunk, but not stable branch (at least not without a delay). We won't know if we're breaking real world code until we do that. Jacek -- Android apps run on BlackBerry 10 Introducing the new BlackBerry 10.2.1 Runtime for Android apps. Now with support for Jelly Bean, Bluetooth, Mapview and more. Get your Android app in front of a whole new audience. Start now. http://pubads.g.doubleclick.net/gampad/clk?id=124407151iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] _mm_set1_epi64 and friends not declared in this scope for dvec.h
2014-02-12 10:58 GMT+01:00 Jacek Caban ja...@codeweavers.com: On 02/12/14 08:57, Adrien Nader wrote: Hi, I recently stumbled on an issue where dvec.h gets included from intrin.h and triggers around 140 different not declared in this scope errors. Basically, there is an #include dvec.h (which is a C++-only header) near the top of intrin.h and the function declarations for non-SSE2 bulds come later on (I guess that if SSE2 is used, the compiler already has declarations for them?). Since dvec.h uses functions which are declared later on, compilation errors out. Jacek told me over IRC that dvec/fvec/ivec .h probably shouldn't be included from intrin.h. I've tried remove them and my build issues went away. Should that change be commited? Should it also be backported to the stable branch? IMO we should remove them in trunk, but not stable branch (at least not without a delay). We won't know if we're breaking real world code until we do that. Jacek For trunk this change seems to be right. For branches I agree to Jacek that we shouldn't do the change. Kai -- Android apps run on BlackBerry 10 Introducing the new BlackBerry 10.2.1 Runtime for Android apps. Now with support for Jelly Bean, Bluetooth, Mapview and more. Get your Android app in front of a whole new audience. Start now. http://pubads.g.doubleclick.net/gampad/clk?id=124407151iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] Memory alignment issue with _mm_loadu_si128 (gcc 4.8.2 32 bit / MinGW-w64 3.0)
Hi, I'm currently investigating a crash [1] in Qt that was caused by introducing SSE2 optimized code. My best guess is that, when calling _mm_loadu_si128 , the generated assembly actually chokes on non-aligned data. This is the code line (with annotated assembly, from gdb): __m128i a_data = _mm_loadu_si128((__m128i*)ptr); 0x6b7f7df4 +0x0049 movdqa %xmm0,-0x28(%ebp) You see that the _mm_loadu_si128 call, that should work for non-aligned memory addresses, actually is is implemented with movdqa, which is Move Aligned Double Quadword. So, do you think this is a bug, or am I on the wrong track here? If so, is it a gcc, or MinGW-w64 issue? Regards Kai PS: I've been able to reproduce this with both Mingw-builds i686-4.8.2-release-posix-dwarf-rt_v3-rev2 and Mingw-builds x32-4.7.2-release-posix-sjlj-rev8 . [1]: https://bugreports.qt-project.org/browse/QTBUG-36807 -- Android apps run on BlackBerry 10 Introducing the new BlackBerry 10.2.1 Runtime for Android apps. Now with support for Jelly Bean, Bluetooth, Mapview and more. Get your Android app in front of a whole new audience. Start now. http://pubads.g.doubleclick.net/gampad/clk?id=124407151iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Memory alignment issue with _mm_loadu_si128 (gcc 4.8.2 32 bit / MinGW-w64 3.0)
2014-02-12 12:56 GMT+01:00 Koehne Kai kai.koe...@digia.com: Hi, I'm currently investigating a crash [1] in Qt that was caused by introducing SSE2 optimized code. My best guess is that, when calling _mm_loadu_si128 , the generated assembly actually chokes on non-aligned data. This is the code line (with annotated assembly, from gdb): __m128i a_data = _mm_loadu_si128((__m128i*)ptr); 0x6b7f7df4 +0x0049 movdqa %xmm0,-0x28(%ebp) You see that the _mm_loadu_si128 call, that should work for non-aligned memory addresses, actually is is implemented with movdqa, which is Move Aligned Double Quadword. So, do you think this is a bug, or am I on the wrong track here? If so, is it a gcc, or MinGW-w64 issue? Regards Kai PS: I've been able to reproduce this with both Mingw-builds i686-4.8.2-release-posix-dwarf-rt_v3-rev2 and Mingw-builds x32-4.7.2-release-posix-sjlj-rev8 . [1]: https://bugreports.qt-project.org/browse/QTBUG-36807 Yes, that seems to be a gcc-bug. As you ask for unaligned, and get aligned. At least I would assume so. Kai -- Android apps run on BlackBerry 10 Introducing the new BlackBerry 10.2.1 Runtime for Android apps. Now with support for Jelly Bean, Bluetooth, Mapview and more. Get your Android app in front of a whole new audience. Start now. http://pubads.g.doubleclick.net/gampad/clk?id=124407151iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Memory alignment issue with _mm_loadu_si128 (gcc 4.8.2 32 bit / MinGW-w64 3.0)
-Original Message- From: Kai Tietz [mailto:ktiet...@googlemail.com] Sent: Wednesday, February 12, 2014 1:02 PM To: mingw-w64-public@lists.sourceforge.net Subject: Re: [Mingw-w64-public] Memory alignment issue with _mm_loadu_si128 (gcc 4.8.2 32 bit / MinGW-w64 3.0) 2014-02-12 12:56 GMT+01:00 Koehne Kai kai.koe...@digia.com: Hi, I'm currently investigating a crash [1] in Qt that was caused by introducing SSE2 optimized code. My best guess is that, when calling _mm_loadu_si128 , the generated assembly actually chokes on non-aligned data. This is the code line (with annotated assembly, from gdb): __m128i a_data = _mm_loadu_si128((__m128i*)ptr); 0x6b7f7df4 +0x0049 movdqa %xmm0,-0x28(%ebp) Actually I was a bit tricked by gdb here: It didn't show the full assembly by default. Only when I stepped into _mm_loadu_si128 I got the full picture: 0x6b7f7de2 +0x0037 jmp0x6b7f7eac ucstrncmp(QChar const*, QChar const*, int)+257 0x6b7f7de7 +0x003c mov-0xc(%ebp),%eax 0x6b7f7dea +0x003f mov%eax,-0x58(%ebp) 0x6b7f7ded +0x0042 mov-0x58(%ebp),%eax 0x6b7f7df0 +0x0045 movdqu (%eax),%xmm0 0x6b7f7df4 +0x0049 movdqa %xmm0,-0x28(%ebp) So we're shuffling registers around here, and it looks like movdqu is used to align the data. Turned out that the core of the problem was (once more) the stack alignment when MinGW is called from MSVC runtime, and the fix is __attribute__ ((force_align_arg_pointer)) . Regards Kai -- Android apps run on BlackBerry 10 Introducing the new BlackBerry 10.2.1 Runtime for Android apps. Now with support for Jelly Bean, Bluetooth, Mapview and more. Get your Android app in front of a whole new audience. Start now. http://pubads.g.doubleclick.net/gampad/clk?id=124407151iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
