[Bug target/114860] [14/15 regression] [aarch64] 511.povray regresses by ~5.5% with -O3 -flto -march=native -mcpu=neoverse-v2 since r14-10014-ga2f4be3dae04fa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114860 --- Comment #3 from Tamar Christina --- I cannot reproduce this even recompiling libc.
[Bug target/113950] PowerPC, ICE with -O1 or higher compiling __builtin_vsx_splat_2di test case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113950 --- Comment #6 from GCC Commits --- The releases/gcc-12 branch has been updated by jeevitha : https://gcc.gnu.org/g:1b91818e47119863f827b19ae4c6c91af3962cd6 commit r12-10406-g1b91818e47119863f827b19ae4c6c91af3962cd6 Author: Jeevitha Date: Sun Apr 28 23:38:41 2024 -0500 rs6000: Don't ICE when compiling the __builtin_vsx_splat_2di [PR113950] When we expand the __builtin_vsx_splat_2di built-in, we were allowing immediate value for second operand which causes an unrecognizable insn ICE. Even though the immediate value was forced into a register, it wasn't correctly assigned to the second operand. So corrected the assignment of op1 to operands[1]. 2024-03-07 Jeevitha Palanisamy gcc/ PR target/113950 * config/rs6000/vsx.md (vsx_splat_): Correct assignment to operand1 and simplify else if with else. gcc/testsuite/ PR target/113950 * gcc.target/powerpc/pr113950.c: New testcase. (cherry picked from commit fa0468877869f52b05742de6deef582e4dd296fc)
[Bug libstdc++/114863] std::format applying grouping to nan's and inf's
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114863 --- Comment #7 from Leo Carreon --- I'm assuming the fix is for all floating point types not just double.
[Bug rtl-optimization/114902] [14/15 Regression] wrong code at -O3 with "-fno-tree-vrp -fno-expensive-optimizations -fno-tree-dominator-opts" on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114902 --- Comment #5 from Andrew Pinski --- (In reply to Andrew Pinski from comment #4) > here is a reduced testcase: > Note ` -O1 -fno-tree-fre -fno-tree-forwprop -fno-tree-ccp > -fno-tree-dominator-opts` This testcase is broken in GCC 13 for mips64-linux-gnu with the added option -march=octeon. And it has been broken since at least 4.9.4. andi$4,$4,0x1 xori$4,$4,0x1 teq $4,0 j $31 move$2,$0 That is: $4 = $4 & 0x1 $4 = $4 ^ 1 trapif $4 == 0 That is the earliest compiler version I could test where I Know that sign_extract shows up in RTL.
[Bug rtl-optimization/114902] [14/15 Regression] wrong code at -O3 with "-fno-tree-vrp -fno-expensive-optimizations -fno-tree-dominator-opts" on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114902
--- Comment #4 from Andrew Pinski ---
here is a reduced testcase:
```
[[gnu::noipa]]
int f(int b)
{
int tt1 = ~b;
int t = 1 & tt1;
int e = -t;
int tt = e >= -1;
if (tt) return 0;
__builtin_trap();
}
int main()
{
for(int i = -1;i < 2; i++)
f(i);
}
```
Note ` -O1 -fno-tree-fre -fno-tree-forwprop -fno-tree-ccp
-fno-tree-dominator-opts` is needed to reproduce it with this one. The generate
gimple is the same between GCC 13 and 14 here.
But the first difference is in combine:
```
Trying 7 -> 8:
7: {r106:SI=r105:SI&0x1;clobber flags:CC;}
REG_DEAD r105:SI
REG_UNUSED flags:CC
8: {r107:SI=-r106:SI;clobber flags:CC;}
REG_DEAD r106:SI
REG_UNUSED flags:CC
Successfully matched this instruction:
(parallel [
(set (reg:SI 107 [ e_5 ])
(sign_extract:SI (reg:SI 105 [ tt1_3 ])
(const_int 1 [0x1])
(const_int 0 [0])))
(clobber (reg:CC 17 flags))
])
allowing combination of insns 7 and 8
original costs 4 + 4 = 8
replacement cost 4
deferring deletion of insn with uid = 7.
modifying insn i3 8: {r107:SI=sign_extract(r105:SI,0x1,0);clobber
flags:CC;}
REG_DEAD r105:SI
```
This is correct but it goes down hill after like as I mentioned in comment #2.
So it does look like a latent bug after all.
If someone does a bisect of this testcase, I am 99% sure you find
r14-4810-ge28869670c9879 is where the failure was introduced. For the original
testcase and the one in comment #1 might find a different commit due to gimple
level being different.
[Bug c++/98940] Implement C++23 language features
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98940 Bug 98940 depends on bug 107688, which changed state. Bug 107688 Summary: [C++23] P2615 - Meaningful exports https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107688 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c++/107688] [C++23] P2615 - Meaningful exports
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107688 Nathaniel Shead changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED Target Milestone|--- |15.0 --- Comment #3 from Nathaniel Shead --- Implemented for GCC 15.
[Bug c++/107688] [C++23] P2615 - Meaningful exports
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107688
--- Comment #2 from GCC Commits ---
The master branch has been updated by Nathaniel Shead :
https://gcc.gnu.org/g:79420dd344145819677b3f975bb305a778fcaf91
commit r15-84-g79420dd344145819677b3f975bb305a778fcaf91
Author: Nathaniel Shead
Date: Mon Mar 4 23:58:30 2024 +1100
c++: Implement P2615 'Meaningful Exports' [PR107688]
This clarifies which kinds of declarations may and may not be exported
in various contexts. The patch additionally fixes up some small issues
that were clarified by the paper.
Most of the changes are with regards to export-declarations, which are
applied for all standards modes that we support '-fmodules-ts' for.
However there are also a couple of changes made to linkage specifiers
('extern "C"'); I've applied these as since C++20, to line up with when
modules were actually introduced.
PR c++/107688
gcc/cp/ChangeLog:
* name-lookup.cc (push_namespace): Error when exporting
namespace with internal linkage.
* parser.h (struct cp_parser): Add new flag
'in_unbraced_export_declaration_p'.
* parser.cc (cp_debug_parser): Print the new flag.
(cp_parser_new): Initialise the new flag.
(cp_parser_module_export): Set the new flag.
(cp_parser_class_specifier): Clear and restore the new flag.
(cp_parser_import_declaration): Imports can now appear directly
in a linkage specification.
(cp_parser_declaration): Categorise declarations as "name" or
"special"; error on the later in contexts where the former is
required.
(cp_parser_class_head): Error when exporting a partial
specialisation.
gcc/testsuite/ChangeLog:
* g++.dg/modules/contracts-1_a.C: Avoid now-illegal syntax.
* g++.dg/modules/contracts-2_a.C: Likewise.
* g++.dg/modules/contracts-3_a.C: Likewise.
* g++.dg/modules/contracts-4_a.C: Likewise.
* g++.dg/modules/lang-1_c.C: Clarify now-legal syntax.
* g++.dg/modules/pr101582-1.C: Remove now-legal XFAILS.
* g++.dg/template/crash71.C: Update error messages.
* g++.dg/cpp2a/linkage-spec1.C: New test.
* g++.dg/modules/export-3.C: New test.
* g++.dg/modules/export-4_a.C: New test.
* g++.dg/modules/export-4_b.C: New test.
Signed-off-by: Nathaniel Shead
[Bug c++/114630] [14/15 Regression] [modules] building module with submodule causes corrupt gcm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114630
--- Comment #7 from Patrick Palka ---
The following seems to minimally fix it:
diff --git a/gcc/cp/module.cc b/gcc/cp/module.cc
index c35e70b8cb8..57ccaec5ebd 100644
--- a/gcc/cp/module.cc
+++ b/gcc/cp/module.cc
@@ -6798,7 +6798,7 @@ trees_in::core_vals (tree t)
body) anyway. */
decl = maybe_duplicate (decl);
- if (!DECL_P (decl) || DECL_CHAIN (decl))
+ if (!DECL_P (decl) || (*chain && *chain != decl))
{
set_overrun ();
break;
In 114630_c.C end up streaming the definition of _M_do_parse() twice, once
from modB and once from the transitive import of modA (which seems wasteful).
The second time around the chain of local types _M_do_parse::A/B get
streamed as simple back references and therefore on stream-in they'll already
have DECL_CHAIN properly set, so we shouldn't give up just because DECL_CHAIN
is already set. Rather, only give up if DECL_CHAIN of the previous decl isn't
what we expect it to be, i.e. either empty or what we want to set it to.
This raises the question, why do we stream the definition of _M_do_parse()
from the GMF of modA even though the same definition is already reachable (and
has been deduplicated) from the import of modB? Seems like this is something
we could/should avoid.
[Bug rtl-optimization/114902] [14/15 Regression] wrong code at -O3 with "-fno-tree-vrp -fno-expensive-optimizations -fno-tree-dominator-opts" on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114902 --- Comment #3 from Andrew Pinski --- Note this is almost definitely a latent bug exposed by some change. Might be interesting to see what change exposed it but not so much really.
[Bug rtl-optimization/114902] [14/15 Regression] wrong code at -O3 with "-fno-tree-vrp -fno-expensive-optimizations -fno-tree-dominator-opts" on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114902
Andrew Pinski changed:
What|Removed |Added
Component|target |rtl-optimization
--- Comment #2 from Andrew Pinski ---
Looks like the issue is during combine.
After combine we have:
```
12: r113:SI=[`b']
13: r112:SI=~r113:SI
REG_DEAD r113:SI
REG_EQUAL ~[`b']
14: NOTE_INSN_DELETED
15: {r109:SI=sign_extract(r112:SI,0x1,0);clobber flags:CC;}
REG_UNUSED flags:CC
18: NOTE_INSN_DELETED
19: NOTE_INSN_DELETED
22: r117:SI=0x1
21: flags:CCZ=cmp(zero_extract(r112:SI,0x1,0),0)
REG_DEAD r112:SI
23: r106:SI={(flags:CCZ==0)?r109:SI:r117:SI}
REG_DEAD r117:SI
REG_DEAD r109:SI
REG_DEAD flags:CCZ
REG_EQUAL {(flags:CCZ==0)?r109:SI:0x1}
```
insn 21 is wrong.
```
Trying 15 -> 18:
15: {r109:SI=sign_extract(r112:SI,0x1,0);clobber flags:CC;}
REG_DEAD r112:SI
REG_UNUSED flags:CC
18: flags:CCGC=cmp(r109:SI,0x)
Failed to match this instruction:
(parallel [
(set (reg:CCZ 17 flags)
(compare:CCZ (zero_extract:SI (reg:SI 112 [ _2 ])
(const_int 1 [0x1])
(const_int 0 [0]))
(const_int 0 [0])))
(set (reg/v:SI 109 [ eD.2798 ])
(sign_extract:SI (reg:SI 112 [ _2 ])
(const_int 1 [0x1])
(const_int 0 [0])))
])
Failed to match this instruction:
(parallel [
(set (reg:CCZ 17 flags)
(compare:CCZ (zero_extract:SI (reg:SI 112 [ _2 ])
(const_int 1 [0x1])
(const_int 0 [0]))
(const_int 0 [0])))
(set (reg/v:SI 109 [ eD.2798 ])
(sign_extract:SI (reg:SI 112 [ _2 ])
(const_int 1 [0x1])
(const_int 0 [0])))
])
Failed to match this instruction:
(parallel [
(set (reg:CCZ 17 flags)
(compare:CCZ (and:SI (reg:SI 112 [ _2 ])
(const_int 1 [0x1]))
(const_int 0 [0])))
(set (reg/v:SI 109 [ eD.2798 ])
(sign_extract:SI (reg:SI 112 [ _2 ])
(const_int 1 [0x1])
(const_int 0 [0])))
])
Failed to match this instruction:
(parallel [
(set (reg:CCZ 17 flags)
(compare:CCZ (and:SI (reg:SI 112 [ _2 ])
(const_int 1 [0x1]))
(const_int 0 [0])))
(set (reg/v:SI 109 [ eD.2798 ])
(sign_extract:SI (reg:SI 112 [ _2 ])
(const_int 1 [0x1])
(const_int 0 [0])))
])
Successfully matched this instruction:
(set (reg/v:SI 109 [ eD.2798 ])
(sign_extract:SI (reg:SI 112 [ _2 ])
(const_int 1 [0x1])
(const_int 0 [0])))
Successfully matched this instruction:
(set (reg:CCZ 17 flags)
(compare:CCZ (zero_extract:SI (reg:SI 112 [ _2 ])
(const_int 1 [0x1])
(const_int 0 [0]))
(const_int 0 [0])))
Successfully matched this instruction:
(set (reg:QI 115 [ _10 ])
(ne:QI (reg:CCZ 17 flags)
(const_int 0 [0])))
allowing combination of insns 15 and 18
original costs 4 + 4 = 12
replacement costs 4 + 4 = 12
modifying other_insn19: r115:QI=flags:CCZ!=0
REG_DEAD flags:CCGC
deferring rescan insn with uid = 19.
modifying insn i215: {r109:SI=sign_extract(r112:SI,0x1,0);clobber
flags:CC;}
REG_UNUSED flags:CC
deferring rescan insn with uid = 15.
modifying insn i318: flags:CCZ=cmp(zero_extract(r112:SI,0x1,0),0)
REG_DEAD r112:SI
deferring rescan insn with uid = 18.
```
We go from CCGC with a sign_extend to a zero_extend with CCZ. that can't be
right.
[Bug target/114902] [14/15 Regression] wrong code at -O3 with "-fno-tree-vrp -fno-expensive-optimizations -fno-tree-dominator-opts" on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114902
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |14.0
Summary|wrong code at -O3 with |[14/15 Regression] wrong
|"-fno-tree-vrp |code at -O3 with
|-fno-expensive-optimization |"-fno-tree-vrp
|s -fno-tree-dominator-opts" |-fno-expensive-optimization
|on x86_64-linux-gnu |s -fno-tree-dominator-opts"
||on x86_64-linux-gnu
Component|tree-optimization |target
Status|UNCONFIRMED |NEW
Last reconfirmed||2024-05-01
Ever confirmed|0 |1
Target||x86_64-linux-gnu
--- Comment #1 from Andrew Pinski ---
Confirmed.
Here is a testcase which does not depedent on division by zero trapping:
```
volatile int a, c;
unsigned b = 1;
int main() {
a = 1;
for (; c < 2; c++) {
unsigned t = 1 & ~b;
int e = -t;
int f = -~(!!(1 % a));
if (a == 0) __builtin_trap();
if (e >= -1)
e = 1;
a = e;
}
return 0;
}
```
The testcase works on aarch64-linux-gnu with no issues.
The difference between GCC 13 and 14 is on the gimple level but the code looks
correct there.
In GCC 13 .optimized has:
```
b.0_1 = b;
_2 = b.0_1 & 1;
_3 = _2 + 4294967295;
e_16 = (int) _3;
_13 = e_16 >= -1;
e_11 = _13 ? 1 : e_16;
```
While in 14 .optimized has:
```
b.0_1 = b;
_2 = ~b.0_1;
t_13 = _2 & 1;
_3 = -t_13;
e_14 = (int) _3;
_10 = e_14 >= -1;
e_9 = _10 ? 1 : e_14;
```
Both are valid and correct.
But then it goes wrong after that.
I have not looked where though.
[Bug tree-optimization/114872] [13/14/15 Regression] Miscompilation with -O2 after commit r13-8037
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114872 --- Comment #11 from Sam James --- also, do asan and ubsan give anything?
[Bug tree-optimization/114872] [13/14/15 Regression] Miscompilation with -O2 after commit r13-8037
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114872 --- Comment #10 from Sam James --- also maybe obvious, but if you can find something from the cython testsuite, or at least some other heavy use of cython, which fails, that may be a good direction.
[Bug tree-optimization/114872] [13/14/15 Regression] Miscompilation with -O2 after commit r13-8037
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114872 --- Comment #9 from Sam James --- unfortunately*
[Bug tree-optimization/114872] [13/14/15 Regression] Miscompilation with -O2 after commit r13-8037
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114872 --- Comment #8 from Sam James --- element.i is unfortunatley huge. It's hard to analyse things without a standalone testcase, but it's even harder without _something_ one can run. I'd suggest: 1) giving instructions to reproduce the crash assuming someone knows nothing about sage and cython; 2) taking sage and cannibalising it (first to directly call `libgap.AbelianGroup(0,0,0)`, then you can cut things down with lots of removals + gdb so that the important caller of Py_XDECREF gets passed with the same args; it's harder if there's a lot of state involved though, of course) 3) build element.i with -fdump-tree-all -fdump-unnumbered -fdump-noaddr (can also try e.g. -da, see https://gcc.gnu.org/onlinedocs/gcc/Developer-Options.html) at the bad commit and before, and diff the produced dumps, and show us the *first* dump which differs between the two
[Bug c/20785] Pragma STDC * (C99 FP) unimplemented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=20785 Campbell changed: What|Removed |Added CC||rlcamp.pdx at gmail dot com --- Comment #19 from Campbell --- Regardless of the wider issue, it would be nice to get STDC CX_LIMITED_RANGE implemented. Is there something specific blocking this?
[Bug tree-optimization/114902] New: wrong code at -O3 with "-fno-tree-vrp -fno-expensive-optimizations -fno-tree-dominator-opts" on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114902
Bug ID: 114902
Summary: wrong code at -O3 with "-fno-tree-vrp
-fno-expensive-optimizations -fno-tree-dominator-opts"
on x86_64-linux-gnu
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: zhendong.su at inf dot ethz.ch
Target Milestone: ---
It appears to be a recent regression as it doesn't reproduce with 13.2.
Compiler Explorer: https://godbolt.org/z/7ssP5W57E
[587] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/suz-local/software/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/15.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-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.0 20240430 (experimental) (GCC)
[588] %
[588] % gcctk -O3 -fno-tree-vrp -fno-expensive-optimizations
-fno-tree-dominator-opts small.c
[589] % ./a.out
Floating point exception
[590] %
[590] % gcctk -O3 small.c; ./a.out
[591] %
[591] % cat small.c
volatile int a, c;
unsigned b = 1;
int main() {
for (; a < 2; a++)
if (a)
for (; c < 2; c++) {
int d = -1, e = -(-d & ~b), f = -~(1 && b % a);
a % f || a;
if (d <= e)
e = a;
a = e;
}
return 0;
}
[Bug libstdc++/114862] std::uppercase not applying to nan's and inf's
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114862 --- Comment #3 from Jonathan Wakely --- I've opened https://cplusplus.github.io/LWG/issue4084
[Bug c++/114841] [P0522R0] partial ordering of template template parameters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114841 --- Comment #1 from Jason Merrill --- Matheus' suggested wording: "When performing deduction such that both A and P are template template params, and A is the template name of a template specialization, instead of just deducing A in that case, we synthesize a new template parameter from A, filling it's parameters with defaults coming from their corresponding template specialization argument."
[Bug ada/81087] array index out of range in gnatlink, making test always false
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81087 --- Comment #6 from Eric Botcazou --- There is a fix in the pipeline for GCC 15, although I'm not sure if it will handle all the issues.
[Bug c/81756] type attributes silently ignored on type declarations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81756
--- Comment #3 from Joseph S. Myers ---
This sort of "???" comment about existing practice means that some past change
(in this case, the one adding support for [[]] attributes) was aiming to avoid
perturbing how the compiler behaved for constructs that were not the subject of
the change (in this case, __attribute__).
Silently ignoring attributes is not good, but it would be important to diagnose
cases where they cannot be respected, such as when the attributes appear after
the type was defined and are not consistent with the attributes in effect when
it was defined.
The documentation you refer to is intended to mean that "struct
__attribute__((...)) foo { ... }" is preferred to "struct foo { ... }
__attribute__((...))", not to suggest that the attributes should be used in a
declaration that does not define the tagged type.
[Bug c++/114901] GCC internal_error on CTAD alias
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114901
--- Comment #3 from Marek Polacek ---
Before, it was rejected:
114901.C:21:23: error: class template argument deduction failed:
21 | T::AFoo s{1, 2};
| ^
114901.C:21:23: error: no matching function for call to ‘Foo(int, int)’
[Bug c++/114901] GCC internal_error on CTAD alias
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114901 Marek Polacek changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #2 from Marek Polacek --- Started with r13-6555: commit 9e6170098d5e7756e85e880f8f4cb18e885a64fd Author: Jason Merrill Date: Wed Feb 8 22:06:22 2023 -0800 c++: fix alias CTAD [PR105841]
[Bug c++/114901] GCC internal_error on CTAD alias
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114901
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
Status|UNCONFIRMED |NEW
Last reconfirmed||2024-04-30
Ever confirmed|0 |1
--- Comment #1 from Marek Polacek ---
Confirmed.
$ ./cc1plus -quiet 114901.C -std=c++20
114901.C: In static member function ‘static T::Foo(int, Y2)-> Foo requires __is_deducible (T::AFoo, T::Foo)’:
114901.C:21:23: internal compiler error: in keep_template_parm, at
cp/pt.cc:10933
21 | T::AFoo s{1, 2};
| ^
0x10dffa0 keep_template_parm
/home/mpolacek/src/gcc/gcc/cp/pt.cc:10933
0x10df925 for_each_template_parm_r
/home/mpolacek/src/gcc/gcc/cp/pt.cc:10740
0x1ec3aef walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
/home/mpolacek/src/gcc/gcc/tree.cc:11429
0x10dfc15 for_each_template_parm
/home/mpolacek/src/gcc/gcc/cp/pt.cc:10843
0x10e0362 any_template_parm_r
/home/mpolacek/src/gcc/gcc/cp/pt.cc:10975
0x10dec7e for_each_template_parm_r
/home/mpolacek/src/gcc/gcc/cp/pt.cc:10632
0x1ec3aef walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
/home/mpolacek/src/gcc/gcc/tree.cc:11429
0x10dfc15 for_each_template_parm
/home/mpolacek/src/gcc/gcc/cp/pt.cc:10843
0x10e07aa find_template_parameter_info::find_in(tree_node*)
/home/mpolacek/src/gcc/gcc/cp/pt.cc:11023
0x10e0a22 find_template_parameters(tree_node*, tree_node*)
/home/mpolacek/src/gcc/gcc/cp/pt.cc:11075
0xe2a236 build_parameter_mapping
/home/mpolacek/src/gcc/gcc/cp/constraint.cc:594
0xe2aa02 normalize_atom
/home/mpolacek/src/gcc/gcc/cp/constraint.cc:819
0xe2ad29 normalize_expression
/home/mpolacek/src/gcc/gcc/cp/constraint.cc:886
0xe2a4c9 normalize_logical_operation
/home/mpolacek/src/gcc/gcc/cp/constraint.cc:692
0xe2acb2 normalize_expression
/home/mpolacek/src/gcc/gcc/cp/constraint.cc:882
0xe2ad82 get_normalized_constraints
/home/mpolacek/src/gcc/gcc/cp/constraint.cc:898
0xe2ae40 get_normalized_constraints_from_info
/home/mpolacek/src/gcc/gcc/cp/constraint.cc:914
0xe2b0df get_normalized_constraints_from_decl
/home/mpolacek/src/gcc/gcc/cp/constraint.cc:990
0xe33953 satisfy_declaration_constraints
/home/mpolacek/src/gcc/gcc/cp/constraint.cc:3378
0xe33a70 constraint_satisfaction_value
/home/mpolacek/src/gcc/gcc/cp/constraint.cc:3406
[Bug libstdc++/114863] std::format applying grouping to nan's and inf's
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114863 Jonathan Wakely changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #6 from Jonathan Wakely --- Fixed for 13.3 and 14.1, thanks for the report.
[Bug libstdc++/114863] std::format applying grouping to nan's and inf's
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114863 --- Comment #5 from GCC Commits --- The releases/gcc-13 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:61c38a231d2df60cb6e914b3ecc73a0229c17ff6 commit r13-8665-g61c38a231d2df60cb6e914b3ecc73a0229c17ff6 Author: Jonathan Wakely Date: Fri Apr 26 11:42:26 2024 +0100 libstdc++: Do not apply localized formatting to NaN and inf [PR114863] We don't want to add grouping to strings like "-inf", and there is no radix character to replace either. libstdc++-v3/ChangeLog: PR libstdc++/114863 * include/std/format (__formatter_fp::format): Only use _M_localized for finite values. * testsuite/std/format/functions/format.cc: Check localized formatting of NaN and initiny. (cherry picked from commit 7501c0a397fcf609a1ff5f083746b6330b89ee11)
[Bug c++/114901] New: GCC internal_error on CTAD alias
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114901
Bug ID: 114901
Summary: GCC internal_error on CTAD alias
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: hokein.wu at gmail dot com
Target Milestone: ---
GCC (trunk) crashes on the following code:
https://godbolt.org/z/43Tqf4qs9
```
template
constexpr bool C = sizeof(D);
template
struct T {
template
struct Foo {
Foo(V, N);
};
template
requires (C) // removes the require-clause will make the crash disappear
Foo(X, N) -> Foo;
template
using AFoo = Foo;
};
T::AFoo s{1, 2};
```
[Bug analyzer/114896] analyzer: false-positive with VLA (analyzer-out-of-bounds, CWE-121)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114896 David Malcolm changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2024-04-30 --- Comment #2 from David Malcolm --- Thanks for filing this bug. The reproducer on Compiler Explorer is: https://godbolt.org/z/4Pc7Wfx8r
[Bug c/81756] type attributes silently ignored on type declarations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81756
Mathias Krause changed:
What|Removed |Added
CC||jsm28 at gcc dot gnu.org,
||minipli at grsecurity dot net
--- Comment #2 from Mathias Krause ---
It's even worse. All GNU attributes get ignored for type declarations. Standard
C attributes, however, are taken into account and I don't see the rationale
behind this? Joseph, do you remember?
The relevant documentation regarding this is even misleading. It states the
following at https://gcc.gnu.org/onlinedocs/gcc/Type-Attributes.html:
"""
You may specify type attributes in an enum, struct or union type declaration or
definition by placing them immediately after the struct, union or enum keyword.
"""
Please note, how declarations are explicitly mentioned, making the reader
assume this, indeed, actually works.
In the very next sentence it gets even more misleading:
"""
You can also place them just past the closing curly brace of the definition,
but this is less preferred because logically the type should be fully defined
at the closing brace.
"""
This can be read as discouraging the use in definitions, implicitly implying
declarations are the preferred way to add attributes while, in fact,
declarations silently ignore these attributes. They get parsed, still, but not
attached to the type declaration at all.
The misleading behaviour can be shown by trying to compile this C code snippet:
```
struct __attribute__((aligned(64))) foo;
struct foo { char i; };
_Static_assert(__alignof__(struct foo) == 64, "decl attribute ignored!");
```
The attribute of the declaration in line 1 should be inherited by the
definition in line 2, making the assert in line 4 pass. However, basically all
versions of gcc fail the assert, as can be seen on godbolt:
https://godbolt.org/z/ssW7T363W
Clang seems to comply to gcc's documentation much better, starting as early as
of clang 3.2. Again, here's the godbolt link: https://godbolt.org/z/MnvzsvcGG
Newer versions of gcc supporting the C23 attribute syntax do pass the test when
specifying attributes using the standard syntax, as can be seen here:
https://godbolt.org/z/8Ee4E3exP
However, I don't see a reason why it should be limited to only the C23
attribute syntax. Especially, as the GNU syntax gets *silently* ignored and
clang already unconditionally excepts both variants.
The following change fixes -- at least from my understanding -- the broken
behaviour in gcc:
diff --git a/gcc/c/c-parser.cc b/gcc/c/c-parser.cc
index 00f8bf4376e5..02cf46f199d7 100644
--- a/gcc/c/c-parser.cc
+++ b/gcc/c/c-parser.cc
@@ -4114,7 +4114,8 @@ c_parser_struct_or_union_specifier (c_parser *parser)
c_parser_error (parser, "expected %<;%>");
/* ??? Existing practice is that GNU attributes are ignored after
the struct or union keyword when not defining the members. */
- ret = parser_xref_tag (ident_loc, code, ident, have_std_attrs, std_attrs,
+ ret = parser_xref_tag (ident_loc, code, ident, have_std_attrs || attrs,
+std_attrs ? chainon (std_attrs, attrs) : attrs,
false);
return ret;
}
It's far from a proper change, as there are more places that need to be adapted
to, for example, cover enums as well. However, it shows where things go wrong
and where the (still parsed!) (GNU only!) attributes get silently ignored. And
yes, the comment needs a change too.
If there's consent that gcc should follow Clang's lead and actually comply to
its own documentation, I can prepare a proper patch.
Thanks,
Mathias
[Bug analyzer/111475] [14/15 regression] Many C++ analyzer tests FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111475 David Malcolm changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #11 from David Malcolm --- Thanks. I've been working on this on cfarm216; I have a messy set of patches with this improvement to g++.sum with analyzer.exp so far: # of expected passes 11395 -> 12015 # of unexpected failures 684 ->64 # of unexpected successes 4 -> 0 # of expected failures 443 -> 447 # of unsupported tests50 However I'm don't have access to my regular workstation/testing box until late tomorrow, so I'm holding off on posting until I've cleaned them up and put them through my usual testing regime. Sorry again about the noise
[Bug c++/104177] coroutine frame is not being allocated with the correct alignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104177 Andrew Pinski changed: What|Removed |Added CC||jankodedic2 at gmail dot com --- Comment #22 from Andrew Pinski --- *** Bug 114900 has been marked as a duplicate of this bug. ***
[Bug c++/114900] Overaligned locals in coroutines are not properly aligned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114900 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Andrew Pinski --- Anyways it is a dup of bug 104177. *** This bug has been marked as a duplicate of bug 104177 ***
[Bug c++/114900] Overaligned locals in coroutines are not properly aligned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114900 --- Comment #1 from Andrew Pinski --- This is by design for C++20 ... The support for P2014 is not in GCC yet, and IIRC it won't be enable for C++20 only C++23+.
[Bug c++/114900] New: Overaligned locals in coroutines are not properly aligned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114900
Bug ID: 114900
Summary: Overaligned locals in coroutines are not properly
aligned
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jankodedic2 at gmail dot com
Target Milestone: ---
GCC 13.2.0 (x86-64)
Flags: -std=c++20
Godbolt link: https://godbolt.org/z/f3KGaGWW6
Overaligned locals in coroutines are not properly aligned. If a local variable
is marked with alignas(n), GCC seemingly does nothing about it. If a local
variable just has an overaligned type, GCC seems to overallocate to try and
align it correctly but alignment is still incorrect (overallocation is probably
the only solution until P2014 is resolved -
https://github.com/cplusplus/papers/issues/750).
Full example pasted below:
```
#include
#include
#include
#include
static constexpr std::size_t alignment = 1 << 13;
bool
is_aligned(void* p)
{
return ((std::uintptr_t)p % alignment) == 0;
}
void* malloc_address = nullptr;
void* local_address = nullptr;
struct coro
{
std::coroutine_handle<> coroutine_handle;
struct promise_type
{
void*
operator new(std::size_t n)
{
std::cout << "allocating " << n << " bytes\n";
malloc_address = std::malloc(n);
return malloc_address;
}
void
operator delete(void* p)
{
std::free(p);
}
std::suspend_never
initial_suspend()
{
return {};
}
coro
get_return_object()
{
return {std::coroutine_handle::from_promise(*this)};
}
void
return_void()
{}
void
unhandled_exception()
{}
std::suspend_always
final_suspend() noexcept
{
return {};
}
};
};
struct S
{
alignas(alignment) int x = 42;
};
coro
foo()
{
#if 0
alignas(alignment) int x = 42;
#else
S x;
#endif
local_address = &x;
std::cout << "is aligned? " << is_aligned(local_address) << std::endl;
co_return;
}
int
main()
{
std::cout << "max align: " << alignof(std::max_align_t) << std::endl;
auto c = foo();
std::cout << "malloc_address: " << malloc_address << std::endl;
std::cout << "local_address: " << local_address << std::endl;
std::cout << "difference: " << ((char*)local_address -
(char*)malloc_address) << std::endl;
}
```
[Bug tree-optimization/114894] `a == 0 ? 0 : a * b` -> `a * b` likewise for `a & b`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114894
--- Comment #4 from Andrew Pinski ---
And divides should happen if we know if the divisor is non-zero:
eg:
```
int fdiv(int a, int b)
{
if (b == 0) __builtin_unreachable();
int c = a / b;
int d = a != 0;
return c & -d;
}
```
Phi-OPT value-replacement does handle it for ifs right now:
```
int fmul3(int a, int b)
{
if (b == 0) __builtin_unreachable();
int c = a / b;
if (a == 0) return 0;
return c;
int d = a != 0;
return c & -d;
}
```
[Bug tree-optimization/114894] `a == 0 ? 0 : a * b` -> `a * b` likewise for `a & b`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114894
--- Comment #3 from Andrew Pinski ---
Note we should catch this too:
```
int fmul2(unsigned a, int b)
{
int c = a * b;
int d = a != 0;
return c & -d;
}
```
Which is more complex ...
[Bug target/98784] [11/12/13/14/15 Regression] problematic build of uClibc with -fPIC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98784 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |MOVED --- Comment #21 from Andrew Pinski --- Closing as moved.
[Bug target/98784] [11/12/13/14/15 Regression] problematic build of uClibc with -fPIC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98784 --- Comment #20 from Dmitriy Chestnykh --- The patch is pushed, sparc systems now works fine with uClibc-ng. I think we should close this issue. https://cgit.uclibc-ng.org/cgi/cgit/uclibc-ng.git/commit/?id=c8d6b02d714251afc82157eabb8752fd0010030e Best regards, Dmitriy
[Bug c++/114458] [C++26] P2573R2 - = delete("reason");
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114458 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- Created attachment 58078 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58078&action=edit gcc15-pr114458.patch Untested implementation.
[Bug fortran/114874] [14/15 Regression] ICE with select type, type is (character(*)), and substring
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114874 --- Comment #6 from Paul Thomas --- (In reply to anlauf from comment #3) > Adding Paul, hoping that he can tell what changed for SELECT TYPE recently. Needless to say, the regression is caused by r14-9489. I have a fix that regtests OK but causes a regression in an, as yet, untested corner: subroutine foobar type :: t integer :: i end type class(*), allocatable :: c c = t (1) select type (c) type is (t) if (c(1)%i .ne. 1) stop 5 ! This now ICEs end select end My efforts have been interrupted by a failure of make-install, which seems to happen every few months. I rather think that I should go back to magnetic drives, rather than SSD. It will now have to wait until tomorrow. Paul
[Bug c++/103524] [meta-bug] modules issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524 Bug 103524 depends on bug 106820, which changed state. Bug 106820 Summary: [modules] ICE in function_and_variable_visibility with modules and weakref https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106820 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug c++/99227] [meta-bug] [modules] Bugs relating to header-units of STL header files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99227 Bug 99227 depends on bug 106820, which changed state. Bug 106820 Summary: [modules] ICE in function_and_variable_visibility with modules and weakref https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106820 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug c++/106820] [modules] ICE in function_and_variable_visibility with modules and weakref
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106820 Patrick Palka changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED Target Milestone|--- |14.0 --- Comment #11 from Patrick Palka --- Fixed for GCC 14(?)
[Bug c/61469] language feature: Support for enum underlying type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61469 --- Comment #17 from Thomas Mercier --- I see, thank you!
[Bug c/61469] language feature: Support for enum underlying type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61469
--- Comment #16 from Andrew Pinski ---
(In reply to Thomas Mercier from comment #15)
> No objection to the error message, but I would have expected a syntax error
> for standards earlier than 23 which don't claim to support manually
> specifying the underlying type for the enum. Like this with gcc 12:
>
> test.c:1:21: error: expected identifier or ‘(’ before ‘:’ token
> 1 | enum node_stat_item : unsigned {
Yes it is supported as an extension to older languages as the syntax does not
conflict with valid code. If you want an error for the extension you can use
-Werror=c11-c23-compat
[Bug tree-optimization/111882] [13 Regression] : internal compiler error: in get_expr_operand in ifcvt with Variable length arrays and bitfields inside a struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111882 avieira at gcc dot gnu.org changed: What|Removed |Added Summary|[13/14/15 Regression] : |[13 Regression] : internal |internal compiler error: in |compiler error: in |get_expr_operand in ifcvt |get_expr_operand in ifcvt |with Variable length arrays |with Variable length arrays |and bitfields inside a |and bitfields inside a |struct |struct Known to work||14.0 --- Comment #5 from avieira at gcc dot gnu.org --- Fixed on gcc-14 (when it was trunk, so removing 14 and 15 tag. Still needs backport to gcc-13
[Bug c/61469] language feature: Support for enum underlying type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61469
--- Comment #15 from Thomas Mercier ---
No objection to the error message, but I would have expected a syntax error for
standards earlier than 23 which don't claim to support manually specifying the
underlying type for the enum. Like this with gcc 12:
test.c:1:21: error: expected identifier or ‘(’ before ‘:’ token
1 | enum node_stat_item : unsigned {
[Bug c/61469] language feature: Support for enum underlying type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61469
--- Comment #14 from Andrew Pinski ---
(In reply to Thomas Mercier from comment #13)
> Was this feature meant to be protected by -std=c23? It doesn't appear to be
> in GCC 13:
>
> /tmp$ cat test.c
> enum node_stat_item : unsigned {
> NR_LRU_BASE = -1,
> NR_INACTIVE_ANON = NR_LRU_BASE, /* must match order of LRU_[IN]ACTIVE */
> NR_ACTIVE_ANON, /* " " " " " */
> NR_INACTIVE_FILE,
> };
>
> int main()
> {}
> /tmp$ gcc --version
> gcc (Debian 13.2.0-10) 13.2.0
> Copyright (C) 2023 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions. There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>
> /tmp$ gcc -std=c11 test.c
> test.c:2:23: error: enumerator value outside the range of underlying type
> 2 | NR_LRU_BASE = -1,
> | ^
> test.c:4:9: error: overflow in enumeration values
> 4 | NR_ACTIVE_ANON, /* " " " " "
> */
> |
Note that is the correct error even for C23. clang also errors out the similar
way:
```
:5:2: error: enumerator value 4294967296 is not representable in the
underlying type 'unsigned int'
5 | NR_ACTIVE_ANON, /* " " " " "
*/
| ^
```
[Bug c/61469] language feature: Support for enum underlying type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61469
Thomas Mercier changed:
What|Removed |Added
CC||thomas.mercier.jr at gmail dot
com
--- Comment #13 from Thomas Mercier ---
Was this feature meant to be protected by -std=c23? It doesn't appear to be in
GCC 13:
/tmp$ cat test.c
enum node_stat_item : unsigned {
NR_LRU_BASE = -1,
NR_INACTIVE_ANON = NR_LRU_BASE, /* must match order of LRU_[IN]ACTIVE
*/
NR_ACTIVE_ANON, /* " " " " " */
NR_INACTIVE_FILE,
};
int main()
{}
/tmp$ gcc --version
gcc (Debian 13.2.0-10) 13.2.0
Copyright (C) 2023 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
/tmp$ gcc -std=c11 test.c
test.c:2:23: error: enumerator value outside the range of underlying type
2 | NR_LRU_BASE = -1,
| ^
test.c:4:9: error: overflow in enumeration values
4 | NR_ACTIVE_ANON, /* " " " " "
*/
|
[Bug analyzer/114899] New: Segmentation fault with -fsanitize=undefined and -fanalyzer since r14-2029-g0e466e978c7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114899
Bug ID: 114899
Summary: Segmentation fault with -fsanitize=undefined and
-fanalyzer since r14-2029-g0e466e978c7
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: iamanonymous.cs at gmail dot com
Target Milestone: ---
Compiler Explorer: https://godbolt.org/z/v8c4csjTE
Bisected to r14-2029-g0e466e978c7
***
OS and Platform:
$ uname -a:
Linux ubuntu 4.15.0-213-generic #224-Ubuntu SMP Mon Jun 19 13:30:12 UTC 2023
x86_64 x86_64 x86_64 GNU/Linux
***
gcc version:
$ gcc -v
Using built-in specs.
COLLECT_GCC=/root/gcc_set/202404101100/bin/gcc
COLLECT_LTO_WRAPPER=/root/gcc_set/202404101100/libexec/gcc/x86_64-pc-linux-gnu/14.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --prefix=/root/gcc_set/202404101100
--with-gmp=/root/build_essential --with-mpfr=/root/build_essential
--with-mpc=/root/build_essential --enable-languages=c,c++ --disable-multilib
--with-sanitizer=address,undefined,thread,leak
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.0.1 20240410 (experimental) (GCC)
git version: 0774240b4df9a9bc48ce33a9625788e402498f5a
***
Program:
$ cat mutant.c
void a() {
int *b = __builtin_malloc(0);
int *c = b - 1;
++*c;
}
***
Command Lines:
$ gcc -fsanitize=undefined -fanalyzer -c mutant.c
mutant.c: In function ‘a’:
mutant.c:3:3: warning: heap-based buffer underwrite [CWE-124]
[-Wanalyzer-out-of-bounds]
3 | ++*c;
| ^~~~
‘a’: events 1-2
|
|2 | int *b = __builtin_malloc(0), *c = b - 1;
| |^~~
| ||
| |(1) capacity: 0 bytes
|3 | ++*c;
| |
| | |
| | (2) out-of-bounds write from byte -4 till byte -1 but region
starts at byte 0
|
during IPA pass: analyzer
mutant.c:3:3: internal compiler error: Segmentation fault
3 | ++*c;
| ^~~~
0x1043a4f crash_signal
../../gcc/gcc/toplev.cc:319
0x216f0e6
ana::written_svalue_spatial_item::get_label_string(text_art::style_manager&)
const
../../gcc/gcc/analyzer/access-diagram.cc:1632
0x216f290 ana::written_svalue_spatial_item::make_table(ana::bit_to_table_map
const&, text_art::style_manager&) const
../../gcc/gcc/analyzer/access-diagram.cc:1620
0x2170348 ana::access_diagram_impl::access_diagram_impl(ana::access_operation
const&, diagnostic_event_id_t, text_art::style_manager&, text_art::theme
const&, ana::logger*)
../../gcc/gcc/analyzer/access-diagram.cc:2131
0x2165157 std::enable_if::value,
std::unique_ptr > >::type
make_unique(ana::access_operation const&, diagnostic_event_id_t&,
text_art::style_manager&, text_art::theme const&, ana::logger*&)
../../gcc/gcc/make-unique.h:41
0x2165157 ana::access_diagram::access_diagram(ana::access_operation const&,
diagnostic_event_id_t, text_art::style_manager&, text_art::theme const&,
ana::logger*)
../../gcc/gcc/analyzer/access-diagram.cc:2679
0x2176727 ana::out_of_bounds::make_access_diagram(ana::access_operation const&,
text_art::style_manager&, text_art::theme const&, ana::logger*) const
../../gcc/gcc/analyzer/bounds-checking.cc:208
0x2176727 ana::out_of_bounds::maybe_show_diagram(ana::logger*) const
../../gcc/gcc/analyzer/bounds-checking.cc:187
0x2176c51
ana::concrete_buffer_underwrite::emit(ana::diagnostic_emission_context&)
../../gcc/gcc/analyzer/bounds-checking.cc:694
0x219c5c1 ana::diagnostic_manager::emit_saved_diagnostic(ana::exploded_graph
const&, ana::saved_diagnostic&)
../../gcc/gcc/analyzer/diagnostic-manager.cc:1617
0x21a02ed ana::dedupe_winners::emit_best(ana::diagnostic_manager*,
ana::exploded_graph const&)
../../gcc/gcc/analyzer/diagnostic-manager.cc:1472
0x219cb35 ana::diagnostic_manager::emit_saved_diagnostics(ana::exploded_graph
const&)
../../gcc/gcc/analyzer/diagnostic-manager.cc:1524
0x1453c7b ana::impl_run_checkers(ana::logger*)
../../gcc/gcc/analyzer/engine.cc:6227
0x1454bb6 ana::run_checkers()
../../gcc/gcc/analyzer/engine.cc:6308
0x1443a98 execute
../../gcc/gcc/analyzer/analyzer-pass.cc:87
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
[Bug middle-end/112976] expand_gimple_stmt_1 vs gimple_assign_nontemporal_move_p vs SSA_NAME on lhs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112976 Andrew Pinski changed: What|Removed |Added Status|ASSIGNED|RESOLVED Target Milestone|--- |15.0 Resolution|--- |FIXED --- Comment #10 from Andrew Pinski --- Fixed.
[Bug middle-end/112976] expand_gimple_stmt_1 vs gimple_assign_nontemporal_move_p vs SSA_NAME on lhs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112976 --- Comment #8 from GCC Commits --- The trunk branch has been updated by Andrew Pinski : https://gcc.gnu.org/g:e3a7f359c18bf347f6ac8fcda05e9839fac5bd62 commit r15-72-ge3a7f359c18bf347f6ac8fcda05e9839fac5bd62 Author: Andrew Pinski Date: Wed Apr 17 14:12:17 2024 -0700 Add verification of gimple_assign_nontemporal_move_p [PR112976] Currently the middle-end only knows how to support temporal stores (the undocumented storent optab) so let's verify that the only time we set nontemporal_move on an assign is if the the lhs is not a gimple reg. Bootstrapped and tested on x86_64-linux-gnu no regressions. gcc/ChangeLog: PR middle-end/112976 * tree-cfg.cc (verify_gimple_assign): Verify that nontmporal moves are stores. * gimple.h (struct gimple): Note that only nontemporal stores are supported. Signed-off-by: Andrew Pinski
[Bug middle-end/112976] expand_gimple_stmt_1 vs gimple_assign_nontemporal_move_p vs SSA_NAME on lhs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112976 --- Comment #9 from GCC Commits --- The trunk branch has been updated by Andrew Pinski : https://gcc.gnu.org/g:8614d60233a64afd7e28ae7af2ab74c4a5b06010 commit r15-73-g8614d60233a64afd7e28ae7af2ab74c4a5b06010 Author: Andrew Pinski Date: Wed Apr 17 14:30:06 2024 -0700 Remove support for nontemporal stores with ssa_names on lhs [PR112976] When cfgexpand was changed to support expanding from tuple gimple (r0-95521-g28ed065ef9f345), the code was added to support doing nontemporal stores with LHS of a SSA_NAME but that will never be a nontemporal store. This patch removes that and asserts that expanding with a LHS of a SSA_NAME is not a nontemporal store. Bootstrapped and tested on x86_64-linux-gnu. gcc/ChangeLog: PR middle-end/112976 * cfgexpand.cc (expand_gimple_stmt_1): Remove support for expanding nontemporal "moves" with ssa names on the LHS. Signed-off-by: Andrew Pinski
[Bug c++/114898] Converting {} to a tag type should be ill-formed SFINAE-friendly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114898 Jonathan Wakely changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2024-04-30 See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=113300 Status|UNCONFIRMED |NEW --- Comment #2 from Jonathan Wakely --- Might be related to Bug 113300 and/or Bug 102257
[Bug target/98784] [11/12/13/14/15 Regression] problematic build of uClibc with -fPIC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98784 Dmitriy Chestnykh changed: What|Removed |Added CC||dm.chestnykh at gmail dot com --- Comment #19 from Dmitriy Chestnykh --- The problem seems to be in sparc implementation of signals-related code in uClibc-ng. Testing the patch now. CC: Waldemar Brodkorb Best regards, Dmitriy
[Bug c++/114898] Converting {} to a tag type should be ill-formed SFINAE-friendly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114898
--- Comment #1 from Jonathan Wakely ---
Standalone testcase:
struct nullopt_t {
enum class Hidden { Token };
explicit constexpr nullopt_t(Hidden) noexcept { }
};
struct in_place_t {
explicit constexpr in_place_t() = default;
};
template
struct optional
{
template
optional(U&&) { }
optional(in_place_t);
optional(nullopt_t);
};
struct Widget {
int i[1];
};
optional r1( {{}} );
optional r2{ {} };
[Bug modula2/114836] error messages should be translatable and follow locale convention
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114836 Gaius Mulley changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2024-04-30 --- Comment #2 from Gaius Mulley --- Confirmed.
[Bug c++/105229] [11/12/13/14/15 Regression] ICE in lookup_template_class_1, at cp/pt.cc:10111
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105229 Simon Martin changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #5 from Simon Martin --- It does not seem to ICE anymore with trunk. Will double check and if so, submit a new testcase.
[Bug target/114734] [11/12/13/14 regression] RISC-V rv64gcv_zvl256b miscompile with -flto -O3 -mrvv-vector-bits=zvl since r8-6047-g65dd1346027bb5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114734 --- Comment #14 from Patrick O'Neill --- I'll send a patch with the testcase in a few hours. Testing it now.
[Bug c++/114898] New: Converting {} to a tag type should be ill-formed SFINAE-friendly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114898
Bug ID: 114898
Summary: Converting {} to a tag type should be ill-formed
SFINAE-friendly
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: arthur.j.odwyer at gmail dot com
Target Milestone: ---
See LWG 2510, "Tag types should not be DefaultConstructible":
https://cplusplus.github.io/LWG/issue2510
WG21 seems convinced that there's also a core-language issue here:
https://cplusplus.github.io/CWG/issues/1518.html
In the notes for LWG2510, I see:
> JW [i.e. jwakely] explains that it's important that tag types cannot be
> constructed from "{}" (e.g. the allocator tag in the tuple constructors).
However, it looks like GCC+libstdc++ violates LWG2510 by allowing tag types to
be constructible from `{}` (or at least to fail in a SFINAE-unfriendly way).
// https://godbolt.org/z/cMzar8Ehf
struct Widget {
int i[1];
};
std::optional r1( {{}} );
// Bug 1: GCC complains about nullopt_t's explicit ctor
std::optional r2{ {} };
// Bug 2: GCC complains about in_place_t's explicit ctor
Now, according to Clang+libstdc++, Clang+libc++, and MSVC+STL, both examples
should be well-formed, and should mean:
- r1 is direct-initialized from {{}} i.e. a Widget with one element {} i.e. a
value-initialized array of int[1].
- r2 is direct-list-initialized from {} i.e. a value-initialized Widget.
In the April 2024 WG21 mailing, Brian Bi brings a paper P3112 "Specify
Constructor of std::nullopt_t" motivated by this bad behavior of GCC's,
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p3112r0.html
but really I think it should just be a bug report, since GCC is the one
compiler currently misbehaving, and jwakely was already quoted above as wanting
`{}` _not_ to construct a tag type.
I don't much care whether this is treated as a GCC compiler bug or a libstdc++
library bug, but at first glance it _looks_ like a compiler bug (since
libstdc++ works fine with Clang). If it _is_ treated as a libstdc++ bug, you
might take this opportunity to audit all of the tag types in the entire library
and just make sure they're all implemented using the same consistent technique,
whatever it is.
[Bug c++/108059] internal compiler error: in tsubst_copy, at cp/pt.c:16425
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108059 --- Comment #6 from Patrick Palka --- FWIW a workaround for most valid code is to replace e.g. ignore_index_t, where v is the problematic NTTP argument, with ignore_index_t.
[Bug target/113832] [14/15 Regression] 6% exec time regression of 464.h264ref on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113832 --- Comment #5 from Roger Sayle --- I'm trying to confirm that there are actually widening multiplications in 464.h264ref (on aarch64), but if anyone's already done an analysis of what might be causing these performance swings, please do post (a pointer here).
[Bug c++/108059] internal compiler error: in tsubst_copy, at cp/pt.c:16425
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108059 Andrew Paprocki changed: What|Removed |Added CC||andrew at ishiboo dot com --- Comment #5 from Andrew Paprocki --- Reconfirmed with all the following versions: * g++-11 11.3.0 internal compiler error: in tsubst_copy, at cp/pt.c:16767 * g++-12 12.2.0 internal compiler error: in tsubst_copy, at cp/pt.cc:16949 * g++-13 13.1.0 internal compiler error: in tsubst_copy, at cp/pt.cc:17275
[Bug ada/81087] array index out of range in gnatlink, making test always false
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81087 --- Comment #5 from Nicolas Boulenguez --- Ping? If the patch is eventually applied, the similar conditions that have been added during the last seven years should probably also call Starts_With.
[Bug ipa/106935] [11/12/13/14/15 Regression] ICE in redirect_call_stmt_to_callee, at cgraph.cc:1505 since r10-5098-g9b14fc3326e08797
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106935 --- Comment #3 from Martin Jambor --- This ICE no longer happens with GCC 13, in fact after r13-4240-gfeeb0d68f1c708 (Martin Jambor: ipa-cp: Do not consider useless aggregate constants). From the patch description, it does not look to be a fix of the underlying issue.
[Bug target/113832] [14/15 Regression] 6% exec time regression of 464.h264ref on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113832 --- Comment #4 from Filip Kastl --- There was another speedup followed by a slowdown. speedup somewhere between g:4b8e7b57d952a103 g:839bc42772ba7af6 slowdown g:7924e352523b3715 g:f3fdcf4a37a7be07 --- Btw, here is a plot also showing GCC 13 https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.7=868.220.0&plot.8=586.220.0&;
[Bug ipa/102310] [11/12 Regression] ICE in visit_ref_for_mod_analysis with OpenACC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102310 Martin Jambor changed: What|Removed |Added Known to work||13.1.0 Summary|[11/12/13/14/15 Regression] |[11/12 Regression] ICE in |ICE in |visit_ref_for_mod_analysis |visit_ref_for_mod_analysis |with OpenACC |with OpenACC| --- Comment #10 from Martin Jambor --- This has been fixed in GCC 13 by r13-2665-g23baa717c991d7 (Julian Brown: OpenMP/OpenACC struct sibling list gimplification extension and rework).
[Bug analyzer/114897] ICE in get_or_create_widening_svalue, at analyzer/region-model-manager.cc:1336 since r13-3077-gbfca9505f6f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114897
--- Comment #1 from Anonymous ---
There is another case that triggers the ICE in replay_call_summary_cluster, at
analyzer/store.cc:3374
Also bisected to r13-3077-gbfca9505f6f
Compiler Explorer: https://godbolt.org/z/Wh5MGf739
Program:
$ cat mutant.c
__attribute__((__vector_size__(sizeof(float float a;
int b;
void c();
void d() {
for (; b;)
if (a[b])
c();
}
void e() {
d();
d();
}
***
Command Lines:
$ gcc -fsanitize=undefined -fanalyzer -fanalyzer-call-summaries -c mutant.c
during IPA pass: analyzer
mutant.c: In function ‘e’:
mutant.c:10:3: internal compiler error: in replay_call_summary_cluster, at
analyzer/store.cc:3374
10 | d();
| ^~~
0x8921e5 ana::store::replay_call_summary_cluster(ana::call_summary_replay&,
ana::store const&, ana::region const*)
../../gcc/gcc/analyzer/store.cc:3374
0x14e1864 ana::store::replay_call_summary(ana::call_summary_replay&, ana::store
const&)
../../gcc/gcc/analyzer/store.cc:3318
0x149174b ana::region_model::replay_call_summary(ana::call_summary_replay&,
ana::region_model const&)
../../gcc/gcc/analyzer/region-model.cc:5635
0x14723eb ana::program_state::replay_call_summary(ana::call_summary_replay&,
ana::program_state const&)
../../gcc/gcc/analyzer/program-state.cc:1635
0x1458743 ana::call_summary_edge_info::update_state(ana::program_state*,
ana::exploded_edge const*, ana::region_model_context*) const
../../gcc/gcc/analyzer/engine.cc:1633
0x1450d9a ana::exploded_graph::process_node(ana::exploded_node*)
../../gcc/gcc/analyzer/engine.cc:4241
0x145166a ana::exploded_graph::process_worklist()
../../gcc/gcc/analyzer/engine.cc:3516
0x1453c4b ana::impl_run_checkers(ana::logger*)
../../gcc/gcc/analyzer/engine.cc:6210
0x1454bb6 ana::run_checkers()
../../gcc/gcc/analyzer/engine.cc:6308
0x1443a98 execute
../../gcc/gcc/analyzer/analyzer-pass.cc:87
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
[Bug modula2/114886] gm2 testsuite arbitrarily reduces timeouts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114886 Rainer Orth changed: What|Removed |Added Assignee|gaius at gcc dot gnu.org |ro at gcc dot gnu.org --- Comment #4 from Rainer Orth --- Fixed for GCC 15.
[Bug modula2/114886] gm2 testsuite arbitrarily reduces timeouts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114886 --- Comment #3 from GCC Commits --- The master branch has been updated by Rainer Orth : https://gcc.gnu.org/g:aff63ac11099d100b6891f3bcc3dc6cbc4fad654 commit r15-69-gaff63ac11099d100b6891f3bcc3dc6cbc4fad654 Author: Rainer Orth Date: Tue Apr 30 13:49:28 2024 +0200 testsuite: gm2: Remove timeout overrides [PR114886] A large number of gm2 tests are timing out even on current Solaris/SPARC systems. As detailed in the PR, the problem is that the gm2 testsuite artificially lowers many timeouts way below the DejaGnu default of 300 seconds, often as short as 10 seconds. The problem lies both in the values (they may be appropriate for some targets, but too low for others, especially under high load) and the fact that it uses absolute values, overriding e.g. settings from a build-wide site.exp. Therefore this patch removes all those overrides, restoring the defaults. Tested on sparc-sun-solaris2.11 (where all the previous timeouts are gone) and i386-pc-solaris2.11. 2024-04-29 Rainer Orth gcc/testsuite: PR modula2/114886 * lib/gm2.exp: Don't load timeout-dg.exp. Don't set gm2_previous_timeout. Don't call dg-timeout. (gm2_push_timeout, gm2_pop_timeout): Remove. (gm2_init): Don't call dg-timeout. * lib/gm2-torture.exp: Don't load timeout-dg.exp. Don't set gm2_previous_timeout. Don't call dg-timeout. (gm2_push_timeout, gm2_pop_timeout): Remove. * gm2/coroutines/pim/run/pass/coroutines-pim-run-pass.exp: Don't load timeout-dg.exp. Don't call gm2_push_timeout, gm2_pop_timeout. * gm2/examples/map/pass/examples-map-pass.exp: Don't call gm2_push_timeout, gm2_pop_timeout. * gm2/iso/run/pass/iso-run-pass.exp: Don't load timeout-dg.exp. Don't call gm2_push_timeout, gm2_pop_timeout. * gm2/pimlib/base/run/pass/pimlib-base-run-pass.exp: Don't load timeout-dg.exp. Don't call gm2_push_timeout, gm2_pop_timeout. * gm2/projects/iso/run/pass/halma/projects-iso-run-pass-halma.exp: Don't call gm2_push_timeout, gm2_pop_timeout. * gm2/switches/whole-program/pass/run/switches-whole-program-pass-run.exp: Don't load timeout-dg.exp. Don't call gm2_push_timeout, gm2_pop_timeout.
[Bug analyzer/114897] New: ICE in get_or_create_widening_svalue, at analyzer/region-model-manager.cc:1336 since r13-3077-gbfca9505f6f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114897
Bug ID: 114897
Summary: ICE in get_or_create_widening_svalue, at
analyzer/region-model-manager.cc:1336 since
r13-3077-gbfca9505f6f
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: iamanonymous.cs at gmail dot com
Target Milestone: ---
Compiler Explorer: https://godbolt.org/z/WMK1K7cMs
Bisected to r13-3077-gbfca9505f6f
***
OS and Platform:
$ uname -a:
Linux ubuntu 4.15.0-213-generic #224-Ubuntu SMP Mon Jun 19 13:30:12 UTC 2023
x86_64 x86_64 x86_64 GNU/Linux
***
gcc version:
$ gcc -v
Using built-in specs.
COLLECT_GCC=/root/gcc_set/202404101100/bin/gcc
COLLECT_LTO_WRAPPER=/root/gcc_set/202404101100/libexec/gcc/x86_64-pc-linux-gnu/14.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --prefix=/root/gcc_set/202404101100
--with-gmp=/root/build_essential --with-mpfr=/root/build_essential
--with-mpc=/root/build_essential --enable-languages=c,c++ --disable-multilib
--with-sanitizer=address,undefined,thread,leak
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.0.1 20240410 (experimental) (GCC)
git version: 0774240b4df9a9bc48ce33a9625788e402498f5a
***
Program:
$ cat mutant.c
int a, b;
char *c;
char *e(char *f) {
while (a) {
unsigned d = *f++;
}
return b ? f : 0;
}
void g() {
c = e(c);
e(c);
}
***
Command Lines:
$ gcc -fanalyzer -fanalyzer-call-summaries -c mutant.c
during IPA pass: analyzer
mutant.c: In function ‘g’:
mutant.c:11:3: internal compiler error: in get_or_create_widening_svalue, at
analyzer/region-model-manager.cc:1336
11 | e(c);
| ^~~~
0x88f731 ana::region_model_manager::get_or_create_widening_svalue(tree_node*,
ana::function_point const&, ana::svalue const*, ana::svalue const*)
../../gcc/gcc/analyzer/region-model-manager.cc:1336
0x217b2aa ana::call_summary_replay::convert_svalue_from_summary(ana::svalue
const*)
../../gcc/gcc/analyzer/call-summary.cc:236
0x219584b ana::replay_fact_visitor::on_fact(ana::svalue const*, tree_code,
ana::svalue const*)
../../gcc/gcc/analyzer/constraint-manager.cc:3273
0x2189728 ana::constraint_manager::for_each_fact(ana::fact_visitor*) const
../../gcc/gcc/analyzer/constraint-manager.cc:3240
0x2189958
ana::constraint_manager::replay_call_summary(ana::call_summary_replay&,
ana::constraint_manager const&)
../../gcc/gcc/analyzer/constraint-manager.cc:3307
0x1491770 ana::region_model::replay_call_summary(ana::call_summary_replay&,
ana::region_model const&)
../../gcc/gcc/analyzer/region-model.cc:5640
0x14723eb ana::program_state::replay_call_summary(ana::call_summary_replay&,
ana::program_state const&)
../../gcc/gcc/analyzer/program-state.cc:1635
0x1458743 ana::call_summary_edge_info::update_state(ana::program_state*,
ana::exploded_edge const*, ana::region_model_context*) const
../../gcc/gcc/analyzer/engine.cc:1633
0x1450d9a ana::exploded_graph::process_node(ana::exploded_node*)
../../gcc/gcc/analyzer/engine.cc:4241
0x145166a ana::exploded_graph::process_worklist()
../../gcc/gcc/analyzer/engine.cc:3516
0x1453c4b ana::impl_run_checkers(ana::logger*)
../../gcc/gcc/analyzer/engine.cc:6210
0x1454bb6 ana::run_checkers()
../../gcc/gcc/analyzer/engine.cc:6308
0x1443a98 execute
../../gcc/gcc/analyzer/analyzer-pass.cc:87
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
[Bug middle-end/13421] IA32 bigmem pointer subtraction and –ftrapv option causes unjustified program abort
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=13421
--- Comment #17 from GCC Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:667c19de86b33648f5f4599f589a5e02adbb35cb
commit r15-67-g667c19de86b33648f5f4599f589a5e02adbb35cb
Author: Richard Biener
Date: Tue Apr 16 14:05:35 2024 +0200
middle-end/13421 - -ftrapv vs. POINTER_DIFF_EXPR
Currently we expand POINTER_DIFF_EXPR using subv_optab when -ftrapv
(but -fsanitize=undefined does nothing). That's not consistent
with the behavior of POINTER_PLUS_EXPR which never uses addv_optab
with -ftrapv. Both are because of the way we select whether to use
the trapping or the non-trapping optab - we look at the result type
of the expression and check
trapv = INTEGRAL_TYPE_P (type) && TYPE_OVERFLOW_TRAPS (type);
the bugreport correctly complains that -ftrapv affects pointer
subtraction (there's no -ftrapv-pointer). Now that we have
POINTER_DIFF_EXPR we can honor that appropriately.
The patch moves both POINTER_DIFF_EXPR and POINTER_PLUS_EXPR
handling so they will never consider trapping (or saturating)
optabs.
PR middle-end/13421
* optabs-tree.cc (optab_for_tree_code): Do not consider
{add,sub}v or {us,ss}{add,sub} optabs for POINTER_DIFF_EXPR
or POINTER_PLUS_EXPR.
[Bug analyzer/114896] analyzer: false-positive with VLA (analyzer-out-of-bounds, CWE-121)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114896 --- Comment #1 from Christian Holme --- Created attachment 58077 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58077&action=edit Unprocessed .c file As the .i file is very because of the system headers, here is the plain .c file.
[Bug analyzer/114896] New: analyzer: false-positive with VLA (analyzer-out-of-bounds, CWE-121)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114896 Bug ID: 114896 Summary: analyzer: false-positive with VLA (analyzer-out-of-bounds, CWE-121) Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: analyzer Assignee: dmalcolm at gcc dot gnu.org Reporter: hcmh at mailbox dot org Target Milestone: --- Created attachment 58076 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58076&action=edit Preprocessed .i triggering the problem Hey, in one of our projects we encountered the following analyzer problem, which I believe to be a false-positive. The code essentially creates a VLA with a size n constrained by assert()s and reads from it. The analyzer claims that this read is out of bounds, with the maximum possible value of the type of n as offset. I have tried to make the example as short as possible while avoiding all warnings with -Wall -Wextra. GCC version: 14.0.1 20240404 (experimental) (compiled from commit 1baec8deb014b8a7da58879a407a4c00cdeb5a09 ) System type: Debian 12 running on x86_64 GCC configuration options: --prefix=$HOME/.local/ --program-suffix=-git --enable-default-pie --disable-multilib --enable-lto --enable-plugin --enable-shared Command line: gcc-git -v -save-temps -fanalyzer -Werror -o false_pos false_pos.c Compiler output: === Using built-in specs. COLLECT_GCC=gcc-git COLLECT_LTO_WRAPPER=/home/cholme/.local/libexec/gcc/x86_64-pc-linux-gnu/14.0.1/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /home/cholme/git/gcc/configure --prefix=/home/cholme/.local/ --program-suffix=-git --enable-default-pie --disable-multilib --enable-lto --enable-plugin --enable-shared Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 14.0.1 20240404 (experimental) (GCC) COLLECT_GCC_OPTIONS='-v' '-save-temps' '-fanalyzer' '-Werror' '-o' 'false_pos' '-mtune=generic' '-march=x86-64' /home/cholme/.local/libexec/gcc/x86_64-pc-linux-gnu/14.0.1/cc1 -E -quiet -v -imultiarch x86_64-linux-gnu false_pos.c -mtune=generic -march=x86-64 -Werror -fanalyzer -fpch-preprocess -o false_pos.i ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu" ignoring nonexistent directory "/home/cholme/.local/lib/gcc/x86_64-pc-linux-gnu/14.0.1/include-fixed/x86_64-linux-gnu" ignoring nonexistent directory "/home/cholme/.local/lib/gcc/x86_64-pc-linux-gnu/14.0.1/../../../../x86_64-pc-linux-gnu/include" #include "..." search starts here: #include <...> search starts here: /home/cholme/.local/lib/gcc/x86_64-pc-linux-gnu/14.0.1/include /usr/local/include /home/cholme/.local/include /home/cholme/.local/lib/gcc/x86_64-pc-linux-gnu/14.0.1/include-fixed /usr/include/x86_64-linux-gnu /usr/include End of search list. COLLECT_GCC_OPTIONS='-v' '-save-temps' '-fanalyzer' '-Werror' '-o' 'false_pos' '-mtune=generic' '-march=x86-64' /home/cholme/.local/libexec/gcc/x86_64-pc-linux-gnu/14.0.1/cc1 -fpreprocessed false_pos.i -quiet -dumpbase false_pos.c -dumpbase-ext .c -mtune=generic -march=x86-64 -Werror -version -fanalyzer -o false_pos.s GNU C17 (GCC) version 14.0.1 20240404 (experimental) (x86_64-pc-linux-gnu) compiled by GNU C version 14.0.1 20240404 (experimental), GMP version 6.2.1, MPFR version 4.1.0, MPC version 1.2.1, isl version isl-0.24-GMP GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Compiler executable checksum: d2ba7c5aec15d00fa77a3643096b9f91 false_pos.c: In function ‘main’: false_pos.c:39:35: error: stack-based buffer over-read [CWE-121] [-Werror=analyzer-out-of-bounds] 39 | return entries[hdr.nscans - 1].id; |~~~^~~ ‘main’: event 1 | |false_pos.c:20:36: | 20 | assert( -1 != fd); | |^ | || | |(1) following ‘true’ branch (when ‘fd != -1’)... | ‘main’: event 2 | |false_pos.c:24:19: | 24 | const ssize_t hdrsz = sizeof hdr; | | ^ | | | | | (2) ...to here | ‘main’: event 3 | |false_pos.c:26:36: | 26 | assert(hdrsz == sr); | |^ | || | |(3) following ‘true’ branch (when ‘hdrsz == sr’)... | ‘main’: event 4 | |false_pos.c:28:12: | 28 | assert((0 < hdr.nscans) && (hdr.nscans < 2)); | | ~~~^~~ | || | |(4) ...to here | ‘main’: event 5 | |false_pos.c:28:36: | 28 | assert((0 < hdr.nscans) && (hdr.nscans < 2)); | |^ | || | |
gcc-bugs@gcc.gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114877 --- Comment #3 from Lénárd Szolnoki --- (In reply to Richard Biener from comment #2) > The standard says the results are unspecified, it doesn't say *p is written > to, > so I'm not sure there's a bug here. C17 (N2176) says in the library section: "The frexp functions break a floating-point number into a normalized fraction and an integral power of 2. They store the integer in the int object pointed to by exp." "If value is not a floating-point number or if the integral power of 2 is outside the range of int, the results are unspecified. Otherwise, the frexp functions return the value x, such that x has a magnitude in the interval [1/2, 1) or zero, and value equals x × 2*exp . If value is zero, both parts of the result are zero." This might be a little bit ambiguous, but my reading is that an int value is always stored, but sometimes the "results are unspecified", where I assume "results" refer to the fractional part and the integer exponent. An unspecified result then is stored to the object pointed to by exp. However further down in Annex F (relevant for targets with IEC 60559, such as x86_64): "frexp(±∞, exp) returns ±∞, and stores an unspecified value in the object pointed to by exp." "frexp(NaN, exp) stores an unspecified value in the object pointed to by exp (and returns a NaN)." This is a lot less ambiguous.
gcc-bugs@gcc.gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114877 Richard Biener changed: What|Removed |Added CC||jsm28 at gcc dot gnu.org --- Comment #2 from Richard Biener --- The standard says the results are unspecified, it doesn't say *p is written to, so I'm not sure there's a bug here. Indeed we do case rvc_nan: case rvc_inf: /* For +-NaN or +-Inf, *exp is unspecified, return arg0. */ return omit_one_operand_loc (loc, rettype, arg0, arg1);
[Bug tree-optimization/114876] [11/12/13/14 Regression] -fprintf-return-value mishandles %lc with a '\0' argument.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114876 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug fortran/114874] [14/15 Regression] ICE with select type, type is (character(*)), and substring
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114874 Richard Biener changed: What|Removed |Added Target Milestone|--- |14.0
[Bug libstdc++/114866] [14/15 Regression] & out_ptr in freestanding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114866 Richard Biener changed: What|Removed |Added Target Milestone|--- |14.0
[Bug tree-optimization/114876] [11/12/13/14 Regression] -fprintf-return-value mishandles %lc with a '\0' argument.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114876 --- Comment #6 from Jakub Jelinek --- Fixed for 15+ so far.
[Bug tree-optimization/114876] [11/12/13/14 Regression] -fprintf-return-value mishandles %lc with a '\0' argument.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114876
--- Comment #5 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:6c6b70f07208ca14ba783933988c04c6fc2fff42
commit r15-66-g6c6b70f07208ca14ba783933988c04c6fc2fff42
Author: Jakub Jelinek
Date: Tue Apr 30 11:22:32 2024 +0200
gimple-ssa-sprintf: Use [0, 1] range for %lc with (wint_t) 0 argument
[PR114876]
Seems when Martin S. implemented this, he coded there strict reading
of the standard, which said that %lc with (wint_t) 0 argument is handled
as wchar_t[2] temp = { arg, 0 }; %ls with temp arg and so shouldn't print
any values. But, most of the libc implementations actually handled that
case like %c with '\0' argument, adding a single NUL character, the only
known exception is musl.
Recently, C23 changed this in response to GB-141 and POSIX in
https://austingroupbugs.net/view.php?id=1647
so that it should have the same behavior as %c with '\0'.
Because there is implementation divergence, the following patch uses
a range rather than hardcoding it to all 1s (i.e. the %c behavior),
though the likely case is still 1 (forward looking plus most of
implementations).
The res.knownrange = true; assignment removed is redundant due to
the same assignment done unconditionally before the if statement,
rest is formatting fixes.
I don't think the min >= 0 && min < 128 case is right either, I'd think
it should be min >= 0 && max < 128, otherwise it is just some possible
inputs are (maybe) ASCII and there can be others, but this code is a total
mess anyway, with the min, max, likely (somewhere in [min, max]?) and then
unlikely possibly larger than max, dunno, perhaps for at least some chars
in the ASCII range the likely case could be for the ascii case; so perhaps
just the one_2_one_ascii shouldn't set max to 1 and mayfail should be true
for max >= 128. Anyway, didn't feel I should touch that right now.
2024-04-30 Jakub Jelinek
PR tree-optimization/114876
* gimple-ssa-sprintf.cc (format_character): For min == 0 && max ==
0,
set max, likely and unlikely members to 1 rather than 0. Remove
useless res.knownrange = true;. Formatting fixes.
* gcc.dg/pr114876.c: New test.
* gcc.dg/tree-ssa/builtin-sprintf-warn-1.c: Adjust expected
diagnostics.
[Bug target/113095] [13 Regression] RISC-V: movcc no longer used for coremark crc functions with -mtune=sifive-7-series
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113095 Kito Cheng changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #8 from Kito Cheng --- Fixed on both trunk and GCC 13
[Bug middle-end/114855] ICE: Segfault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114855 Richard Biener changed: What|Removed |Added CC||aldyh at gcc dot gnu.org --- Comment #6 from Richard Biener --- I've backported the fix for the recursion issue, only the memory/compile-time hog issue should prevail on the branch. comment#14 now also applies to the GCC 13 branch.
[Bug target/113095] [13 Regression] RISC-V: movcc no longer used for coremark crc functions with -mtune=sifive-7-series
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113095 --- Comment #7 from GCC Commits --- The releases/gcc-13 branch has been updated by Kito Cheng : https://gcc.gnu.org/g:6335baaf31c0f1f0952d1a3f507b0e5655b1136f commit r13-8663-g6335baaf31c0f1f0952d1a3f507b0e5655b1136f Author: Monk Chiang Date: Wed Jan 24 10:19:28 2024 -0700 [PATCH v3] RISC-V: Add split pattern to generate SFB instructions. [PR113095] Since the match.pd transforms (zero_one == 0) ? y : z y, into ((typeof(y))zero_one * z) y. Add splitters to recongize this expression to generate SFB instructions. gcc/ChangeLog: PR target/113095 * config/riscv/riscv.md: New splitters to rewrite single bit sign extension as the condition to SFB instructions. gcc/testsuite/ChangeLog: * gcc.target/riscv/sfb.c: New test. * gcc.target/riscv/pr113095.c: New test. (cherry picked from commit fb54b9772816968032518d4008be5090e0d95109)
[Bug libstdc++/80977] uniform_int_distribution downscaling throws away perfectly good entropy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80977 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2024-04-30
[Bug libstdc++/114863] std::format applying grouping to nan's and inf's
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114863 --- Comment #4 from GCC Commits --- The releases/gcc-14 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:7a00c459cbb913ac165a39d344a48fc27800bb0a commit r14-10154-g7a00c459cbb913ac165a39d344a48fc27800bb0a Author: Jonathan Wakely Date: Fri Apr 26 11:42:26 2024 +0100 libstdc++: Do not apply localized formatting to NaN and inf [PR114863] We don't want to add grouping to strings like "-inf", and there is no radix character to replace either. libstdc++-v3/ChangeLog: PR libstdc++/114863 * include/std/format (__formatter_fp::format): Only use _M_localized for finite values. * testsuite/std/format/functions/format.cc: Check localized formatting of NaN and initiny. (cherry picked from commit 7501c0a397fcf609a1ff5f083746b6330b89ee11)
[Bug target/111600] [14/15 Regression] RISC-V bootstrap time regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111600 --- Comment #33 from GCC Commits --- The releases/gcc-13 branch has been updated by Richard Biener : https://gcc.gnu.org/g:440a612dbadfae5887ec7c9b3ab2fca88b065366 commit r13-8662-g440a612dbadfae5887ec7c9b3ab2fca88b065366 Author: Richard Biener Date: Thu Sep 28 11:51:30 2023 +0200 target/111600 - avoid deep recursion in access diagnostics pass_waccess::check_dangling_stores uses recursion to traverse the CFG. The following changes this to use a heap allocated worklist to avoid blowing the stack. Instead of using a better iteration order it tries hard to preserve the current iteration order to avoid new false positives to pop up since the set of stores we keep track isn't properly modeling flow, so what is diagnosed and what not is quite random. We are also lacking the ideal RPO compute on the inverted graph that would just ignore reverse unreachable code (as the current iteration scheme does). PR target/111600 * gimple-ssa-warn-access.cc (pass_waccess::check_dangling_stores): Use a heap allocated worklist for CFG traversal instead of recursion. (cherry picked from commit f194c684a28a5d449bd034a2c604d04ba465e4fe)
[Bug fortran/114859] [14/15 Regression] Seeing new segmentation fault in same_type_as since r14-9752
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114859 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #18 from Jakub Jelinek --- And now cherry-picked to 14.1 as well: commit r14-10153-ge976bef1579086e6e83c6a47f6c5f8f996208f99 Author: Paul Thomas Date: Mon Apr 29 11:52:11 2024 +0100 Fortran: Fix regression caused by r14-9752 [PR114959] 2024-04-29 Paul Thomas gcc/fortran PR fortran/114959 * trans-expr.cc (gfc_trans_class_init_assign): Return NULL_TREE if the default initializer has all NULL fields. Guard this by a requirement that the code not be EXEC_INIT_ASSIGN and that the object be an INTENT_OUT dummy. * trans-stmt.cc (gfc_trans_allocate): Change the initializer code for allocate with mold to EXEC_ALLOCATE to allow an initializer with all NULL fields. gcc/testsuite/ PR fortran/114959 * gfortran.dg/pr114959.f90: New test. (cherry picked from commit bca41a8d55e830c882b0f39246afead4fcfae6f7)
[Bug tree-optimization/114883] [14/15 Regression] 521.wrf_r ICE with -O2 -march=sapphirerapids -fvect-cost-model=cheap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114883 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #13 from Jakub Jelinek --- Fixed.
[Bug tree-optimization/114883] [14/15 Regression] 521.wrf_r ICE with -O2 -march=sapphirerapids -fvect-cost-model=cheap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114883
--- Comment #12 from GCC Commits ---
The releases/gcc-14 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:a795a7b67027bc976a353b5fa927ac8c5f29347d
commit r14-10152-ga795a7b67027bc976a353b5fa927ac8c5f29347d
Author: Jakub Jelinek
Date: Tue Apr 30 10:11:47 2024 +0200
vect: Adjust vect_transform_reduction assertion [PR114883]
The assertion doesn't allow IFN_COND_MIN/IFN_COND_MAX, which are
commutative conditional binary operations like ADD/MUL/AND/IOR/XOR,
and can be handled just fine.
In particular, we emit
vminpd %zmm3, %zmm5, %zmm0{%k2}
vminpd %zmm0, %zmm3, %zmm5{%k1}
and
vmaxpd %zmm3, %zmm5, %zmm0{%k2}
vmaxpd %zmm0, %zmm3, %zmm5{%k1}
in the vectorized loops of the first and second subroutine.
2024-04-30 Jakub Jelinek
Hongtao Liu
PR tree-optimization/114883
* tree-vect-loop.cc (vect_transform_reduction): Allow IFN_COND_MIN
and
IFN_COND_MAX in the assert.
* gfortran.dg/pr114883.f90: New test.
(cherry picked from commit 04ef92a62af3a815b86a2037267cd4e747ae225c)
[Bug tree-optimization/114883] [14/15 Regression] 521.wrf_r ICE with -O2 -march=sapphirerapids -fvect-cost-model=cheap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114883
--- Comment #11 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:04ef92a62af3a815b86a2037267cd4e747ae225c
commit r15-64-g04ef92a62af3a815b86a2037267cd4e747ae225c
Author: Jakub Jelinek
Date: Tue Apr 30 10:11:47 2024 +0200
vect: Adjust vect_transform_reduction assertion [PR114883]
The assertion doesn't allow IFN_COND_MIN/IFN_COND_MAX, which are
commutative conditional binary operations like ADD/MUL/AND/IOR/XOR,
and can be handled just fine.
In particular, we emit
vminpd %zmm3, %zmm5, %zmm0{%k2}
vminpd %zmm0, %zmm3, %zmm5{%k1}
and
vmaxpd %zmm3, %zmm5, %zmm0{%k2}
vmaxpd %zmm0, %zmm3, %zmm5{%k1}
in the vectorized loops of the first and second subroutine.
2024-04-30 Jakub Jelinek
Hongtao Liu
PR tree-optimization/114883
* tree-vect-loop.cc (vect_transform_reduction): Allow IFN_COND_MIN
and
IFN_COND_MAX in the assert.
* gfortran.dg/pr114883.f90: New test.
[Bug libfortran/114895] Build failure with !HAVE_WORKING_STAT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114895 --- Comment #6 from Jakub Jelinek --- I've hacked up my libgfortran/configure, added there sleep 60s after writing conftest.c for working stat check, and then rm -f config.cache; ./config.status --recheck in the x86*/32/libgfortran directory and the above conftest.c is what I saw.
[Bug libfortran/114895] Build failure with !HAVE_WORKING_STAT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114895 --- Comment #5 from Jakub Jelinek --- Created attachment 58075 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58075&action=edit conftest.c
[Bug libfortran/114895] Build failure with !HAVE_WORKING_STAT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114895
--- Comment #4 from Jakub Jelinek ---
That is really weird.
Because the
checking for _FILE_OFFSET_BITS value needed for large files... 64
test should add
#define _FILE_OFFSET_BITS 64
line to confdefs.h and I believe the working stat testing should use that:
if test "$cross_compiling" = yes; then :
case "${target}" in
*mingw*) libgfor_cv_have_working_stat=no ;;
*) libgfor_cv_have_working_stat=yes;;
esac
else
cat confdefs.h - <<_ACEOF >conftest.$ac_ext
/* end confdefs.h. */
#include
#include
#include
#include
int main ()
{
FILE *f, *g;
struct stat st1, st2;
f = fopen ("foo", "w");
g = fopen ("bar", "w");
if (stat ("foo", &st1) != 0 || stat ("bar", &st2))
return 1;
if (st1.st_dev == st2.st_dev && st1.st_ino == st2.st_ino)
return 1;
fclose(f);
fclose(g);
return 0;
}
_ACEOF
The cat should source in all of confdefs.h so far.
[Bug c++/105320] Use of shared_ptr within a type exported from a module results in spurious compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105320 Nathaniel Shead changed: What|Removed |Added Target Milestone|--- |14.2 CC||nshead at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |nshead at gcc dot gnu.org --- Comment #5 from Nathaniel Shead --- Fixed for GCC 15 for now. Will backport later to GCC 14.2 with adjustments requested by Jason here: https://gcc.gnu.org/pipermail/gcc-patches/2024-April/650204.html
[Bug c++/114275] using std::thread within a templated function in a module fails to compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114275 Nathaniel Shead changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |nshead at gcc dot gnu.org Target Milestone|--- |14.2 --- Comment #7 from Nathaniel Shead --- Fixed for GCC 15 for now. Will backport later to GCC 14.2 with adjustments requested by Jason here: https://gcc.gnu.org/pipermail/gcc-patches/2024-April/650204.html
[Bug modula2/114886] gm2 testsuite arbitrarily reduces timeouts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114886 Rainer Orth changed: What|Removed |Added URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2024-April/6 ||50222.html Status|UNCONFIRMED |NEW Last reconfirmed||2024-04-30 Target Milestone|--- |14.2 Ever confirmed|0 |1 --- Comment #2 from Rainer Orth --- Proper patch posted.
[Bug libstdc++/114891] Unconditional use of std::is_pointer_interconvertible_base_of_v in makes the header unusable with Clang 18
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114891 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2024-04-30 --- Comment #2 from Jonathan Wakely --- It's only used for static assertions, so we can just disable those when the feature isn't supported. But it's not a big deal, Clang users can just not use for now.
[Bug c++/110338] Implement C++26 language features
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110338 Bug 110338 depends on bug 114456, which changed state. Bug 114456 Summary: [C++26] P0609R3 - Attributes for structured bindings https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114456 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
