https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99852
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Ever confirmed|0 |1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99852
--- Comment #2 from anlauf at gcc dot gnu.org ---
*** Bug 104848 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104848
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |DUPLICATE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28032
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113682
Tamar Christina changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92178
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Assignee|anlauf at gcc dot gnu.org |mikael at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106987
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114526
--- Comment #13 from Kaz Kylheku ---
(In reply to Joseph S. Myers from comment #11)
> I think that simply failing to say whether a value of type X may be
> converted to type Y is clearly enough for it at least to be unspecified
> whether or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114533
Jakub Jelinek changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103707
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|WAITING
--- Comment #10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114533
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113799
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114526
--- Comment #12 from Kaz Kylheku ---
(In reply to Harald van Dijk from comment #10)
> Sorry, sent my earlier comment too soon.
>
> (In reply to Joseph S. Myers from comment #8)
> > I believe conversions between function and object pointers are
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114526
--- Comment #11 from Joseph S. Myers ---
I think that simply failing to say whether a value of type X may be converted
to type Y is clearly enough for it at least to be unspecified whether or when
such conversions are possible in a cast at all
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106987
--- Comment #9 from GCC Commits ---
The releases/gcc-13 branch has been updated by Harald Anlauf
:
https://gcc.gnu.org/g:2808797fc4da7cc455803e2b69368b52db857b4c
commit r13-8559-g2808797fc4da7cc455803e2b69368b52db857b4c
Author: Harald Anlauf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114533
--- Comment #8 from Jakub Jelinek ---
I guess we should go with the above patch after fixing formatting, but it isn't
enough,
printf_fphex.c has similar code.
Even in glibc which doesn't support printing _Float128 nor any other type which
would
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103707
--- Comment #9 from GCC Commits ---
The releases/gcc-13 branch has been updated by Harald Anlauf
:
https://gcc.gnu.org/g:2808797fc4da7cc455803e2b69368b52db857b4c
commit r13-8559-g2808797fc4da7cc455803e2b69368b52db857b4c
Author: Harald Anlauf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104352
--- Comment #6 from GCC Commits ---
The releases/gcc-13 branch has been updated by Harald Anlauf
:
https://gcc.gnu.org/g:0dd82c0fba660775ff76ae27077a67f2f1358920
commit r13-8557-g0dd82c0fba660775ff76ae27077a67f2f1358920
Author: Harald Anlauf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95374
--- Comment #5 from GCC Commits ---
The releases/gcc-13 branch has been updated by Harald Anlauf
:
https://gcc.gnu.org/g:0dd82c0fba660775ff76ae27077a67f2f1358920
commit r13-8557-g0dd82c0fba660775ff76ae27077a67f2f1358920
Author: Harald Anlauf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113799
--- Comment #10 from GCC Commits ---
The releases/gcc-13 branch has been updated by Harald Anlauf
:
https://gcc.gnu.org/g:ec8303dea72ed4f9ae9fdf3c996a0deef6809351
commit r13-8558-gec8303dea72ed4f9ae9fdf3c996a0deef6809351
Author: Harald Anlauf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114533
--- Comment #7 from Joseph S. Myers ---
Note also that in glibc, _Float128 support in printf code can only be used in
limited circumstances: either on powerpc64le, as one of the multiple supported
long double formats there, or through the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111407
qinzhao at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111407
--- Comment #16 from GCC Commits ---
The releases/gcc-11 branch has been updated by Qing Zhao :
https://gcc.gnu.org/g:4de35949e462d89926a171cd1ef7b6f40a308dab
commit r11-11306-g4de35949e462d89926a171cd1ef7b6f40a308dab
Author: Qing Zhao
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114560
--- Comment #3 from Jakub Jelinek ---
(In reply to Meirav Grimberg from comment #2)
> (In reply to Jakub Jelinek from comment #1)
> > AVX512BW is needed to be able to use __mmask32/__mmask64, those aren't
> > supported in AVX512F, which only
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114565
Gaius Mulley changed:
What|Removed |Added
Attachment #57851|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114403
--- Comment #20 from Tamar Christina ---
This is a bad interaction with early break and peeling for gaps.
when peeling for gaps we set bias_for_lowest to 0, which then negates the ceil
for the upper bound calculation when the div is exact.
We
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114526
--- Comment #10 from Harald van Dijk ---
Sorry, sent my earlier comment too soon.
(In reply to Joseph S. Myers from comment #8)
> I believe conversions between function and object pointers are undefined as
> a property of the translation unit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114526
--- Comment #9 from Harald van Dijk ---
(In reply to Joseph S. Myers from comment #8)
> "rejects", in the ISO C sense, only applies to errors and pedwarns in GCC;
> not to warnings conditional on -pedantic (of which there are also some, but
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114560
--- Comment #2 from Meirav Grimberg ---
(In reply to Jakub Jelinek from comment #1)
> AVX512BW is needed to be able to use __mmask32/__mmask64, those aren't
> supported in AVX512F, which only supports __mmask16. __mmask8 needs
> AVX512DQ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114526
--- Comment #8 from Joseph S. Myers ---
"rejects", in the ISO C sense, only applies to errors and pedwarns in GCC; not
to warnings conditional on -pedantic (of which there are also some, but which
don't turn into errors with -pedantic).
If you
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111407
--- Comment #15 from GCC Commits ---
The releases/gcc-12 branch has been updated by Qing Zhao :
https://gcc.gnu.org/g:5f23f9f141c4b52e8f4a9aadc88b8155cf1959a3
commit r12-10306-g5f23f9f141c4b52e8f4a9aadc88b8155cf1959a3
Author: Qing Zhao
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114565
--- Comment #2 from Gaius Mulley ---
Created attachment 57851
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57851=edit
Proposed patch
Here is a proposed patch which introduces the option -fm2-debug-trace=
and allows a comma separated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114560
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114565
Gaius Mulley changed:
What|Removed |Added
Last reconfirmed||2024-04-02
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114565
Bug ID: 114565
Summary: progress trace would be useful to isolate ICE for
users
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106999
--- Comment #6 from GCC Commits ---
The master branch has been updated by Paul Thomas :
https://gcc.gnu.org/g:a7aa9455a8b9cb080649a7357b7360f2d99bcbf1
commit r14-9753-ga7aa9455a8b9cb080649a7357b7360f2d99bcbf1
Author: Paul Thomas
Date: Tue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114562
Jason Merrill changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114564
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111407
--- Comment #14 from GCC Commits ---
The releases/gcc-13 branch has been updated by Qing Zhao :
https://gcc.gnu.org/g:2d9a9488e26233eb9497722fa9ccb88258f7402c
commit r13-8556-g2d9a9488e26233eb9497722fa9ccb88258f7402c
Author: Qing Zhao
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114552
Roger Sayle changed:
What|Removed |Added
CC||roger at nextmovesoftware dot
com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114561
Jason Merrill changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106987
--- Comment #8 from paul.richard.thomas at gmail dot com ---
Hi Harald,
After a lot of messing around, I managed to backport the patch; essentially
by hand. However, two of the testcases ICEd in trans-array.cc and so there
were obviously
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114561
Jakub Jelinek changed:
What|Removed |Added
Target Milestone|--- |11.5
Priority|P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114561
Jakub Jelinek changed:
What|Removed |Added
Summary|Comma operator with |[11/12/13/14 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88309
--- Comment #5 from Andrew Pinski ---
(In reply to Kewen Lin from comment #4)
> (In reply to Andrew Pinski from comment #3)
> > Found it:
> > /* In GIMPLE the type of the MEM_REF specifies the alignment. The
> > required alignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114562
Jakub Jelinek changed:
What|Removed |Added
Target Milestone|--- |11.5
Priority|P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107945
--- Comment #4 from Jason Liam ---
Here is another invalid snippet that gcc accepts but both clang and msvc
rejects correctly. https://godbolt.org/z/sz4rczEaG
```
#include
template
requires std::is_arithmetic_v && (N >= 1)
class Vector
{
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114552
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114492
Alex Coplan changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114115
--- Comment #12 from Andrew Pinski ---
For anyone reading this, -fprofile-generate with ifunc attributes should be
fixed and is not related to the xz backdoor. The issue will show up in valid
usage of ifuncs even ones which don't call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114552
--- Comment #4 from Jakub Jelinek ---
The r13-989 to r13-990 difference is
- movlk(%rip), %eax
- movl%eax, (%rsp)
- movzwl k+4(%rip), %eax
- movw%ax, 4(%rsp)
+ movw$1, (%rsp)
+ movl$0,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114533
Andreas Schwab changed:
What|Removed |Added
Status|WAITING |UNCONFIRMED
Ever confirmed|1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106987
--- Comment #7 from paul.richard.thomas at gmail dot com ---
Hi Harald,
I will have a stab at backporting r14-1629 later this afternoon and will
let you know what happens. I am just rebuilding after applying the fix for
pr112407 (yes, I did
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114552
Jakub Jelinek changed:
What|Removed |Added
Summary|[13/14 Regression] wrong|[13/14 Regression] wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114480
--- Comment #16 from Richard Biener ---
Created attachment 57849
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57849=edit
patch for expand
Interestingly this patch for RTL expansion, more specifically
add_scope_conflicts, only slows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114403
Tamar Christina changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114551
--- Comment #2 from Jakub Jelinek ---
Started with r14-2944-g3d48c11ad082def8ee237e5778d8a5d569bff96d
a is -1, so the testcase shouldn't do much except almost empty loops with a few
iterations.
The continue in there seems to be important, but
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114533
Andreas Schwab changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106813
--- Comment #2 from Rainer Orth ---
Created attachment 57848
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57848=edit
Alternative patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112407
--- Comment #10 from GCC Commits ---
The master branch has been updated by Paul Thomas :
https://gcc.gnu.org/g:35408b3669fac104cd380582b32e32c64a603d8b
commit r14-9752-g35408b3669fac104cd380582b32e32c64a603d8b
Author: Paul Thomas
Date: Tue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106813
Rainer Orth changed:
What|Removed |Added
CC||ro at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111781
Mikael Morin changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114475
Mikael Morin changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107426
Mikael Morin changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107426
--- Comment #13 from GCC Commits ---
The releases/gcc-11 branch has been updated by Mikael Morin
:
https://gcc.gnu.org/g:3d05b9ac1c6ad950339f9487702c3165c189fe9e
commit r11-11305-g3d05b9ac1c6ad950339f9487702c3165c189fe9e
Author: Mikael Morin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107426
--- Comment #12 from GCC Commits ---
The releases/gcc-12 branch has been updated by Mikael Morin
:
https://gcc.gnu.org/g:38dd703d368c9e60159e6f19cfc8303ad639b557
commit r12-10305-g38dd703d368c9e60159e6f19cfc8303ad639b557
Author: Mikael Morin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114533
--- Comment #4 from Florian Weimer ---
This looks like a glibc bug to me.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114034
--- Comment #4 from Iain Sandoe ---
fixed on trunk, needed on open branches.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114036
--- Comment #5 from Iain Sandoe ---
fixed on trunk, needed on open branches.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114533
--- Comment #3 from Andreas Schwab ---
Is the stack properly aligned at this point?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114533
--- Comment #2 from Jakub Jelinek ---
>From what I can see, glibc uses there the same thing as libquadmath does, so
why is it ok on the glibc side and not on the libquadmath side?
I mean
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106472
--- Comment #38 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:9a5e4aade2b847c5262577a1490ce6f3df9a9841
commit r14-9751-g9a5e4aade2b847c5262577a1490ce6f3df9a9841
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114553
--- Comment #2 from Jonathan Wakely ---
(In reply to Toni Lammi from comment #0)
> The issue does not seem to be present in trunk.
It seems to be a change in inlining decisions on trunk, because the swap symbol
still isn't exported from the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114553
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114558
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114561
--- Comment #4 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #3)
> Further reduced:
Actually now that it's no longer a function template we don't even need to
instantiate it to trigger the error, so this is the minimal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114552
Richard Biener changed:
What|Removed |Added
Version|unknown |14.0
Priority|P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114561
--- Comment #3 from Jonathan Wakely ---
Further reduced:
void create(void* u) {
const void* const& r = ( (void)0, u );
}
void test_func() {
create(0);
}
The result of (0, u) is an lvalue of type void* which should then be converted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114551
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
Version|unknown
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114549
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114034
--- Comment #3 from GCC Commits ---
The master branch has been updated by Iain D Sandoe :
https://gcc.gnu.org/g:799a056cf804f433ce0050a5a6bf900f7a01ecb1
commit r14-9748-g799a056cf804f433ce0050a5a6bf900f7a01ecb1
Author: Iain Sandoe
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114535
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |13.3
Priority|P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114533
Richard Biener changed:
What|Removed |Added
Keywords||ABI
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114561
--- Comment #2 from Jonathan Wakely ---
Reduced:
void* const NONE = nullptr; //Compiles
void beforeParam();
template
void create(U && u) noexcept {
const void* const& r = ( (void) beforeParam(), u );
}
void test_func() {
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114036
--- Comment #4 from GCC Commits ---
The master branch has been updated by Iain D Sandoe :
https://gcc.gnu.org/g:ad8e34eaa870608e2b07b4e7147e6ef2944bb8b5
commit r14-9747-gad8e34eaa870608e2b07b4e7147e6ef2944bb8b5
Author: Iain Sandoe
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111731
Richard Biener changed:
What|Removed |Added
Known to work||13.2.1
Known to fail|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57573
Jonathan Wakely changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114561
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2024-04-02
See Also|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109817
--- Comment #6 from Eric Botcazou ---
It's not visible in release builds and testing shows that it's a very rare
situation in practice, so no real need IMO.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109817
Jan Hubicka changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114564
Bug ID: 114564
Summary: Accessing template Base via template Derived fails
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114462
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114115
--- Comment #11 from Sam James ---
(In reply to Sam James from comment #10)
> I'm aware, but there's a minimised test case attached here which shows this
> is still somewhat of a problem by itself.
>
> Either a better diagnostic is needed or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114115
--- Comment #10 from Sam James ---
I'm aware, but there's a minimised test case attached here which shows this is
still somewhat of a problem by itself.
Either a better diagnostic is needed or to not instrument the resolver.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114557
--- Comment #2 from Richard Biener ---
The free_phinodes buckets itself could better use the ->next chain of the
gimple stmts rather than a (re-allocated) GC vector. Given the current
bucket structure a single chain for the 4-argument case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114563
Richard Biener changed:
What|Removed |Added
Keywords||compile-time-hog
See Also|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114563
Bug ID: 114563
Summary: ggc_internal_alloc is slow
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114115
--- Comment #9 from Chung-Ju Wu ---
(In reply to Sam James from comment #1)
> One of the xz developers, Jia Tan, has kindly minimised it to not need
> BIND_NOW. I've adapted it a bit to cleanup flags and warnings.
>
CVE-2024-3094
Jia Tan is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114562
Bug ID: 114562
Summary: ICE when trying to bind rvalue reference to lvalue
with comma operator and forwarding reference to
pointer
Product: gcc
Version: 14.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114561
Bug ID: 114561
Summary: Comma operator with forwarding reference to pointer
raises invalid lvalue required error
Product: gcc
Version: 14.0
Status: UNCONFIRMED
101 - 200 of 230 matches
Mail list logo
