: target
Assignee: unassigned at gcc dot gnu.org
Reporter: zoltan at hidvegi dot com
CC: wschmidt at gcc dot gnu.org
Target Milestone: ---
Target: powerpc64
Compile the following with g++ -mcpu=power7 -S ppc_vec_extract_ice.C
This probably happens
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: zoltan at hidvegi dot com
Target Milestone: ---
Target: x86_64-*-*
I would like to zero out the upper 128-bit of a 256-bit vector. The Intel
intrinsics for that is _mm256_zextsi128_si256 but it's
Assignee: unassigned at gcc dot gnu.org
Reporter: zoltan at hidvegi dot com
Target Milestone: ---
Target: x86_64-*-*
__m256i foo(long x) { return (__m256i){x}; }
gcc -mavx2 -O2 generates
20: c5 f9 ef c0 vpxor %xmm0,%xmm0,%xmm0
24: c4 e3 f9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79252
--- Comment #2 from Zoltan Hidvegi ---
Created attachment 41855
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41855=edit
Possible vec_insert implementation
The attached code shows two implementation for inserting a byte to a variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81504
--- Comment #1 from Zoltan Hidvegi ---
This may not be a gcc-7 regression, my application fails even with gcc-6, even
with -O1 when I use vec_ld and vec_st, but works if I replace them with vec_xl
and vec_xst, and also works when I replace it
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: zoltan at hidvegi dot com
CC: wschmidt at gcc dot gnu.org
Target Milestone: ---
Target: powerpc64le-unknown-linux-gnu
Created attachment 41802
--> https://gcc.gnu.org/bugzi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78246
--- Comment #1 from Zoltan Hidvegi ---
Created attachment 39986
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39986=edit
gcc -O2 -S -Wall warning_test.C gives incorrect warning: variable ‘sm’ set but
not used
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: zoltan at hidvegi dot com
Target Milestone: ---
Negating a vector variable can cause incorrect unused variable warning. This
happens both on x86 and PowerPC. Compile with g++ -O2 -S -Wall warning_test.C
Interestingly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60939
--- Comment #8 from Zoltan Hidvegi zoltan at hidvegi dot com ---
How about using -bkeepfile: for all linked .o objects, that would create a very
similar semantics to other platforms, all .o objects are included, and only
objects that resolve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60939
--- Comment #6 from Zoltan Hidvegi zoltan at hidvegi dot com ---
gcc collect2 links the programs twice, first it links just all the object and
archive files passed, then it parses the output and if necessary creates a
source file that contains
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28586
--- Comment #5 from Zoltan Hidvegi zoltan at hidvegi dot com ---
Btw. the original testcase was really failing because of Bug 33704, and it
seems that is already fixed, however it's still open, or is it not fully fixed?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28586
Zoltan Hidvegi zoltan at hidvegi dot com changed:
What|Removed |Added
CC||zoltan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64256
--- Comment #11 from Zoltan Hidvegi zoltan at hidvegi dot com ---
Do you have more info regarding the AIX assembler bug you are referring to?
PR46072 was about a different assembler bug, it's just someone in that report
have also encountered
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64256
--- Comment #7 from Zoltan Hidvegi zoltan at hidvegi dot com ---
With the above trivial change I've been able to build code with long
stabstrings on AIX 6.1. I was using the gcc-4.8 branch since that's what we are
using here. If you fix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64256
--- Comment #6 from Zoltan Hidvegi zoltan at hidvegi dot com ---
Created attachment 34672
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34672action=edit
Patch to limit dbx stabstring length to 32000
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64256
--- Comment #9 from Zoltan Hidvegi zoltan at hidvegi dot com ---
xlC generates stubs with continuation, and it seems to cut them at 16k both for
32-bit and 64-bit objects, so maybe gcc could do the same. gdb-7.7.1 seems to
segfault on stubs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64256
Zoltan Hidvegi zoltan at hidvegi dot com changed:
What|Removed |Added
CC||zoltan
Assignee: unassigned at gcc dot gnu.org
Reporter: zoltan at hidvegi dot com
typedef signed char v16si __attribute__ ((vector_size (16)));
v16si ary(signed char a)
{
return v16si{a,a,a,a,a,a,a,a,a,a,a,a,a,a,a,a};
}
Compiled with g++-4.9 -m64 -O2 -fomit-frame-pointer -Wall -I
18 matches
Mail list logo
