Assignee: unassigned at gcc dot gnu.org
Reporter: e...@coeus-group.com
Target Milestone: ---
The _mm{,256,512}_cmp_epi{8,16,32,64}_mask functions take a _MM_CMPINT_ENUM
according to the Intel Intrinsics Guide (e.g.,
<https://software.intel.com/sites/landingpage/IntrinsicsGu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53784
Evan Nemerson changed:
What|Removed |Added
CC||e...@coeus-group.com
--- Comment #4
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: e...@coeus-group.com
Target Milestone: ---
It would be nice if the value passed to -mprefer-vector-width=* were exposed to
the preprocessor. Something like `#define __PREFERRED_VECTOR_WIDTH
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: e...@coeus-group.com
Target Milestone: ---
GCC has signed return values for the vqmovun* functions, but they should be
unsigned. See
https://developer.arm.com/architectures/instruction-sets/simd-isas/neon
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: e...@coeus-group.com
Target Milestone: ---
The avx512fintrin.h header sometimes uses different implementations depending
on whether __OPTIMIZE__ is defined, but many functions
Assignee: unassigned at gcc dot gnu.org
Reporter: e...@coeus-group.com
Target Milestone: ---
I'm running into an ICE on ppc64le:
internal compiler error: in _cpp_pop_context, at libcpp/macro.c:2644
Here is a reproducer:
#define a
#define b(d) d
#if defined(a)
b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95471
--- Comment #2 from Evan Nemerson ---
In that case shouldn't the header be adjusted to not define the vrndvq_f32
function unless it is enabled?
It is already guarded by a check for __ARM_ARCH >= 8 (see
Assignee: unassigned at gcc dot gnu.org
Reporter: e...@coeus-group.com
Target Milestone: ---
Created attachment 48663
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48663=edit
Script to generate the list
I noticed the _mm_loadu_epi* functions were missing, so I threw toget
Assignee: unassigned at gcc dot gnu.org
Reporter: e...@coeus-group.com
Target Milestone: ---
With -march=armv8-a -mfpu=neon, arm_neon.h exposes vrndnq_f32, but the
intrinsic used to implement it (__builtin_neon_vrintnv4sf) emits an "error:
this builtin is not supp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95399
Evan Nemerson changed:
What|Removed |Added
Attachment #48635|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95421
--- Comment #1 from Evan Nemerson ---
> Several functions are actually present in arm but not aarch64, I'm guessing
> that will be an easy place to start. Here is that list:
I pasted the wrong list here; that is actually the list of functions
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: e...@coeus-group.com
Target Milestone: ---
Created attachment 48636
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48636=edit
Full list of missing functions
This is a compan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95399
--- Comment #2 from Evan Nemerson ---
Created attachment 48635
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48635=edit
List of functions missing from 32-bit arm_neon.h
You're right, sorry. I'm not sure why I was thinking that header
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: e...@coeus-group.com
Target Milestone: ---
Documentation:
https://developer.arm.com/architectures/instruction-sets/simd-isas/neon/intrinsics?search=vcvtnq
Clang supports them: https
Assignee: unassigned at gcc dot gnu.org
Reporter: e...@coeus-group.com
Target Milestone: ---
Created attachment 48573
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48573=edit
Test case
I'm trying to create a macro which evaluates an expression while ignoring
warni
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: e...@coeus-group.com
Target Milestone: ---
Pretty straightforward. With -maltivec -Wunused-but-set-parameter, this works
in C but emits a diagnostic in C++:
#include
int f(vector int b) {
return vec_extract
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95144
--- Comment #1 from Evan Nemerson ---
Godbolt link with corrected flags for MSVC: https://godbolt.org/z/M9sgxe
Sorry about that.
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: e...@coeus-group.com
Target Milestone: ---
There are a bunch of functions in AVX-512F which, according to Intel's
documentation (https://software.intel.com/sites/landingpage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94482
--- Comment #25 from Evan Nemerson ---
Created attachment 48253
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48253=edit
Similar test which fails on armv7
I'm also getting an error on armv7-a for the same original code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94488
--- Comment #3 from Evan Nemerson ---
Thanks for looking into this.
Left shift instead of right also seems to be a problem. The backtrace is a bit
different, but I figure it's probably the same issue; if not I can open up a
new report.
I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94482
Evan Nemerson changed:
What|Removed |Added
Attachment #48193|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94482
--- Comment #7 from Evan Nemerson ---
Created attachment 48203
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48203=edit
Non-reduced test case
Thanks for looking into this.
ASan didn't have any issues with the original, non-reduced test.
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: e...@coeus-group.com
Target Milestone: ---
Created attachment 48199
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48199=edit
Test case
On AArch64 with optimizations enabled (-O1 is eno
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94482
--- Comment #2 from Evan Nemerson ---
Created attachment 48195
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48195=edit
Output from cc -v
Sure. It's just -O2, and of course if you're on x86_64 you'll need to pass
-m32. For example:
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: e...@coeus-group.com
Target Milestone: ---
Created attachment 48193
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48193=edit
Test case
I'm tyring to implem
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: e...@coeus-group.com
Target Milestone: ---
One of my projects is hitting an internal compiler error on GCC 10. It works
for g++ 9, and it works in C mode.
Here is a test case
: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: e...@coeus-group.com
Target Milestone: ---
Created attachment 47771
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47771=edit
test case (pass -Wextra to enable the warnings)
I'm getting some false positi
Assignee: unassigned at gcc dot gnu.org
Reporter: e...@coeus-group.com
Target Milestone: ---
GCC doesn't implement _mm256_storeu2_m128, _mm256_storeu2_m128d, or
_mm256_storeu2_m128i.
It's not hard to work around their absence, but it would be nice to have them
just to match
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80502
--- Comment #3 from Evan Nemerson <e...@coeus-group.com> ---
(In reply to Jakub Jelinek from comment #2)
> _OPENMP_SIMD is a bad idea, that namespace is reserved for OpenMP, so unless
> it shows up in the OpenMP standard, it should
: c
Assignee: unassigned at gcc dot gnu.org
Reporter: e...@coeus-group.com
Target Milestone: ---
Created attachment 41250
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41250=edit
define _OPENMP_SIMD when -fopenmp-simd or -fopenmp is passed
_OPENMP is (correctly) o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79518
--- Comment #4 from Evan Nemerson <e...@coeus-group.com> ---
I agree that GCC's implementation makes more sense, but unfortunately it makes
it hard to write portable code.
I'm not suggesting the current behavior be abandoned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79518
--- Comment #2 from Evan Nemerson <e...@coeus-group.com> ---
(In reply to Andrew Pinski from comment #1)
> Why can't you use:
> #define __assume_aligned(arg, align) arg = __builtin_assume_aligned
> (arg, align)
>
> ?
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: e...@coeus-group.com
Target Milestone: ---
TL;DR: It would be very helpful if __builtin_assume_aligned() would mark its
first argument as aligned (assuming it represents a variable).
I'm trying
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: e...@coeus-group.com
Target Milestone: ---
If you pass an unrecognized -Wno-* option to gcc (or g++) with -Wall -Wextra
also set, you should get a warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65709
--- Comment #1 from Evan Nemerson e...@coeus-group.com ---
Created attachment 35267
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35267action=edit
preprocessed test case
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: e...@coeus-group.com
Created attachment 35266
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35266action=edit
Test data
With GCC 5 at -O3 on x86_64 some inputs to LZ4
36 matches
Mail list logo
