https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119576
--- Comment #11 from Richard Biener ---
There might be an argument that we should provide a way to disable all "late"
(during/after optimization) diagnostics. There are often instances of the same
-Wxyz that are emitted from both frontends and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119408
--- Comment #15 from chenglulu ---
(In reply to Xi Ruoyao from comment #14)
> (In reply to chenglulu from comment #13)
> > There is a problem now. When gcc supports both _Float128 and Q suffixes, the
> > libquadmath library will be automatically
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119408
--- Comment #17 from Xi Ruoyao ---
(In reply to Xi Ruoyao from comment #16)
/* snip */
> diff --git a/libgfortran/acinclude.m4 b/libgfortran/acinclude.m4
> index a73207e5465..8913dacb2b1 100644
> --- a/libgfortran/acinclude.m4
> +++ b/libgfort
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119577
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2025-04-02
Status|UNCONFIR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98845
--- Comment #18 from GCC Commits ---
The releases/gcc-14 branch has been updated by Richard Biener
:
https://gcc.gnu.org/g:9d516fb8ea547fa7b0ddea1f56cdb44a48f93663
commit r14-11504-g9d516fb8ea547fa7b0ddea1f56cdb44a48f93663
Author: Richard Biene
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79786
--- Comment #12 from GCC Commits ---
The releases/gcc-14 branch has been updated by Richard Biener
:
https://gcc.gnu.org/g:931277d91f29eab79e2d4008f0f69c809df95bcb
commit r14-11501-g931277d91f29eab79e2d4008f0f69c809df95bcb
Author: Richard Biene
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119408
--- Comment #16 from Xi Ruoyao ---
(In reply to chenglulu from comment #15)
> (In reply to Xi Ruoyao from comment #14)
> > (In reply to chenglulu from comment #13)
> > > There is a problem now. When gcc supports both _Float128 and Q suffixes,
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87984
--- Comment #47 from GCC Commits ---
The releases/gcc-14 branch has been updated by Richard Biener
:
https://gcc.gnu.org/g:3b84ac64816557e6c953984f096e0995f946e063
commit r14-11502-g3b84ac64816557e6c953984f096e0995f946e063
Author: Richard Biene
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119574
Richard Biener changed:
What|Removed |Added
Known to fail||14.2.1
--- Comment #6 from Richard Bie
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119408
--- Comment #19 from Xi Ruoyao ---
(In reply to Jakub Jelinek from comment #18)
> _Float128 is definitely not for backward compatibility
Sorry, I mean __float128.
The problem here is we added __float128 as an alias of _Float128 for
compatibili
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119408
--- Comment #20 from chenglulu ---
(In reply to Xi Ruoyao from comment #19)
> (In reply to Jakub Jelinek from comment #18)
> > _Float128 is definitely not for backward compatibility
>
> Sorry, I mean __float128.
>
> The problem here is we adde
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101478
--- Comment #9 from GCC Commits ---
The releases/gcc-14 branch has been updated by Richard Biener
:
https://gcc.gnu.org/g:a57c877f8899ac9171eaeafa7641ac79cce96f89
commit r14-11505-ga57c877f8899ac9171eaeafa7641ac79cce96f89
Author: Richard Biene
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119408
--- Comment #21 from chenglulu ---
(In reply to Jakub Jelinek from comment #18)
> _Float128 is definitely not for backward compatibility, it is a standard C23
> type and in C++ used for the standard std::float128_t type.
> I think aarch64 doesn'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119408
--- Comment #22 from Jakub Jelinek ---
I think for libgfortran the cleanest would be in the configure check whether
long double is IEEE quad and if so, have libgfor_cv_have_float128 no.
That can be e.g.
#if __LDBL_MANT_DIG__ == __FLT128_MANT_DIG
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119556
--- Comment #1 from GCC Commits ---
The trunk branch has been updated by Christophe Lyon :
https://gcc.gnu.org/g:df225ae29a147ae40bb44ba14ee979b67fd19c8e
commit r15-9144-gdf225ae29a147ae40bb44ba14ee979b67fd19c8e
Author: Christophe Lyon
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119556
Christophe Lyon changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110854
Jonathan Wakely changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119604
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101440
sandra at gcc dot gnu.org changed:
What|Removed |Added
CC||sandra at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119539
--- Comment #4 from GCC Commits ---
The master branch has been updated by Hongyu Wang :
https://gcc.gnu.org/g:2488843477b3dcfeef76f8512ff6d9e8f3b58dca
commit r15-9166-g2488843477b3dcfeef76f8512ff6d9e8f3b58dca
Author: Hongyu Wang
Date: Mon M
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101440
--- Comment #1 from GCC Commits ---
The master branch has been updated by Sandra Loosemore :
https://gcc.gnu.org/g:4590a31f81ae18e0d887c1a56f510d22754f31ed
commit r15-9165-g4590a31f81ae18e0d887c1a56f510d22754f31ed
Author: Sandra Loosemore
Dat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119604
--- Comment #3 from Andrew Pinski ---
(In reply to Nathaniel Shead from comment #2)
> Maybe worth noting that the C++ frontend already uses an 'iloc_sentinel'
> RAII type for this (defined in cp/cp-tree.h), maybe it would be worth moving
> somew
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119599
--- Comment #8 from Andrew Pinski ---
Note this does not ICE at -O1 is because of PR 82158 which changes return
(inside the noreturn function) into __builtin_unreachable when optimizing.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119605
Bug ID: 119605
Summary: change the code fixup_cfg for __builtin_unreachable to
be a verifier
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords: internal-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119539
Hongyu Wang changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61727
sandra at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119586
--- Comment #5 from GCC Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:574c59cfe6e29c9e5758988b75c2e7ab6edc37da
commit r15-9149-g574c59cfe6e29c9e5758988b75c2e7ab6edc37da
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119583
--- Comment #5 from Siddhesh Poyarekar ---
Appeared since r15-3078-g6ea25c041964bf which was also backported to the gcc14
branch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119591
Bug ID: 119591
Summary: Concept constraint expression normalization uses too
much memory
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119586
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107087
--- Comment #21 from Jonathan Wakely ---
(In reply to Ted Lyngmo from comment #20)
> I noticed something very similar that started with 12.4 and that is still
> there. I think it's a duplicate this ticket so I'll post here for you to
> decide.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119351
--- Comment #12 from Jakub Jelinek ---
Sorry, I was looking for r15-something string and missed g: prefixed hash.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119482
Andi Kleen changed:
What|Removed |Added
CC||andi-gcc at firstfloor dot org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119387
Patrick Palka changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119590
--- Comment #2 from Andrew Pinski ---
For c++ alignof should be used.
But for c _Alignof needs to be used.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119590
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119583
--- Comment #6 from Jakub Jelinek ---
Note, generally -fomit-frame-pointer doesn't guarantee that the frame pointer
is omitted:
"Omit the frame pointer in functions that don't need one."
Functions using VLAs/alloca or requiring dynamic stack rea
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108016
--- Comment #7 from Alexey Merzlyakov ---
> For DSE to kick in, I'm pretty sure we'd need to eliminate the memory load
> first. Eliminating the memory load will likely be nontrivial.
For this, I think we could start from loads that was partiall
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119590
Francois-Xavier Coudert changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119096
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119590
--- Comment #4 from Iain Sandoe ---
(In reply to Jakub Jelinek from comment #3)
> So something fixincludes should fix?
looks like another case where having a single FE for c-family makes it easy to
mistakenly accept C in C++ and vice versa
At
sable-bootstrap
--enable-checking=yes --prefix=/local/suz-local/software/local/gcc-trunk
--enable-sanitizers --enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 15.0.1 20250402 (experimental) (GCC)
[509] %
[509] % gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119592
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119595
--- Comment #2 from Jakub Jelinek ---
Created attachment 60964
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60964&action=edit
gcc15-pr119595.patch
Here is my WIP, with emulation classes.
libgcobol still builds for 64-bit x86_64 and make
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119594
Sam James changed:
What|Removed |Added
Keywords||wrong-code
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66279
--- Comment #10 from GCC Commits ---
The releases/gcc-14 branch has been updated by Richard Biener
:
https://gcc.gnu.org/g:12b536c17d28500fa9ad32563ae6088726162051
commit r14-11500-g12b536c17d28500fa9ad32563ae6088726162051
Author: Richard Biene
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119595
Bug ID: 119595
Summary: Port libgcobol to 32-bit architectures
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: cobol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119594
Andrew Pinski changed:
What|Removed |Added
Keywords||needs-bisection
Status|UNCO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119594
--- Comment #2 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #1)
> The difference with/without -fno-dce is:
> mov edi, 4294967295
>
>
> vs:
> xor edi, edi
4294967295 is the correct value.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119596
--- Comment #1 from Andrew Pinski ---
This is 100% a tuning issue. The generic tuning is tuned for a generic target.
You could use -mtune= to get a better tuning for the processor you using.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116212
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117849
Patrick Palka changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117983
--- Comment #10 from Jonathan Wakely ---
fixed for 13.4 and 14.3 so far.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110498
--- Comment #10 from GCC Commits ---
The releases/gcc-13 branch has been updated by Jonathan Wakely
:
https://gcc.gnu.org/g:a5f7850221f935b97980e2a52b1aaeb944d7d1cf
commit r13-9488-ga5f7850221f935b97980e2a52b1aaeb944d7d1cf
Author: Jonathan Wak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117983
--- Comment #9 from GCC Commits ---
The releases/gcc-13 branch has been updated by Jonathan Wakely
:
https://gcc.gnu.org/g:8f633fe7c7d03ed6c0ce029a831037a6274a0882
commit r13-9486-g8f633fe7c7d03ed6c0ce029a831037a6274a0882
Author: Jonathan Wake
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114758
--- Comment #10 from GCC Commits ---
The releases/gcc-13 branch has been updated by Jonathan Wakely
:
https://gcc.gnu.org/g:d1929ba18c1e4f0fa4212ec2181f8345896bb7e8
commit r13-9487-gd1929ba18c1e4f0fa4212ec2181f8345896bb7e8
Author: Jonathan Wak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119596
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88443
Bug 88443 depends on bug 114758, which changed state.
Bug 114758 Summary: [13 Regression] The layout of a std::vector reports a
warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114758
What|Removed |Added
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110498
--- Comment #11 from Jonathan Wakely ---
Fixed for 13.4 and 14.3 as well
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119593
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116212
--- Comment #8 from GCC Commits ---
The releases/gcc-13 branch has been updated by Jonathan Wakely
:
https://gcc.gnu.org/g:30a0a942007ac01601c6493b558b747d6a5b6371
commit r13-9485-g30a0a942007ac01601c6493b558b747d6a5b6371
Author: Jonathan Wake
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119594
--- Comment #3 from Andrew Pinski ---
RTL fwprop1 is removing:
(insn 7 2 8 2 (set (reg/v:DI 101 [ gD.2871 ])
(const_int -1 [0x])) "/app/example.cpp":9:10 95
{*movdi_internal}
(expr_list:REG_UNUSED (reg/v:DI 101 [ gD.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119596
--- Comment #4 from Mateusz Guzik ---
Sorry guys, I must have pressed something by accident and the bug submitted
before I typed it out.
Anyhow the crux is:
(In reply to Andrew Pinski from comment #1)
> This is 100% a tuning issue. The generic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119596
--- Comment #3 from Mateusz Guzik ---
Normally inlined memset and memcpy ops use SIMD.
However, kernel are built for with -mno-sse for performance reasons.
For buffers up to 40 bytes gcc emits regular stores, which is fine. For sizes
above tha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119582
--- Comment #4 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:29bc904cb827615ed9f36bc3742ccc4ac77515ec
commit r15-9153-g29bc904cb827615ed9f36bc3742ccc4ac77515ec
Author: Jakub Jelinek
Date: W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119596
--- Comment #5 from Andrew Pinski ---
>Benching based on the Linux kernel and the Sapphire Rapids CPU:
With -mtune=sapphirerapids , GCC produces:
```
_Z4zeroP3foo:
.LFB0:
.cfi_startproc
mov QWORD PTR [rdi], 0
mov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119597
Bug ID: 119597
Summary: SEGV on Cobol "hello world" on Power
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119597
Peter Bergner changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Target|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119540
--- Comment #7 from anlauf at gcc dot gnu.org ---
(In reply to anlauf from comment #4)
> (In reply to anlauf from comment #3)
> > I might be missing to set some elem_len or span or ...
>
> Testcase:
The apparent string length issue with -fcheck
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119604
Bug ID: 119604
Summary: expand_call_inline could use an RAII for
input_location
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords: internal-improvement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119599
--- Comment #7 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #6)
> Actually you are right inliner should be fixed. Let me try to do that
> instead.
```
diff --git a/gcc/tree-inline.cc b/gcc/tree-inline.cc
index 05843b8ccf0..da40
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119605
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2025-04-03
Status|UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60972
sandra at gcc dot gnu.org changed:
What|Removed |Added
CC||sandra at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119599
--- Comment #6 from Andrew Pinski ---
(In reply to Jakub Jelinek from comment #5)
> Empty block with no successors is how we represent __builtin_unreachable in
> RTL, in GIMPLE there should be __builtin_unreachable call. We should just
> make s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117892
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119491
Jakub Jelinek changed:
What|Removed |Added
Attachment #60952|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119376
Bug 119376 depends on bug 119491, which changed state.
Bug 119491 Summary: missed tail call due to exceptions which is empty
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119491
What|Removed |Added
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96345
Derek Huang changed:
What|Removed |Added
CC||djh458 at stern dot nyu.edu
--- Comment #7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119604
Nathaniel Shead changed:
What|Removed |Added
CC||nshead at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119242
--- Comment #6 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:1bfc026035e6bade36538077dc1dd4f9baff0bf2
commit r15-9172-g1bfc026035e6bade36538077dc1dd4f9baff0bf2
Author: Jakub Jelinek
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119586
--- Comment #3 from Richard Biener ---
More to the point testcase:
void __attribute__((noipa)) foo (long *) {}
void __attribute__((noipa))
d()
{
long e[6][8][5];
for (int b = 0; b < 6; b++)
for (int c = 0; c < 8; c++)
{
e[
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119589
Richard Biener changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119583
--- Comment #3 from Siddhesh Poyarekar ---
I'm not so sure, the stack is correctly aligned here, just that it happens a
little too late and results in holding on to the frame pointer.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111245
--- Comment #10 from GCC Commits ---
The releases/gcc-14 branch has been updated by Richard Biener
:
https://gcc.gnu.org/g:d9faa7c2eb47c7fabf9dafce6d569f52d49c7030
commit r14-11514-gd9faa7c2eb47c7fabf9dafce6d569f52d49c7030
Author: Richard Bien
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119067
--- Comment #14 from GCC Commits ---
The releases/gcc-14 branch has been updated by Richard Biener
:
https://gcc.gnu.org/g:85ed633f26c725bbe5c3a3c6fceada637bf33f7c
commit r14-11517-g85ed633f26c725bbe5c3a3c6fceada637bf33f7c
Author: Richard Bien
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119145
--- Comment #6 from GCC Commits ---
The releases/gcc-14 branch has been updated by Richard Biener
:
https://gcc.gnu.org/g:534a7895e969793285c77a42aca62d426cd56c1e
commit r14-11520-g534a7895e969793285c77a42aca62d426cd56c1e
Author: Richard Biene
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119067
Richard Biener changed:
What|Removed |Added
Known to fail||14.2.0
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
Bug 45375 depends on bug 119067, which changed state.
Bug 119067 Summary: [14 Regression] ICE when building firefox-135.0.1 with LTO
(tree check: expected none of vector_type, have vector_type in
odr_types_equivalent_p, at ipa-devirt.cc:1262)
ht
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105424
Jonathan Wakely changed:
What|Removed |Added
Attachment #52901|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119588
Richard Biener changed:
What|Removed |Added
Severity|normal |enhancement
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119308
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114945
--- Comment #6 from GCC Commits ---
The releases/gcc-14 branch has been updated by Jonathan Wakely
:
https://gcc.gnu.org/g:6b11aed73f6601de32082a4519022d4de1ce8a8f
commit r14-11507-g6b11aed73f6601de32082a4519022d4de1ce8a8f
Author: Jonathan Wak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88443
Bug 88443 depends on bug 114945, which changed state.
Bug 114945 Summary: [14 regression] Sporadic std::vector::resize()
-Wstringop-overflow or -Warray-bounds warning with gcc 14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114945
Wha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119408
--- Comment #18 from Jakub Jelinek ---
_Float128 is definitely not for backward compatibility, it is a standard C23
type and in C++ used for the standard std::float128_t type.
I think aarch64 doesn't build libquadmath either, but maybe it only s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114945
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456
Bug 56456 depends on bug 114945, which changed state.
Bug 114945 Summary: [14 regression] Sporadic std::vector::resize()
-Wstringop-overflow or -Warray-bounds warning with gcc 14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114945
Wha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119217
--- Comment #10 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #5 from Rainer Orth ---
Given the recent flurry of activity to make the COBOL frontend (and
libgcobol) more portable, I've given a Solaris/amd64 build another try.
Some
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456
Bug 56456 depends on bug 116841, which changed state.
Bug 116841 Summary: [14 Regression] spurious -Warray-bounds=1 warning when
resizing + memcpy-ing into vector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116841
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116841
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
sable-bootstrap
--enable-checking=yes --prefix=/local/suz-local/software/local/gcc-trunk
--enable-sanitizers --enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 15.0.1 20250402 (experimental) (GCC)
[511] %
[511] % gc
1 - 100 of 218 matches
Mail list logo
