https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115325
--- Comment #2 from Jan Wassenberg ---
Thanks, we are equipped to use pragma GCC target as soon as it is ready. Is
there any bug/tracker to which I could subscribe for updates on that?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115325
Bug ID: 115325
Summary: RVV vmulh and vmulhu unknown without -march, but vmul
is known
Product: gcc
Version: 14.1.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115115
--- Comment #12 from Jan Wassenberg ---
Thanks for continuing to look into this and filing the issues.
It seems like the Highway tests are examples of nontrivial vector code that are
detecting some regressions. Would it be useful to add them to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115115
--- Comment #10 from Jan Wassenberg ---
We have a workaround. I changed the ConvertTo (round to nearest int) code to
const auto overflow = RebindMask(di, Ge(v, Set(df, 2147483648.0f)));
return IfThenElse(overflow, Set(di, LimitsMax()), Convert
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115115
--- Comment #9 from Jan Wassenberg ---
On second thought, we are actually trying to convert out-of-bounds values to
the closest representable. We use the documented behavior of the instruction,
as mentioned in #5, and then correct the result aft
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115115
Jan Wassenberg changed:
What|Removed |Added
CC||jan.wassenberg at gmail dot com
--- Co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111828
--- Comment #4 from Jan Wassenberg ---
I understand the slippery slope concern. But the empty asm string is a special
case, we and others use it (with +r output and memory clobber) to prevent
optimizing variables out e.g. during tests.
It seems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111366
--- Comment #18 from Jan Wassenberg ---
Ah, got it. We'll change the pragma to ",htm" as you suggest. Thank you :)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111366
--- Comment #6 from Jan Wassenberg ---
Thinking about this more, the LTO means more opportunity for inlining and thus
for the compiler to hit the legit "don't want to inline POWER9 into POWER8"
error.
Interestingly this does not happen on x86 -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111366
Jan Wassenberg changed:
What|Removed |Added
CC||jan.wassenberg at gmail dot com
--- Co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=17
Bug ID: 17
Summary: Crash in vector code
Product: gcc
Version: 8.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: un
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109175
--- Comment #7 from Jan Wassenberg ---
Thanks, I will be changing the code to add a nullptr check.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109228
--- Comment #6 from Jan Wassenberg ---
Nice, thank you Mathieu, Kito and JuzheZhong!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109173
--- Comment #5 from Jan Wassenberg ---
Thanks, Mathieu, for raising this.
Note that clang has changed their intrinsic to require an unsigned arg:
https://github.com/google/highway/commit/45b1fac0b1c404e6573c2f182b36c245af6503e0
I understand t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106187
--- Comment #23 from Jan Wassenberg ---
Thanks for having a look. For casting, we CopyBytes between the two
representations, which boils down to __builtin_memcpy
(https://github.com/google/highway/blob/master/hwy/base.h#L819). Is there some
othe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106187
--- Comment #7 from Jan Wassenberg ---
The easiest way to reduce the amount of code in the binary is to comment out
from mul_test.cc all the HWY_EXPORT_AND_TEST_P except the one with
TestAllMulEven.
The actual miscompilation is probably happeni
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106041
--- Comment #7 from Jan Wassenberg ---
Sure, added GCC11 .ii. It does indeed still freeze GCC 12.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106041
--- Comment #6 from Jan Wassenberg ---
Created attachment 53181
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53181&action=edit
GCC11 zipped preprocessed source
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106041
--- Comment #4 from Jan Wassenberg ---
Thanks for having a look! BTW forgot to mention: version 11.0 does not have
this issue.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106041
Bug ID: 106041
Summary: Long/infinite compile time for Arm SIMD -O1 or -O2 but
not -O0
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
20 matches
Mail list logo
