[Bug c++/56038] declarations in xmmintrin.h conflict with mingw-w64 intrin.h in c++ mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56038 --- Comment #12 from Erik van Pienbroek erik-gcc-bugzilla at vanpienbroek dot nl --- (In reply to tim.lebedkov from comment #11) Qt 5.2.1 cannot be build in 32 bit with mingw-w64 4.8.2 because of this bug. Why is it not fixed? A fix for this issue was applied in the intrin.h of mingw-w64 v3.1.0 (which was released in January 2014). Here's the commit in question: http://sourceforge.net/p/mingw-w64/code/6303/ You might want to consider updating your toolchain. I can't judge whether the fix applied in mingw-w64 is correct or whether something needs to be changed in gcc itself as well. Therefore I'm leaving this bug open for now. If the gcc devs think otherwise feel free to close this bug. Qt5 itself can now be built properly against gcc 4.8.2 and mingw-w64 v3.1.0 without any issues.
[Bug c++/56038] declarations in xmmintrin.h conflict with mingw-w64 intrin.h in c++ mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56038 tim.lebedkov at gmail dot com changed: What|Removed |Added CC||tim.lebedkov at gmail dot com --- Comment #11 from tim.lebedkov at gmail dot com --- Qt 5.2.1 cannot be build in 32 bit with mingw-w64 4.8.2 because of this bug. Why is it not fixed?
[Bug c++/56038] declarations in xmmintrin.h conflict with mingw-w64 intrin.h in c++ mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56038 Ruben Van Boxem vanboxem.ruben at gmail dot com changed: What|Removed |Added CC||vanboxem.ruben at gmail dot com --- Comment #7 from Ruben Van Boxem vanboxem.ruben at gmail dot com --- Can this patch please be either applied or rejected for a valid reason? As far as I understand, something might be broken in the compiler wrt inlining: http://gcc.gnu.org/ml/gcc-patches/2010-03/msg00059.html which affects this issue indirectly. Nearly three years have passed since the original discussion.
[Bug c++/56038] declarations in xmmintrin.h conflict with mingw-w64 intrin.h in c++ mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56038 Jacek Caban jacek at codeweavers dot com changed: What|Removed |Added CC||jacek at codeweavers dot com --- Comment #8 from Jacek Caban jacek at codeweavers dot com --- It would be great if this could be fixed in GCC so that we wouldn't need to work around linkage differences in headers, but this should not be a problem for mingw-w64 since rev 6303, which added a work around to intrin.h.
[Bug c++/56038] declarations in xmmintrin.h conflict with mingw-w64 intrin.h in c++ mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56038 --- Comment #9 from H.J. Lu hjl.tools at gmail dot com --- Does mingw provide its own SSE/MMX intrinsic implementations? Can mingw just include xmmintrin.h where SSE/MMX instrincis is needed?
[Bug c++/56038] declarations in xmmintrin.h conflict with mingw-w64 intrin.h in c++ mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56038 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #10 from Jason Merrill jason at gcc dot gnu.org --- (In reply to H.J. Lu from comment #9) Does mingw provide its own SSE/MMX intrinsic implementations? Can mingw just include xmmintrin.h where SSE/MMX instrincis is needed? Right. Why does mingw need to declare these functions itself?
[Bug c++/56038] declarations in xmmintrin.h conflict with mingw-w64 intrin.h in c++ mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56038 --- Comment #6 from Kai Koehne kai.koehne at digia dot com --- The issue is still there with 4.8.1 . It understand that the discussion on Kai Tietz' original patch has stalled ... Any suggestion on how we can move this forward?
[Bug c++/56038] declarations in xmmintrin.h conflict with mingw-w64 intrin.h in c++ mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56038 --- Comment #5 from Kai Koehne kai.koehne at digia dot com 2013-03-26 12:26:04 UTC --- Can confirm that the patch fixes the issue when applied locally.
[Bug c++/56038] declarations in xmmintrin.h conflict with mingw-w64 intrin.h in c++ mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56038 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added CC||ktietz at gcc dot gnu.org --- Comment #3 from Kai Tietz ktietz at gcc dot gnu.org 2013-03-25 08:20:59 UTC --- Issue is an old one ... I had even posted already a patch for this subject. See as reference http://gcc.gnu.org/ml/gcc-patches/2010-03/msg00033.html link. The only way to solve this in a sane way is by moving it into C namespace for C++.
[Bug c++/56038] declarations in xmmintrin.h conflict with mingw-w64 intrin.h in c++ mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56038 --- Comment #4 from Jonathan Liu net147 at gmail dot com 2013-03-25 10:38:33 UTC --- Created attachment 29719 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29719 Add extern C modifier in intrinsics headers for C++
[Bug c++/56038] declarations in xmmintrin.h conflict with mingw-w64 intrin.h in c++ mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56038 --- Comment #2 from Jonathan Liu net147 at gmail dot com 2013-03-25 04:12:41 UTC --- I can reproduce this with MinGW-w64 GCC 4.8.0 x86 DW2/SJLJ. It does not occur with MinGW-w64 GCC 4.8.0 x86_64 SEH/SJLJ.
[Bug c++/56038] declarations in xmmintrin.h conflict with mingw-w64 intrin.h in c++ mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56038 Matthias Kretz kretz at kde dot org changed: What|Removed |Added CC||kretz at kde dot org --- Comment #1 from Matthias Kretz kretz at kde dot org 2013-02-15 10:40:46 UTC --- I also just came across this issue with GCC 4.7.2 on Windows. It appears that all the intrin.h headers are missing the extern C part. Since the functions are always inline and thus the symbols never show up anywhere this has not been a problem before. But now that another header declares those functions a second time something must be done. Maybe what also needs to happen is that in the mingw environment the intrin.h header does not declare the SSE/AVX intrinsics, but instead includes the proper xxxintrin.h headers. In any case, I believe the intrinsics should always be declared with C linkage.
