: target
Assignee: unassigned at gcc dot gnu.org
Reporter: wen...@mitsuba-renderer.org
Target Milestone: ---
Created attachment 39047
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39047&action=edit
Preprocessed file causing the issue
Hi,
I'm running
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72773
--- Comment #1 from Wenzel Jakob ---
The LLVM ticket is here: https://llvm.org/bugs/show_bug.cgi?id=28810
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72773
--- Comment #3 from Wenzel Jakob ---
It looks like it is an LLVM issue (see
https://llvm.org/bugs/show_bug.cgi?id=28810)
Assignee: unassigned at gcc dot gnu.org
Reporter: wen...@mitsuba-renderer.org
Target Milestone: ---
AVX512 introduces the ability to do scalar broadcasts, which significantly cuts
down on the number of explicit broadcast instructions in vectorized code. It
looks like the AVX512
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: wen...@mitsuba-renderer.org
Target Milestone: ---
GCC (HEAD) fails to compile basic AVX512 code on my machine (OSX 10.11.6) which
I'm using to develop for (and emulate) this architecture.
Consider the following
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: wen...@mitsuba-renderer.org
Target Milestone: ---
Consider the following minimal program, which initializes an 16 int AVX512
vector with -1 entries, does a componen-twise "< 0" comparison, and prints the
r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72805
--- Comment #6 from Wenzel Jakob ---
awesome, thanks!
: 7.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: wen...@mitsuba-renderer.org
Target Milestone: ---
The trunk version of GCC has a regression which
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: wen...@mitsuba-renderer.org
Target Milestone: ---
The Intel intrinsics provide a family functions for computing the minimum and
maximum of two floating point vectors of different
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72782
--- Comment #1 from Wenzel Jakob ---
Looks like this issue was first reported in 2014 but got stuck -- see Bug
63351.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63351
Wenzel Jakob changed:
What|Removed |Added
CC||wen...@mitsuba-renderer.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72824
--- Comment #8 from Wenzel Jakob ---
Thank you, I can confirm that the issue is fixed on my end.
Assignee: unassigned at gcc dot gnu.org
Reporter: wen...@mitsuba-renderer.org
Target Milestone: ---
The AVX512 instruction set introduced the ability to specify a rounding flag
for almost every arithmetic operation that is subject to rounding. This is
extremely useful because
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=73350
--- Comment #1 from Wenzel Jakob ---
Sorry, there was a stupid typo in my message below. The middle part should have
read
At optimization level, -O1, this currently stops working (tested with GCC
trunk):
$ g++ test.c -o test -mavx512f -O1 -fomi
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: wen...@mitsuba-renderer.org
Target Milestone: ---
Consider the following snippet:
// --
#include
__m512 test() { return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=76731
--- Comment #6 from Wenzel Jakob ---
Are there any news here? This is clearly an issue, and it would be nice to fix
it. I currently can't compile my AVX512 project on GCC due to this bug.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=76731
--- Comment #9 from Wenzel Jakob ---
Hi -- just a ping regarding this issue.
Thanks,
Wenzel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=73350
--- Comment #4 from Wenzel Jakob ---
This bug is still present in the latest GCC -- are there any plans to fix it?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=76731
--- Comment #11 from Wenzel Jakob ---
Searching through the intrinsics guide (e.g.
https://software.intel.com/sites/landingpage/IntrinsicsGuide/#text=gather_ps),
I see "void *" for all gather scatter intrinsics and "const void *" for all
gather i
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: wen...@mitsuba-renderer.org
Target Milestone: ---
The latest trunk version (and all versions before as far as I can tell) are
missing the following (unmasked) intrinsics for gather prefetches
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79481
--- Comment #2 from Wenzel Jakob ---
I agree that the docs from Intel are not particularly consistent. In this case,
the hardware has dedicated instructions for these type of gathers, so it would
make sense for a matching intrinsic to be part of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79481
--- Comment #4 from Wenzel Jakob ---
I think that's right. Clang e.g. also does this:
#define _mm512_prefetch_i32gather_ps(index, addr, scale, hint) ({\
__builtin_ia32_gatherpfdps((__mmask16) -1, \
(__v16si)(__m512
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=76342
Wenzel Jakob changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: wen...@mitsuba-renderer.org
Target Milestone: ---
All of the scatter/gather intrinsics in avx512intrin.h use int/float/double
pointers, which is incorrect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=76731
--- Comment #2 from Wenzel Jakob ---
+1 this looks great!
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: wen...@mitsuba-renderer.org
Target Milestone: ---
Created attachment 39640
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39640&action=edit
Preprocessed source cod
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69481
--- Comment #4 from Wenzel Jakob ---
I'm pretty sure this is a recent regression -- GCC was able to compile the code
on Bug 77629 a month ago.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69481
--- Comment #6 from Wenzel Jakob ---
No -- I am experimenting with the AVX512F backend and thus need to use the
development branch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=76731
--- Comment #3 from Wenzel Jakob ---
Any updates here? Should this be closed?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=76731
--- Comment #4 from Wenzel Jakob ---
Hmm, it looks like this is still an issue. Recompiling my codebase with the
latest trunk version of gcc still produces many errors caused by this, e.g.
include/simdarray/array_avx512.h:1059:53: error: invali
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72824
--- Comment #13 from Wenzel Jakob ---
The fix was merged, so I assume this bug should be closed as RESOLVED?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69481
--- Comment #7 from Wenzel Jakob ---
Correction: this ICE indeed goes away when building with
--enable-checking=release (though that doesn't seem like a nice solution). I
assume I used this check level in my trunk builds before and forgot it this
: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: wen...@mitsuba-renderer.org
Target Milestone: ---
The AVX512 shuffle intrinsic switches to a different implementation (&
different signature) when optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77633
--- Comment #2 from Wenzel Jakob ---
I just tried compiling this snippet with ICC 17.0.0. It accepts it without
warnings (-Wall -Wconversion -Wextra). So even if the signature is different,
ICC seems to be more relaxed about passing an integer va
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77633
--- Comment #4 from Wenzel Jakob ---
Aha, interesting -- that breaks it:
test.cpp(9): error: argument of type "int" is incompatible with parameter of
type "_MM_PERM_ENUM={_MM_PERM_ENUM}"
_mm512_shuffle_epi32(_mm512_setzero_epi32(), _MM_SHU
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72784
Wenzel Jakob changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
Assignee: unassigned at gcc dot gnu.org
Reporter: wen...@mitsuba-renderer.org
Target Milestone: ---
Hi,
I'm seeing a number of warnings related to the following three intrinsics,
which appaer to have an incorrect signature. The fix is easy: simply change
__mmask16 to __m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87674
--- Comment #3 from Wenzel Jakob ---
Thanks -- this patch works for me.
With regards to the signature difference: I had already stumbled about the
(float *) vs (some value *) difference in some intrinsics.
In the best case differences cause wa
38 matches
Mail list logo