https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60662
--- Comment #8 from Sam James ---
(In reply to Antoine Pitrou from comment #7)
For cases like this, a new bug is best, as it's not always the exact same
issue, and in any case is harder to miss in a new bug.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120917
--- Comment #24 from Frank Heckenbach ---
(In reply to Jason Merrill from comment #23)
>
> Then yes, it does look like it should work; libstdc++ uses that 'requires
> function call' pattern in
>
> template
> concept __is_derived_from_opt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120763
Bug 120763 depends on bug 116686, which changed state.
Bug 116686 Summary: [15/16 Regression] RISC-V:
gcc.target/riscv/rvv/autovec/pr114734.c failing with zvl1024b lmul2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116686
What|Re
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116242
Bug 116242 depends on bug 116686, which changed state.
Bug 116686 Summary: [15/16 Regression] RISC-V:
gcc.target/riscv/rvv/autovec/pr114734.c failing with zvl1024b lmul2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116686
What|Re
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116686
Jeffrey A. Law changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116242
Jeffrey A. Law changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120922
Jeffrey A. Law changed:
What|Removed |Added
CC||tamar.christina at arm dot com
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120817
--- Comment #20 from GCC Commits ---
The master branch has been updated by Tamar Christina :
https://gcc.gnu.org/g:4b9f760c511a4ef3a390dd6cfab80bada57c2535
commit r16-2067-g4b9f760c511a4ef3a390dd6cfab80bada57c2535
Author: Tamar Christina
Date
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120881
--- Comment #28 from GCC Commits ---
The master branch has been updated by H.J. Lu :
https://gcc.gnu.org/g:3e34c54d72f6e3723601bcd936409af4a42d17b8
commit r16-2072-g3e34c54d72f6e3723601bcd936409af4a42d17b8
Author: H.J. Lu
Date: Wed Jul 2 08
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120621
--- Comment #11 from James K. Lowden ---
I would like to close this issue or fix what remains. It was reopened because
it broke the bootstrap build, a lesson sorely learned. With the commit of June
20, that's been fixed.
As of today, using a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120922
Tamar Christina changed:
What|Removed |Added
CC||tnfchris at gcc dot gnu.org
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120922
--- Comment #3 from Edwin Lu ---
(In reply to Tamar Christina from comment #2)
> Looks like it's because a very high VF was chosen
>
> optimized: loop vectorized using masked 1024 byte vectors and unroll factor
> 256
> Updating vectorization fa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120949
--- Comment #7 from GCC Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:ed912b1ee5ad0f241f968d5fd1a54a7e9e0e20dd
commit r16-2078-ged912b1ee5ad0f241f968d5fd1a54a7e9e0e20dd
Author: Jonathan Wakely
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120243
Jason Merrill changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment #8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120949
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60662
--- Comment #9 from Jonathan Wakely ---
(In reply to Antoine Pitrou from comment #7)
> It seems this comment is mistaken as GCC 13.3, at least, still uses
> pthread_once for std::call_once:
>
> > This should be fixed in GCC 11 which no longer us
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120922
Tamar Christina changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |tnfchris at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119920
--- Comment #6 from Andrew Pinski ---
Created attachment 61814
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61814&action=edit
First prototype
Has some rough edges (extra dumps for quick debugging; it also does not handle
commutative ope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120725
Bug 120725 depends on bug 84719, which changed state.
Bug 84719 Summary: gcc's __builtin_memcpy performance with certain number of
bytes is terrible compared to clang's
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84719
What|Remo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70308
H.J. Lu changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120725
Bug 120725 depends on bug 70308, which changed state.
Bug 70308 Summary: memset generates rep stosl instead of rep stosq
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70308
What|Removed |Added
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120670
H.J. Lu changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120725
Bug 120725 depends on bug 120708, which changed state.
Bug 120708 Summary: ix86_expand_set_or_cpymem ignores MOVE_MAX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120708
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120725
Bug 120725 depends on bug 101366, which changed state.
Bug 101366 Summary: memset codegen for constant sized does not use SSE
instructions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101366
What|Removed |Adde
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84719
H.J. Lu changed:
What|Removed |Added
Target Milestone|--- |16.0
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120708
H.J. Lu changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119704
H.J. Lu changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120725
Bug 120725 depends on bug 119703, which changed state.
Bug 119703 Summary: x86: spurious branches for inlined memset in ranges (40;
64) when requesting unrolled loops without simd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119703
W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102294
H.J. Lu changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120725
Bug 120725 depends on bug 119704, which changed state.
Bug 119704 Summary: x86: partially disobeyed strategy rep-based request for
inlined memset
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119704
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84009
Jakub Jelinek changed:
What|Removed |Added
Target Milestone|--- |16.0
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120725
Bug 120725 depends on bug 118276, which changed state.
Bug 118276 Summary: memset 88 uses rep stosq while 80 uses SSE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118276
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120725
Bug 120725 depends on bug 102294, which changed state.
Bug 102294 Summary: memset expansion is sometimes slow for small sizes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102294
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118276
H.J. Lu changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108585
H.J. Lu changed:
What|Removed |Added
Target Milestone|--- |16.0
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120976
--- Comment #5 from Tomasz Kamiński ---
> powerpc as well (at least with some options), one can have long double as
> IEEE double, IBM double double and IEEE quad depending on options.
s390 as well (again, long double can be IEEE double or IEEE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120725
H.J. Lu changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101366
H.J. Lu changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120986
Bug ID: 120986
Summary: ICE when expanding svcreate2 intrinsic with compile
time know FPMR
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120817
--- Comment #18 from rguenther at suse dot de ---
On Mon, 7 Jul 2025, tnfchris at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120817
>
> --- Comment #17 from Tamar Christina ---
> (In reply to Richard Biener from com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #461 from Oleg Endo ---
(In reply to John Paul Adrian Glaubitz from comment #460)
> Oleg, would it make sense to rebase your branch on git.gcc.org with master,
> add all the tests from your tree on Github and then bootstrap gcc native
::function only with -Wsystem-headers which turns on a lot of conversion
warnings outside of std::function):
/opt/compiler-explorer/arm64/gcc-trunk-20250707/aarch64-unknown-linux-gnu/aarch64-unknown-linux-gnu/include/c++/16.0.0/bits/invoke.h:116:42:
warning: conversion from 'long unsigned in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120990
--- Comment #2 from Andrew Pinski ---
>Interestingly, if I try this on ARM 32-bit GCC 15.1, it does report:
That is because long is 32bit so there is a warning at the function definition
rather than at the function call point.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120888
--- Comment #8 from GCC Commits ---
The master branch has been updated by Max Filippov :
https://gcc.gnu.org/g:2a6ac385076a0d43a529e84e7f7ebcbfc3831437
commit r16-2069-g2a6ac385076a0d43a529e84e7f7ebcbfc3831437
Author: H.J. Lu
Date: Tue Jul
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120987
--- Comment #8 from Tom de Vries ---
(In reply to Andrew Pinski from comment #7)
> Question does it just happen on x86_64-linux-gnu or can it be reproduce on
> aarch64-linux-gnu or powerpc64-linux-gnu too?
Reproduced on Fedora Linux Asahi Remix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120358
Sam James changed:
What|Removed |Added
Attachment #61749|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120960
--- Comment #3 from GCC Commits ---
The master branch has been updated by Martin Jambor :
https://gcc.gnu.org/g:f555ee597ac4fa522da798e9c6a966903a5b7113
commit r16-2071-gf555ee597ac4fa522da798e9c6a966903a5b7113
Author: Martin Jambor
Date: M
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119331
--- Comment #4 from Simon Sobisch ---
I see, so I guess you'll leave enabling in the command line interface for now
and autogen+include a temporary CDF for disabling in cobcd?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119100
--- Comment #10 from Jeffrey A. Law ---
So I don't mind these changes being tagged to pr119100. My only concern is how
do we know when we're done on this bug?
We don't need to figure it out right now, but we do need to keep that question
in mi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120976
--- Comment #8 from dave.anglin at bell dot net ---
On 2025-07-07 7:43 a.m., tkaminsk at gcc dot gnu.org wrote:
> --- Comment #7 from Tomasz Kamiński ---
> The issue should be addressed now.
Fixes build on hppa64-hp-hpux11.11.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96635
--- Comment #8 from Julian Waters ---
Wait, I just realized this isn't the bug that was reported for 32 bit MinGW. My
comment can be ignored.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119876
Andrew Pinski changed:
What|Removed |Added
Depends on||119920
--- Comment #3 from Andrew Pinsk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120990
--- Comment #3 from Andrew Pinski ---
I am not sure if a warning is even wanted here. This is just one bad symptoms
of std::function.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120976
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |16.0
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120657
--- Comment #1 from Halalaluyafail3 ---
The wrong token being pointed to also occurs when using restrict normally, for
example:
void(*restrict x)()=0;
This generates the error message:
:2:5: error: invalid use of 'restrict'
2 | void(*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119920
Andrew Pinski changed:
What|Removed |Added
Attachment #61814|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116369
--- Comment #19 from GCC Commits ---
The master branch has been updated by Francois Dumont :
https://gcc.gnu.org/g:2fd6f42c17a8040dbd3460ca34d93695dacf8575
commit r16-2084-g2fd6f42c17a8040dbd3460ca34d93695dacf8575
Author: François Dumont
Date
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120990
Bug ID: 120990
Summary: Narrowing conversion in std::function return value is
not reported
Product: gcc
Version: 15.1.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120980
--- Comment #3 from Krister Walfridsson ---
(In reply to Richard Biener from comment #2)
> We do not want to introduce additional code generation overhead to avoid a
> fully out-of-bounds but known not trapping because it's known to fall into
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112324
Andrew Pinski changed:
What|Removed |Added
Depends on||119920
--- Comment #9 from Andrew Pinsk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120990
--- Comment #4 from Rohan Suri ---
Thanks for looking into it Andrew. Good to know that those compiler flags do
catch it.
> I am not sure if a warning is even wanted here. This is just one bad symptoms
> of std::function.
I don't know if GCC
101 - 161 of 161 matches
Mail list logo
