https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116289
--- Comment #8 from Fedor Chelnokov ---
Thanks for quick fix.
A workaround for this issue in GCC 13.3 is to declare spaceship operator as
constexpr:
```
int main() {
struct A {
int x = 0;
constexpr auto operator<=>(const A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116321
Bug ID: 116321
Summary: [lra][avr] internal compiler error: in
avr_out_lpm_no_lpmx, at config/avr/avr.cc:4572
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Se
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116321
Georg-Johann Lay changed:
What|Removed |Added
Keywords||ice-on-valid-code, ra
St
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113934
--- Comment #10 from Georg-Johann Lay ---
(In reply to Segher Boessenkool from comment #9)
> (In reply to Georg-Johann Lay from comment #4)
> > Would someone please explain what has to be done?
> >
> > It's likely more than just
> >
> > #defin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116292
--- Comment #10 from Andre Vehreschild ---
A fix is in prep. At the moment it still regresses. So stay tuned.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116322
Bug ID: 116322
Summary: regenerate-opt-urls.py usage
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
Ass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116323
Bug ID: 116323
Summary: ICE: tree check: expected record_type or union_type or
qual_union_type, have bound_template_template_parm in
access_in_type, at cp/search.cc:663
Pro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116324
Bug ID: 116324
Summary: [lra] error: inconsistent operand constraints in an
'asm'
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Pri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116324
Georg-Johann Lay changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116322
Sam James changed:
What|Removed |Added
CC||mark at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113934
--- Comment #11 from Georg-Johann Lay ---
LRA even breaks building libgcc: PR116324
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116325
Bug ID: 116325
Summary: [lra] error: unable to generate reloads for:
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116325
Georg-Johann Lay changed:
What|Removed |Added
Ever confirmed|0 |1
Target|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116326
Bug ID: 116326
Summary: [lra] internal compiler error: in get_reload_reg, at
lra-constraints.cc:755
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116326
Georg-Johann Lay changed:
What|Removed |Added
Last reconfirmed||2024-08-10
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116236
Georg-Johann Lay changed:
What|Removed |Added
CC||gjl at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116322
--- Comment #2 from Georg-Johann Lay ---
And it may be easier to use when we had a $builddir/gcc/regenerate-opt-urls.py
built by configure
1) $builddir/gcc/regenerate-opt-urls.py would know where $srcdir is.
2) $builddir/gcc/regenerate-opt-url
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116282
--- Comment #2 from Jeffrey A. Law ---
I haven't fully debugged, but I strongly suspect this is a case where matching
is inconsistent before/after LRA due to the paths through the constant
synthesis code which check if we can create new pseudos.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116244
--- Comment #3 from Jeffrey A. Law ---
Adjusting subreg_regno isn't going to work. reload depends on it producing
"bogus" results to then trigger reloading inner parts of the subreg
expressions. Adjusting alter_reg might be an option.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116319
--- Comment #4 from SHIH YEN-TE ---
I see, thank you.
So, sounds like that if I don't implement the math by myself.
For this case, we don't have a STL function to get the answer looks like
infinite precision without doing rounding twice? In oth
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116327
Bug ID: 116327
Summary: ICE in coroutine with parameter preview on lambda with
captures.
Product: gcc
Version: 14.2.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116327
--- Comment #1 from John Eivind Helset ---
Created attachment 58899
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58899&action=edit
Reproducer, compile with --std=c++20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116236
--- Comment #8 from Jeffrey A. Law ---
If you have a case where a pseudo register is normally valid, but a MEM would
not be valid. Then you reject that case when strict is on and the pseudo did
not get a hard register.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116327
--- Comment #2 from John Eivind Helset ---
had to revert both changes in 066c7893eae to compile my hobby project without
ICE.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116260
--- Comment #4 from Sam James ---
(In reply to Christophe Lyon from comment #3)
> Thanks for the additional information, indeed in our CI we do not run
> validations for several "variations", so it's not surprising this case is
> not handled ver
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116236
--- Comment #9 from Andreas Schwab ---
The ADDR_SPACE hooks are only used if the target has support for named address
spaces.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70150
--- Comment #37 from GCC Commits ---
The master branch has been updated by Xi Ruoyao :
https://gcc.gnu.org/g:331f7d8a393af99afccdb2729d4ab45797fd7a86
commit r15-2869-g331f7d8a393af99afccdb2729d4ab45797fd7a86
Author: Xi Ruoyao
Date: Mon May 6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70150
--- Comment #38 from GCC Commits ---
The master branch has been updated by Xi Ruoyao :
https://gcc.gnu.org/g:8035619b7313d9503852e1c7c8c06cfddca4d648
commit r15-2870-g8035619b7313d9503852e1c7c8c06cfddca4d648
Author: Xi Ruoyao
Date: Mon May 6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116321
--- Comment #1 from Georg-Johann Lay ---
What I do not understand is when I also set -mlog=legitimate_address_p then I
only get logs that have strict=0 and not a single one with strict=1, like:
avr_addr_space_legitimate_address_p[fun64:split5(3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116236
--- Comment #10 from Georg-Johann Lay ---
What do we do when strict=0 and legitimate_address_p passes a hard register
that is not valid? Reject it? Or is that fine and ra will fix it?
(There are cases where passes like insn combine are propag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86476
frankhb1989 at gmail dot com changed:
What|Removed |Added
CC||frankhb1989 at gmail dot co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116323
Andrew Pinski changed:
What|Removed |Added
Known to work||10.1.0
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116236
--- Comment #11 from Jeffrey A. Law ---
In general I would think rejecting is right way to go under the general
guidance of making the predicates and such match what the underlying hardware
can actually do. So for example, if we we have (mem (r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115205
--- Comment #7 from Mahesh Madhav ---
I built the current mainline and added the patch, but we still have an ICE.
Maybe it gets further?
Using the artifacts in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116248
$ /usr/local/gcc-15.0.0-2024080
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115205
--- Comment #8 from Andrew Pinski ---
(In reply to Mahesh Madhav from comment #7)
> I built the current mainline and added the patch, but we still have an ICE.
> Maybe it gets further?
>
> Using the artifacts in https://gcc.gnu.org/bugzilla/sho
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116221
--- Comment #6 from Sam James ---
That works for me, thanks!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102217
John Eivind Helset changed:
What|Removed |Added
CC||jehelset at gmail dot com
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115205
--- Comment #9 from Mahesh Madhav ---
I confirm that is the full fix. There are no errors anymore! Thank you.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108357
Jorn Wolfgang Rennecke changed:
What|Removed |Added
CC||amylaar at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114855
--- Comment #20 from Andrew Macleod ---
I did an -O2 run after those patches.
Highlights:
tree SSA incremental : 117.74 ( 1%) 0.63 ( 3%) 120.37 ( 1%)
1049M ( 24%)
dominator optimization : 680.49 ( 5%) 0.65
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #154 from John Paul Adrian Glaubitz ---
(In reply to John Paul Adrian Glaubitz from comment #151)
> (In reply to Kazumoto Kojima from comment #147)
> > (In reply to John Paul Adrian Glaubitz from comment #145)
> >
> > Looks that some
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116319
SHIH YEN-TE changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVALID
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116319
SHIH YEN-TE changed:
What|Removed |Added
Summary|std::fma should compute as |std::fma doesn't compute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116319
--- Comment #7 from Andrew Pinski ---
(In reply to SHIH YEN-TE from comment #5)
> Sorry, could you please confirm if there is any standard function in library
> can compute bfloat16_t without rounding twice as if to infinite precision?
> Thank
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116319
SHIH YEN-TE changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111654
--- Comment #8 from Eric Gallager ---
(In reply to Julian Waters from comment #7)
> I recently stumbled upon -Wno-attributes, which can apparently take a
> parameter like -Wno-attributes=vendor:: and I think that's appropriate for
> this particu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109565
Eric Gallager changed:
What|Removed |Added
CC||egallager at gcc dot gnu.org
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116328
Bug ID: 116328
Summary: Sub-optimal code generated on Arm M0+ when accessing
fields using a proxy object
Product: gcc
Version: 13.3.1
Status: UNCONFIRMED
Sever
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116328
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65371
Andrew Pinski changed:
What|Removed |Added
CC||terrygreeniaus at gmail dot com
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41458
Andrew Pinski changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3506
Andrew Pinski changed:
What|Removed |Added
CC||tobias at ringis dot se
--- Comment #16 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41458
--- Comment #4 from Andrew Pinski ---
I meant 60749.
*** This bug has been marked as a duplicate of bug 60749 ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60749
Andrew Pinski changed:
What|Removed |Added
CC||tobias at ringis dot se
--- Comment #4 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60749
Andrew Pinski changed:
What|Removed |Added
CC||gcc-bugzilla at enginuities
dot co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65371
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49807
Andrew Pinski changed:
What|Removed |Added
CC||tobias at ringis dot se
--- Comment #7 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41458
--- Comment #5 from Andrew Pinski ---
Actually PR 49807 but all are the same.
*** This bug has been marked as a duplicate of bug 49807 ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116329
--- Comment #1 from Terry Greeniaus ---
I was using -O2 as well when compiling, which I omitted from the bug report by
accident.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116329
Bug ID: 116329
Summary: Arm M0+ doesn't do tail-call optimization
Product: gcc
Version: 13.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
60 matches
Mail list logo
