https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120776
Jakub Jelinek changed:
What|Removed |Added
Attachment #61911|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121164
Bug ID: 121164
Summary: [15 Regression] Modula 2 build failure
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: modula2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121159
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121148
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120776
Jakub Jelinek changed:
What|Removed |Added
Attachment #61896|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121156
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121131
Jakub Jelinek changed:
What|Removed |Added
Target Milestone|--- |14.4
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121147
--- Comment #11 from Jakub Jelinek ---
(In reply to terryinzaghi from comment #9)
>cd gcc-15.1.0
>./configure --disable-multilib
Don't do this, this is not supported.
The build directory must be different from the source directory.
Eith
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120924
--- Comment #4 from Jakub Jelinek ---
Works for me too. Just that we don't have too much time for 15.2.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120924
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121143
--- Comment #5 from Jakub Jelinek ---
My bet is that before cunroll we didn't know that __n_206 is 9 and during
cunroll we completely unroll the loop that computes it and when processing the
next loop we use ranger to ask about __n_206 value, ge
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121143
--- Comment #4 from Jakub Jelinek ---
That first loop corresponds to
struct __distance_fn final
{
template _Sent>
requires (!sized_sentinel_for<_Sent, _It>)
constexpr iter_difference_t<_It>
operator()[[nodiscard]](_It _
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121143
--- Comment #3 from Jakub Jelinek ---
Before cunroll that first loop is
[local count: 8680598903]:
# __n_274 = PHI <__n_206(43), 0(39)>
# ivtmp_255 = PHI
__n_206 = __n_274 + 1;
ivtmp_374 = ivtmp_255 - 1;
if (ivtmp_374 != 0)
got
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121143
Jakub Jelinek changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121131
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121131
--- Comment #4 from Jakub Jelinek ---
r14-2224 added (admittedly before _BitInt support went in):
/* Integral bit-fields are left-justified on big-endian targets, so
we must arrange for native_encode_int to start at their
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121131
--- Comment #3 from Jakub Jelinek ---
Reduced testcase:
struct A { _BitInt(156) b : 135; };
static inline _BitInt(6)
foo (struct A *x)
{
return x[1].b;
}
_BitInt(6)
bar (void)
{
struct A a[] = {1, 1, 1, 1, 1, 1, 1, 1, 2, 2, 1, 1 };
retur
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120776
Jakub Jelinek changed:
What|Removed |Added
Attachment #61885|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109934
Jakub Jelinek changed:
What|Removed |Added
CC||Colin.NAKACHE at cea dot fr
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121144
Jakub Jelinek changed:
What|Removed |Added
Keywords|needs-bisection |
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121144
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121144
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120776
--- Comment #7 from Jakub Jelinek ---
Regarding 1), I think the problem is that if there are automatic vars defined
in the expansion stmt body, there is no DECL_EXPR created for them.
The problem is start_decl doing:
6214 if (processing_tem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120776
Jakub Jelinek changed:
What|Removed |Added
Attachment #61842|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121114
--- Comment #4 from Jakub Jelinek ---
BTW, does the standard require that in all standard headers where these
exceptions can be thrown the corresponding exception types have to be defined,
or are the __throw_* functions just trying to make the t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121114
--- Comment #3 from Jakub Jelinek ---
One terribly ugly and not very clang++ friendly solution would be to treat some
of these __throw_* calls as magic constexpr builtins like we already treat
__cxa_bad_cast() etc.
But if we can do it some other
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121114
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44677
--- Comment #30 from Jakub Jelinek ---
(In reply to Vincent Lefèvre from comment #28)
> It seems that to get -Wunused-but-set-parameter=3 implicitly, one needs
> -Wextra (contrary to -Wunused-but-set-variable=3). So the condition
>
> -Wunused
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63164
--- Comment #20 from Jakub Jelinek ---
(In reply to Thomas de Bock from comment #18)
> (In reply to Jason Merrill from comment #17)
> > As I commented at
> >
> > https://inbox.sourceware.org/gcc-patches/75ff8af8-af03-42fa-b68b-
> > e6c16a34c...@
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63164
--- Comment #19 from Jakub Jelinek ---
(In reply to Jason Merrill from comment #17)
> As I commented at
>
> https://inbox.sourceware.org/gcc-patches/75ff8af8-af03-42fa-b68b-
> e6c16a34c...@redhat.com/
>
> we could optimize the dynamic_cast to t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63164
--- Comment #15 from Jakub Jelinek ---
Sure, but that is the only way how to make the optimization reliable.
If the a local type (i.e. mangled for RTTI with * character at the start), it
can just do the name pointer comparison (or perhaps compare
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44677
--- Comment #27 from Jakub Jelinek ---
Nothing changed in what options imply -Wunused-but-set-variable or
-Wunused-but-set-parameter, just that those 2 options now mean the =3 level and
users can explicitly use say -Wunused-but-set-variable=1 etc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121070
--- Comment #5 from Jakub Jelinek ---
Or -fsanitize=undefined,bounds-strict
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63164
--- Comment #12 from Jakub Jelinek ---
I'd think it should just optimize __dynamic_cast to std::type_info::operator==
in that case (if that is available) or, if not (i.e. not included)
to
if (__name == __arg.__name)
return true;
re
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120608
Jakub Jelinek changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110338
Bug 110338 depends on bug 119064, which changed state.
Bug 119064 Summary: [C++26] P2786R13 - Trivial Relocatability
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119064
What|Removed |Added
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119064
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117785
--- Comment #39 from Jakub Jelinek ---
Sorry for screwing the value and I didn't see it should be in too.
I think only P3378R2 adds it to the further headers.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120776
Jakub Jelinek changed:
What|Removed |Added
Attachment #61819|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117785
--- Comment #36 from Jakub Jelinek ---
I think that would be weird, because it changes behavior between constant
evaluation and runtime. And very hard to implement at least on the GCC side.
The constant evaluation is on IL which already includ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117785
--- Comment #34 from Jakub Jelinek ---
It is true that trying to evaluate it just in case can do less harm than if it
is at runtime. That said, e.g. with the constexpr printing it can print
different messages and a script can launch missiles or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117785
--- Comment #31 from Jakub Jelinek ---
what() is printed if derived from std::exception, constexpr, etc.
E.g.
/usr/src/gcc/gcc/testsuite/g++.dg/cpp26/constexpr-eh9.C:108:23: in
'constexpr' expansion of 'bar(1)'
/usr/src/gcc/gcc/testsuite/g++.d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117785
--- Comment #29 from Jakub Jelinek ---
For std::exception or classes derived from it the standard documents what
what() means. For other classes the standard doesn't say anything on those,
even if it has const char * return type and is constexp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117785
--- Comment #27 from Jakub Jelinek ---
(In reply to Hana Dusíková from comment #26)
> (In reply to Jakub Jelinek from comment #25)
> > In the end this is done only for classes derived from std::exception, to
> > match e.g. the verbose terminate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120569
--- Comment #5 from Jakub Jelinek ---
Fixed for 16+ and 15.2+ so far, unsure if we want to backport it further.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121023
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120628
--- Comment #6 from Jakub Jelinek ---
Fixed for 16+ and 15.2+ so far, unsure if we want to backport it further.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120837
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120954
Jakub Jelinek changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117785
--- Comment #25 from Jakub Jelinek ---
(In reply to Hana Dusíková from comment #1)
> It's not part of the wording as CWG told me to take it out. But it's very
> useful when an exception is not caught to call it's `.what()` and print
> resulting
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110338
Bug 110338 depends on bug 117785, which changed state.
Bug 117785 Summary: [C++26] P3068R5 - constexpr exceptions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117785
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117785
Jakub Jelinek changed:
What|Removed |Added
Target Milestone|--- |16.0
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121023
Jakub Jelinek changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121023
Jakub Jelinek changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121023
Bug ID: 121023
Summary: musttail vs. IPA optimizations on the caller
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121007
--- Comment #11 from Jakub Jelinek ---
Though even there is uninitialized read I guess from temp.a.
That said, LRA obviously shouldn't hang even on code which has UB at runtime.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121007
--- Comment #10 from Jakub Jelinek ---
Slightly tweaked testcase to avoid -Wuninitialized as well as avoid the
aliasing violation.
typedef struct { int a; } A;
unsigned char *a;
char b;
int c;
void foo (vector char, vector char, vector char);
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121000
--- Comment #9 from Jakub Jelinek ---
The problem if it is the scalar type rather than pointer to it is that it could
be e.g. too narrow to fit all the ACCESS_MODE values there. Think about
unsigned _BitInt(1) counted_by.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121000
--- Comment #8 from Jakub Jelinek ---
The usual way would be to make the argument pointer to the scalar type,
basically have the access mode the same type as the second argument. So e.g.
int * or unsigned * or size_t * etc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121000
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121007
--- Comment #6 from Jakub Jelinek ---
Reduced -mcpu=power9 -O2:
typedef struct { int a; } A;
unsigned char *a;
char b;
int c;
void foo (vector char, vector char, vector char);
void
bar (long stride)
{
vector char v0, v1, v2, v3, v4, v5;
ve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121004
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121007
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121001
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117784
--- Comment #3 from Jakub Jelinek ---
As the commit message says, so far partially implemented. One can declare
structured bindings constexpr as long as the C++23-ish constant expression
handling allows that.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120776
Jakub Jelinek changed:
What|Removed |Added
Attachment #61817|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120993
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120776
Jakub Jelinek changed:
What|Removed |Added
Attachment #61786|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120471
Jakub Jelinek changed:
What|Removed |Added
Target Milestone|12.5|13.5
--- Comment #22 from Jakub Jelinek
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120954
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P1
Summary|[12/13/14/15 Regr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84009
Jakub Jelinek changed:
What|Removed |Added
Target Milestone|--- |16.0
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120976
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120954
Jakub Jelinek changed:
What|Removed |Added
Target Milestone|15.2|12.5
Summary|[15/16 Regressi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84009
Jakub Jelinek changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120954
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120953
Bug ID: 120953
Summary: Accepts invalid with range for
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Ass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120948
--- Comment #4 from Jakub Jelinek ---
(In reply to Richard Biener from comment #1)
> So you say that we fail to optimize
>
> int foo (unsigned x)
> {
> unsigned tem = 1/x;
> if (x == 0)
> return 5;
> return tem;
> }
>
> because we tu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120948
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120949
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120947
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120940
Jakub Jelinek changed:
What|Removed |Added
Target Milestone|15.2|12.5
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120940
--- Comment #2 from Jakub Jelinek ---
Created attachment 61796
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61796&action=edit
gcc16-pr120940.patch
Brown paper bag time, very sorry.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120940
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120936
--- Comment #6 from Jakub Jelinek ---
E.g.
body: .LFB[0-9]+:
.*\t.cfi_.*
\t1:callmcount
.*
against: .LFB0:
.cfi_startproc
pushq %rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
movq%rsp, %rbp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120936
--- Comment #5 from Jakub Jelinek ---
And
+FAIL: gcc.target/i386/pr120936-10.c check-function-bodies foo
+FAIL: gcc.target/i386/pr120936-11.c check-function-bodies foo
+FAIL: gcc.target/i386/pr120936-12.c check-function-bodies foo
+FAIL: gcc.tar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120936
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120837
--- Comment #17 from Jakub Jelinek ---
Created attachment 61792
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61792&action=edit
gcc16-pr120837.patch
Untested patch which instead of dropping the optimization simply performs
everything in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120471
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120776
--- Comment #2 from Jakub Jelinek ---
Created attachment 61786
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61786&action=edit
gcc16-pr120776-wip.patch
Very early WIP, this can just parse stuff, on say
struct S { int a, b, c; };
struct T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120895
--- Comment #33 from Jakub Jelinek ---
If you want a type that will be always 64-byte aligned, it can be easily
defined, e.g. by
typedef float m512 __attribute__ ((__vector_size__ (64), __may_alias__,
__aligned__ (64)));
and you can then use it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120895
--- Comment #35 from Jakub Jelinek ---
Note, the alignof value for __m512 when -mavx512f is not enabled has been
changed in
r8-7957-gaa2b10551159df as part of the PR69560 https://wg21.link/CWG1879
implementation, the type had the similar propert
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120919
Jakub Jelinek changed:
What|Removed |Added
Summary|[14/15/16 Regression] |[14 Regression]
|gcc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120895
--- Comment #31 from Jakub Jelinek ---
Note, the __m512 type as documented in Intel documentation simply doesn't exist
when the corresponding ISAs aren't enabled.
In older versions of GCC before target attribute and pragmas have been
introduced,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120895
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120471
Jakub Jelinek changed:
What|Removed |Added
Summary|[12/13/14/15/16 regression] |[12/13/14 regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120919
Jakub Jelinek changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
Eve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120919
Jakub Jelinek changed:
What|Removed |Added
Target Milestone|--- |14.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120919
Bug ID: 120919
Summary: [14/15/16 Regression]
gcc.target/powerpc/builtin_altivec_tr_stxvr_runnable.c
fails with -fstack-protector-strong
Product: gcc
Version: 16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118567
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120895
--- Comment #25 from Jakub Jelinek ---
You're wrong. See https://godbolt.org/z/36eGehvTW for details.
All of gcc 13.4, 14.3 and 15.1 say alignof (__m512) is 16 (if AVX is disabled),
32 (if AVX enabled but AVX512F is not) and 64 if AVX512F is en
1 - 100 of 6108 matches
Mail list logo
