https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120644
--- Comment #2 from Jakub Jelinek ---
I have tried to reproduce this with a.h
struct A {};
enum E { E0, E1 };
template
struct B {};
template
constexpr auto format_kind = []{ static_assert (false); return E1; };
template
inline constexpr bool
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120644
--- Comment #1 from Jakub Jelinek ---
Changing auto to std::range_format fixes the error, so could be used at least
as a workaround.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120644
Jakub Jelinek changed:
What|Removed |Added
CC||nshead at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120644
Bug ID: 120644
Summary: [16 Regression] FAILs in various xtreme-header tests
since r16-1487
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120483
Andre Vehreschild changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #9 from Andre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119187
--- Comment #10 from Tamar Christina ---
(In reply to ktkachov from comment #9)
> (In reply to Tamar Christina from comment #8)
> > (In reply to ktkachov from comment #7)
> > > Could this be extended to scale Neon intrinsics code to SVE by
> > >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120483
Thomas Koenig changed:
What|Removed |Added
Last reconfirmed|2025-05-31 00:00:00 |2025-6-13
Known to fail|16.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120513
--- Comment #34 from Greg Chandler ---
With this set of debugs in gcc.cc:execute
/* Run each piped subprocess. */
fprintf (stdout, "Run each piped subprocess\n");
fprintf (stdout, "progname: %s\ntemp_filename: %s\n", progname, temp_filename)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120643
--- Comment #1 from Haochen Jiang ---
A possible change could be:
diff --git a/gcc/testsuite/gcc.target/i386/vect-pragma-target-1.c
b/gcc/testsuite/gcc.target/i386/vect-pragma-target-1.c
index f5e71e453ec..7f0ce3f8544 100644
--- a/gcc/testsuite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120643
Bug ID: 120643
Summary: [16 Regression] r16-1429 caused
vect-pragma-target-1/2.c testcase failed with SSE3+
related options
Product: gcc
Version: 16.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120589
H.J. Lu changed:
What|Removed |Added
Target Milestone|--- |16.0
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120589
--- Comment #4 from GCC Commits ---
The master branch has been updated by H.J. Lu :
https://gcc.gnu.org/g:11059b4a4e8d4a19e7b554817f7cf0f68e3d54bb
commit r16-1493-g11059b4a4e8d4a19e7b554817f7cf0f68e3d54bb
Author: H.J. Lu
Date: Sun Jun 8 14:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115842
--- Comment #11 from Hongtao Liu ---
(In reply to Tamar Christina from comment #9)
> (In reply to Hongtao Liu from comment #8)
> > (In reply to Tamar Christina from comment #7)
> > > (In reply to Hongtao Liu from comment #6)
> > > > I noticed s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120513
--- Comment #33 from Greg Chandler ---
for (n_commands = 1, i = 0; argbuf.iterate (i, &arg); i++)
fprintf (stdout, "%d: %s\n", i, argbuf[0]);
With the following inside the following if: if (arg && strcmp (arg, "|") == 0)
fprintf (stdo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107362
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Target Milestone|--- |15.0
Status|WAIT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110076
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Target Milestone|--- |15.0
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118150
--- Comment #4 from Spencer Abson ---
For a similar reason, we're also missing BIC+PTEST under the same
conditions:
int
bar (svbool_t a, svbool_t b)
{
svbool_t c = svptrue_b8();
return svptest_first (c, svbic_z (c, a, b));
}
generates:
ba
gcc-trunk//binary-trunk-20250612182937-r16-1487-g774ae8734f0e19-checking-yes-rtl-df-extra-riscv64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 16.0.0 20250612 (experimental) (GCC)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119187
--- Comment #9 from ktkachov at gcc dot gnu.org ---
(In reply to Tamar Christina from comment #8)
> (In reply to ktkachov from comment #7)
> > Could this be extended to scale Neon intrinsics code to SVE by
> > re-vectorising and treating the 128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120641
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2025-06-12
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119496
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120638
Jakub Jelinek changed:
What|Removed |Added
Summary|[16 regression] |[14/15 regression]
|O
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120638
--- Comment #7 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:8804e5b5b127b27d099d0c361fa2161d0b13edef
commit r16-1490-g8804e5b5b127b27d099d0c361fa2161d0b13edef
Author: Jakub Jelinek
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119496
--- Comment #3 from Giuseppe D'Angelo ---
Fixed on trunk. Backporting should be relatively safe, but given that no-one
has ever complained about this, maybe not worth it...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120636
Sam James changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120629
Sam James changed:
What|Removed |Added
CC||dcb314 at hotmail dot com
--- Comment #28 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120434
Bug 120434 depends on bug 120629, which changed state.
Bug 120629 Summary: [16 regression] profiledbootstrap with lto fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120629
What|Removed |Added
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120630
Sam James changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120629
Sam James changed:
What|Removed |Added
CC||zhendong.su at inf dot ethz.ch
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120629
Sam James changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120630
--- Comment #4 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:00aa59e5b120e4f5f70dcabafa57f7d4b5b9ad5d
commit r16-1489-g00aa59e5b120e4f5f70dcabafa57f7d4b5b9ad5d
Author: Jakub Jelinek
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117030
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119496
--- Comment #2 from GCC Commits ---
The trunk branch has been updated by Giuseppe D'Angelo :
https://gcc.gnu.org/g:c9a6c1b5a763d0d3f7a369ed281f9009f270939a
commit r16-1488-gc9a6c1b5a763d0d3f7a369ed281f9009f270939a
Author: Giuseppe D'Angelo
Da
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120587
--- Comment #2 from GCC Commits ---
The master branch has been updated by Stafford Horne :
https://gcc.gnu.org/g:c0694f95f591ee49dd0fc3d3bef4765bf36ab5a4
commit r16-1486-gc0694f95f591ee49dd0fc3d3bef4765bf36ab5a4
Author: Stafford Horne
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117030
--- Comment #5 from Marek Polacek ---
Fixed?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120641
--- Comment #2 from Pierre Ossman ---
It's problematic when you are trying to adopt a "no warnings" approach to your
development. This severely undermines that, as you train the developers back in
to ignoring warning messages.
It also seems exc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120640
--- Comment #2 from Vlad Serebrennikov ---
Yes, because in this case it's an elaborated-type-specifier, and name lookup is
type-only. The original example should be diagnosed in pedantic mode at the
very least.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120640
--- Comment #1 from Daniel Krügler ---
It looks to me like an extension of the "struct stat" hack, where typename
takes the role of struct such as in:
```
namespace N {
class A {};
int A();
}
class N::A a; // everyone accepts
```
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120641
--- Comment #1 from Andrew Pinski ---
I am not sure this is not unwanted. The abi is changed between 6 and 7 (fixed
to be following the specs). And we are warning about that.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120604
--- Comment #14 from GCC Commits ---
The master branch has been updated by Uros Bizjak :
https://gcc.gnu.org/g:03e87c78d399e7fd9510a7db3025a9ed1393e874
commit r16-1483-g03e87c78d399e7fd9510a7db3025a9ed1393e874
Author: Uros Bizjak
Date: Thu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120639
--- Comment #1 from Robin Dapp ---
I'm just realizing that without knowing the stride statically, we'd generate a
lot of code as we don't have a way of setting an element size for loads
dynamically. Although riscv offers a dynamic element size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120629
--- Comment #25 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:701a7cceba56217b466b5854d1e145bbf52679ac
commit r16-1482-g701a7cceba56217b466b5854d1e145bbf52679ac
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120641
Bug ID: 120641
Summary: Parameter passing warning from libstdc++ header
Product: gcc
Version: 15.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114065
--- Comment #50 from John David Anglin ---
On second thought, maybe the tv_nsec field in the ada timspec record
should also be type time_t?
#if __TIMESIZE == 64
# define __timespec64 timespec
#else
#include
/* The glibc Y2038-proof struct __ti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120625
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120625
--- Comment #2 from GCC Commits ---
The releases/gcc-15 branch has been updated by Jonathan Wakely
:
https://gcc.gnu.org/g:bbe9ec92138b1dfc7c61a3d8db7351ee57586388
commit r15-9828-gbbe9ec92138b1dfc7c61a3d8db7351ee57586388
Author: Jonathan Wake
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120629
Jonathan Wakely changed:
What|Removed |Added
CC||redi at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120640
Bug ID: 120640
Summary: Keyword 'typename' should not affect qualified name
lookup
Product: gcc
Version: 15.1.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120638
--- Comment #6 from chenglulu ---
(In reply to Jakub Jelinek from comment #5)
> Created attachment 61628 [details]
> gcc16-pr120638.patch
>
> Untested fix.
So cool! My problem can be resolved!
Thanks very much!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120630
--- Comment #3 from Zhendong Su ---
Here is a test without using any flags (fails at -O{s,2,3}), assuming it's due
to the same root cause:
[595] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/home/suz/suz-local/s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120295
Martin Jambor changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120638
Jakub Jelinek changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
Eve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120295
--- Comment #12 from GCC Commits ---
The releases/gcc-15 branch has been updated by Martin Jambor
:
https://gcc.gnu.org/g:f5fc1c6a169bfa6ebe569c701f293b55e5a3490e
commit r15-9827-gf5fc1c6a169bfa6ebe569c701f293b55e5a3490e
Author: Martin Jambor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120624
--- Comment #2 from GCC Commits ---
The trunk branch has been updated by Richard Sandiford :
https://gcc.gnu.org/g:8546265e2ee386ea8a4b2f9150ddfed32c9d15ea
commit r16-1476-g8546265e2ee386ea8a4b2f9150ddfed32c9d15ea
Author: Richard Sandiford
Da
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120630
--- Comment #2 from Jakub Jelinek ---
I guess one more testcase doesn't hurt. If/when the PR120629 patch is
approved, I'll commit this one too and close.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120636
Sam James changed:
What|Removed |Added
Target Milestone|--- |16.0
Summary|-O3 runtime problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120630
--- Comment #1 from Sam James ---
This seems to pass with Jakub's fix for PR120629. Up to him if he wants a
non-PGO case or not. Given this involves disabling some passes too, not sure
it's strictly better as a testcase, but up to him.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120624
Richard Sandiford changed:
What|Removed |Added
Known to work||16.0
Summary|aarch64: In
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94109
--- Comment #23 from Antony Lewis ---
New report, possibly related to underlying finalization issues:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120637
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120638
--- Comment #4 from chenglulu ---
(In reply to Jakub Jelinek from comment #3)
> Ah, that seems like a bug in the recip pass.
> Before that we have
> # RANGE [frange] float [1.0e+0 (0x0.8p+1), 4.294967296e+9 (0x0.8p+33)]
> _4 = (float) _3;
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120638
--- Comment #3 from Jakub Jelinek ---
Ah, that seems like a bug in the recip pass.
Before that we have
# RANGE [frange] float [1.0e+0 (0x0.8p+1), 4.294967296e+9 (0x0.8p+33)]
_4 = (float) _3;
# RANGE [frange] float [1.0e+0 (0x0.8p+1), 6.553
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120614
--- Comment #13 from Jan Hubicka ---
> I re-tested and can confirm that it is working now. Sorry for the false alarm.
I was fixing bug in this area recently, so perhaps you just had older
tree. Should have mentioned that - sorry for that.
I am
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120629
--- Comment #23 from Sam James ---
(In reply to Jakub Jelinek from comment #22)
> Created attachment 61626 [details]
> gcc16-pr120629.patch
>
> Untested fix.
Thanks. This restores bootstrap for me and regtests fine (one "regression" in
c761007
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120608
--- Comment #11 from Jakub Jelinek ---
Untested patch which fixes the #c5 testcase at -O0 -fsanitize=address.
There all that needs to be done is emit the asan epilogue sequence before the
musttail call(s) instead of disabling the tail call when
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120639
Robin Dapp changed:
What|Removed |Added
Severity|normal |enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120625
--- Comment #1 from GCC Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:76bf78d32c683af3bf88f4aef595048edbd82372
commit r16-1462-g76bf78d32c683af3bf88f4aef595048edbd82372
Author: Jonathan Wakely
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120638
Sam James changed:
What|Removed |Added
Target Milestone|--- |16.0
Summary|Optimization errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120638
--- Comment #2 from chenglulu ---
I compared the test.c.141t.dom2 and testf.c.208t.dom3
dom2：
```
range_of_expr (_5) [frange] float [1.0e+0 (0x0.8p+1), 6.5536e+4 (0x0.8p+17)]
range_of_expr (_6) [frange] float [7.62939453125e-6 (0x0.8p-16), 5.0e-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120639
Bug ID: 120639
Summary: vect: Strided memory access type, stores with gaps?
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120231
Sam James changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119650
--- Comment #5 from GCC Commits ---
The master branch has been updated by Gaius Mulley :
https://gcc.gnu.org/g:c291bde420556c69423961f59ef6765dc6c4c547
commit r16-1465-gc291bde420556c69423961f59ef6765dc6c4c547
Author: Gaius Mulley
Date: Thu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120638
chenglulu changed:
What|Removed |Added
CC||chenglulu at loongson dot cn
Ta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120638
Bug ID: 120638
Summary: Optimization errors caused by frange calculation
errors
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Severity: normal
Prior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120489
--- Comment #2 from Wentao Zhang ---
> The "continue" at line 10 should have never been executed. The wrongly
> reported "1" contradicts with (1) "#" at its previous line (2) the
> relationship among if-then-else.
Sorry I was trying to say
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52641
--- Comment #33 from GCC Commits ---
The master branch has been updated by Georg-Johann Lay :
https://gcc.gnu.org/g:07f229c2d7ee6b604e5a86092e675d5d36c1ba4e
commit r16-1435-g07f229c2d7ee6b604e5a86092e675d5d36c1ba4e
Author: Georg-Johann Lay
Dat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120637
--- Comment #1 from Antony Lewis ---
Here's a code that reproduces a similar issue without explicit final.
module MiscUtils
implicit none
contains
logical function isFloat0(R)
class(*), intent(in) :: R
select type(R)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120604
--- Comment #13 from Uroš Bizjak ---
Created attachment 61627
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61627&action=edit
Additional patch to make sure we can represent the difference
Actually, we have to make sure we can represent t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117811
--- Comment #26 from GCC Commits ---
The master branch has been updated by Georg-Johann Lay :
https://gcc.gnu.org/g:07f229c2d7ee6b604e5a86092e675d5d36c1ba4e
commit r16-1435-g07f229c2d7ee6b604e5a86092e675d5d36c1ba4e
Author: Georg-Johann Lay
Da
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120614
--- Comment #12 from kugan at gcc dot gnu.org ---
(In reply to kugan from comment #11)
> This specific ICE seems to be fixed with
> e416c8097fc87513e05c2d104c63488f733758c0
> Thanks for the fix.
>
> I am now seeing one in:
>
> x264_src/common/m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120614
--- Comment #11 from kugan at gcc dot gnu.org ---
This specific ICE seems to be fixed with
e416c8097fc87513e05c2d104c63488f733758c0
Thanks for the fix.
I am now seeing one in:
x264_src/common/mc.c: In function 'mc_weight_w16.part.0':
x264_src/c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120636
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2
81 matches
Mail list logo
