[Bug tree-optimization/113898] [14 regression] ICE in copy_reference_ops_from_ref, at tree-ssa-sccvn.cc:1156 since r14-8929-g938a419182f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113898
Shaohua Li changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED |---
--- Comment #5 from Shaohua Li ---
Looks like the fix is not complete
Compiler explorer: https://godbolt.org/z/z3YKznMzE
% cat reduced.c
long a, b, c;
int d;
long e[2][1];
int f() {
if (c == a)
c = b;
}
void g() {
int h, i = 0;
for (; f() + d + i; i++)
e[h][i] = 4;
}
void main() {}
%
% gcc -O3 reduced.c
during GIMPLE pass: fre
reduced.c: In function 'g':
reduced.c:8:6: internal compiler error: in copy_reference_ops_from_ref, at
tree-ssa-sccvn.cc:1177
8 | void g() {
| ^
0x233ba2c internal_error(char const*, ...)
???:0
0x96c20f fancy_abort(char const*, int, char const*)
???:0
0x12991ba vn_reference_lookup(tree_node*, tree_node*, vn_lookup_kind,
vn_reference_s**, bool, tree_node**, tree_node*, bool)
???:0
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
[Bug tree-optimization/112508] [14 Regression] Size regression when using -Os starting with r14-4089-gd45ddc2c04e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112508 --- Comment #3 from Richard Biener --- Loop store-motion is a difficult thing to cost - it's a critical enabler for many of our loop optimizations, including scalar evolution analysis. Now, this might not hold true so much for the cases where we end up using an extra flag to avoid store data races and this example also shows we're doing a bad job in trying to unify flags for variables stored in the same blocks (we don't try to do this at all ...). Value-numbering has difficulties getting from zero flags to "same flags", it only manages to elide one flag (but maybe that's all we can do - I didn't exactly analyze). Conditionally set (conditionally within a loop, not so much conditionally executed subloops) vars at least less likely will help SCEV, so cost modeling (aka estimating register pressure in a simplistic way, like counting the number of IVs) of store-motion of those might be a way to combat this. Or, for example, disable conditional store-motion for -Os entirely. For targets where -Os matters likely -fallow-store-data-races would be a way to rescue. With that I get on x86_64 main1: .LFB1: .cfi_startproc movbh(%rip), %sil movld(%rip), %edx movlg(%rip), %edi movle(%rip), %ecx movlf(%rip), %eax .L2: testb %sil, %sil je .L5 movl%eax, %ecx .L6: movl%ecx, %eax cmpl$9, %ecx jg .L9 testl %edx, %edx je .L3 xorl%edi, %edi .L3: incl%ecx jmp .L6 .L9: decl%esi xorl%ecx, %ecx xorl%edx, %edx jmp .L2 .L5: movb$0, h(%rip) movl%eax, f(%rip) movl%ecx, e(%rip) movl%edi, g(%rip) movl%edx, d(%rip) ret Actionable items: a) disable flag store motion for cold loops (or stores only happening in cold parts of the loop) b) optimize flag variable allocation (try to use the same flag for multiple vars) c) some kind of register pressure estimation, possibly only for non-innermost loops
[Bug fortran/113956] New: ice in gfc_trans_pointer_assignment, at fortran/trans-expr.cc:10524
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113956 Bug ID: 113956 Summary: ice in gfc_trans_pointer_assignment, at fortran/trans-expr.cc:10524 Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- Created attachment 57435 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57435&action=edit F90 source code >From the flang test suite at https://github.com/llvm/llvm-project/tree/main/flang/test, the file ./Lower/pointer-assignments.f90 does this: test $ ~/gcc/results/bin/gfortran -c -w ./Lower/dummy-procedure-character.f90 ./Lower/dummy-procedure-character.f90:183:4: 183 | function bar10(n) |1 internal compiler error: in gfc_get_symbol_decl, at fortran/trans-decl.cc:1629 0x861f00 gfc_get_symbol_decl(gfc_symbol*) /home/dcb38/gcc/working/gcc/../../trunk.20210101/gcc/fortran/trans-decl.cc:1629 0x8911b5 gfc_conv_variable(gfc_se*, gfc_expr*) /home/dcb38/gcc/working/gcc/../../trunk.20210101/gcc/fortran/trans-expr.cc:3049
[Bug tree-optimization/112508] [14 Regression] Size regression when using -Os starting with r14-4089-gd45ddc2c04e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112508
--- Comment #4 from Richard Biener ---
We are already doing
/* Verify whether the candidate is hot for LOOP. Only do store motion if the
candidate's profile count is hot. Statement in cold BB shouldn't be moved
out of it's loop_father. */
if (!for_all_locs_in_loop (loop, ref, ref_in_loop_hot_body (loop)))
return false;
but
/* Check the coldest loop between loop L and innermost loop. If there is one
cold loop between L and INNER_LOOP, store motion can be performed, otherwise
no cold loop means no store motion. get_coldest_out_loop also handles cases
when l is inner_loop. */
bool
ref_in_loop_hot_body::operator () (mem_ref_loc *loc)
{
basic_block curr_bb = gimple_bb (loc->stmt);
class loop *inner_loop = curr_bb->loop_father;
return get_coldest_out_loop (l, inner_loop, curr_bb);
}
checks that there's a good place to move a store to but it doesn't verify
whether there's a store that's likely to be executed in its contained loop.
The for_all_locs_in_loop is also happy if _any_ of the stores for the var
can be moved to a colder place, likely the intent was to check that for
all of the stores (though it's unlikely to differ in simple cases).
This all doesn't distinguish between always and not always executed refs.
[Bug tree-optimization/51848] GCC is not able to vectorize when a constant value is also added to the sum of array expression inside a loop.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51848 Richard Biener changed: What|Removed |Added Keywords|needs-bisection | Status|NEW |RESOLVED Resolution|--- |FIXED Known to work||11.4.1 --- Comment #6 from Richard Biener --- long fixed.
[Bug tree-optimization/53947] [meta-bug] vectorizer missed-optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947 Bug 53947 depends on bug 51848, which changed state. Bug 51848 Summary: GCC is not able to vectorize when a constant value is also added to the sum of array expression inside a loop. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51848 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/113898] [14 regression] ICE in copy_reference_ops_from_ref, at tree-ssa-sccvn.cc:1156 since r14-8929-g938a419182f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113898 Richard Biener changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Richard Biener --- Yes, that case is tracked in PR113895 - we value number e[h_7(D)][1] = 4; and out-of-bound array indices behave differently, choking the verifier code. And I don't see an easy way to fix that so the plan is to remove the verifier code (not sure if it's worth detecting those cases and selectively disabling it). Let's track this in the other bug.
[Bug tree-optimization/113895] [14 Regression] ice in in copy_reference_ops_from_ref, at tree-ssa-sccvn.cc:1144
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113895
--- Comment #9 from Richard Biener ---
Other testcase with -O3:
long a, b, c;
int d;
long e[2][1];
int f() {
if (c == a)
c = b;
}
void g() {
int h, i = 0;
for (; f() + d + i; i++)
e[h][i] = 4;
}
void main() {}
[Bug ipa/98237] gcc-dg-lto-modref-3-01.exe etc. FAIL when LTO plugin is not enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98237 --- Comment #6 from GCC Commits --- The master branch has been updated by Rainer Orth : https://gcc.gnu.org/g:de658585d6dcc89f1cba71ef5f8f5b55719a7054 commit r14-9024-gde658585d6dcc89f1cba71ef5f8f5b55719a7054 Author: Rainer Orth Date: Fri Feb 16 09:47:35 2024 +0100 testsuite: Require lto-plugin support in gcc.dg/lto/modref-3 etc. [PR98237] gcc.dg/lto/modref-3 etc. FAIL on Solaris with the native linker: FAIL: gcc-dg-lto-modref-3-01.exe scan-wpa-ipa-dump modref "parm 1 flags: no_direct_clobber no_direct_escape" FAIL: gcc-dg-lto-modref-4-01.exe scan-wpa-ipa-dump modref "parm 1 flags: no_direct_clobber no_direct_escape" FAIL: gcc.dg/lto/modref-3 c_lto_modref-3_0.o-c_lto_modref-3_1.o execute -O2 -flto-partition=max -fdump-ipa-modref -fno-ipa-sra -fno-ipa-cp -flto FAIL: gcc.dg/lto/modref-4 c_lto_modref-4_0.o-c_lto_modref-4_1.o execute -O2 -flto-partition=max -fdump-ipa-modref -fno-ipa-sra -flto The issue is that the tests require the linker plugin, which isn't available with Solaris ld. Thus, it also FAILs when gcc is configured with --disable-lto-plugin. This patch thus declares the requirement. As it turns out, there's an undocumented dg-require-linker-plugin already, but I introduce and use the corresponding effective-target keyword and document both. Given that the effective-target form is more flexible, I'm tempted to remove dg-require-* with an empty arg as already mentioned in sourcebuild.texi. That is not this patch, however. Tested on i386-pc-solaris2.11 with ld and gld. 2024-02-14 Rainer Orth gcc/testsuite: PR ipa/98237 * lib/target-supports.exp (is-effective-target): Handle linker_plugin. * gcc.dg/lto/modref-3_0.c: Require linker_plugin support. * gcc.dg/lto/modref-4_0.c: Likewise. gcc: * doc/sourcebuild.texi (Effective-Target Keywords, Other attribugs): Document linker_plugin. (Require Support): Document dg-require-linker-plugin.
[Bug ipa/98237] gcc-dg-lto-modref-3-01.exe etc. FAIL when LTO plugin is not enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98237 Rainer Orth changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Assignee|unassigned at gcc dot gnu.org |ro at gcc dot gnu.org Resolution|--- |FIXED --- Comment #7 from Rainer Orth --- Mine. Fixed for GCC 14.0.1.
[Bug target/113690] [13 Regression] ICE: in as_a, at machmode.h:381 with -O2 -fno-dce -fno-forward-propagate -fno-split-wide-types -funroll-loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113690 Roger Sayle changed: What|Removed |Added Summary|[13/14 Regression] ICE: in |[13 Regression] ICE: in |as_a, at machmode.h:381 |as_a, at machmode.h:381 |with -O2 -fno-dce |with -O2 -fno-dce |-fno-forward-propagate |-fno-forward-propagate |-fno-split-wide-types |-fno-split-wide-types |-funroll-loops |-funroll-loops --- Comment #6 from Roger Sayle --- This has now been fixed on mainline. Please let me know if this is worth backporting to GCC 13.
[Bug tree-optimization/113895] [14 Regression] ice in in copy_reference_ops_from_ref, at tree-ssa-sccvn.cc:1144
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113895
--- Comment #10 from Richard Biener ---
(In reply to Zhendong Su from comment #8)
> extern void f();
> char a[1][1], b;
> int main() {
> int c = -1U;
> if (b)
> f(a[c][b]);
> return 0;
> }
for this case, while it's also out-of-bounds, we run into the issue that
we compute op.off to -1 but that's also used as the special value for
"unknown".
[Bug rtl-optimization/111267] [14 Regression] Codegen regression from i386 argument passing changes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111267 Roger Sayle changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #16 from Roger Sayle --- This should now be fixed on mainline. The testsuite regressions (on non-x86 targets) are cosmetic, i.e. neither wrong code nor worse performance/size, just differences in expected code generation.
[Bug target/109349] riscv: Add --print-supported-extensions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109349 Kito Cheng changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #6 from Kito Cheng --- Implemented on trunk now :)
[Bug target/106530] RISCV documentation for -march= is very lacking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106530 Kito Cheng changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #2 from Kito Cheng --- g:19260a04ba6f75b1fae52afab50dcb43d44eb259 and g:5a22bb250d8f4ad239e12fea9828c18a0aa23e38 should address this issue :)
[Bug target/106060] Inefficient constant broadcast on x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106060 Roger Sayle changed: What|Removed |Added Target Milestone|--- |15.0 --- Comment #5 from Roger Sayle --- For the record (so it doesn't get lost) the final patch was posted at https://gcc.gnu.org/pipermail/gcc-patches/2024-January/643973.html and approved (for stage 1) at https://gcc.gnu.org/pipermail/gcc-patches/2024-January/643996.html
[Bug fortran/113928] Aliasing of pointer in expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113928 Richard Biener changed: What|Removed |Added Known to fail||13.2.1, 14.0 --- Comment #1 from Richard Biener --- Confirmed also with GCC 13 and trunk.
[Bug target/113932] [meta-bug] Targets which should be ported to LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113932 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2024-02-16
[Bug rtl-optimization/113951] regression redundant load
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113951
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
Component|target |rtl-optimization
Target||x86_64-*-*
Last reconfirmed||2024-02-16
--- Comment #1 from Richard Biener ---
Confirmed. There's no CSE between sched1 and RA and while GCSE after RA sees
both loads:
expr: (mem/f/c:DI (symbol_ref:DI ("g_677") [flags 0x2] ) [3 g_677+0 S8 A64])
hashcode: 2958100634
list of occurrences:
(insn 19 16 57 5 (set (reg/f:DI 0 ax [orig:104 pretmp_21 ] [104])
(mem/f/c:DI (symbol_ref:DI ("g_677") [flags 0x2] ) [3 g_677+0 S8 A64])) "t.c":46:3 84 {*movdi_internal}
(nil))
(insn 9 8 52 3 (set (reg/f:DI 0 ax [orig:104 pretmp_21 ] [104])
(mem/f/c:DI (symbol_ref:DI ("g_677") [flags 0x2] ) [3 g_677+0 S8 A64])) "t.c":46:3 84 {*movdi_internal}
(nil))
it doesn't do anything here.
[Bug target/106543] [11/12/13/14 Regression] *sge_ uses operand 2 but there is no operand 2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106543 --- Comment #3 from GCC Commits --- The master branch has been updated by Kito Cheng : https://gcc.gnu.org/g:325d5dd53270fe8fd62b36c92c8f8b87c2938bf1 commit r14-9025-g325d5dd53270fe8fd62b36c92c8f8b87c2938bf1 Author: Kito Cheng Date: Fri Feb 16 17:27:24 2024 +0800 RISC-V: Fix *sge_ pattern *sge_ pattern has referenced operand[2] which is invalid...it should just use `slti` rather than `slti%i2`. gcc/ChangeLog: PR target/106543 * config/riscv/riscv.md (*sge_): Fix asm pattern.
[Bug libstdc++/113931] [14 regression] 26_numerics/random/pr60037-neg.cc fails after r14-8998-gc9ce332b557bb9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113931 --- Comment #4 from GCC Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:7f3d900684ad989164114f25eb46a33871c6533d commit r14-9028-g7f3d900684ad989164114f25eb46a33871c6533d Author: Jonathan Wakely Date: Wed Feb 7 11:31:10 2024 + libstdc++: Fix FAIL: 26_numerics/random/pr60037-neg.cc [PR113931] PR libstdc++/87744 PR libstdc++/113931 libstdc++-v3/ChangeLog: * testsuite/26_numerics/random/pr60037-neg.cc: Adjust dg-error line number.
[Bug libstdc++/87744] Some valid instantiations of linear_congruential_engine produce compiler errors when __int128 isn't available
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87744 --- Comment #16 from GCC Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:7f3d900684ad989164114f25eb46a33871c6533d commit r14-9028-g7f3d900684ad989164114f25eb46a33871c6533d Author: Jonathan Wakely Date: Wed Feb 7 11:31:10 2024 + libstdc++: Fix FAIL: 26_numerics/random/pr60037-neg.cc [PR113931] PR libstdc++/87744 PR libstdc++/113931 libstdc++-v3/ChangeLog: * testsuite/26_numerics/random/pr60037-neg.cc: Adjust dg-error line number.
[Bug c++/113957] New: [14 Regression] bad-mapper-1.C hangs on all Darwin.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113957 Bug ID: 113957 Summary: [14 Regression] bad-mapper-1.C hangs on all Darwin. Product: gcc Version: 14.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: c++ Assignee: iains at gcc dot gnu.org Reporter: iains at gcc dot gnu.org Target Milestone: --- Target: *-*-darwin* Initial analysis: this seems to be hanging in a read in libcody.
[Bug c++/113957] [14 Regression] bad-mapper-1.C hangs on all Darwin.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113957 Iain Sandoe changed: What|Removed |Added Target Milestone|--- |14.0 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2024-02-16
[Bug c++/113958] New: support visibility attribute for typeinfo symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113958
Bug ID: 113958
Summary: support visibility attribute for typeinfo symbol
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: noelgrandin at gmail dot com
Target Milestone: ---
Currently, if I want to compile with visibility=hidden, and only expose some
parts of a class definition to the linker, I can use
class Foo {
__attribute__ ((visibility("default"))) some_member() {}
};
on the individual class members. Unfortunately, if external code wants to
dynamic_cast that class, then I end up with
/usr/bin/ld: libsvxlo.so: undefined reference to `typeinfo for SvxCharView'
When compiling with clang, I can specify
__attribute__ ((type_visibility("default"))) class Foo {}
to solve the typeinfo linkage problem.
It would be wonderful if GCC could support something similar.
[Bug libstdc++/113931] [14 regression] 26_numerics/random/pr60037-neg.cc fails after r14-8998-gc9ce332b557bb9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113931 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Jonathan Wakely --- fixed now
[Bug tree-optimization/113895] [14 Regression] ice in in copy_reference_ops_from_ref, at tree-ssa-sccvn.cc:1144
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113895 --- Comment #11 from GCC Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:5fd1cbfd65ef2b6dd87cd78ce6509e7d561981ac commit r14-9029-g5fd1cbfd65ef2b6dd87cd78ce6509e7d561981ac Author: Richard Biener Date: Fri Feb 16 10:08:43 2024 +0100 tree-optimization/113895 - consistency check fails in copy_reference_ops_from_ref The following addresses consistency check fails in copy_reference_ops_from_ref when we are handling out-of-bound array accesses (it's almost impossible to identically mimic the get_ref_base_and_extent behavior). It also addresses the case where an out-of-bound constant offset computes to a -1 off which is the special value for "unknown". This patch basically turns off verification in those cases. PR tree-optimization/113895 * tree-ssa-sccvn.cc (copy_reference_ops_from_ref): Disable consistency checking when there are out-of-bound array accesses. Allow -1 off when from an array reference with constant index. * gcc.dg/torture/pr113895-2.c: New testcase. * gcc.dg/torture/pr113895-3.c: Likewise. * gcc.dg/torture/pr113895-4.c: Likewise.
[Bug tree-optimization/113895] [14 Regression] ice in in copy_reference_ops_from_ref, at tree-ssa-sccvn.cc:1144
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113895 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #12 from Richard Biener --- This should now be fixed.
[Bug sanitizer/113785] c-c++-common/asan/swapcontext-test-1.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113785 Rainer Orth changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |ro at gcc dot gnu.org Last reconfirmed||2024-02-16 Status|UNCONFIRMED |NEW URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2024-Februar ||y/645798.html Ever confirmed|0 |1 --- Comment #4 from Rainer Orth --- Mine, patch posted.
[Bug fortran/113503] [14 Regression] xtb test miscompilation starting with r14-870
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113503
--- Comment #5 from Jakub Jelinek ---
For the warning case, I think
--- gcc/fortran/trans-expr.cc.jj2024-02-14 14:26:19.764810614 +0100
+++ gcc/fortran/trans-expr.cc 2024-02-16 13:22:48.693104239 +0100
@@ -9253,19 +9253,20 @@ gfc_trans_subcomponent_assign (tree dest
|| (cm->ts.type == BT_CLASS && CLASS_DATA (cm)->attr.allocatable
&& expr->ts.type != BT_CLASS)))
{
+ tree size;
+
gfc_init_se (&se, NULL);
gfc_conv_expr (&se, expr);
- tree size;
+ /* The remainder of these instructions follow the if (cm->attr.pointer)
+if (!cm->attr.dimension) part above. */
+ gfc_add_block_to_block (&block, &se.pre);
/* Take care about non-array allocatable components here. The alloc_*
routine below is motivated by the alloc_scalar_allocatable_for_
assignment() routine, but with the realloc portions removed and
different input. */
alloc_scalar_allocatable_subcomponent (&block, dest, cm, expr,
se.string_length);
- /* The remainder of these instructions follow the if (cm->attr.pointer)
-if (!cm->attr.dimension) part above. */
- gfc_add_block_to_block (&block, &se.pre);
if (expr->symtree && expr->symtree->n.sym->attr.proc_pointer
&& expr->symtree->n.sym->attr.dummy)
should fix this. I don't see how code in se.pre could depend on what
alloc_scalar_allocatable_subcomponent emits, and clearly from the #c0 testcase
there can be a dependency in the other direction.
As for the ICE case, this is due to
if (!expr2->ts.u.cl->backend_decl
|| !VAR_P (expr2->ts.u.cl->backend_decl))
expr2->ts.u.cl->backend_decl = gfc_create_var (TREE_TYPE (slen),
"slen");
gfc_add_modify (block, expr2->ts.u.cl->backend_decl, slen);
expr2->ts.u.cl->backend_decl here is INTEGER_CST and slen is the same
INTEGER_CST (20 in both cases), so changing expr2->ts.u.cl->backend_decl to a
temporary variable pushed into current block is definitely undesirable, it
means references to that slen var can be emitted even before or after the
containing block into which the temporary is pushed using pushdecl.
[Bug tree-optimization/113910] [12/13 Regression] Factor 15 slowdown compiling AMDGPUDisassembler.cpp on SPARC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113910
--- Comment #17 from Richard Biener ---
The following still helps quite a bit on its own.
diff --git a/gcc/bitmap.cc b/gcc/bitmap.cc
index 459e32c1ad1..a05ad810800 100644
--- a/gcc/bitmap.cc
+++ b/gcc/bitmap.cc
@@ -2695,18 +2695,21 @@ hashval_t
bitmap_hash (const_bitmap head)
{
const bitmap_element *ptr;
- BITMAP_WORD hash = 0;
+ hashval_t hash = 0;
int ix;
gcc_checking_assert (!head->tree_form);
for (ptr = head->first; ptr; ptr = ptr->next)
{
- hash ^= ptr->indx;
+ hash = iterative_hash_hashval_t (ptr->indx, hash);
for (ix = 0; ix != BITMAP_ELEMENT_WORDS; ix++)
- hash ^= ptr->bits[ix];
+ if (sizeof (BITMAP_WORD) > sizeof (hashval_t))
+ hash = iterative_hash_host_wide_int (ptr->bits[ix], hash);
+ else
+ hash = iterative_hash_hashval_t (ptr->bits[ix], hash);
}
- return iterative_hash (&hash, sizeof (hash), 0);
+ return hash;
}
^L
[Bug sanitizer/113785] c-c++-common/asan/swapcontext-test-1.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113785 --- Comment #5 from GCC Commits --- The master branch has been updated by Rainer Orth : https://gcc.gnu.org/g:7c6071a66f32f43cea7aa4aa32d89b338e768307 commit r14-9030-g7c6071a66f32f43cea7aa4aa32d89b338e768307 Author: Rainer Orth Date: Fri Feb 16 14:06:24 2024 +0100 libsanitizer: Intercept __makecontext_v2 on Solaris/SPARC [PR113785] c-c++-common/asan/swapcontext-test-1.c FAILs on Solaris/SPARC: FAIL: c-c++-common/asan/swapcontext-test-1.c -O0 execution test FAIL: c-c++-common/asan/swapcontext-test-1.c -O1 execution test FAIL: c-c++-common/asan/swapcontext-test-1.c -O2 execution test FAIL: c-c++-common/asan/swapcontext-test-1.c -O2 -flto execution test FAIL: c-c++-common/asan/swapcontext-test-1.c -O2 -flto -flto-partition=none execution test FAIL: c-c++-common/asan/swapcontext-test-1.c -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions execution test FAIL: c-c++-common/asan/swapcontext-test-1.c -O3 -g execution test FAIL: c-c++-common/asan/swapcontext-test-1.c -Os execution test As detailed in PR sanitizer/113785, this happens because an ABI change in Solaris 10/SPARC caused the external symbol for makecontext to be changed to __makecontext_v2, which isn't intercepted. The following patch, submitted upstream at https://github.com/llvm/llvm-project/pull/81588, fixes that. Tested on sparc-sun-solaris2.11 and i386-pc-solaris2.11. 2024-02-16 Rainer Orth libsanitizer: PR sanitizer/113785 * asan/asan_interceptors.cpp: Cherry-pick llvm-project revision 8c2033719a843a1880427a5e8caa5563248bce78.
[Bug sanitizer/113785] c-c++-common/asan/swapcontext-test-1.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113785 Rainer Orth changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #6 from Rainer Orth --- Fixed for GCC 14.0.1.
[Bug middle-end/111156] [14 Regression] aarch64 aarch64/sve/mask_struct_store_4.c failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56
Richard Biener changed:
What|Removed |Added
CC||rsandifo at gcc dot gnu.org
--- Comment #23 from Richard Biener ---
(In reply to Richard Biener from comment #18)
> diff --git a/gcc/tree-vect-slp.cc b/gcc/tree-vect-slp.cc
> index 7cf9504398c..8deeecfd4aa 100644
> --- a/gcc/tree-vect-slp.cc
> +++ b/gcc/tree-vect-slp.cc
> @@ -1280,8 +1280,11 @@ vect_build_slp_tree_1 (vec_info *vinfo, unsigned char
> *swap,
> && rhs_code.is_tree_code ()
> && (TREE_CODE_CLASS (tree_code (first_stmt_code))
> == tcc_comparison)
> - && (swap_tree_comparison (tree_code (first_stmt_code))
> - == tree_code (rhs_code)))
> + && ((swap_tree_comparison (tree_code (first_stmt_code))
> +== tree_code (rhs_code))
> + || ((TREE_CODE_CLASS (tree_code (alt_stmt_code))
> +== tcc_comparison)
> + && rhs_code == alt_stmt_code)))
>&& !(STMT_VINFO_GROUPED_ACCESS (stmt_info)
> && (first_stmt_code == ARRAY_REF
> || first_stmt_code == BIT_FIELD_REF
>
diff --git a/gcc/tree-vect-slp.cc b/gcc/tree-vect-slp.cc
index 7cf9504398c..e35a3fa 100644
--- a/gcc/tree-vect-slp.cc
+++ b/gcc/tree-vect-slp.cc
@@ -1519,7 +1522,9 @@ vect_build_slp_tree_1 (vec_info *vinfo, unsigned char
*swap,
if (alt_stmt_code != ERROR_MARK
&& (!alt_stmt_code.is_tree_code ()
|| (TREE_CODE_CLASS (tree_code (alt_stmt_code)) != tcc_reference
- && TREE_CODE_CLASS (tree_code (alt_stmt_code)) !=
tcc_comparison)))
+ && (TREE_CODE_CLASS (tree_code (alt_stmt_code)) != tcc_comparison
+ || (swap_tree_comparison (tree_code (first_stmt_code))
+ != tree_code (alt_stmt_code))
{
*two_operators = true;
}
is also needed btw. to avoid wrong-code. I see
t.c:8:26: note: ==> examining statement: pretmp_29 = *_28;
t.c:8:26: missed: unsupported load permutation
t.c:10:30: missed: not vectorized: relevant stmt not supported: pretmp_29 =
*_28;
t.c:8:26: note: removing SLP instance operations starting from: .MASK_STORE
(_5, 8B, patt_12, pretmp_29);
using -O3 -march=armv8.3-a+sve - it then does
t.c:8:26: missed: unsupported SLP instances
t.c:8:26: note: re-trying with SLP disabled
and _that_ fails then with
t.c:8:26: missed: Not using elementwise accesses due to variable
vectorization factor.
t.c:6:1: missed: not vectorized: relevant stmt not supported: .MASK_STORE
(_5, 8B, patt_12, pretmp_29);
but the interesting bit is why it fails to handle the SLP case.
That's possibly because the load isn't a grouped access, we get
dr_group_size == 1 and group_size == 2 and nunits is {16, 16}
(!repeating_p) and so
/* We need to construct a separate mask for each vector statement. */
unsigned HOST_WIDE_INT const_nunits, const_vf;
if (!nunits.is_constant (&const_nunits)
|| !vf.is_constant (&const_vf))
return false;
I'm not sure what that comment means, but supposedly we simply fail to handle
another special case that we could here? Possibly dr_group_size == 1?
[Bug fortran/113503] [14 Regression] xtb test miscompilation starting with r14-870
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113503 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #6 from Jakub Jelinek --- Created attachment 57436 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57436&action=edit gcc14-pr113503.patch So far only lightly tested patch (make -j32 check-gfortran).
[Bug target/113955] Finish LRA transition for mips by removing -mlra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113955 Xi Ruoyao changed: What|Removed |Added CC||xry111 at gcc dot gnu.org --- Comment #1 from Xi Ruoyao --- Maybe I can try a full system rebuild with -mlra...
[Bug target/113934] Switch avr to LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113934 --- Comment #1 from Georg-Johann Lay --- What's the LRA way to do LEGITIMIZE_RELOAD_ADDRESS?
[Bug ipa/44563] GCC uses a lot of RAM when compiling a large numbers of functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44563 Richard Biener changed: What|Removed |Added Last reconfirmed|2010-06-17 10:36:48 |2024-2-16 --- Comment #40 from Richard Biener --- Reconfirmed. On for GCC 14 we use about 2GB of ram on x86_64 with -O0 and 20s. With -O1 that regresses to 60s and a little less peak memory. callgraph ipa passes : 14.18 ( 23%) tree PTA : 16.43 ( 27%) And -O2 memory usage improves further at about the same compile-time.
[Bug analyzer/113314] [14 Regression] -Wanalyzer-infinite-loop false positive seen on haproxy's fd.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113314 David Malcolm changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2024-02-16 Summary|-Wanalyzer-infinite-loop|[14 Regression] |false positive seen on |-Wanalyzer-infinite-loop |haproxy's fd.c |false positive seen on ||haproxy's fd.c
[Bug analyzer/109251] [13/14 Regression] -Wanalyzer-deref-before-check false positives seen in Linux kernel due to check in macros
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109251 David Malcolm changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Summary|-Wanalyzer-deref-before-che |[13/14 Regression] |ck false positives seen in |-Wanalyzer-deref-before-che |Linux kernel due to check |ck false positives seen in |in macros |Linux kernel due to check ||in macros Last reconfirmed||2024-02-16
[Bug tree-optimization/108357] [13 Regression] Dead Code Elimination Regression at -O2 since r13-4607-g2dc5d6b1e7ec88
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108357 Rainer Orth changed: What|Removed |Added CC||ro at gcc dot gnu.org --- Comment #21 from Rainer Orth --- Created attachment 57437 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57437&action=edit 32- bit i386-pc-solaris2.11 pr108357.c.120t.threadfull1 The test also FAILs on 32 and 64-bit Solaris/SPARC since it was committed. Changing b from char to unsigned char lets it PASS. Again, this is weird insofar as char is signed on both Solaris/SPARC and Solaris/x86, but the test PASSes on x86 already.
[Bug analyzer/105961] -Wanalyzer-use-of-uninitialized-value false positive after "= {0}"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105961 David Malcolm changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |WORKSFORME --- Comment #5 from David Malcolm --- I tried this again on Compiler Explorer, but I'm now not seeing any output on the reproducer: Trunk: https://godbolt.org/z/G8fravbbT GCC 13.2: https://godbolt.org/z/8aj7zTssG GCC 12.3: https://godbolt.org/z/6v15Es3nc GCC 11.4: https://godbolt.org/z/hxPdxGTr9 Marking as RESOLVED WORKSFORME. Feel free to reopen if you're still able to reproduce this.
[Bug middle-end/113959] New: Optimize `__builtin_isnan(x) || __builtin_isinf(x)` to `__builtin_isfinite(x)`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113959 Bug ID: 113959 Summary: Optimize `__builtin_isnan(x) || __builtin_isinf(x)` to `__builtin_isfinite(x)` Product: gcc Version: 14.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: antoshkka at gmail dot com Target Milestone: --- Sometimes people check for finite number using `__builtin_isnan(x) || __builtin_isinf(x)`. However `__builtin_isfinite(x)` produces a better assembly. Please, add the optimization. Godbolt playground: https://godbolt.org/z/5r38169fn
[Bug c++/113957] [14 Regression] bad-mapper-1.C hangs on all Darwin.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113957 --- Comment #1 from Iain Sandoe --- the problem is that liberty is using the value set by posix_spawnp for pid. but: (darwin): The argument pid is a pointer to a pid_t variable to receive the pid of the spawned process; if this is NULL, then the pid of the spawned process is not returned. If this pointer is non-NULL, then on successful completion, the variable will be modified to contain the pid of the spawned process. The value is undefined in the case of a failure. (linux): Upon successful completion, posix_spawn() and posix_spawnp() place the PID of the child process in pid, and return 0. If there is an error during the fork() step, then no child is created, the contents of *pid are unspecified, and these functions return an error number as described below. So .. I think the fix will be to set pid = -1 in the error paths .. will try that.
[Bug analyzer/108400] [12/13/14 Regression] -Wanalyzer-null-dereference false positive on SoftEtherVPN's src/Cedar/WebUI.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108400 David Malcolm changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2024-02-16 Status|UNCONFIRMED |NEW Summary|-Wanalyzer-null-dereference |[12/13/14 Regression] |false positive on |-Wanalyzer-null-dereference |SoftEtherVPN's |false positive on |src/Cedar/WebUI.c |SoftEtherVPN's ||src/Cedar/WebUI.c
[Bug c++/113960] New: std::map with std::vector as input overwrites itself with c++20, on s390x platform
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113960
Bug ID: 113960
Summary: std::map with std::vector as input overwrites itself
with c++20, on s390x platform
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: miladfarca at gmail dot com
Target Milestone: ---
Host: s390x
Target: s390x
```
#include
#include
#include
int main(){
std::vector v1 = {1};
std::vector v2 = {2};
std::map, int> m;
m[v1] = 1;
m[v2] = 2; // this overwrites m[v1]
std::cout << m.size() << std::endl; // prints 1, should be 2
return 0;
}
```
Compile with `g++ std=c++20`. Output is correct with c++17. Tested on g++
12.2.1 and g++ 13.2.1
[Bug analyzer/105755] -Wanalyzer-null-dereference regression compiling Emacs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105755 --- Comment #3 from David Malcolm --- Current status of reproducer on Compiler Explorer: GCC trunk: no warning: https://godbolt.org/z/o6ecKKa8e GCC 13.2: no warning: https://godbolt.org/z/z7hdYx1Y7 GCC 12.3: false +ve: https://godbolt.org/z/8W7c68GoT GCC 11.4: no warning: https://godbolt.org/z/5vv5KWsTP
[Bug analyzer/108562] [meta-bug] tracker bug for issues with -Wanalyzer-null-dereference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108562 Bug 108562 depends on bug 105755, which changed state. Bug 105755 Summary: -Wanalyzer-null-dereference regression compiling Emacs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105755 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WORKSFORME
[Bug analyzer/105755] -Wanalyzer-null-dereference regression compiling Emacs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105755 David Malcolm changed: What|Removed |Added Resolution|--- |WORKSFORME Status|UNCONFIRMED |RESOLVED --- Comment #4 from David Malcolm --- Looks like this was fixed sometime in GCC 13; resolving as WORKSFORME. Feel free to reopen if you have a reproducer that triggers on a more recent GCC.
[Bug middle-end/113907] [14 regression] ICU miscompiled since on x86 since r14-5109-ga291237b628f41
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907
--- Comment #39 from Jan Hubicka ---
This testcase
#include
int data[100];
__attribute__((noinline))
int bar (int d, unsigned int d2)
{
if (d2 > 10)
printf ("Bingo\n");
return d + d2;
}
int
test2 (unsigned int i)
{
if (i > 10)
__builtin_unreachable ();
if (__builtin_expect (data[i] != 0, 1))
return data[i];
printf ("%i\n",i);
for (int j = 0; j < 100; j++)
data[i] += bar (data[j], i+17);
return data[i];
}
int
test (unsigned int i)
{
if (i > 100)
__builtin_unreachable ();
if (__builtin_expect (data[i] != 0, 1))
return data[i];
printf ("%i\n",i);
for (int j = 0; j < 100; j++)
data[i] += bar (data[j], i+17);
return data[i];
}
int
main ()
{
test (1);
test (2);
test (3);
test2 (4);
test2 (100);
return 0;
}
gets me most of what I want to reproduce ipa-prop problem. Functions test and
test2 are split with different value ranges visible in the fnsplit dump.
However curiously enough ipa-prop analysis seems to ignore the value ranges and
does not attach them to the jump function, which is odd...
[Bug libstdc++/113060] std::variant converting constructor/assignment is non-conforming after P2280?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113060 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |SUSPENDED Last reconfirmed||2024-02-16 Ever confirmed|0 |1 --- Comment #3 from Jonathan Wakely --- Suspending until https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p3146r0.html is handled.
[Bug c++/54052] [11/12/13/14 Regression] g++ takes excessive time in opt and generate phase; can lead to Segmentation Fault when not enough memory available
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54052 Richard Biener changed: What|Removed |Added CC||rguenth at gcc dot gnu.org, ||rsandifo at gcc dot gnu.org Summary|g++ takes excessive time in |[11/12/13/14 Regression] |opt and generate phase; can |g++ takes excessive time in |lead to Segmentation Fault |opt and generate phase; can |when not enough memory |lead to Segmentation Fault |available |when not enough memory ||available Last reconfirmed|2018-09-18 00:00:00 |2024-2-16 Target Milestone|--- |11.5 --- Comment #10 from Richard Biener --- GCC 14: -O0 800MB in 10s -O1 1.2GB in 30min (!) SSA construction (rtl_ssa::function_info::place_phis) takes forever. forward prop :1669.98 ( 95%) combiner : 34.80 ( 2%) TOTAL :1749.78 unsurprisingly -fno-forward-propagate helps a lot, compile-time down to 76s. GCC 11 seems to be similarly slow, stopped after some minutes, -fno-forward-propagate helps as well (63s). GCC 10 (no RTL SSA): -O1 1GB in 70s dominance frontiers: 13.69 ( 19%) combiner : 36.62 ( 50%) so there's at least a big regression from GCC 10 here. The testcase might be a bit large to work with and I didn't profile but for -O1 we need some "fix" here, even if it might be simply giving up for some CFG + nregs characteristics that makes things blow up here.
[Bug other/113957] [14 Regression] bad-mapper-1.C hangs on all Darwin.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113957 Iain Sandoe changed: What|Removed |Added Component|c++ |other Keywords|wrong-code |error-recovery URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2024-Februar ||y/645814.html --- Comment #2 from Iain Sandoe --- patch posted.
[Bug middle-end/113907] [14 regression] ICU miscompiled since on x86 since r14-5109-ga291237b628f41
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907
--- Comment #40 from Jakub Jelinek ---
(In reply to Jan Hubicka from comment #39)
> This testcase
> #include
> int data[100];
>
> __attribute__((noinline))
> int bar (int d, unsigned int d2)
> {
> if (d2 > 10)
> printf ("Bingo\n");
> return d + d2;
> }
So, while d2 should have [17, 27] range when called from test2 and [17, 117]
from test,
I don't see anything that would limit ranges of data[?], it can be anything
(say some global constructor modifying the data array). So bar has to return
VARYING.
[Bug libstdc++/99117] [11/12/13 Regression] cannot accumulate std::valarray
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99117 --- Comment #24 from GCC Commits --- The releases/gcc-13 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:3a72c717b311ce8093042d927a1f2f2b940a969c commit r13-8334-g3a72c717b311ce8093042d927a1f2f2b940a969c Author: Jonathan Wakely Date: Thu Feb 8 13:59:42 2024 + libstdc++: Avoid aliasing violation in std::valarray [PR99117] The call to __valarray_copy constructs an _Array object to refer to this->_M_data but that means that accesses to this->_M_data are through a restrict-qualified pointer. This leads to undefined behaviour when copying from an _Expr object that actually aliases this->_M_data. Replace the call to __valarray_copy with a plain loop. I think this removes the only use of that overload of __valarray_copy, so it could probably be removed. I haven't done that here. libstdc++-v3/ChangeLog: PR libstdc++/99117 * include/std/valarray (valarray::operator=(const _Expr&)): Use loop to copy instead of __valarray_copy with _Array. * testsuite/26_numerics/valarray/99117.cc: New test. (cherry picked from commit b58f0e5216a3053486e7f1aa96c3f2443b14d630)
[Bug libstdc++/113294] constexpr error from accessing inactive union member in basic_string after move assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113294 --- Comment #4 from GCC Commits --- The releases/gcc-13 branch has been updated by Patrick Palka : https://gcc.gnu.org/g:ebe00c9d3a0436dec5c354a62d98e444d763ff95 commit r13-8335-gebe00c9d3a0436dec5c354a62d98e444d763ff95 Author: Paul Keir Date: Mon Feb 12 18:15:49 2024 + libstdc++: Fix constexpr basic_string union member [PR113294] A call to `basic_string::clear()` in the std::string move assignment operator leads to a constexpr error from an access of inactive union member `_M_local_buf` in the added test (`test_move()`). Changing `__str._M_local_buf` to `__str._M_use_local_data()` in `operator=(basic_string&& __str)` fixes this. PR libstdc++/113294 libstdc++-v3/ChangeLog: * include/bits/basic_string.h (basic_string::operator=): Use _M_use_local_data() instead of _M_local_buf on the moved-from string. * testsuite/21_strings/basic_string/modifiers/constexpr.cc (test_move): New test. Signed-off-by: Paul Keir Reviewed-by: Patrick Palka Reviewed-by: Jonathan Wakely (cherry picked from commit 065dddc6e07a917c57c7955db13b1fe77abbcabc)
[Bug libstdc++/113294] constexpr error from accessing inactive union member in basic_string after move assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113294 Patrick Palka changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|--- |13.3 Status|NEW |RESOLVED --- Comment #5 from Patrick Palka --- Fixed for GCC 13.3/14 thanks for the report and patch!
[Bug middle-end/113907] [12/13/14 regression] ICU miscompiled since on x86 since r14-5109-ga291237b628f41
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907
Jan Hubicka changed:
What|Removed |Added
Summary|[14 regression] ICU |[12/13/14 regression] ICU
|miscompiled since on x86|miscompiled since on x86
|since |since
|r14-5109-ga291237b628f41|r14-5109-ga291237b628f41
--- Comment #41 from Jan Hubicka ---
OK, the reason why this does not work is that ranger ignores earlier value
ranges on everything but default defs and phis.
// This is where the ranger picks up global info to seed initial
// requests. It is a slightly restricted version of
// get_range_global() above.
//
// The reason for the difference is that we can always pick the
// default definition of an SSA with no adverse effects, but for other
// SSAs, if we pick things up to early, we may prematurely eliminate
// builtin_unreachables.
//
// Without this restriction, the test in g++.dg/tree-ssa/pr61034.C has
// all of its unreachable calls removed too early.
//
// See discussion here:
// https://gcc.gnu.org/pipermail/gcc-patches/2021-June/571709.html
void
gimple_range_global (vrange &r, tree name, struct function *fun)
{
tree type = TREE_TYPE (name);
gcc_checking_assert (TREE_CODE (name) == SSA_NAME);
if (SSA_NAME_IS_DEFAULT_DEF (name) || (fun && fun->after_inlining)
|| is_a (SSA_NAME_DEF_STMT (name)))
{
get_range_global (r, name, fun);
return;
}
r.set_varying (type);
}
This makes ipa-prop to ignore earlier known value range and mask the bug.
However adding PHI makes the problem to reproduce:
#include
#include
int data[100];
int c;
static __attribute__((noinline))
int bar (int d, unsigned int d2)
{
if (d2 > 30)
c++;
return d + d2;
}
static int
test2 (unsigned int i)
{
if (i > 100)
__builtin_unreachable ();
if (__builtin_expect (data[i] != 0, 1))
return data[i];
for (int j = 0; j < 100; j++)
data[i] += bar (data[j], i&1 ? i+17 : i + 16);
return data[i];
}
static int
test (unsigned int i)
{
if (i > 10)
__builtin_unreachable ();
if (__builtin_expect (data[i] != 0, 1))
return data[i];
for (int j = 0; j < 100; j++)
data[i] += bar (data[j], i&1 ? i+17 : i + 16);
return data[i];
}
int
main ()
{
int ret = test (1) + test (2) + test (3) + test2 (4) + test2 (30);
if (!c)
abort ();
return ret;
}
This fails with trunk, gcc12 and gcc13 and also with Jakub's patch.
[Bug middle-end/113907] [12/13/14 regression] ICU miscompiled since on x86 since r14-5109-ga291237b628f41
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907 --- Comment #42 from Jakub Jelinek --- So guess we need to union the ranges and for earlier gccs also the zero bits stuff upon ICF, right?
[Bug libstdc++/113841] Can't swap two std::hash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113841 Jonathan Wakely changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Target Milestone|--- |12.4
[Bug other/113961] New: [14 regression] 26_numerics/random/pr60037-neg.cc fails in new place after r14-9028-g7f3d900684ad98
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113961 Bug ID: 113961 Summary: [14 regression] 26_numerics/random/pr60037-neg.cc fails in new place after r14-9028-g7f3d900684ad98 Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- g:7f3d900684ad989164114f25eb46a33871c6533d, r14-9028-g7f3d900684ad98 make -k check RUNTESTFLAGS="conformance.exp=26_numerics/random/pr60037-neg.cc" FAIL: 26_numerics/random/pr60037-neg.cc -std=gnu++17 (test for errors, line 3350) FAIL: 26_numerics/random/pr60037-neg.cc -std=gnu++17 (test for excess errors) commit 7f3d900684ad989164114f25eb46a33871c6533d (HEAD) Author: Jonathan Wakely Date: Wed Feb 7 11:31:10 2024 + libstdc++: Fix FAIL: 26_numerics/random/pr60037-neg.cc [PR113931] This commit fixed the previous error in pr60037-neg.cc but caused a new one. In file included from /home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/random:48,^M from /home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/powerpc64le-unknown-linux-gnu/bits/stdc++.h:179,^M from :^M /home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/bits/random.h: In instantiation of 'struct std::__detail::_Adaptor, long unsigned int>':^M /home/seurer/gcc/git/gcc-test/libstdc++-v3/testsuite/26_numerics/random/pr60037-neg.cc:8: required from here^M /home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/bits/random.h:270: error: static assertion failed: template argument must be a floating point type^M /home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/bits/random.h:270: note: 'std::integral_constant::value' evaluates to false^M In file included from /home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/random:50:^M /home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/bits/random.tcc: In instantiation of '_RealType std::generate_canonical(_UniformRandomNumberGenerator&) [with _RealType = long unsigned int; long unsigned int __bits = 64; _UniformRandomNumberGenerator = mersenne_twister_engine]':^M /home/seurer/gcc/git/gcc-test/libstdc++-v3/testsuite/26_numerics/random/pr60037-neg.cc:11: required from here^M /home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/bits/random.tcc:3351: error: static assertion failed: template argument must be a floating point type^M /home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/bits/random.tcc:3351: note: 'std::integral_constant::value' evaluates to false^M compiler exited with status 1 PASS: 26_numerics/random/pr60037-neg.cc -std=gnu++17 (test for errors, line 270) FAIL: 26_numerics/random/pr60037-neg.cc -std=gnu++17 (test for errors, line 3350)
[Bug middle-end/113907] [12/13/14 regression] ICU miscompiled since on x86 since r14-5109-ga291237b628f41
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907 --- Comment #43 from Jan Hubicka --- > // See discussion here: > // https://gcc.gnu.org/pipermail/gcc-patches/2021-June/571709.html Discussion says: "Once legacy evrp is removed, this won't be an issue, as ranges in the IL will tell the truth. However, this will mean that we will no longer remove the first __builtin_unreachable combo. But ISTM, that would be correct behavior ??." So perhaps, we could remove that special case for default def and phi? It is an odd thing and we clearly lose info here. The problem is that value of parameter i itself does not have global value range [0...10] so I need to compute new SSA name to get it preserved through ipa-split. Maybe ipa-split can be extended to fire up ranger and try to get better value ranges on function parameters from the split function header. Not sure if that is worth the effort though. If we go with merging functions with different ranges, we indeed need to update ranges and bits both in SSA_NAME infos and in ipa-prop's jump functions. At the time sem_fuction::merge calls ipa_merge_profiles we do have both function bodies in memory and thus we can do the job. If we just drop the info instead of merging, we do limited harm on SSA_NAME infos since they mostly will be recomputed again. For ipa-prop this may cause more interesting precision loss. So perhaps for backportability we may want to just limit ICF to functions wth same ranges in SSA_NAME infos. Let me cook up a patch and see if there is significant loss in merged functions. I think it should be quite small given that ranges seem to only diverge through ipa-split in very specific cases for now. (and given how much time I spent on producing the testcase)
[Bug ipa/111960] [14 Regression] ICE: during GIMPLE pass: rebuild_frequencies: SIGSEGV (Invalid read of size 4) with -fdump-tree-rebuild_frequencies-all
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111960
--- Comment #5 from Jan Hubicka ---
hmm. cfg.cc:815 for me is:
fputs (", maybe hot", outf);
which seems quite safe.
The problem does not seem to reproduce for me:
jh@ryzen3:~/gcc/build/gcc> ./xgcc -B ./ tt.c -O
--param=max-inline-recursive-depth=100 -fdump-tree-rebuild_frequencies-all
-wrapper valgrind
==25618== Memcheck, a memory error detector
==25618== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==25618== Using Valgrind-3.22.0 and LibVEX; rerun with -h for copyright info
==25618== Command: ./cc1 -quiet -iprefix
/home/jh/gcc/build/gcc/../lib64/gcc/x86_64-pc-linux-gnu/14.0.1/ -isystem
./include -isystem ./include-fixed tt.c -quiet -dumpdir a- -dumpbase tt.c
-dumpbase-ext .c -mtune=generic -march=x86-64 -O
-fdump-tree-rebuild_frequencies-all --param=max-inline-recursive-depth=100
-o /tmp/ccpkfjdK.s
==25618==
==25618==
==25618== HEAP SUMMARY:
==25618== in use at exit: 1,818,714 bytes in 1,175 blocks
==25618== total heap usage: 39,645 allocs, 38,470 frees, 12,699,874 bytes
allocated
==25618==
==25618== LEAK SUMMARY:
==25618==definitely lost: 0 bytes in 0 blocks
==25618==indirectly lost: 0 bytes in 0 blocks
==25618== possibly lost: 8,032 bytes in 1 blocks
==25618==still reachable: 1,810,682 bytes in 1,174 blocks
==25618== suppressed: 0 bytes in 0 blocks
==25618== Rerun with --leak-check=full to see details of leaked memory
==25618==
==25618== For lists of detected and suppressed errors, rerun with: -s
==25618== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
==25627== Memcheck, a memory error detector
==25627== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==25627== Using Valgrind-3.22.0 and LibVEX; rerun with -h for copyright info
==25627== Command: ./as --64 -o /tmp/ccp5TNme.o /tmp/ccpkfjdK.s
==25627==
==25637== Memcheck, a memory error detector
==25637== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==25637== Using Valgrind-3.22.0 and LibVEX; rerun with -h for copyright info
==25637== Command: ./collect2 -plugin ./liblto_plugin.so
-plugin-opt=./lto-wrapper -plugin-opt=-fresolution=/tmp/cclWZD7F.res
-plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s
-plugin-opt=-pass-through=-lc -plugin-opt=-pass-through=-lgcc
-plugin-opt=-pass-through=-lgcc_s --eh-frame-hdr -m elf_x86_64 -dynamic-linker
/lib64/ld-linux-x86-64.so.2 /lib/../lib64/crt1.o /lib/../lib64/crti.o
./crtbegin.o -L. -L/lib/../lib64 -L/usr/lib/../lib64 /tmp/ccp5TNme.o -lgcc
--push-state --as-needed -lgcc_s --pop-state -lc -lgcc --push-state --as-needed
-lgcc_s --pop-state ./crtend.o /lib/../lib64/crtn.o
==25637==
/usr/lib64/gcc/x86_64-suse-linux/13/../../../../x86_64-suse-linux/bin/ld:
/lib/../lib64/crt1.o: in function `_start':
/home/abuild/rpmbuild/BUILD/glibc-2.38/csu/../sysdeps/x86_64/start.S:103:(.text+0x2b):
undefined reference to `main'
collect2: error: ld returned 1 exit status
==25637==
==25637== HEAP SUMMARY:
==25637== in use at exit: 89,760 bytes in 39 blocks
==25637== total heap usage: 175 allocs, 136 frees, 106,565 bytes allocated
==25637==
==25637== LEAK SUMMARY:
==25637==definitely lost: 0 bytes in 0 blocks
==25637==indirectly lost: 0 bytes in 0 blocks
==25637== possibly lost: 0 bytes in 0 blocks
==25637==still reachable: 89,760 bytes in 39 blocks
==25637== of which reachable via heuristic:
==25637== newarray : 1,544 bytes in 1 blocks
==25637== suppressed: 0 bytes in 0 blocks
==25637== Rerun with --leak-check=full to see details of leaked memory
==25637==
==25637== For lists of detected and suppressed errors, rerun with: -s
==25637== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
[Bug middle-end/113907] [12/13/14 regression] ICU miscompiled since on x86 since r14-5109-ga291237b628f41
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907 Jakub Jelinek changed: What|Removed |Added CC||aldyh at gcc dot gnu.org --- Comment #44 from Jakub Jelinek --- (In reply to Jan Hubicka from comment #43) > > // See discussion here: > > // https://gcc.gnu.org/pipermail/gcc-patches/2021-June/571709.html > Discussion says: > > "Once legacy evrp is removed, this won't be an issue, as ranges in the IL > will tell the truth. However, this will mean that we will no longer > remove the first __builtin_unreachable combo. But ISTM, that would be > correct behavior ??." ... But that doesn't cause these problems, just perhaps losing some info, right? If so, trying to change that feels like stage1 material to me.
[Bug analyzer/111213] -Wanalyzer-out-of-bounds false negative with `return arr[9];` at -O1 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111213 David Malcolm changed: What|Removed |Added Status|NEW |SUSPENDED --- Comment #4 from David Malcolm --- Marking this one as SUSPENDED since it would require the big rewrite for PR 111312.
[Bug ipa/108802] [11/12/13/14 Regression] missed inlining of call via pointer to member function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108802 --- Comment #5 from Jan Hubicka --- I don't think we can reasonably expect every caller of lambda function to be early inlined, so we need to extend ipa-prop to understand the obfuscated code. I disucussed that with Martin some time ago - I think this is quite common problem with modern C++, so we will need to pattern match this, which is quite unfortunate.
[Bug other/113961] [14 regression] 26_numerics/random/pr60037-neg.cc fails in new place after r14-9028-g7f3d900684ad98
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113961 --- Comment #1 from seurer at gcc dot gnu.org --- < previous run: g:1aef0a9b07766d100a218ef3e9576d0a0dd35a2d, r14-9027-g1aef0a9b07766d > this run: g:7f3d900684ad989164114f25eb46a33871c6533d, r14-9028-g7f3d900684ad98 < FAIL: 26_numerics/random/pr60037-neg.cc -std=gnu++17 (test for errors, line 271) > FAIL: 26_numerics/random/pr60037-neg.cc -std=gnu++17 (test for errors, line 3350)
[Bug c++/98752] wrong "error: ‘this’ is not a constant expression" with consteval constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98752 --- Comment #7 from Marek Polacek --- Comment 5 test was fixed by r14-5979-g99d114c15523e0 commit 99d114c15523e0bfe7a89ef1947f82eb5ff0260b Author: Marek Polacek Date: Fri Nov 17 14:48:44 2023 -0500 c++: P2280R4, Using unknown refs in constant expr [PR106650] the comment 6 one still doesn't work.
[Bug c++/113929] GCC accepts template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113929 --- Comment #2 from GCC Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:5286b0761b5dfac4348d1c5bfdcc162a66f338ee commit r14-9033-g5286b0761b5dfac4348d1c5bfdcc162a66f338ee Author: Jakub Jelinek Date: Fri Feb 16 17:42:32 2024 +0100 c++: Diagnose this specifier on template parameters [PR113929] For template parameters, the optional this specifier is in the grammar template-parameter-list -> template-parameter -> parameter-declaration, just [dcl.fct/6] says that it is only valid in parameter-list of certain functions. So, unlike the case of decl-specifier-seq used in non-terminals other than parameter-declaration, I think it is better not to fix this by cp_parser_decl_specifier_seq (parser, -flags | CP_PARSER_FLAGS_PARAMETER, +flags | (template_parameter_p ? 0 + : CP_PARSER_FLAGS_PARAMETER), &decl_specifiers, &declares_class_or_enum); which would be pretending it isn't in the grammar, but by diagnosing it separately, which is what the following patch does. 2024-02-16 Jakub Jelinek PR c++/113929 * parser.cc (cp_parser_parameter_declaration): Diagnose this specifier on template parameter declaration. * g++.dg/parse/pr113929.C: New test.
[Bug c++/113929] GCC accepts template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113929 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Jakub Jelinek --- Fixed.
[Bug middle-end/113907] [12/13/14 regression] ICU miscompiled since on x86 since r14-5109-ga291237b628f41
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907 --- Comment #45 from Jan Hubicka --- > > "Once legacy evrp is removed, this won't be an issue, as ranges in the IL > > will tell the truth. However, this will mean that we will no longer > > remove the first __builtin_unreachable combo. But ISTM, that would be > > correct behavior ??." > ... > > But that doesn't cause these problems, just perhaps losing some info, right? > If so, trying to change that feels like stage1 material to me. Yep. It would be nice to not forget about that - it kept me confused for over an hour :)
[Bug other/113961] [14 regression] 26_numerics/random/pr60037-neg.cc fails in new place after r14-9028-g7f3d900684ad98
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113961 Jonathan Wakely changed: What|Removed |Added Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Target Milestone|--- |14.0 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2024-02-16 --- Comment #2 from Jonathan Wakely --- Gah, now I see what's going on ... I have another patch for bits/random.h in my local tree which is affecting those line numbers.
[Bug c++/104919] [modules] enum in constexpr function causes "failed to read compiled module cluster 1: Bad file data"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104919 Patrick Palka changed: What|Removed |Added CC||ppalka at gcc dot gnu.org Status|UNCONFIRMED |NEW Last reconfirmed||2024-02-16 See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=106009 Ever confirmed|0 |1 --- Comment #1 from Patrick Palka --- s/constexpr/inline also triggers the bug, unsurprisingly. PR106009 about templated local enums might be related.
[Bug middle-end/113907] [12/13/14 regression] ICU miscompiled since on x86 since r14-5109-ga291237b628f41
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907 --- Comment #46 from Andrew Macleod --- (In reply to Jan Hubicka from comment #43) > > // See discussion here: > > // https://gcc.gnu.org/pipermail/gcc-patches/2021-June/571709.html > Discussion says: > > "Once legacy evrp is removed, this won't be an issue, as ranges in the IL > will tell the truth. However, this will mean that we will no longer > remove the first __builtin_unreachable combo. But ISTM, that would be > correct behavior ??." > > So perhaps, we could remove that special case for default def and phi? > It is an odd thing and we clearly lose info here. > legacy VRP has been removed now. So in theory we are free to do as we want.. but I don't remember the specific details. So do you just want to always use get_range_global() ? and not do the check? I can try changing it to just get_global and see what happens.
[Bug c++/113789] [13/14 Regression] ICE on P2266/C++23 `decltype(throw x)` where x is move-eligible parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113789
--- Comment #8 from GCC Commits ---
The trunk branch has been updated by Marek Polacek :
https://gcc.gnu.org/g:254ff3d0e34835b4de93d5e5763a7366dc7d989d
commit r14-9034-g254ff3d0e34835b4de93d5e5763a7366dc7d989d
Author: Marek Polacek
Date: Wed Feb 14 17:53:52 2024 -0500
c++: implicit move with throw [PR113853]
Here we have
template
auto is_throwable(T t) -> decltype(throw t, true) { ... }
where we didn't properly mark 't' as IMPLICIT_RVALUE_P, which caused
the wrong overload to have been chosen. Jason figured out it's because
we don't correctly implement [expr.prim.id.unqual]#4.2, which post-P2266
says that an id-expression is move-eligible if
"the id-expression (possibly parenthesized) is the operand of
a throw-expression, and names an implicitly movable entity that belongs
to a scope that does not contain the compound-statement of the innermost
lambda-expression, try-block, or function-try-block (if any) whose
compound-statement or ctor-initializer contains the throw-expression."
I worked out that it's trying to say that given
struct X {
X();
X(const X&);
X(X&&) = delete;
};
the following should fail: the scope of the throw is an sk_try, and it's
also x's scope S, and S "does not contain the compound-statement of the
*try-block" so x is move-eligible, so we move, so we fail.
void f ()
try {
X x;
throw x; // use of deleted function
} catch (...) {
}
Whereas here:
void g (X x)
try {
throw x;
} catch (...) {
}
the throw is again in an sk_try, but x's scope is an sk_function_parms
which *does* contain the {} of the *try-block, so x is not move-eligible,
so we don't move, so we use X(const X&), and the code is fine.
The current code also doesn't seem to handle
void h (X x) {
void z (decltype(throw x, true));
}
where there's no enclosing lambda or sk_try so we should move.
I'm not doing anything about lambdas because we shouldn't reach the
code at the end of the function: the DECL_HAS_VALUE_EXPR_P check
shouldn't let us go further.
PR c++/113789
PR c++/113853
gcc/cp/ChangeLog:
* typeck.cc (treat_lvalue_as_rvalue_p): Update code to better
reflect [expr.prim.id.unqual]#4.2.
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/sfinae69.C: Remove dg-bogus.
* g++.dg/cpp0x/sfinae70.C: New test.
* g++.dg/cpp0x/sfinae71.C: New test.
* g++.dg/cpp0x/sfinae72.C: New test.
* g++.dg/cpp2a/implicit-move4.C: New test.
[Bug c++/113853] implicit move in throw in trailing return type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113853
--- Comment #2 from GCC Commits ---
The trunk branch has been updated by Marek Polacek :
https://gcc.gnu.org/g:254ff3d0e34835b4de93d5e5763a7366dc7d989d
commit r14-9034-g254ff3d0e34835b4de93d5e5763a7366dc7d989d
Author: Marek Polacek
Date: Wed Feb 14 17:53:52 2024 -0500
c++: implicit move with throw [PR113853]
Here we have
template
auto is_throwable(T t) -> decltype(throw t, true) { ... }
where we didn't properly mark 't' as IMPLICIT_RVALUE_P, which caused
the wrong overload to have been chosen. Jason figured out it's because
we don't correctly implement [expr.prim.id.unqual]#4.2, which post-P2266
says that an id-expression is move-eligible if
"the id-expression (possibly parenthesized) is the operand of
a throw-expression, and names an implicitly movable entity that belongs
to a scope that does not contain the compound-statement of the innermost
lambda-expression, try-block, or function-try-block (if any) whose
compound-statement or ctor-initializer contains the throw-expression."
I worked out that it's trying to say that given
struct X {
X();
X(const X&);
X(X&&) = delete;
};
the following should fail: the scope of the throw is an sk_try, and it's
also x's scope S, and S "does not contain the compound-statement of the
*try-block" so x is move-eligible, so we move, so we fail.
void f ()
try {
X x;
throw x; // use of deleted function
} catch (...) {
}
Whereas here:
void g (X x)
try {
throw x;
} catch (...) {
}
the throw is again in an sk_try, but x's scope is an sk_function_parms
which *does* contain the {} of the *try-block, so x is not move-eligible,
so we don't move, so we use X(const X&), and the code is fine.
The current code also doesn't seem to handle
void h (X x) {
void z (decltype(throw x, true));
}
where there's no enclosing lambda or sk_try so we should move.
I'm not doing anything about lambdas because we shouldn't reach the
code at the end of the function: the DECL_HAS_VALUE_EXPR_P check
shouldn't let us go further.
PR c++/113789
PR c++/113853
gcc/cp/ChangeLog:
* typeck.cc (treat_lvalue_as_rvalue_p): Update code to better
reflect [expr.prim.id.unqual]#4.2.
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/sfinae69.C: Remove dg-bogus.
* g++.dg/cpp0x/sfinae70.C: New test.
* g++.dg/cpp0x/sfinae71.C: New test.
* g++.dg/cpp0x/sfinae72.C: New test.
* g++.dg/cpp2a/implicit-move4.C: New test.
[Bug c++/113853] implicit move in throw in trailing return type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113853 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Marek Polacek --- Fixed in GCC 14.
[Bug c++/98388] Throwing move-only parameter results in hard error in SFINAE context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98388 Marek Polacek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #3 from Marek Polacek --- Should be fixed now.
[Bug c++/113789] [13 Regression] ICE on P2266/C++23 `decltype(throw x)` where x is move-eligible parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113789 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Summary|[13/14 Regression] ICE on |[13 Regression] ICE on |P2266/C++23 `decltype(throw |P2266/C++23 `decltype(throw |x)` where x is |x)` where x is |move-eligible parameter |move-eligible parameter Resolution|--- |FIXED --- Comment #9 from Marek Polacek --- Should be fully fixed now.
[Bug c++/113158] [11/12/13/14 Regression] Erroneous "looser exception specification" error for class template and depedent noexcept value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113158 Marek Polacek changed: What|Removed |Added Keywords||patch --- Comment #3 from Marek Polacek --- https://gcc.gnu.org/pipermail/gcc-patches/2024-February/645767.html
[Bug c++/113545] ICE in label_matches with constexpr function with switch-statement and converted (nonconstant, cast address) input
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113545 --- Comment #6 from GCC Commits --- The releases/gcc-13 branch has been updated by Marek Polacek : https://gcc.gnu.org/g:e501a279fb4298c9b23637d573287e059b3b06c8 commit r13-8336-ge501a279fb4298c9b23637d573287e059b3b06c8 Author: Marek Polacek Date: Fri Feb 16 12:25:26 2024 -0500 c++: ICE with reinterpret_cast and switch [PR113545] Jason, this is the patch you proposed for PR113545. It looks very safe so I'm posting it here so that it's not forgotten. PR c++/113545 gcc/cp/ChangeLog: * constexpr.cc (cxx_eval_switch_expr): If the condition doesn't reduce to an INTEGER_CST, consider it non-constant. gcc/testsuite/ChangeLog: * g++.dg/cpp1y/constexpr-reinterpret3.C: New test. * g++.dg/cpp1y/constexpr-reinterpret4.C: New test. (cherry picked from commit 39d989022dd0eacf1a7b95b7b20621acbe717d70)
[Bug c++/113545] ICE in label_matches with constexpr function with switch-statement and converted (nonconstant, cast address) input
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113545 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Marek Polacek --- Fixed in 13+.
[Bug analyzer/113923] Segfault in gcc/gcc/tree-diagnostic.cc:265
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113923 --- Comment #5 from Antoni --- Created attachment 57438 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57438&action=edit GIMPLE for the Rust reproducer
[Bug analyzer/113923] Segfault in gcc/gcc/tree-diagnostic.cc:265
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113923 --- Comment #6 from Antoni --- Created attachment 57439 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57439&action=edit Rust reproducer
[Bug c++/111682] [14 regression] valgrind error in tsubst_template_decl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111682 --- Comment #2 from GCC Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:c95dc611a6203f0564722975acff4ad866b9c45e commit r14-9035-gc95dc611a6203f0564722975acff4ad866b9c45e Author: Patrick Palka Date: Fri Feb 16 12:44:27 2024 -0500 c++: add fixed testcase [PR111682] Fixed by the PR113612 fix r14-8960-g19ac327de421fe. PR c++/111682 gcc/testsuite/ChangeLog: * g++.dg/cpp1y/var-templ86.C: New test.
[Bug analyzer/113923] Segfault in gcc/gcc/tree-diagnostic.cc:265
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113923 --- Comment #7 from Antoni --- I don't know if this helps, but I added a small Rust reproducer that can trigger the segfault when compiled with rustc_codegen_gcc and the corresponding GIMPLE for this Rust reproducer.
[Bug c++/111682] [14 regression] valgrind error in tsubst_template_decl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111682 Patrick Palka changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=113612 Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Patrick Palka --- Incidentally fixed.
[Bug c++/113789] [13 Regression] ICE on P2266/C++23 `decltype(throw x)` where x is move-eligible parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113789
--- Comment #10 from Arthur O'Dwyer ---
FWIW, I think I agree with your analysis. To reiterate what you already said
(and I think GCC already gets the following snippet correct): in
X g (X x) try {
throw x;
} catch (...) {
return x;
}
the `throw x` copies but the `return x` moves. That is, `throw x` treats `x` as
an lvalue because it could be used again later (in the function-catch-block),
but `return x` treats it as an rvalue because it can't[*] be used again later.
[* — except if you sneakily use a captured reference within a destructor, but
C++ implicit move doesn't care — has never cared — about such sneaky uses]
[Bug c++/17000] parse error calling member template function of non-lvalue from within template class member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=17000 Marek Polacek changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED CC||mpolacek at gcc dot gnu.org --- Comment #12 from Marek Polacek --- We say 17000.C: In member function ‘void b::func()’: 17000.C:10:17: warning: expected ‘template’ keyword before dependent template name [-Wmissing-template-keyword] 10 | get_a().func2 (); | ^ | template and clang++ says 17000.C:10:17: error: use 'template' keyword to treat 'func2' as a dependent template name 10 | get_a().func2 (); | ^ | template I think we can close this.
[Bug c++/19073] cp_binding_level::names not returning all decls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19073 Marek Polacek changed: What|Removed |Added Resolution|--- |WORKSFORME CC||mpolacek at gcc dot gnu.org Status|NEW |RESOLVED --- Comment #13 from Marek Polacek --- It doesn't appear there's anything to do here.
[Bug c++/26278] ambiguous overload candidates list contains duplicates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26278
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment #7 from Marek Polacek ---
Still happens:
$ xg++ -c 26278.C
26278.C: In function ‘int main()’:
26278.C:14:5: error: ambiguous overload for ‘operator==’ (operand types are
‘coEnum’ and ‘X’)
14 | c == p;
| ~ ^~ ~
| ||
| |X
| coEnum
26278.C:14:5: note: candidate: ‘operator==(X, X)’ (built-in)
14 | c == p;
| ~~^~~~
26278.C:14:5: note: candidate: ‘operator==(int, int)’ (built-in)
26278.C:14:5: note: candidate: ‘operator==(X, X)’ (built-in)
26278.C:7:8: note: candidate: ‘bool coEnum::operator==(coEnum)
const [with e1 = A; e2 = X]’
7 | bool operator==(coEnum e) const { return 0; }
|^~~~
[Bug c++/29040] missing access control checks in subclasses for nested types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29040 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|NEW CC||mpolacek at gcc dot gnu.org Assignee|paolo.carlini at oracle dot com|unassigned at gcc dot gnu.org
[Bug c++/85908] Internal error with concepts and polymorphic lambdas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85908 Marek Polacek changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED CC||mpolacek at gcc dot gnu.org --- Comment #2 from Marek Polacek --- Compiles fine with -std=c++17 -fconcepts-ts. There's error: the ‘bool’ keyword is not allowed in a C++20 concept definition [-fpermissive] so I'm not adding the test.
[Bug c++/87331] if delete "node->operator_type = kADD; " will report "internal compiler error: Segmentation fault"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87331 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org Status|WAITING |RESOLVED Resolution|--- |INVALID
[Bug c++/67491] [meta-bug] concepts issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491 Bug 67491 depends on bug 87536, which changed state. Bug 87536 Summary: Illegal recursive concept leads to compiler ICE https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87536 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug c++/87536] Illegal recursive concept leads to compiler ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87536 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Marek Polacek --- I no longer get any crashes here: $ xg++ -c -std=c++20 87536.C 87536.C:2:6: error: C++20 concept definition syntax is ‘concept = ’ 2 | bool concept X = X; | ^~~ $ xg++ -c -std=c++17 87536.C -fconcepts-ts cc1plus: note: ‘-fconcepts-ts’ is deprecated and will be removed in GCC 15; please convert your code to C++20 concepts
[Bug c++/89336] internal compiler error when compiling a constexpr function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89336 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #10 from Marek Polacek --- Assuming fixed.
[Bug c++/55004] [meta-bug] constexpr issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55004 Bug 55004 depends on bug 89336, which changed state. Bug 89336 Summary: internal compiler error when compiling a constexpr function https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89336 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c++/111974] internal error: Segmentation fault on Ubuntu 23.10 (x86-64) - compiling RefPerSys
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111974 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #6 from Marek Polacek --- No testcase; please reopen when/if you find one.
[Bug analyzer/113923] Segfault in gcc/gcc/tree-diagnostic.cc:265
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113923
--- Comment #8 from Antoni ---
(In reply to David Malcolm from comment #2)
> inlined_call_event's ctor should probably assert that params
> tree apparent_callee_fndecl,
> tree apparent_caller_fndecl,
> are both non-NULL, which might catch the issue slightly early.
I added an assert and here's the stacktrace:
during IPA pass: analyzer
libgccjit.so: internal compiler error: : in inlined_call_event, at
analyzer/checker-event.h:578
0x73d4eafbf076 ana::inlined_call_event::inlined_call_event(unsigned int,
tree_node*, tree_node*, int, int)
../../../gcc/gcc/analyzer/checker-event.h:578
0x73d4eafbe7dd ana::checker_path::inject_any_inlined_call_events(ana::logger*)
../../../gcc/gcc/analyzer/checker-path.cc:319
0x73d4eafd415f
ana::diagnostic_manager::emit_saved_diagnostic(ana::exploded_graph const&,
ana::saved_diagnostic&)
../../../gcc/gcc/analyzer/diagnostic-manager.cc:1599
0x73d4eafd981d ana::dedupe_winners::emit_best(ana::diagnostic_manager*,
ana::exploded_graph const&)
../../../gcc/gcc/analyzer/diagnostic-manager.cc:1472
0x73d4eafd3dcb
ana::diagnostic_manager::emit_saved_diagnostics(ana::exploded_graph const&)
../../../gcc/gcc/analyzer/diagnostic-manager.cc:1524
0x73d4e9a0327a ana::impl_run_checkers(ana::logger*)
../../../gcc/gcc/analyzer/engine.cc:6226
0x73d4e9a03613 ana::run_checkers()
../../../gcc/gcc/analyzer/engine.cc:6300
0x73d4e99f484c execute
../../../gcc/gcc/analyzer/analyzer-pass.cc:87
I can also confirm that this is related to always_inline as there are no
segfaults when removing the #[inline(always)] in the following example (see
comment):
#![no_std]
#![allow(internal_features)]
#![feature(core_intrinsics, lang_items, start)]
#![feature(transparent_unions)]
use core::mem::ManuallyDrop;
#[panic_handler]
fn panic_handler(_: &core::panic::PanicInfo<'_>) -> ! {
core::intrinsics::abort();
}
#[lang="eh_personality"]
fn eh_personality(){}
#[derive(Clone, Copy)]
#[repr(transparent)]
pub union MaybeUninit {
uninit: (),
value: ManuallyDrop,
}
impl MaybeUninit {
// NOTE: there are no segfaults when removing the next line.
#[inline(always)]
pub const fn uninit() -> MaybeUninit {
MaybeUninit { uninit: () }
}
}
#[start]
fn main(_argc: isize, _argv: *const *const u8) -> isize {
let mut x = MaybeUninit::<&i32>::uninit();
0
}
