[Bug c++/79264] New: ICE verify_type failed

2017-01-28 Thread guille at berkeley dot edu
: unassigned at gcc dot gnu.org Reporter: guille at berkeley dot edu Target Milestone: --- The following code ICEs on: $ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-apple-darwin13.4.0/7.0.1/lto-wrapper Target: x86_64-apple-darwin13.4.0

[Bug target/80124] Possible bug in _mm_cmpeq_ps

2017-03-20 Thread guille at berkeley dot edu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80124 --- Comment #6 from Guille --- Thanks.

[Bug c++/80124] New: Possible bug in _mm_cmpeq_ps

2017-03-20 Thread guille at berkeley dot edu
++ Assignee: unassigned at gcc dot gnu.org Reporter: guille at berkeley dot edu Target Milestone: --- The following code (below) seems to trigger a gcc bug because the following: (A) * _mm_cmpeq_ps(r, r) (B) * _mm_castsi128_ps(_mm_cmpeq_epi32(_mm_castps_si128(r), _mm_castps_si128(r))) which

[Bug c++/80124] Possible bug in _mm_cmpeq_ps

2017-03-20 Thread guille at berkeley dot edu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80124 --- Comment #1 from Guille --- I forgot to mention that a while back (~1year) I had a similar problem with _mm256_cmp_ps(a,b, _CMP_EQ_OQ) (the AVX equivalent of _mm_cmpeq_ps), but I wasn't able to isolate the problem back then.

[Bug c++/80124] Possible bug in _mm_cmpeq_ps

2017-03-20 Thread guille at berkeley dot edu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80124 --- Comment #2 from Guille --- Created attachment 41008 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41008=edit the code that triggers possible bug Compile with 'c++ t.c' (or maybe 'c++ -msse -msse2 t.c').

[Bug c++/80124] Possible bug in _mm_cmpeq_ps

2017-03-20 Thread guille at berkeley dot edu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80124 --- Comment #3 from Guille --- Apologies, this maybe should've gone in the 'C bugs' section, not the C++ section.

[Bug c++/83024] ICE in build_address, at cp/typeck.c:5623

2017-12-01 Thread guille at berkeley dot edu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83024 --- Comment #2 from Guille --- I should point out that the '-fconcepts' option isn't necessary, but '-std=c++1z' is (e.g. with '-std=c++11' it won't ICE but it also won't compile). So a minimal compilation command is: $ c++ t.c -std=c++1z

[Bug c++/83024] New: ICE in build_address, at cp/typeck.c:5623

2017-11-16 Thread guille at berkeley dot edu
++ Assignee: unassigned at gcc dot gnu.org Reporter: guille at berkeley dot edu Target Milestone: --- The following short code ICEs on $ c++ -v Using built-in specs. COLLECT_GCC=c++ COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-pc-linux-gnu/8.0.0/lto-wrapper Target: x86_64

[Bug c++/83024] ICE in build_address, at cp/typeck.c:5623

2017-11-16 Thread guille at berkeley dot edu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83024 --- Comment #1 from Guille --- I have tested the unsimplified version of this code, and it ICEs on every version *after* gcc-8-20170827.

[Bug c++/93885] New: Spurious instruction kshiftlw issued

2020-02-22 Thread guille at berkeley dot edu
++ Assignee: unassigned at gcc dot gnu.org Reporter: guille at berkeley dot edu Target Milestone: --- [gcc version 10.0.1 20200216] The following code ( https://www.godbolt.org/z/JynEy6 ) #include __m512 f(__m512 x, __m512 y, __m512 z) { const __mmask16 masky = 0b0010001000100010