https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111806
--- Comment #1 from AK ---
It seems like we could 'sink' the 4 common instructions (of .L2) at -O3
L2:
add rsp, 48
xor eax, eax
pop rbx
ret
Or is it due to some kind of tail duplication?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111806
Bug ID: 111806
Summary: g++ generates better code for variant at
-Os compared to -O3
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111805
Bug ID: 111805
Summary: suboptimal codegen of variant
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111804
--- Comment #1 from CTC <19373742 at buaa dot edu.cn> ---
Created attachment 56104
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56104&action=edit
The compiler output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111804
Bug ID: 111804
Summary: wrong code with '-O3 -fno-inline-functions-called-once
-fno-inline-small-functions -fno-toplevel-reorder
-fno-tree-fre'
Product: gcc
Vers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103216
Andrew Pinski changed:
What|Removed |Added
Keywords||TREE
--- Comment #10 from Andrew Pinski
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111803
--- Comment #3 from grbrown ---
(In reply to grbrown from comment #2)
> From my tests though, removing the 'template' will allow it to
> work, so I don't know if you're explanation is entirely correct.
I.e. replace
template
void print(DataType
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111803
--- Comment #2 from grbrown ---
(In reply to Andrew Pinski from comment #1)
> Note clang also rejects this code for the same reason as GCC.
>
> Here is a reduced version which shows the difference between ICC/MSVC and
> GCC/clang:
> ```
> struc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111803
--- Comment #1 from Andrew Pinski ---
Note clang also rejects this code for the same reason as GCC.
Here is a reduced version which shows the difference between ICC/MSVC and
GCC/clang:
```
struct A
{
int data;
};
struct B : A{};
struct Conta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111803
Bug ID: 111803
Summary: Template deduction failure for baseclass member
pointer with template data type
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111218
--- Comment #7 from kargl at gcc dot gnu.org ---
An alternative patch that allows the original code to compile is
diff --git a/gcc/fortran/symbol.cc b/gcc/fortran/symbol.cc
index a6078bc608a..34eb3a65e8f 100644
--- a/gcc/fortran/symbol.cc
+++ b/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111218
kargl at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P4
--- Comment #6 from kargl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111218
--- Comment #5 from kargl at gcc dot gnu.org ---
Interesting bug. If one puts a break point ...
0x75917d gfc_format_decoder
/home/toon/compilers/gcc/gcc/fortran/error.cc:1078
0x2153e1f pp_format(pretty_printer*, text_info*)
/hom
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111432
Andrew Pinski changed:
What|Removed |Added
URL||https://gcc.gnu.org/piperma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111791
JuzheZhong changed:
What|Removed |Added
CC||juzhe.zhong at rivai dot ai
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104698
Michael Meissner changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106271
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |14.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45129
Jerry DeLisle changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53962
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66499
Jerry DeLisle changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83282
Jerry DeLisle changed:
What|Removed |Added
Status|NEW |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83282
Jerry DeLisle changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jvdelisle at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83829
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88052
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97017
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104626
Jerry DeLisle changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jvdelisle at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109105
Jerry DeLisle changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104351
--- Comment #4 from CVS Commits ---
The master branch has been updated by Harald Anlauf :
https://gcc.gnu.org/g:d78fef5371759849944966dec65d9e987efba509
commit r14-4632-gd78fef5371759849944966dec65d9e987efba509
Author: Harald Anlauf
Date: W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110957
--- Comment #3 from CVS Commits ---
The master branch has been updated by Harald Anlauf :
https://gcc.gnu.org/g:458c253ccdae9df439b9a452d04e325101e5756e
commit r14-4631-g458c253ccdae9df439b9a452d04e325101e5756e
Author: Harald Anlauf
Date: F
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93550
Jerry DeLisle changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110644
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
Ever c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111802
Bug ID: 111802
Summary: New analyser diagram failures since commit
b365e9d57ad4
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Prior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111222
Patrick Palka changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111800
--- Comment #8 from Jakub Jelinek ---
Even in the gcc 13 -fdump-tree-ccp1-details I see
PHI node value: CONSTANT
0xff
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111800
--- Comment #7 from Jakub Jelinek ---
Created attachment 56101
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56101&action=edit
gcc14-pr111800.patch
Untested patch to avoid the buffer overflows when printing wide_int/widest_int.
The more
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111222
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111800
Jakub Jelinek changed:
What|Removed |Added
CC||rsandifo at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111797
--- Comment #3 from Paul Floyd ---
With clang 17.0.2 (also tried 14.0) I get
:
0: 55 push %rbp
1: 41 57 push %r15
3: 41 56 push
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111537
ibuclaw at gcc dot gnu.org changed:
What|Removed |Added
CC||ibuclaw at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111800
Jakub Jelinek changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
Last
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111800
--- Comment #4 from Andrew Pinski ---
There looks to be some stack corruption going on; valgrind didn't catch it
though.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111537
--- Comment #9 from Iain Buclaw ---
(In reply to Iain Buclaw from comment #8)
> I see in the olden days when D sat outside of GCC, this is what was done too.
>
> https://github.com/D-Programming-GDC/gdc/commit/
> b9d36fc9d71ec4122d1c986599d87c6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111800
--- Comment #3 from Andrew Pinski ---
(gdb) p this->get_val()
$2 = (const long *) 0x303030303030
That seem wrong.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111801
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2023-10-13
Status|UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111801
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |14.0
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111801
Bug ID: 111801
Summary: [14 Regression] Missed Dead Code Elimination since
r14-4141-gbf6b107e2a3
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: norma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111800
--- Comment #2 from Andrew Pinski ---
Worked at r14-4561-ge8d418df3dc609f27 .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111799
--- Comment #2 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #1)
> Right now I get an ICE while doing -fdump-tree-ccp1-details even:during
Filed PR 111800 for that ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111800
Andrew Pinski changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
Target Miles
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111800
Bug ID: 111800
Summary: [14 Regression] ICE with -fdump-tree-ccp1-details
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111799
--- Comment #1 from Andrew Pinski ---
Right now I get an ICE while doing -fdump-tree-ccp1-details even:during GIMPLE
pass: ccp
dump file: /app/output.cpp.034t.ccp1
: In function 'q':
:42:1: internal compiler error: Segmentation fault
42 | }
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111799
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |14.0
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111799
Bug ID: 111799
Summary: [14 Regression] Missed Dead Code Elimination since
r14-2365-g2e406f0753e
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: norma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111798
Bug ID: 111798
Summary: [14 Regression] Recent change causing testsuite
regression and poor code on mcore-elf
Product: gcc
Version: unknown
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111778
Andrew Pinski changed:
What|Removed |Added
CC||zsojka at seznam dot cz
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111746
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111778
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |14.0
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111661
--- Comment #3 from Patrick Bégou ---
Hi Tobias,
thanks for this information.
- yes removing the "finalize" make this small test case working. In my
mind it should only remove the allocated attribute from the GPU with
setting the count to zer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111622
Andrew Macleod changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111622
--- Comment #8 from CVS Commits ---
The releases/gcc-13 branch has been updated by Andrew Macleod
:
https://gcc.gnu.org/g:1c2bd0839e3574ab2a76ec18faf906b2f64b5f81
commit r13-7949-g1c2bd0839e3574ab2a76ec18faf906b2f64b5f81
Author: Andrew MacLeod
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111622
--- Comment #7 from CVS Commits ---
The master branch has been updated by Andrew Macleod :
https://gcc.gnu.org/g:8be20f3b0bded7f9b690b27cbee58b283dbe827b
commit r14-4630-g8be20f3b0bded7f9b690b27cbee58b283dbe827b
Author: Andrew MacLeod
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111796
--- Comment #6 from Richard Biener ---
GCN handles this fine using simdlen(64).
[local count: 939524096]:
# ivtmp.31_10 = PHI
vectp_x.27_17 = (vector(64) int *) ivtmp.31_10;
vect__4.24_14 = MEM [(int *)vectp_x.27_17];
vect__5.25_15
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111797
--- Comment #2 from Paul Floyd ---
(In reply to Richard Biener from comment #1)
> I think it's easiest to use a frame pointer when custom stack alignment is
> needed both for the return path and accessing arguments on the stack.
But is it faste
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111796
Richard Biener changed:
What|Removed |Added
Target||x86_64-*-*
--- Comment #5 from Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111591
--- Comment #19 from Richard Biener ---
So maybe it's the same issue as PR90348 (you can verify the RTL expansion dump
on whether the two involved decls are coalesced and see whether that's valid).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
Bug 53947 depends on bug 111795, which changed state.
Bug 111795 Summary: OMP SIMD inbranch call vectorization missing for AVX512
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111795
What|Removed |Added
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111795
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111795
--- Comment #2 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:3179ad72f67f31824c444ef30ef171ad7495d274
commit r14-4629-g3179ad72f67f31824c444ef30ef171ad7495d274
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111796
--- Comment #4 from Richard Biener ---
(In reply to Richard Biener from comment #3)
> (In reply to Richard Biener from comment #1)
> > It's the promote_prototypes hook btw.
>
> Of the major targets (x86, arm, aarch64, powerpc, s390, riscv) only
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111796
--- Comment #3 from Richard Biener ---
(In reply to Richard Biener from comment #1)
> It's the promote_prototypes hook btw.
Of the major targets (x86, arm, aarch64, powerpc, s390, riscv) only x86
defines the hook to true. But there are a lot o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111591
--- Comment #18 from Kewen Lin ---
(In reply to Richard Biener from comment #17)
> it stores to a different object - but seeing the CLOBBERs, does
> -fstack-reuse=none fix the issue? Is r1 the stack pointer?
Just tried with -fstack-reuse=none,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111796
--- Comment #2 from Richard Biener ---
We could also decide to only apply promote_prototype at RTL expansion time?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111796
--- Comment #1 from Richard Biener ---
It's the promote_prototypes hook btw.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111797
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization
Target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111797
Bug ID: 111797
Summary: Code generation of -march=znver2 -O3 includes frame
pointer
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111591
--- Comment #17 from Richard Biener ---
it stores to a different object - but seeing the CLOBBERs, does
-fstack-reuse=none fix the issue? Is r1 the stack pointer?
ref-all is carried to RTL by MEM_ALIAS_SET == 0.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111746
--- Comment #2 from Zdenek Sojka ---
Maybe fixed by the PR111778 patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111746
--- Comment #1 from Zdenek Sojka ---
This seems to have got fixed between gdfb40855a08 (BAD) and g0f40e59f193
(GOOD).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111796
Bug ID: 111796
Summary: OMP SIMD call vectorization fails for arguments
subject to integer promotion rules
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Sever
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111591
--- Comment #16 from Kewen Lin ---
Tracing down it with template specialization, the aborting happens on
auto vn_b = Load(dn, in_b.get());
HWY_ASSERT_VEC_EQ(
dw, vw_signed_max,
SatWidenMulPairwiseAdd(
dw, InterleaveLow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111793
--- Comment #5 from Richard Biener ---
(In reply to Jakub Jelinek from comment #4)
> So, shouldn't we match.pd (or something else) pattern match
> vect_cst__50 = {mask.48_7(D), mask.48_7(D), mask.48_7(D), mask.48_7(D),
> mask.48_7(D), mask.48_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111793
--- Comment #4 from Jakub Jelinek ---
So, shouldn't we match.pd (or something else) pattern match
vect_cst__50 = {mask.48_7(D), mask.48_7(D), mask.48_7(D), mask.48_7(D),
mask.48_7(D), mask.48_7(D), mask.48_7(D), mask.48_7(D), mask.48_7(D),
mas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111793
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111661
--- Comment #2 from Tobias Burnus ---
@Patrick: It seems to work fine without "finalize".
Can you check whether the big program then works for you?
Usually, one should be able to do proper ref counting such that a
'finalize' -> force setting r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111795
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111795
Bug ID: 111795
Summary: OMP SIMD inbranch call vectorization missing for
AVX512
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Prior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111794
--- Comment #4 from Robin Dapp ---
Just to mention here as well. As this seems ninstance++ where the
adjust_precision thing comes back to bite us, I'm going to go back and check if
the issue why it was introduced (DCE?) cannot be solved differe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111794
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization
--- Comment #3 fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111600
--- Comment #27 from rguenther at suse dot de ---
On Fri, 13 Oct 2023, rdapp at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111600
>
> --- Comment #26 from Robin Dapp ---
> So insn-opinit.cc still takes 2-3 minutes t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111600
--- Comment #26 from Robin Dapp ---
So insn-opinit.cc still takes 2-3 minutes to compile here, even though the file
is not gigantic.
With the same GCC 13.1 x86 host compiler I see:
phase opt and generate : 170.28 ( 99%) 0.75 ( 48
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111776
--- Comment #2 from Lénárd Szolnoki ---
Same ICE without destroying delete:
```
struct A {
void operator delete(void *);
};
struct B {
void operator delete(void *);
};
struct C : A, B {
using A::operator delete;
using B::opera
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111794
--- Comment #2 from JuzheZhong ---
Note that the reason we adjust the mask mode precision here is because
the DSE bug for "small mask mode"
https://github.com/gcc-mirror/gcc/commit/247cacc9e381d666a492dfa4ed61b7b19e2d008f
This is the commit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111794
--- Comment #1 from JuzheZhong ---
This is RISC-V target specific issue.
ARM SVE can vectorize it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111793
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111794
Bug ID: 111794
Summary: RISC-V: Missed SLP optimization due to mask mode
precision
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111793
Richard Biener changed:
What|Removed |Added
Blocks||53947
Target|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111600
--- Comment #25 from Robin Dapp ---
At least here locally the maximum I saw was 1.4 GB of RES for insn-emit-10.cc.
That's still not ideal (especially when 8 or 10 of those files compile in
parallel) but at least no 8 GB for a single file anymor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111793
Bug ID: 111793
Summary: OpenMP SIMD inbranch clones for AVX are highly
sub-optimal
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111788
--- Comment #3 from Giuliano Procida ---
https://en.cppreference.com/w/cpp/language/variadic_arguments (see introduction
and Notes)
It's been allowed for longer than in C, but there is no portable way of
accessing the arguments.
99 matches
Mail list logo
