https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81022
--- Comment #3 from Vladimir Sedach ---
(In reply to Richard Biener from comment #1)
>
> So I'd say INVALID but x86 people may want to double-check the official
> intrinsic documentation.
I was using _mm_store_sd(_mm_load_sd()) to copy an arbit
++
Assignee: unassigned at gcc dot gnu.org
Reporter: vvsed at hotmail dot com
Target Milestone: ---
Created attachment 41505
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41505&action=edit
same source code
/*
D:\Tools\MinGW64\bin\g++.exe -m64 -O2 -Wall -save-temps
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69641
--- Comment #3 from Vladimir Sedach ---
Thanks. Better to use "unsigned int" than options:
0 > (int)((unsigned int)i + 0x0080)
: unassigned at gcc dot gnu.org
Reporter: vvsed at hotmail dot com
Target Milestone: ---
The program prints 0 1 instead of 1 1.
Same behavior with gcc 4.8 and 5.1, with both -m64 and -m32.
/*
D:\Tools\MinGW64\bin\g++.exe -m64 -O2 -Wall -save-temps gcerr.cpp -ovx_class_gc
Compiler: http
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68484
--- Comment #8 from Vladimir Sedach ---
Adding "static" to "volatile" "solves" the problem:
static int * volatile x = _x;
I'm using this trick to avoid aggressive optimization when measuring the time
of execution. The compiler does not skip cal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68484
--- Comment #7 from Vladimir Sedach ---
The "store" pointer could be not only volatile, but also static or global with
same error.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68484
--- Comment #2 from Vladimir Sedach ---
It is not just about "long long".
_mm_store_ps() is also wrong, while _mm_store_pd() / _mm_store_si128() are OK:
#include
#include
int main(int argc, const char *argv[])
{
__attribute__((align
D
Severity: critical
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: vvsed at hotmail dot com
Target Milestone: ---
Created attachment 36803
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36803&action=edit
I
