https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121933
--- Comment #2 from Andrew Pinski ---
: In function 'foo':
:19:1: error: NOTE_INSN_BASIC_BLOCK is missing for block 5
19 | }
| ^
:19:1: error: NOTE_INSN_BASIC_BLOCK 24 in middle of basic block 5
:19:1: error: insn outside basic block
(i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121933
--- Comment #3 from Andrew Pinski ---
I am suspecting r16-3747-gafa74d37e8170d exposed this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121933
--- Comment #1 from Andrew Pinski ---
It worked at r16-3732-g45e5b65be26d37
(https://gcc.gnu.org/pipermail/gcc-testresults/2025-September/857170.html) but
failed at r16-3757-gffbbeeec04a304
(https://gcc.gnu.org/pipermail/gcc-testresults/2025-Sep
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121933
Bug ID: 121933
Summary: [16 Regression] gcs-nonlocal-1-track-speculation.c
ICEs
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code, tes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121932
--- Comment #6 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #5)
> (In reply to Andrew Pinski from comment #4)
> > Reduced further to:
> > ```
> > struct s1{
> > template void f(int (&)[N]);
> > };
> > struct s2{
> > void f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121932
--- Comment #5 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #4)
> Reduced further to:
> ```
> struct s1{
> template void f(int (&)[N]);
> };
> struct s2{
> void f(const s1);
> };
> void s2::f(const s1) {}
> ```
>
> If we
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121932
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121932
Andrew Pinski changed:
What|Removed |Added
Priority|P3 |P1
Severity|normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121932
--- Comment #3 from Andrew Pinski ---
I am 99% sure it is related to to_dtring and not remove template methods.
Like that is still being streamed out.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121932
--- Comment #2 from Sam James ---
```
struct enum_flags {
template void to_string(int (&)[N]);
};
struct language_defn {
virtual void language_arch_info(int *, int *) const;
virtual void lookup_symbol_local(const enum_flags) {}
};
struct
--enable-host-pie
--enable-host-bind-now --enable-default-ssp --disable-fixincludes
--with-gxx-libcxx-include-dir=/usr/include/c++/v1 --enable-linker-build-id
--with-build-config='bootstrap-O3 bootstrap-lto'
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121932
Sam James changed:
What|Removed |Added
Target Milestone|--- |16.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121932
--- Comment #1 from Sam James ---
Pretty sure it's from r16-3821-gb9fde0219f35cd.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121911
--- Comment #1 from H.J. Lu ---
Created attachment 62376
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=62376&action=edit
A patch
Something like this?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121923
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2025-09-13
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121931
--- Comment #3 from Andrew Pinski ---
This was the doc change:
https://github.com/llvm/llvm-project/commit/2b61d12f1ea5970c128c83a05e5acf2541174c2d
But it looks like it was supported before that.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121931
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |WONTFIX
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121931
--- Comment #10 from Andrew Pinski ---
Oh maybe this is not needed as GCC already defaults not to instrument variables
that have their section set by the user.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121931
Andrew Pinski changed:
What|Removed |Added
See Also||https://github.com/zephyrpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121931
--- Comment #8 from Andrew Pinski ---
https://github.com/slankdev/frr/blob/79fd3e0c973cf8941a597cab4ca75d38ea344ffd/lib/xref.h#L147
is the only place I have seen it used in the wild in the use case I mentioned.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121931
--- Comment #7 from Andrew Pinski ---
So to summarize, the use case is an array that is built via using a specific
section. So you need no redzone to happen for the variable.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121931
Sam James changed:
What|Removed |Added
CC||sjames at gcc dot gnu.org
--- Comment #1 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121931
--- Comment #6 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #5)
> here is the commit from LLVM:
> https://github.com/llvm/llvm-project/commit/
> 3ed0f643fc3267b7fbb319e4cb5610e5a7e1ba86
>
> that implemented this in the first p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121931
--- Comment #5 from Andrew Pinski ---
here is the commit from LLVM:
https://github.com/llvm/llvm-project/commit/3ed0f643fc3267b7fbb319e4cb5610e5a7e1ba86
that implemented this in the first place. No link to review or anything else.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121931
--- Comment #4 from Andrew Pinski ---
Here are the ones allowed on globals by clang:
https://github.com/llvm/llvm-project/blob/bac9e463b1f77b7354fe68c87d58be67e3294806/clang/lib/Sema/SemaDeclAttr.cpp#L6328
address, hwaddress and memtag.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121931
--- Comment #2 from Andrew Pinski ---
(In reply to Sam James from comment #1)
> Wonder if any applications are actually using this..
I have been trying to find the reason why it applies in clang and the use case.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121931
Bug ID: 121931
Summary: no_sanitize attribute should also apply to global
variables
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Severity: enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121894
--- Comment #13 from qinzhao at gcc dot gnu.org ---
[opc@qinzhao-aarch64-ol8 gcc]$ git diff
diff --git a/gcc/tree-sra.cc b/gcc/tree-sra.cc
index 921664ef470..dd976f96a91 100644
--- a/gcc/tree-sra.cc
+++ b/gcc/tree-sra.cc
@@ -1678,7 +1678,13 @@ sc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121930
--- Comment #2 from Andrew Pinski ---
__stack_chk_guard is in the implementation namespace. There is nothing to
check.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121795
Patrick Palka changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121928
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2025-09-12
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121930
Andrew Pinski changed:
What|Removed |Added
Component|c |target
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110442
--- Comment #8 from Sam James ---
Works well for me so far.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121930
Bug ID: 121930
Summary: c/c++ front ends doesn't check __stack_chk_guard
conflict
Product: gcc
Version: 15.2.1
Status: UNCONFIRMED
Severity: normal
P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121913
--- Comment #3 from GCC Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:7801236069a95ce13a968084463cdbbea8ce907a
commit r16-3835-g7801236069a95ce13a968084463cdbbea8ce907a
Author: Jonathan Wakely
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121929
Bug ID: 121929
Summary: std::format prints a valid-looking date for invalid
2020y/January/Friday[10]
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Keywords: w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121913
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121890
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121890
--- Comment #3 from GCC Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:7b99d184bc9eada80992f7134c6c8e3b0eb0d19d
commit r16-3834-g7b99d184bc9eada80992f7134c6c8e3b0eb0d19d
Author: Jonathan Wakely
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117276
--- Comment #15 from GCC Commits ---
The releases/gcc-15 branch has been updated by Jonathan Wakely
:
https://gcc.gnu.org/g:210b7a0d8cae48268b69a331249e702495cf2639
commit r15-10320-g210b7a0d8cae48268b69a331249e702495cf2639
Author: Jonathan Wa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121532
--- Comment #6 from GCC Commits ---
The master branch has been updated by Eric Botcazou :
https://gcc.gnu.org/g:f6e00192cdff2c87e744c870c0e5d061ba5b7569
commit r16-3833-gf6e00192cdff2c87e744c870c0e5d061ba5b7569
Author: Eric Botcazou
Date: F
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110442
Sam James changed:
What|Removed |Added
Last reconfirmed||2025-09-12
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121921
--- Comment #5 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #4)
> (In reply to Richard Biener from comment #3)
> > We only have e + (b - e):
>
> Right and that was added with r0-128019-g77574c353464b3 (PR 58742) and the
> move
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81426
Thomas Petazzoni changed:
What|Removed |Added
CC||thomas.petazzoni@free-elect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121567
Thomas Petazzoni changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108581
--- Comment #4 from anlauf at gcc dot gnu.org ---
The following one-liner fixes the issue:
diff --git a/gcc/fortran/trans-io.cc b/gcc/fortran/trans-io.cc
index df2fef70172..b73a8b4948d 100644
--- a/gcc/fortran/trans-io.cc
+++ b/gcc/fortran/trans
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108872
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121894
--- Comment #14 from qinzhao at gcc dot gnu.org ---
with the fix in comment #13, the optimized IR for the testing case in
description is:
void foo ()
{
int s$b;
[local count: 1073741824]:
s$b_6 = .DEFERRED_INIT (4, 1, &"s"[0]);
bar (2,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121795
--- Comment #3 from GCC Commits ---
The releases/gcc-15 branch has been updated by Patrick Palka
:
https://gcc.gnu.org/g:a03c244f530346ed04a3ecac0c718d83ed7fae47
commit r15-10319-ga03c244f530346ed04a3ecac0c718d83ed7fae47
Author: Patrick Palka
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121795
--- Comment #2 from GCC Commits ---
The master branch has been updated by Patrick Palka :
https://gcc.gnu.org/g:8e3230f4fed0d41e790d68c2534c057911bab35c
commit r16-3832-g8e3230f4fed0d41e790d68c2534c057911bab35c
Author: Patrick Palka
Date: F
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120378
--- Comment #8 from GCC Commits ---
The master branch has been updated by Edwin Lu :
https://gcc.gnu.org/g:d0c08415310d1daecb28f8fbfeef3d7f18b21d56
commit r16-3831-gd0c08415310d1daecb28f8fbfeef3d7f18b21d56
Author: Edwin Lu
Date: Mon Sep 8 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114457
Jakub Jelinek changed:
What|Removed |Added
Attachment #62368|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121917
Patrick Palka changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121921
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121894
--- Comment #11 from qinzhao at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #9)
>
> For SRA decisions, it is better to handle s = .DEFERRED_INIT (); similarly to
> s = {};
Yes, that's what I am doing right now: try to fix this f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121894
--- Comment #12 from qinzhao at gcc dot gnu.org ---
(In reply to Martin Jambor from comment #10)
> You can most likely set it in scan_function() at eactly the same place
> where IFN_DEFERRED_INIT is already handled specially.
yeah, thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121894
--- Comment #10 from Martin Jambor ---
(In reply to qinzhao from comment #8)
> in tree-sra.cc, for the following stmt:
> s = {};
>
> for the above lhs "s", the field "grp_assignment_write" of the created
> struct access is 1;
>
> however, for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121876
David Malcolm changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121888
H.J. Lu changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121148
--- Comment #19 from Jonathan Wakely ---
The problem is -fanalyzer-call-summaries
If I do
git checkout 6456da6bab8a2c43e7899afda991589065d96595^
libstdc++-v3/include/ext/atomicity.h
then the analyzer warnings come back. If I then make this c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121928
--- Comment #1 from Jonathan Wakely ---
Slightly simpler version of the "fix it by defining OLD_CODE" change, with a
little more context:
--- a/libstdc++-v3/include/ext/atomicity.h
+++ b/libstdc++-v3/include/ext/atomicity.h
@@ -92,24 +92,29 @@
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121894
--- Comment #8 from qinzhao at gcc dot gnu.org ---
in tree-sra.cc, for the following stmt:
s = {};
for the above lhs "s", the field "grp_assignment_write" of the created struct
access is 1;
however, for the following stmt:
s= .DEFERRED_INIT (8,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121888
--- Comment #1 from GCC Commits ---
The master branch has been updated by H.J. Lu :
https://gcc.gnu.org/g:5d6ddba76434a9f0dc105d2e6c38954739ccbcb6
commit r16-3829-g5d6ddba76434a9f0dc105d2e6c38954739ccbcb6
Author: H.J. Lu
Date: Wed Sep 10 05
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121928
--- Comment #2 from Jonathan Wakely ---
The old code just does *mem += val with both values having type int, while the
new code does the arithmetic in unsigned and assigns back to the int. But apart
from one being well-defined for all values (no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121928
Bug ID: 121928
Summary: FAIL:
g++.dg/analyzer/fanalyzer-show-events-in-system-header
s-no.C
Product: gcc
Version: 15.2.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117276
--- Comment #14 from Oliver Schönrock ---
(In reply to Jonathan Wakely from comment #13)
> Thanks for the reminder, fixed on trunk only so far.
Great to see this get fixed. Thanks Jonathan.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121894
--- Comment #9 from Jakub Jelinek ---
(In reply to qinzhao from comment #8)
> in tree-sra.cc, for the following stmt:
> s = {};
>
> for the above lhs "s", the field "grp_assignment_write" of the created
> struct access is 1;
>
> however, for t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71945
Bug 71945 depends on bug 121148, which changed state.
Bug 121148 Summary: Should use modular arithmetic for _Atomic_word
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121148
What|Removed |Added
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121148
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |FIXED
Status|REOPENED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108872
--- Comment #3 from Tomáš Trnka ---
(In reply to anlauf from comment #2)
> It appears that the testcase in comment#0 does no longer fail since
> at least 13.3.0. It still crashes with 12.5.0.
You're right, I just rechecked with all releases of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116253
Bug 116253 depends on bug 121876, which changed state.
Bug 121876 Summary: [16 Regression] recursive ICE in ICE handling with nested
diagnostics, in set_diagnostic_buffer, at buffering.cc:49
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121876
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120063
--- Comment #5 from David Malcolm ---
Thanks for filing this bug.
I considered making fatal_error be a "notification" within the
"toolExecutionNotifications" of the "invocation" (similar to ICEs), but it's
simpler to treat it as "error" result.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120063
--- Comment #4 from GCC Commits ---
The master branch has been updated by David Malcolm :
https://gcc.gnu.org/g:259347de43e9650659a6e7e624b5dc037c0180a0
commit r16-3828-g259347de43e9650659a6e7e624b5dc037c0180a0
Author: David Malcolm
Date: F
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121876
--- Comment #2 from GCC Commits ---
The master branch has been updated by David Malcolm :
https://gcc.gnu.org/g:38cb4289180d13a71c2e1005223f442747bcf56e
commit r16-3827-g38cb4289180d13a71c2e1005223f442747bcf56e
Author: David Malcolm
Date: F
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121703
--- Comment #5 from David Binderman ---
(In reply to Richard Biener from comment #4)
> I think this is fixed now.
I think so also. UBSAN bootstrap with -g -O2 -march=znver3 works.
I will try changing -O2 to -O3 and see what happens.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117276
--- Comment #13 from Jonathan Wakely ---
Thanks for the reminder, fixed on trunk only so far.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524
Bug 103524 depends on bug 121893, which changed state.
Bug 121893 Summary: [16 Regression] [Modules] ICE when using modules + ranges.
regression in gcc 16.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121893
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121893
Nathaniel Shead changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121046
--- Comment #6 from GCC Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:f534db54a65b42638c08275338423063fe836f31
commit r16-3823-gf534db54a65b42638c08275338423063fe836f31
Author: Jonathan Wakely
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117276
--- Comment #12 from GCC Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:d8f1655a781a76f5c86b3545b181b2005e585d29
commit r16-3824-gd8f1655a781a76f5c86b3545b181b2005e585d29
Author: Jonathan Wakely
Date
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121893
--- Comment #3 from GCC Commits ---
The master branch has been updated by Nathaniel Shead :
https://gcc.gnu.org/g:85409b9d6a29392d33f3fbac40c641eeda22062a
commit r16-3822-g85409b9d6a29392d33f3fbac40c641eeda22062a
Author: Nathaniel Shead
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121393
--- Comment #2 from Andrew Stubbs ---
Here's preprocessed code:
#pragma omp for collapse(3)
for (v1 = 0; v1 < 20; v1 += 2)
for (v2 = 0x7fffLL + 11ULL;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121148
H.J. Lu changed:
What|Removed |Added
Resolution|FIXED |---
Status|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71945
Bug 71945 depends on bug 121148, which changed state.
Bug 121148 Summary: Should use modular arithmetic for _Atomic_word
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121148
What|Removed |Added
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121926
--- Comment #5 from Cassio Neri ---
I already have an implementation of Tejú Jaguá that seems to work for IBM128
but I'm not yet comfortable with it. I'll be happy to drop this support
altogether if this is acceptable. More precisely, on platfor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121225
--- Comment #3 from Richard Biener ---
I think the bswap pass should instead re-use the original load and truncate it
instead of emitting another one.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121926
--- Comment #4 from Jonathan Wakely ---
You can bootstrap with --with-long-double-format=ieee to tell GCC to default to
IEEE long double on powerpc64le. That's what modern Linux POWER systems should
be using.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121926
--- Comment #3 from Cassio Neri ---
I see. I've sent the patch anyway but just ignore it.
https://patchwork.sourceware.org/project/gcc/patch/20250912115126.21006-1-cassio.n...@gmail.com/
I came across this problem when benchmarking Tejú Jaguá
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119739
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119739
--- Comment #2 from Jonathan Wakely ---
The most recent patch for this is
https://gcc.gnu.org/pipermail/gcc-patches/2025-August/693721.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121865
Nathaniel Shead changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524
Bug 103524 depends on bug 121865, which changed state.
Bug 121865 Summary: ICE with modules and LTO (expected template_decl, have
overload in maybe_template_info, at cp/mangle.cc:311)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121865
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121865
--- Comment #4 from GCC Commits ---
The master branch has been updated by Nathaniel Shead :
https://gcc.gnu.org/g:b9fde0219f35cd5244f647c20c7b31b0395dbc5a
commit r16-3821-gb9fde0219f35cd5244f647c20c7b31b0395dbc5a
Author: Nathaniel Shead
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117276
Jonathan Wakely changed:
What|Removed |Added
Summary|std::sort(par_unseq ,...) |[13/14/15/16 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117276
Benjamin Buch changed:
What|Removed |Added
CC||benni.buch at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121926
--- Comment #1 from Jonathan Wakely ---
Using std::generate_canonical with anything except float, double and long
double is undefined:
https://eel.is/c++draft/rand#req.genl-1.4
There is a patch underway to rewrite generate_canonical, for P0952
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121926
--- Comment #2 from Jonathan Wakely ---
(In reply to Cassio Neri from comment #0)
> 2) generate_canonical fails to compile on powerpc*
> (long double==IBM128):
You can stop testing this configuration, it isn't a good use of anybody's time
:-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121927
Bug ID: 121927
Summary: [gcn][OpenMP] "Asynchronous queue error" with 'omp
parallel if(0) ordered' + 'omp ordered'
Product: gcc
Version: 16.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121926
Bug ID: 121926
Summary: generate_canonical fails for std::float16_t and
std::float128_t
Product: gcc
Version: 15.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121925
--- Comment #4 from Tamar Christina ---
(In reply to Richard Biener from comment #3)
> (In reply to Tamar Christina from comment #0)
> > Given the following vectors
> >
> > a = [A1 A0]
> > b = [C D ]
>
> b = [C B] I suppose?
yeah, I double
1 - 100 of 108 matches
Mail list logo
