https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121643
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121643
Andrew Pinski changed:
What|Removed |Added
Attachment #62176|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121643
Andrew Pinski changed:
What|Removed |Added
Known to fail||15.2.0
Summary|Internal comp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121643
Bug ID: 121643
Summary: Internal compiler error when await_suspend takes
default argument
Product: gcc
Version: 15.2.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121636
--- Comment #8 from Andrew Pinski ---
(In reply to Huiba Li from comment #7)
> > ```
> > struct A {
> > A(int, int = 0);
> > A(int, int, int = 0) = delete;
> > };
> > struct B : A {
> > using A::A;
> > };
> > B b(1);
> >
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121644
Bug ID: 121644
Summary: inh-ctor11a.C xfailed
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Keywords: FIXME, testsuite-fail, xfail
Severity: normal
Priority:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524
Bug 103524 depends on bug 120499, which changed state.
Bug 120499 Summary: import std: indirect use of an exported class using a
vector yields undefined symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120499
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120499
Nathaniel Shead changed:
What|Removed |Added
Target Milestone|--- |16.0
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120499
--- Comment #3 from GCC Commits ---
The master branch has been updated by Nathaniel Shead :
https://gcc.gnu.org/g:5b85364a6dd0bbfd3e26d3346b075a0819be7cd4
commit r16-3353-g5b85364a6dd0bbfd3e26d3346b075a0819be7cd4
Author: Nathaniel Shead
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121636
--- Comment #7 from Huiba Li ---
> ```
> struct A {
> A(int, int = 0);
> A(int, int, int = 0) = delete;
> };
> struct B : A {
> using A::A;
> };
> B b(1);
>
> ```
>
> This is rejected by GCC and EDG while accepted by clan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118481
--- Comment #3 from Andrew Pinski ---
BIT_INSERT_EXPR ;
That above should just be VCE<>(iftmp.1_2) since the size of a.0_1 is 8 bits.
That should be done anyways as that will remove the dependency on a.0_1 there.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65846
H.J. Lu changed:
What|Removed |Added
Resolution|--- |WONTFIX
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101446
Matteo Nicoli changed:
What|Removed |Added
CC||matteo.nicoli001 at gmail dot
com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117818
--- Comment #12 from Segher Boessenkool ---
Hrm, yeah, the ISA says bits 57..63 of VRB. That seems wrong, 121..127 is more
logical. Let me test what existing hardware does.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115974
Andrew Pinski changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109112
Andrew Pinski changed:
What|Removed |Added
CC||pinskia at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115975
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118857
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120811
--- Comment #9 from Jeffrey A. Law ---
Costing should prevent mvconst_internal from causing problems in this case.
>From the compiler's current cost model mvconst_internal+add has the same cost
as addi+addi. So there's no reason for combine to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79002
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |FIXED
See Also|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121498
--- Comment #11 from Jeffrey A. Law ---
I still need to throw it under a debugger, but I suspect it's the whole
prologue/epilogue shrink wrapping that's the problem here. The component based
shrink wrapping code excludes RA.
Assuming that's th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=10837
--- Comment #28 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #27)
> (In reply to Josh Haberman from comment #26)
> > I have just noticed a very odd edge case though; if multiple functions in
> > a file make tail calls to a noret
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121642
Bug ID: 121642
Summary: ICF loses musttail due to inlining
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Keywords: diagnostic, tail-call
Severity: normal
Prio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=10837
--- Comment #27 from Andrew Pinski ---
(In reply to Josh Haberman from comment #26)
> I have just noticed a very odd edge case though; if multiple functions in
> a file make tail calls to a noreturn function, only the first one defined
> in the f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117455
jsberg at bnl dot gov changed:
What|Removed |Added
CC||jsberg at bnl dot gov
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=10837
--- Comment #26 from Josh Haberman ---
I have just noticed a very odd edge case though; if multiple functions in
a file make tail calls to a noreturn function, only the first one defined
in the file is a tail call! https://godbolt.org/z/exKE7GKM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=10837
--- Comment #25 from Josh Haberman ---
(In reply to Lukas Grätz from comment #24)
> (In reply to Josh Haberman from comment #23)
> > (In reply to Lukas Grätz from comment #22)
> > > I think the status should be changed into RESOLVED FIXED now. Af
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109740
Derek Martin changed:
What|Removed |Added
CC||quirkygnu at bladeshadow dot
org
--- Co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121640
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121640
--- Comment #2 from Derek Martin ---
Making it private doesn't solve the issue, since the derived class can itself
still incorrectly call the private included method. Not likely to happen in
the oversimple example I gave but perhaps more so in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115201
Andrew Pinski changed:
What|Removed |Added
Keywords|FIXME |EH
--- Comment #11 from Andrew Pinski
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121595
--- Comment #6 from Andrew Pinski ---
(In reply to Matteo Nicoli from comment #5)
> Created attachment 62175 [details]
> A patch to fix 121595
>
> I attached a patch for this issue; Hope I haven't violated the coding
> standards. I added a coup
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90795
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |WAITING
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121640
--- Comment #1 from Andrew Pinski ---
I am not 100% sure since you can do:
```
private:
// Use the GCC-documented solution
using Request::set_options;
```
Which makes the inheirted set_options private.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=10837
--- Comment #24 from Lukas Grätz ---
(In reply to Josh Haberman from comment #23)
> (In reply to Lukas Grätz from comment #22)
> > I think the status should be changed into RESOLVED FIXED now. After PR
> > 119483 and PR 121159 with GCC 16+ and 15
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117818
--- Comment #11 from Steven Munroe ---
(In reply to Segher Boessenkool from comment #10)
> Btw, from power10 on (arch 3.1 and later) vslq (and vsrq) are preferred :-)
Noted. PVECLIB will generate these for #if defined(_ARCH_PWR10)
https://munro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121203
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Target Milestone|--- |15.2
Status|ASSI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121641
Bug ID: 121641
Summary: Rejects valid constexpr explicitly defaulted
constructor which is never a constant expression
(P2448R2)
Product: gcc
Version: 16.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121640
Bug ID: 121640
Summary: -Woverloaded-virtual is probably bad
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121636
Andrew Pinski changed:
What|Removed |Added
Summary|incorrect invocation to |[13/14/15/16 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121636
--- Comment #6 from Andrew Pinski ---
https://cplusplus.github.io/CWG/issues/1941.html as far as I can tell is the
defect report and reading the end part of
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0136r1.html . This
needs a lan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121145
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120784
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Target Milestone|--- |14.4
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121636
--- Comment #5 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #4)
> So the change in GCC 7 was done due to:
> https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0136r1.html
That is r7-4255 .
Here is another example whic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121636
--- Comment #4 from Andrew Pinski ---
So the change in GCC 7 was done due to:
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0136r1.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63426
Bug 63426 depends on bug 118890, which changed state.
Bug 118890 Summary: ubsan bootstrap failure for powerpc64le-unknown-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118890
What|Removed |Added
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=10837
Josh Haberman changed:
What|Removed |Added
CC||jhaberman at gmail dot com
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121636
--- Comment #3 from Andrew Pinski ---
So here is a summary of the compilers:
MSVC, clang: calls C1 for derived
GCC, EDG: calls C2 for derived
I have not looked to see if there is a defect report to C++ yet about this.
Especially when half of t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121636
--- Comment #2 from Andrew Pinski ---
I am not saying this is correct but GCC is acting like the following code:
```
typedef double T;
template
void f(const T(&arr)[N], int asdf = 468)
{
__builtin_printf("f()\n");
}
void f(const T* arr, int n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120784
--- Comment #14 from GCC Commits ---
The releases/gcc-14 branch has been updated by Harald Anlauf
:
https://gcc.gnu.org/g:97ad2824f4faffd5da6e90e91f3dbfcc4bb3cc25
commit r14-11975-g97ad2824f4faffd5da6e90e91f3dbfcc4bb3cc25
Author: Harald Anlauf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121595
--- Comment #5 from Matteo Nicoli ---
Created attachment 62175
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=62175&action=edit
A patch to fix 121595
I attached a patch for this issue; Hope I haven't violated the coding
standards. I added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121145
--- Comment #5 from GCC Commits ---
The releases/gcc-14 branch has been updated by Harald Anlauf
:
https://gcc.gnu.org/g:087fe1daf1024c3d481b708c40cf47cc26b06a3a
commit r14-11976-g087fe1daf1024c3d481b708c40cf47cc26b06a3a
Author: Harald Anlauf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120784
--- Comment #13 from GCC Commits ---
The releases/gcc-14 branch has been updated by Harald Anlauf
:
https://gcc.gnu.org/g:6fc73d887341122dce5df56b0eaac1244e57e766
commit r14-11974-g6fc73d887341122dce5df56b0eaac1244e57e766
Author: Harald Anlauf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121635
--- Comment #4 from Sergei Trofimovich ---
The change fixed nodejs-22.18.0 build for me as well. Thank you!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118890
Kishan Parmar changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108001
--- Comment #2 from Andrew Pinski ---
Funny how I was just going to file this bug again today due to PR 121637.
So what is not documented is the rejecting of fields that have a constructor or
deconstructor. unamed structs that are fields can't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118890
--- Comment #8 from GCC Commits ---
The master branch has been updated by kishan parmar :
https://gcc.gnu.org/g:9d63110c4334335a920424c301691dae9ecf398f
commit r16-3351-g9d63110c4334335a920424c301691dae9ecf398f
Author: Kishan Parmar
Date: S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=10
Andrew Pinski changed:
What|Removed |Added
Resolution|DUPLICATE |---
Status|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121638
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Version|unknown
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114986
--- Comment #2 from TC ---
It seems like what it does is that it ignores the attribute's effect on the
specific member, but still applies it on the other members. Consider:
struct Short { short x = {}; };
struct __attribute__((packed)) Y
{
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121638
--- Comment #1 from Andrew Pinski ---
Created attachment 62174
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=62174&action=edit
Little more reduced
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121639
Bug ID: 121639
Summary: [OpenMP] ICE when trying to map a member variable of
reference type
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Keywords: ice-on-val
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121638
Andrew Pinski changed:
What|Removed |Added
Target||aarch64 x86_64
Summary|wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121598
TC changed:
What|Removed |Added
CC||rs2740 at gmail dot com
--- Comment #1 from TC --
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120553
Jeffrey A. Law changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120553
--- Comment #10 from GCC Commits ---
The master branch has been updated by Jeff Law :
https://gcc.gnu.org/g:ebbeaf490c56e04d2e9be25caf9522ef5fba6c72
commit r16-3350-gebbeaf490c56e04d2e9be25caf9522ef5fba6c72
Author: Jeff Law
Date: Fri Aug 22
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117818
--- Comment #10 from Segher Boessenkool ---
Btw, from power10 on (arch 3.1 and later) vslq (and vsrq) are preferred :-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121633
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121637
Andrew Pinski changed:
What|Removed |Added
Keywords||accepts-invalid
--- Comment #1 from And
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120811
--- Comment #8 from Vineet Gupta ---
(In reply to Jeffrey A. Law from comment #5)
> So a bit of clarification here from the patchwork meeting today.
>
> Shreya's work isn't meant to directly fix this particular issue, though it
> is very closel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121627
--- Comment #6 from kargls at comcast dot net ---
(In reply to Dustin Warkotsch from comment #5)
>
> Huh, I didn't notice that. I just took the name from the example program in
> the "selected_real_kind" GCC doc (
> https://gcc.gnu.org/onlinedoc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121614
--- Comment #6 from Nathaniel Shead ---
(In reply to m...@duck.com from comment #5)
> I would try to make a feature request for gcc to add an option to check
> whether CMI is included in the archive with object (also not yet implemented
> "modul
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121614
--- Comment #5 from mtxn at duck dot com ---
(In reply to Nathaniel Shead from comment #4)
> Hi, thanks for the report!
>
> The issue looks to be with the Makefile, GCC is behaving correctly here. A
> module TU also should produce an object fi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121638
Bug ID: 121638
Summary: wrong code at -O3 with "-fno-tree-vrp
-fno-tree-scev-cprop" on x86_64-linux-gnu
Product: gcc
Version: unknown
Status: UNCONFIRMED
Sever
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121637
Bug ID: 121637
Summary: Anonymous structs with GCC are broken
Product: gcc
Version: 15.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121635
--- Comment #2 from GCC Commits ---
The master branch has been updated by H.J. Lu :
https://gcc.gnu.org/g:e12208722dabdad25cc13bb580991b5bf511a104
commit r16-3345-ge12208722dabdad25cc13bb580991b5bf511a104
Author: H.J. Lu
Date: Fri Aug 22 05
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121636
--- Comment #1 from Huiba Li ---
```diff
- https://wandbox.org/permlink/d3W0Mr3WvO0SCDZG
+ https://wandbox.org/permlink/9rKAQBU6d1ga5qaZ
-derived z(x); // should be "C2: 0x?, 3, 0", but it is
"C2: 0x?, 468, 0"
+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121636
Bug ID: 121636
Summary: inherited templated constructor invocation wrong
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121635
H.J. Lu changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121634
--- Comment #5 from Xi Ruoyao ---
It turns out to be a stupid pasto:
diff --git a/gcc/config/loongarch/simd.md b/gcc/config/loongarch/simd.md
index dd17cd13fc5..4156b269f9a 100644
--- a/gcc/config/loongarch/simd.md
+++ b/gcc/config/loongarch/si
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121635
H.J. Lu changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121604
--- Comment #2 from Jennifer Schmitz ---
Thanks for catching this.
Both svbrka and svbrkb produce wrong code with _m predication. Same for
svpmov_lane with _m and a pfalse predicate.
The problem for svbrka/b is that they get folded by the code i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121634
Xi Ruoyao changed:
What|Removed |Added
Priority|P3 |P2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121634
Xi Ruoyao changed:
What|Removed |Added
Ever confirmed|0 |1
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121634
--- Comment #4 from Xi Ruoyao ---
(insn 10 9 11 2
(set (reg:V4SI 82 [ _6 ])
(plus:V4SI
(mult:V4SI
(sign_extend:V4SI
(vec_select:V4HI (reg:V8HI 88)
(parallel [
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121634
Xi Ruoyao changed:
What|Removed |Added
Known to fail||15.2.0, 16.0
Summary|internal co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121634
--- Comment #2 from Xi Ruoyao ---
typedef short v8i16 __attribute__((vector_size(16)));
typedef long __m128i __attribute__((__vector_size__(16)));
__m128i __lsx_vmaddwod_w_h__1, WidenMulPairwiseAdd___trans_tmp_2;
template using CappedTag = int;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121627
--- Comment #5 from Dustin Warkotsch ---
(In reply to kargls from comment #2)
> (In reply to kargls from comment #1)
> > This leads to the same ICE without the overhead of a Fortran IO statement.
> >
> > program real_kinds
> > use iso_fortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121634
Richard Biener changed:
What|Removed |Added
Keywords||needs-bisection
--- Comment #1 from Ri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121635
Richard Biener changed:
What|Removed |Added
Keywords||ice-on-valid-code
Target Milestone|-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118748
--- Comment #15 from user3mila at disroot dot org ---
I tried this and the problem persists:
export CFLAGS="-O0 -fstack-clash-protection -Wformat -Werror=format-security
-fstack-reuse=none"
export CXXFLAGS="-O0 -fstack-clash-protection -Wformat
-disable-bootstrap --disable-lto --disable-libsanitizer
--disable-libstdcxx-pch --enable-languages=c,c++ --disable-libgomp
--disable-libquadmath --disable-libvtv CFLAGS='-O1 -g0' CXXFLAGS='-O1 -g0'
LDFLAGS='-O1 -g0'
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 16.0.0 20250822 (experimental) (GCC)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121634
Bug ID: 121634
Summary: internal compiler error: in new_binary_operation, at
vector-builder.h:300 compiling highway gtest on
LoongArch with -O2 -mlasx
Product: gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121633
Bug ID: 121633
Summary: missed optimization for carry on ARM
Product: gcc
Version: 15.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83161
--- Comment #8 from uecker at gcc dot gnu.org ---
And one very unfortunate choice in the design of the clang feature is that the
output is not legal C.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83161
--- Comment #7 from Richard Biener ---
C++ reflection should be able to implement this in the library?
Of course this is useful for C as well, but as clang defines it is necessarily
to be handled from the frontend(s).
96 matches
Mail list logo
