https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115766
--- Comment #10 from Bi6c ---
Sorry I pasted the wrong link.
It should be this one https://godbolt.org/z/GM13fhWbb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115978
--- Comment #5 from H.J. Lu ---
(In reply to Hongtao Liu from comment #4)
> To clarify, the question originally came from whether or not to report error
> for -m32,-march=native, and then LLVM folks said it's diffcult for LLVM not
> issuing erro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106800
--- Comment #3 from Richard Biener ---
Created attachment 58699
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58699&action=edit
patches in progress
I've come up with this sofar, it's a bit difficult to navigate the current
behavior wrt.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82904
--- Comment #17 from GCC Commits ---
The master branch has been updated by Andre Vehreschild :
https://gcc.gnu.org/g:0231b076dc98eb02e3289b21ace1757782e3917b
commit r15-2131-g0231b076dc98eb02e3289b21ace1757782e3917b
Author: Andre Vehreschild
D
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106805
--- Comment #11 from GCC Commits ---
The master branch has been updated by Roger Sayle :
https://gcc.gnu.org/g:030186cabe8128e752619e101768cf8823a42c38
commit r15-2132-g030186cabe8128e752619e101768cf8823a42c38
Author: Roger Sayle
Date: Thu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57371
--- Comment #11 from GCC Commits ---
The master branch has been updated by Roger Sayle :
https://gcc.gnu.org/g:030186cabe8128e752619e101768cf8823a42c38
commit r15-2132-g030186cabe8128e752619e101768cf8823a42c38
Author: Roger Sayle
Date: Thu J
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115897
Matthias Kretz (Vir) changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115978
--- Comment #6 from Hongtao Liu ---
(In reply to H.J. Lu from comment #5)
> (In reply to Hongtao Liu from comment #4)
> > To clarify, the question originally came from whether or not to report error
> > for -m32,-march=native, and then LLVM folk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104515
--- Comment #11 from GCC Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:8c67dc40459e3d72e8169b099cc8c5dbdb759da3
commit r15-2133-g8c67dc40459e3d72e8169b099cc8c5dbdb759da3
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115897
--- Comment #8 from Matthias Kretz (Vir) ---
I can work around 'wrong1' and 'wrong3' by replacing std::is_same_v<...> with
__is_same(...).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104515
Richard Biener changed:
What|Removed |Added
Known to work||15.0
Summary|[11/12/13/14/1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108889
--- Comment #10 from GCC Commits ---
The master branch has been updated by Paul Thomas :
https://gcc.gnu.org/g:c3aa339ea50f050caf7ed2e497f5499ec2d7b9cc
commit r15-2135-gc3aa339ea50f050caf7ed2e497f5499ec2d7b9cc
Author: Paul Thomas
Date: Thu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115979
--- Comment #1 from Richard Biener ---
I'd say the frontend should diagnose [[gnu::musttail]] in such a case because
it can use appropriate C++ wording?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115979
--- Comment #2 from Richard Biener ---
(In reply to Richard Biener from comment #1)
> I'd say the frontend should diagnose [[gnu::musttail]] in such a case
> because it can use appropriate C++ wording?
A possible point could be genericization/g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57437
--- Comment #3 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:e217e7dbdc1040e7ee160796e9ca1ef12a0dd1cb
commit r15-2136-ge217e7dbdc1040e7ee160796e9ca1ef12a0dd1cb
Author: Sam James
Date: Thu Ju
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88101
--- Comment #15 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:e217e7dbdc1040e7ee160796e9ca1ef12a0dd1cb
commit r15-2136-ge217e7dbdc1040e7ee160796e9ca1ef12a0dd1cb
Author: Sam James
Date: Thu J
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65345
--- Comment #31 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:e217e7dbdc1040e7ee160796e9ca1ef12a0dd1cb
commit r15-2136-ge217e7dbdc1040e7ee160796e9ca1ef12a0dd1cb
Author: Sam James
Date: Thu J
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53288
--- Comment #7 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:e217e7dbdc1040e7ee160796e9ca1ef12a0dd1cb
commit r15-2136-ge217e7dbdc1040e7ee160796e9ca1ef12a0dd1cb
Author: Sam James
Date: Thu Ju
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96369
--- Comment #10 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:e217e7dbdc1040e7ee160796e9ca1ef12a0dd1cb
commit r15-2136-ge217e7dbdc1040e7ee160796e9ca1ef12a0dd1cb
Author: Sam James
Date: Thu J
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108692
--- Comment #10 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:e217e7dbdc1040e7ee160796e9ca1ef12a0dd1cb
commit r15-2136-ge217e7dbdc1040e7ee160796e9ca1ef12a0dd1cb
Author: Sam James
Date: Thu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102124
--- Comment #11 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:e217e7dbdc1040e7ee160796e9ca1ef12a0dd1cb
commit r15-2136-ge217e7dbdc1040e7ee160796e9ca1ef12a0dd1cb
Author: Sam James
Date: Thu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78466
--- Comment #4 from GCC Commits ---
The master branch has been updated by Andre Vehreschild :
https://gcc.gnu.org/g:18f3b223b97011c2eab71c8e48c3a38a12ff8f65
commit r15-2137-g18f3b223b97011c2eab71c8e48c3a38a12ff8f65
Author: Andre Vehreschild
Da
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80774
--- Comment #13 from GCC Commits ---
The master branch has been updated by Andre Vehreschild :
https://gcc.gnu.org/g:18f3b223b97011c2eab71c8e48c3a38a12ff8f65
commit r15-2137-g18f3b223b97011c2eab71c8e48c3a38a12ff8f65
Author: Andre Vehreschild
D
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110855
--- Comment #5 from Arsen Arsenović ---
agreed, but note that it still gives us the name of the actor function:
pr110855.C:51:1ReturnObject bar(int)
pr110855.C:51:1void bar(bar(int)::_Z3bari.Frame*)
(the latter print is from initial_suspen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115950
Richard Sandiford changed:
What|Removed |Added
CC||rsandifo at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115981
Bug ID: 115981
Summary: Redundant vmovaps to itself after vmovups
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-op
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115950
--- Comment #5 from Richard Sandiford ---
Alternatively, I suppose we could say that svcntp_bN(svptrue_bN(), pg) etc.
should be folded to svcntp_bN(pg, pg) in gimple/expand, and then make the
INCP/DECP wrappers only match the equal-predicate ver
📢 เรียนท่านเจ้าของกิจการ
📢 หากท่านกำลังมองหาทุนหมุนเวียนระยะสั้น
📢 ดอกเบี้ยเริ่มต้น 1.5%
ถ้าท่านสนใจบริการของเรา สอบถามเพิ่มเติมได้เลยครับ
Line ID : esc.credit
โทร : 093-6782499 คุณตะวัน
โทร : 082-5928519 คุณเอก
📢 ไม่ต้องเดินทางเราไปทำสัญญาถึงที่
❌ ทางเราไม่มี นโยบายให้ก่อนทำสัญญาทั้งสิ้น ❌
ขออภัยห
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115982
Bug ID: 115982
Summary: ICE: unrecognizable insn in ira_remove_insn_scratches
with -mavx512vl
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords: ice-on-v
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110057
--- Comment #20 from user202729 ---
(In reply to Jonathan Wakely from comment #19)
> That's easily solved by accessing the new object through the pointer
> returned by the new expression:
>
> std::vector v(1);
> Base* p = v.data();
> p->~Base()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115981
Richard Biener changed:
What|Removed |Added
Summary|Redundant vmovaps to itself |[14/15 Regression]
|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109753
Richard Biener changed:
What|Removed |Added
Depends on||115403
--- Comment #21 from Richard Bi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111475
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115459
Richard Biener changed:
What|Removed |Added
Known to fail||14.1.0
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115754
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115645
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115527
--- Comment #14 from Jakub Jelinek ---
Should be fixed for 15.1+, 14.2+ and 11.5 for now, 13 and 12 backports to be
done later.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115887
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115815
Richard Biener changed:
What|Removed |Added
CC||jamborm at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115753
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115671
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115960
--- Comment #7 from Jonathan Wakely ---
(In reply to Andrew Pinski from comment #6)
> (In reply to Noah Williams from comment #5)
> > It isn't? The library I was trying to compile included the "optional"
> > header, and I had looked it up and fo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115982
Filip Kastl changed:
What|Removed |Added
Target Milestone|--- |15.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115641
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115494
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115406
Richard Biener changed:
What|Removed |Added
Last reconfirmed|2024-06-10 00:00:00 |2024-7-18
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115403
--- Comment #4 from Richard Biener ---
(In reply to Sergei Trofimovich from comment #2)
> `cvise` came up with this example:
>
> //$ cat float_test.cc.cc
> template __attribute__((always_inline)) inline void
> AssertEqual() {}
> vo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113673
--- Comment #10 from GCC Commits ---
The releases/gcc-14 branch has been updated by Richard Biener
:
https://gcc.gnu.org/g:0f593e4cd82eeced5d7666ae6752f238c7dbd7f6
commit r14-10455-g0f593e4cd82eeced5d7666ae6752f238c7dbd7f6
Author: Roger Sayle
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114899
--- Comment #3 from GCC Commits ---
The releases/gcc-14 branch has been updated by Richard Biener
:
https://gcc.gnu.org/g:b0452ed2fdc8bd9d5e911b6ea3166e4cd4be5256
commit r14-10457-gb0452ed2fdc8bd9d5e911b6ea3166e4cd4be5256
Author: David Malcolm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113787
--- Comment #24 from GCC Commits ---
The releases/gcc-14 branch has been updated by Richard Biener
:
https://gcc.gnu.org/g:0b7ec50ae2959153650c0b3dc134c8872ff9fcfc
commit r14-10456-g0b7ec50ae2959153650c0b3dc134c8872ff9fcfc
Author: Jan Hubicka
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115351
--- Comment #6 from GCC Commits ---
The releases/gcc-14 branch has been updated by Richard Biener
:
https://gcc.gnu.org/g:a4c9ade72885f9cf72c873d110545e4e3c2c7805
commit r14-10458-ga4c9ade72885f9cf72c873d110545e4e3c2c7805
Author: Roger Sayle
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115476
--- Comment #11 from GCC Commits ---
The releases/gcc-14 branch has been updated by Richard Biener
:
https://gcc.gnu.org/g:c314867fc06d475e3c2ace32032e0d72e3915b55
commit r14-10459-gc314867fc06d475e3c2ace32032e0d72e3915b55
Author: Marek Polace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115175
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101926
Bug 101926 depends on bug 115351, which changed state.
Bug 115351 Summary: [14 regression] pointless movs when passing by value on
x86-64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115351
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114899
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115351
Richard Biener changed:
What|Removed |Added
Known to fail||14.1.0
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102217
Arsen Arsenović changed:
What|Removed |Added
CC||arsen at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115969
Richard Sandiford changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115983
Bug ID: 115983
Summary: ICE on valid code in gfc_is_nodesc_array, at
fortran/trans-types.cc:
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115641
--- Comment #4 from GCC Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:3670c70c561656a19f6bff36dd229f18120af127
commit r15-2139-g3670c70c561656a19f6bff36dd229f18120af127
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115641
Richard Biener changed:
What|Removed |Added
Known to work||15.0
Summary|[11/12/13/14/1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115984
Bug ID: 115984
Summary: Missed optimization: unnecessary register copies
Product: gcc
Version: 14.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Componen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115049
--- Comment #14 from GCC Commits ---
The master branch has been updated by Jonathan Yong :
https://gcc.gnu.org/g:5080840d8fbf25a321dd27543a1462d393d338bc
commit r15-2140-g5080840d8fbf25a321dd27543a1462d393d338bc
Author: LIU Hao
Date: Mon Ju
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77518
Andre Vehreschild changed:
What|Removed |Added
CC||vehre at gcc dot gnu.org
A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115985
Bug ID: 115985
Summary: anoymous struct with base class rejected by gcc
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115049
--- Comment #15 from GCC Commits ---
The releases/gcc-14 branch has been updated by Jonathan Yong
:
https://gcc.gnu.org/g:747c4b58573ea00419f64293a61537eb69f43307
commit r14-10460-g747c4b58573ea00419f64293a61537eb69f43307
Author: LIU Hao
Date
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101232
--- Comment #8 from Franciszek Witt ---
Created attachment 58700
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58700&action=edit
[patchv2] improvements to the previous patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101232
--- Comment #9 from Franciszek Witt ---
I have implemented the improvement mentioned by Jason and also added the hint
about missing comma or operator.
This patch fails testsuite/g++.dg/parse/error59.C but it was intended to check
for ICE (see PR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103963
Arsen Arsenović changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99575
Arsen Arsenović changed:
What|Removed |Added
CC||fchelnokov at gmail dot com
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115984
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization
Target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105475
Arsen Arsenović changed:
What|Removed |Added
CC||arsen at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114104
Patrick Palka changed:
What|Removed |Added
Status|NEW |RESOLVED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58416
akrl at gcc dot gnu.org changed:
What|Removed |Added
CC||akrl at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115255
Andi Kleen changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115526
--- Comment #26 from GCC Commits ---
The releases/gcc-12 branch has been updated by Uros Bizjak :
https://gcc.gnu.org/g:c5a26fc24b0af61498fae65ccad69d51d63d2a8b
commit r12-10623-gc5a26fc24b0af61498fae65ccad69d51d63d2a8b
Author: Uros Bizjak
Da
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115865
--- Comment #7 from GCC Commits ---
The trunk branch has been updated by Marek Polacek :
https://gcc.gnu.org/g:1e60a6abfece40c7bf55d6ca0a439078d3f5159a
commit r15-2141-g1e60a6abfece40c7bf55d6ca0a439078d3f5159a
Author: Marek Polacek
Date: Th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115526
Uroš Bizjak changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115986
Bug ID: 115986
Summary: [14/15 Regression] ICE in fold_convert_loc, at
fold-const.cc:2644 involving user-defined uint128
literals
Product: gcc
Version: 14.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114661
Roger Sayle changed:
What|Removed |Added
Target Milestone|--- |15.0
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115979
--- Comment #3 from Andi Kleen ---
Doing it in the frontend would require some duplication between C/C++ at least?
I was thinking to just keep searching if has_mustail is set, but was wary of
endless loops walking single basic block precessors.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83324
--- Comment #19 from Andi Kleen ---
Middle/back-end parts are in, still need acks for the C/C++ frontend parts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115987
Bug ID: 115987
Summary: False "possibly dangling reference" false positive
when having an extra template parameter
Product: gcc
Version: 13.3.1
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115865
--- Comment #8 from GCC Commits ---
The releases/gcc-14 branch has been updated by Marek Polacek
:
https://gcc.gnu.org/g:493035c8780cd510a680a791d0c7f94368164352
commit r14-10461-g493035c8780cd510a680a791d0c7f94368164352
Author: Marek Polacek
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115865
Marek Polacek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115987
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109642
Andrew Pinski changed:
What|Removed |Added
CC||durosu at yahoo dot com
--- Comment #22
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115986
Andrew Pinski changed:
What|Removed |Added
Keywords||ice-on-valid-code
Summary|[1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115986
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2024-07-18
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115987
--- Comment #2 from Dan Urosu ---
Hi Andrew,
I cannot use "#pragma GCC diagnostic ignored" because we have thousands of call
sites where we plan to use this kind of code.
And we don't want to disable globally this warning either.
Would "no_da
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115987
--- Comment #3 from Dan Urosu ---
The 109642 is not a duplicate of the attached code.
The error is the same but the code that causes it is completely different.
Also, the "solution" to disable the warning/error is not actually resolving the
iss
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115984
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2024-07-18
Blocks|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115986
Marek Polacek changed:
What|Removed |Added
Priority|P3 |P2
Keywords|needs-bisection
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115986
--- Comment #3 from Valentin Tolmer ---
Some notes:
- The fact that the static_assert fails is not relevant. Changing b() to return
1 still exhibits the error.
- The branch taken in `long f = true ? 0 : b(long(1));` matters; it only fails
if b i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115987
--- Comment #4 from Jonathan Wakely ---
Firstly, you're reporting a false positive warning, so using -Werror just
confuses things. Some warnings have false positives, that's unavoidable. But it
only fails to compile because you used -Werror. Don
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115987
--- Comment #5 from Dan Urosu ---
Ah indeed, but...
In the real use case we call it from macro.
#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wdangling-reference"
template
const T& unwrap_2(const Wrapper& r, FUNC&&) { // n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115985
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115987
--- Comment #6 from Dan Urosu ---
Using the macro with the unwrap_1 does not error.
The GCC behavior is very weird.
On Thursday, July 18, 2024 at 12:44:21 PM EDT, Dan Urosu
wrote:
Ah indeed, but...
In the real use case we call it fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115987
--- Comment #7 from Dan Urosu ---
Why does not warn for unwarp_1?
The mere addition of an unused template parameter triggers this warning.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115987
--- Comment #8 from Dan Urosu ---
Why does not warn for unwarp_1?
The mere addition of an unused template parameter triggers this warning.
Also "decorating the unwrap_2 function to tell the compiler not to warn there."
does not work if we have
1 - 100 of 210 matches
Mail list logo