[Bug other/116253] RFE: support for nested diagnostics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116253 --- Comment #11 from David Malcolm --- An example of the nested diagnostics on Compiler Explorer: Trunk with -std=c++20 -fconcepts-diagnostics-depth=2 Text output (via -fdiagnostics-set-output=text:experimental-nesting=yes), showing indentation and bullet points: https://godbolt.org/z/xs4Gr6n6K SARIF output (via -fdiagnostics-format=sarif-stderr), showing nestingLevel properties: https://godbolt.org/z/zj17qKTee
[Bug ada/117956] New: Assert failure in precondition, sinfo-nodes.ads
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117956 Bug ID: 117956 Summary: Assert failure in precondition, sinfo-nodes.ads Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: simon at pushface dot org CC: dkm at gcc dot gnu.org Target Milestone: --- Created attachment 59820 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59820&action=edit Reproducer $ gnatmake -O0 -gnatA -gnatX -g -gnatwe -gnata -fPIC -feliminate-unused-debug-symbols -c -u -f libadalang-rewriting_implementation.adb gcc -c -O0 -gnatA -gnatX -g -gnatwe -gnata -fPIC -feliminate-unused-debug-symbols libadalang-rewriting_implementation.adb +===GNAT BUG DETECTED==+ | 15.0.0 20241201 (experimental) (x86_64-apple-darwin23) Assert_Failure failed precondition from sinfo-nodes.ads:4217| | Error detected at libadalang-rewriting_implementation.ads:262:41 | | Compiling libadalang-rewriting_implementation.adb| | Please submit a bug report; see https://gcc.gnu.org/bugs/ . | | Use a subject line meaningful to you and us to track the bug.| | Include the entire contents of this bug box in the report. | | Include the exact command that you entered. | | Also include sources listed below. | +==+ The source files (all 197 of them) are in the attachment. This also happens with aarch64-apple-darwin. Compiling without any switches doesn't trigger the error. I haven't checked which of the switches does. The switches are those used building ada_language_server v25.0.0.
[Bug target/117955] [15 Regression] GCC generate illegal riscv instruction `vsetvli zero,zero,e64,mf4,ta,ma` with -O2 and -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117955 --- Comment #3 from rvismith --- (In reply to Andrew Pinski from comment #1) > What version of qemu are you usirng? Thanks for your reply. I use qemu v9.1.0: ``` $ /home/emulator/qemu-9.1.0/build/qemu-riscv64 --version qemu-riscv64 version 9.1.0 Copyright (c) 2003-2024 Fabrice Bellard and the QEMU Project developers ``` I have tried the illegal instruction can be fixed by changing the instruction to `vsetvli zero,zero,e16,mf4,ta,ma`. `e64mf4` is illegal because `vlen` can be 128, and in this case the fraction of vector register cannot hold 64-bit elements (1/4 * 128 = 32 < 64). In the type system of rvv intrinsic (https://github.com/riscv-non-isa/rvv-intrinsic-doc/blob/main/doc/rvv-intrinsic-spec.adoc#type-system), there are also no 64mf4 types.
[Bug target/117953] [15 Regression] GCC miscompile rvv intrinsics at `-O2` and `-O3`, missing `csrwi` to modify `vxrm`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117953 --- Comment #1 from rvismith --- Here are results of array b I get (by gcc 15 + qemu 9.1.0): at -O0 (correct) >>> 0 2 5 7 10 12 15 17 20 22 at -O3 (rounding error) >>> 0 3 5 8 10 13 15 18 20 23
[Bug target/117955] [15 Regression] GCC generate illegal riscv instruction `vsetvli zero,zero,e64,mf4,ta,ma` with -O2 and -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117955 --- Comment #2 from Andrew Pinski --- >From my reading of the V 1.0 spec, `vsetvli zero,zero,e64,mf4,ta,ma` should be valid still.
[Bug target/117955] [15 Regression] GCC generate illegal riscv instruction `vsetvli zero,zero,e64,mf4,ta,ma` with -O2 and -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117955 --- Comment #1 from Andrew Pinski --- What version of qemu are you usirng?
[Bug tree-optimization/117935] [14/15 Regression] [[likely]] attribute is lost by phiopt1 in some cases since r14-203-ga2339e0fe9dbef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117935 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug tree-optimization/117950] vector extraction view convert not detected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117950 Richard Biener changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2024-12-08 --- Comment #1 from Richard Biener --- Confirmed (it's not loads). Likely would also happen with BIT_FIELD_REFs from non-vector objects (not sure how to easily build those). As enhancement arbitrary permutes could be handled on the vector source side by code generating as VEC_PERM + VIEW_CONVERT.
[Bug target/117953] [15 Regression] GCC miscompile rvv intrinsics at `-O2` and `-O3`, missing `csrwi` to modify `vxrm`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117953 Richard Biener changed: What|Removed |Added Target Milestone|--- |15.0 Keywords||wrong-code Target||riscv
[Bug tree-optimization/117954] [15 Regression] gcc.dg/tree-ssa/pr111456-1.c FAILs for non-LOGICAL_OP_NON_SHORT_CIRCUIT after r15-5646-gd1cf0d7a0f27fd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117954 --- Comment #3 from Richard Biener --- I can look to adjust the testcase (adding #pragma GCC unroll or --param logical-op-short-circuit=1) if nobody beats me to it.
[Bug target/117947] [14/15 Regression] GCC miscompile rvv intrinsics at `-O2` and `-O3`, use `vlenb` after an inappropriate `vsetvli`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117947 Richard Biener changed: What|Removed |Added Target||riscv Keywords||wrong-code Target Milestone|--- |14.3
[Bug target/117955] [15 Regression] GCC generate illegal riscv instruction `vsetvli zero,zero,e64,mf4,ta,ma` with -O2 and -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117955 Richard Biener changed: What|Removed |Added Target Milestone|--- |15.0 Keywords||wrong-code
[Bug target/117957] vectorization pesimises std::vector push/pop test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117957 --- Comment #4 from Andrew Pinski --- I suspect the issue is very similar (or the same) as PR 115777 .
[Bug target/117957] vectorization pesimises std::vector push/pop test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117957 --- Comment #3 from Andrew Pinski --- x86_64: 0 1 times scalar_store costs 12 in body _3 1 times scalar_store costs 12 in body 0 1 times unaligned_store (misalign -1) costs 12 in body node 0x46037c0 1 times vec_construct costs 10 in prologue /opt/compiler-explorer/gcc-trunk-20241208/include/c++/15.0.0/bits/new_allocator.h:191:4: note: Cost model analysis for part in loop 1: Vector cost: 22 Scalar cost: 24 aarch64: 0 1 times scalar_store costs 1 in body _3 1 times scalar_store costs 1 in body 0 1 times unaligned_store (misalign -1) costs 1 in body node 0x43b8ba8 1 times vec_construct costs 2 in prologue /opt/compiler-explorer/arm64/gcc-trunk-20241208/aarch64-unknown-linux-gnu/aarch64-unknown-linux-gnu/include/c++/15.0.0/bits/new_allocator.h:191:4: note: Cost model analysis for part in loop 1: Vector cost: 6 Scalar cost: 2
[Bug tree-optimization/117935] [14/15 Regression] [[likely]] attribute is lost by phiopt1 in some cases since r14-203-ga2339e0fe9dbef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117935 --- Comment #6 from Jason Merrill --- (In reply to Jan Hubicka from comment #5) > Note that propagation of branch probabilities from callee to caller > works only by kind of accident. I originally made branch prediction to > be done after early inlining since it makes some patterns branch > predictors looks for to appear. > > with the likely attribute it will only happen with early inlining and not > with late inlining, since there is a chicken-egg problem. To make good > inline decisions you already need profile to be computed. > So I am not sure we want to convince users these hints are going to be > used. Perhaps with always_inline functions. Why would this argument not apply equally to __builtin_expect? In both cases the program is expressing that b is probably true.
[Bug target/117957] vectorization pesimises std::vector push/pop test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117957
--- Comment #2 from Andrew Pinski ---
_32 = {0, _3};
MEM [(unsigned int *)_101 + -8B] = _32;
[Bug libstdc++/87502] Poor code generation for std::string("c-style string")
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87502 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=93558, ||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=91019 --- Comment #11 from Andrew Pinski --- (In reply to Jakub Jelinek from comment #10) > __builtin_memcpy (&D.35539.D.25336._M_local_buf, "abc", 3); > MEM[(char_type &)&D.35539 + 11] = 0; > change to > __builtin_memcpy (&D.35539.D.25336._M_local_buf, "abc", 4); > seems like something that the strlen pass could do. That is very similar to PR 92245 and PR 93558 and PR 91019.
[Bug tree-optimization/93558] missing mempcpy folding defeats strlen optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93558 Andrew Pinski changed: What|Removed |Added Depends on||91019 --- Comment #1 from Andrew Pinski --- Very similar to PR 91019. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91019 [Bug 91019] Missed optimization on sequential memcpy calls
[Bug c++/103827] function which takes an argument via (hidden) reference should assume the argument does not escape or is only read from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103827
Jan Hubicka changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org,
||jason at redhat dot com,
||jwakely at redhat dot com
--- Comment #1 from Jan Hubicka ---
Is this really invalid implementation of foo?
#include
int foo (const std::string s)
{
std::string *ptr = const_cast (&s);
*ptr = "I am long string over 15 chars";
return s.size();
}
similarly I am not 100% sure about non-escaping. Perhaps the destructor of the
type passed may check that pointer is somewhere in global memory?
[Bug tree-optimization/117958] New: g++.dg/tree-ssa/pr117123.C fails on aarch64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117958 Bug ID: 117958 Summary: g++.dg/tree-ssa/pr117123.C fails on aarch64-linux-gnu Product: gcc Version: 15.0 Status: UNCONFIRMED Keywords: missed-optimization, testsuite-fail Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: pinskia at gcc dot gnu.org Target Milestone: --- Target: aarch64-linux-gnu https://gcc.gnu.org/pipermail/gcc-testresults/2024-December/832336.html I can't figure out why there is a missed optimization though. Note adding `--param logical-op-non-short-circuit=0` or `--param logical-op-non-short-circuit=1` allows the ifs to be optimized.
[Bug libstdc++/87502] Poor code generation for std::string("c-style string")
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87502
Jan Hubicka changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
Ever confirmed|0 |1
Last reconfirmed||2024-12-08
Status|UNCONFIRMED |NEW
--- Comment #9 from Jan Hubicka ---
We currently do:
{
[local count: 1073741824]:
MEM[(struct basic_string *)&D.35505] ={v} {CLOBBER(bob)};
MEM[(struct _Alloc_hider *)&D.35505] ={v} {CLOBBER(bob)};
MEM[(struct _Alloc_hider *)&D.35505]._M_p = &D.35505.D.25336._M_local_buf;
__builtin_memcpy (&D.35505.D.25336._M_local_buf, "abc", 3);
D.35505._M_string_length = 3;
MEM[(char_type &)&D.35505 + 11] = 0;
foo (&D.35505);
[local count: 1073741824]:
_33 = D.35505._M_dataplus._M_p;
if (&D.35505.D.25336._M_local_buf == _33)
goto ; [18.09%]
else
goto ; [81.91%]
[local count: 879501928]:
_35 = D.35505.D.25336._M_allocated_capacity;
_36 = _35 + 1;
operator delete (_33, _36);
[local count: 1073741824]:
D.35505 ={v} {CLOBBER(eob)};
D.35505 ={v} {CLOBBER(eos)};
MEM[(struct basic_string *)&D.35539] ={v} {CLOBBER(bob)};
MEM[(struct _Alloc_hider *)&D.35539] ={v} {CLOBBER(bob)};
MEM[(struct _Alloc_hider *)&D.35539]._M_p = &D.35539.D.25336._M_local_buf;
__builtin_memcpy (&D.35539.D.25336._M_local_buf, "abc", 3);
D.35539._M_string_length = 3;
MEM[(char_type &)&D.35539 + 11] = 0;
foo (&D.35539);
[local count: 1073741824]:
_48 = D.35539._M_dataplus._M_p;
if (&D.35539.D.25336._M_local_buf == _48)
goto ; [18.09%]
else
goto ; [81.91%]
[local count: 879501928]:
_50 = D.35539.D.25336._M_allocated_capacity;
_51 = _50 + 1;
operator delete (_48, _51);
[local count: 1073741824]:
D.35539 ={v} {CLOBBER(eob)};
D.35539 ={v} {CLOBBER(eos)};
return;
[count: 0]:
:
std::__cxx11::basic_string::_M_dispose (&D.35505);
D.35505 ={v} {CLOBBER(eob)};
_52 = __builtin_eh_pointer (4);
__builtin_unwind_resume (_52);
[count: 0]:
:
std::__cxx11::basic_string::_M_dispose (&D.35539);
D.35539 ={v} {CLOBBER(eob)};
_37 = __builtin_eh_pointer (12);
__builtin_unwind_resume (_37);
}
so memcpy calls are still not updated to also copy the zero termination. I
think store merging may do this, but it is also quite specific pattern, so
perhaps handling it on libstdc++ side makes sense. The string constructor knows
source is zero terminated.
The reason why full destructor is inlined is that we do not know what foo is
doing and it may make the string bigger. "const" does not promise that the
callee does not modify the object.
So I think all we can hope for is merging memcpy with the extra write of 0.
Updating testcase:
#include
__attribute__ ((pure))
extern int foo (const std::string &);
int
bar ()
{
return foo ("abc") + foo (std::string("abc"));
}
here GCC knows object is read only and constructor is optimized away:
int bar ()
{
void * D.39810;
struct string D.35539;
const struct string D.35505;
int _5;
int _8;
int _9;
void * _14;
[local count: 1073741824]:
MEM[(struct basic_string *)&D.35505] ={v} {CLOBBER(bob)};
MEM[(struct _Alloc_hider *)&D.35505] ={v} {CLOBBER(bob)};
MEM[(struct _Alloc_hider *)&D.35505]._M_p = &D.35505.D.25336._M_local_buf;
__builtin_memcpy (&D.35505.D.25336._M_local_buf, "abc", 3);
D.35505._M_string_length = 3;
MEM[(char_type &)&D.35505 + 11] = 0;
_5 = foo (&D.35505);
[local count: 1073741824]:
MEM[(struct basic_string *)&D.35539] ={v} {CLOBBER(bob)};
MEM[(struct _Alloc_hider *)&D.35539] ={v} {CLOBBER(bob)};
MEM[(struct _Alloc_hider *)&D.35539]._M_p = &D.35539.D.25336._M_local_buf;
__builtin_memcpy (&D.35539.D.25336._M_local_buf, "abc", 3);
D.35539._M_string_length = 3;
MEM[(char_type &)&D.35539 + 11] = 0;
_8 = foo (&D.35539);
[local count: 1073741824]:
_9 = _5 + _8;
D.35539 ={v} {CLOBBER(eob)};
D.35539 ={v} {CLOBBER(eos)};
D.35505 ={v} {CLOBBER(eob)};
D.35505 ={v} {CLOBBER(eos)};
return _9;
[count: 0]:
:
std::__cxx11::basic_string::_M_dispose (&D.35539);
D.35539 ={v} {CLOBBER(eob)};
__builtin_eh_copy_values (4, 8);
[count: 0]:
:
D.35539 ={v} {CLOBBER(eos)};
std::__cxx11::basic_string::_M_dispose (&D.35505);
D.35505 ={v} {CLOBBER(eob)};
_14 = __builtin_eh_pointer (4);
__builtin_unwind_resume (_14);
}
_Z3barv:
.LFB1393:
.cfi_startproc
.cfi_personality 0,__gxx_personality_v0
.cfi_lsda 0,.LLSDA1393
pushl %ebp
.cfi_def_cfa_offset 8
.cfi_offset 5, -8
movl$25185, %edx
movl%esp, %ebp
.cfi_def_cfa_register 5
pushl %edi
pushl %esi
leal-64(%ebp), %eax
pushl %ebx
.cfi_offset 7, -12
.cfi_offset 6, -16
.cfi_offset 3, -20
leal-72(%ebp), %ebx
[Bug libstdc++/87502] Poor code generation for std::string("c-style string")
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87502 --- Comment #10 from Jakub Jelinek --- __builtin_memcpy (&D.35539.D.25336._M_local_buf, "abc", 3); MEM[(char_type &)&D.35539 + 11] = 0; change to __builtin_memcpy (&D.35539.D.25336._M_local_buf, "abc", 4); seems like something that the strlen pass could do.
[Bug target/117926] [14 Regression] emits 3dnow (MMX) instruction from autovectorized GIMPLE without emms at -O2 since r14-2786-gade30fad6669e5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117926 --- Comment #11 from GCC Commits --- The releases/gcc-14 branch has been updated by Uros Bizjak : https://gcc.gnu.org/g:c08ae0cf33e7e8339456a4a9ba0c494600eadcf3 commit r14-11073-gc08ae0cf33e7e8339456a4a9ba0c494600eadcf3 Author: Uros Bizjak Date: Fri Dec 6 16:59:16 2024 +0100 i386: Fix unwanted fwprop to 3dNOW! insn [PR117926] The compiler is able to forward propagate a partial vector V4SF instruction using XMM registers to a 3dNOW! V2SF instruction using MM registers. Prevent unwanted transformation by tagging 3dNOW! V2SF instructions using generic RTXes with "(unspec [(const_int 0)] UNSPEC_3DNOW)" tag. PR target/117926 gcc/ChangeLog: * config/i386/mmx.md (UNSPEC_3DNOW): New unspec. (mmx_addv2sf3): Tag insn with UNSPEC_3DNOW tag. (*mmx_addv2sf3): Ditto. (mmx_sub2vsf3): Ditto. (mmx_subrv2sf3): Ditto. (*mmx_subv2sf3): Ditto. (mmx_mulv2sf3): Ditto. (mmx_v2sf3): Ditto. (*mmx_v2sf3): Ditto. (mmx_ieee_v2sf3): Ditto. (mmx_eqv2sf3): Ditto. (*mmx_eqv2sf3): Ditto. (mmx_gtv2sf3): Ditto. (mmx_gev2sf3): Ditto. (mmx_fix_truncv2sfv2si2): Ditto. (mmx_floatv2siv2sf2): Ditto. gcc/testsuite/ChangeLog: * gcc.target/i386/pr117926.c: New test. (cherry picked from commit 1acc5cffbb04949a790d6e1a34a46ec71418a57b)
[Bug target/117957] [15 regression] vectorization pesimises std::vector push/pop test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117957 Sam James changed: What|Removed |Added Target Milestone|--- |15.0 Version|unknown |15.0
[Bug tree-optimization/117954] [15 Regression] gcc.dg/tree-ssa/pr111456-1.c FAILs for non-LOGICAL_OP_NON_SHORT_CIRCUIT after r15-5646-gd1cf0d7a0f27fd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117954 Hans-Peter Nilsson changed: What|Removed |Added URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2024-Decembe ||r/671144.html Keywords||patch --- Comment #4 from Hans-Peter Nilsson --- (In reply to Richard Biener from comment #3) > I can look to adjust the testcase (adding #pragma GCC unroll or --param > logical-op-short-circuit=1) if nobody beats me to it. I sent my suggested change (xfail and =0), to make it easier to spot.
[Bug tree-optimization/117935] [14/15 Regression] [[likely]] attribute is lost by phiopt1 in some cases since r14-203-ga2339e0fe9dbef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117935 --- Comment #7 from Andrew Pinski --- Looking into optimization passes that might ignore predictors, only phiopt will ignore them and maybe remove them. And that is what is happening here. Other passes will keep them around. Jump threading, etc. will duplicate them as needed. phiopt is the only pass that totally ignores them and throws them away. Phiopt does not look through __builtin_expect so for early phiopt (which is before inlining) should not do what it is doing for explicit user provided predictors which is what the patch is designed for. For early return predictors, those can be ignored here most of the time you will have `if (a) return b; else return c;` so both sides will have a return predictor on it which we want to ignore since both sides return. Though having an user predictor does mean it might change code generation overall but I doubt it will be that much because like the case above, jump threading will already have optimized away the one if statement. There is not much code out there with user provided predictors yet either so doing benchmarking to see the effect overall will be hard.
[Bug target/117957] [15 regression] vectorization pesimises std::vector push/pop test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117957 --- Comment #5 from Jan Hubicka --- > I suspect the issue is very similar (or the same) as PR 115777 . Yep, I think it store-to-load forwarding. The stack is organized in pairs that are likely written independetly and loaded together. Sadly I think it is relatively common pattern that stack values are reused quickly.
[Bug ipa/106568] -freorder-blocks-algorithm appears to causes a crash in stable code, no way to disable it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106568
--- Comment #27 from Andrew Pinski ---
[local count: 1073741824]:
[t.cc:102620:32 discrim 2] __builtin___ubsan_handle_builtin_unreachable
([t.cc:102620:32 discrim 2] &*.Lubsan_data109);
PK_FinalTemplate(const AsymmetricAlgorithm &algorithm)
{this->AccessKey().AssignFrom(algorithm.GetMaterial());}
column 32 points to beginging of algorithm.
[Bug libstdc++/87502] Poor code generation for std::string("c-style string")
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87502 --- Comment #12 from Jan Hubicka --- > (In reply to Jakub Jelinek from comment #10) > > __builtin_memcpy (&D.35539.D.25336._M_local_buf, "abc", 3); > > MEM[(char_type &)&D.35539 + 11] = 0; > > change to > > __builtin_memcpy (&D.35539.D.25336._M_local_buf, "abc", 4); > > seems like something that the strlen pass could do. > > That is very similar to PR 92245 and PR 93558 and PR 91019. I agree that this would be useful. However std::string has one extra invariant that the end pointer always points to 0. This lets us to optimize this even when source is not known constant string, but another std::string. This is probably something we can not easily expose to back-end. Technically we may do that using __builtin_unreachable but then we would need to pattern match it somewehre in the middle-end. It seems that updating std::string to use 0 termination in common scenarios is not too hard to do, so perhaps we could do both (extend strlen pass and optimize std::string implementation).
[Bug ipa/106568] -freorder-blocks-algorithm appears to causes a crash in stable code, no way to disable it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106568 Sam James changed: What|Removed |Added Keywords||needs-reduction --- Comment #26 from Sam James --- (In reply to Jonathan Wakely from comment #22) > Created attachment 57344 [details] > Gzipped preprocessed source Is this testcase standalone? It fails to link for me. If not, Jeffrey, could you try work on that please? (or at least a collection of .ii rather than needing to clone the repo, then you can work on inlining from there)
[Bug libstdc++/87502] Poor code generation for std::string("c-style string")
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87502 --- Comment #13 from M Welinder --- > The reason why full destructor is inlined is that we do not know what > foo is doing and it may make the string bigger. "const" does not promise > that the callee does not modify the object. :-( > So I think all we can hope for is merging memcpy with the extra write of 0. That's not actually clear. It would be reasonable to assume that foo isn't likely to change the string and have the inlined destructor for a string that was initialized as a short string like here do something like if (stuff_got_changed) [[unlikely]] obj.noninlined_full_destructor(); That would still work if someone were to naughtily cast away the "const", but they would pay the price in the form of two jumps and the function call.
[Bug c++/70769] function definition wrongfully allowed inside comma separated member declaration list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70769
Halalaluyafail3 changed:
What|Removed |Added
CC||luigighiron at gmail dot com
--- Comment #2 from Halalaluyafail3 ---
Here is another example of this bug:
struct S{
S()=delete,~S()=default;
S&operator=(const S&)=delete,&operator=(S&&)=default;
};
Multiple =delete and =default are accepted in the same declaration.
[Bug target/117946] ICE: maximum number of generated reload insns per insn achieved (90) with -O -favoid-store-forwarding -mavx10.1 -mprefer-avx128 --param=store-forwarding-max-distance=128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117946 Hongtao Liu changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |liuhongt at gcc dot gnu.org Status|NEW |ASSIGNED CC||liuhongt at gcc dot gnu.org --- Comment #3 from Hongtao Liu --- I'll take a look.
[Bug target/117946] ICE: maximum number of generated reload insns per insn achieved (90) with -O -favoid-store-forwarding -mavx10.1 -mprefer-avx128 --param=store-forwarding-max-distance=128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117946 --- Comment #6 from Hongtao Liu --- (In reply to Hongtao Liu from comment #5) > (In reply to Hongtao Liu from comment #4) > > The insn is generated by avoid_store_fowarding, and it is valid but failed > > reload > > Reload want to find a insn to move data from GPR to SSE_REGS but > *movti_internal only support INDEX_GPR16 to SSE_REGS, that confuses reload. No, jc should be GENERAL_REGS. (define_register_constraint "jc" 463 "TARGET_APX_EGPR && !TARGET_AVX ? GENERAL_GPR16 : GENERAL_REGS")
[Bug target/117946] ICE: maximum number of generated reload insns per insn achieved (90) with -O -favoid-store-forwarding -mavx10.1 -mprefer-avx128 --param=store-forwarding-max-distance=128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117946
--- Comment #4 from Hongtao Liu ---
The insn is generated by avoid_store_fowarding, and it is valid but failed
reload
170Store forwarding detected:
171From: (insn 24 23 25 2 (set (mem/c:SI (plus:DI (reg/f:DI 19 frame)
172(const_int -36 [0xffdc])) [0 S4 A32])
173(const_int 0 [0])) "test.c":12:3 discrim 1 96 {*movsi_internal}
174 (nil))
175From: (insn 23 22 24 2 (set (mem/c:SI (plus:DI (reg/f:DI 19 frame)
176(const_int -40 [0xffd8])) [0 S4 A64])
177(const_int 0 [0])) "test.c":12:3 discrim 1 96 {*movsi_internal}
178 (nil))
179From: (insn 22 21 23 2 (set (mem/c:SI (plus:DI (reg/f:DI 19 frame)
180(const_int -44 [0xffd4])) [0 S4 A32])
181(const_int 0 [0])) "test.c":12:3 discrim 1 96 {*movsi_internal}
182 (nil))
183From: (insn 21 160 22 2 (set (mem/c:SI (plus:DI (reg/f:DI 19 frame)
184(const_int -48 [0xffd0])) [0 S4 A128])
185(const_int 0 [0])) "test.c":12:3 discrim 1 96 {*movsi_internal}
186 (nil))
187To: (insn 37 36 38 2 (set (reg:TI 108)
188(mem/c:TI (plus:DI (reg/f:DI 19 frame)
189(const_int -48 [0xffd0])) [3 S16 A128]))
"test.c":12:3 discrim 1 94 {*movti_internal}
190 (nil))
[Bug fortran/116261] [15 regression] gfortran.dg/sizeof_6.f90 -O1 timeout since r15-2739-g4cb07a38233
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116261 --- Comment #15 from GCC Commits --- The master branch has been updated by Paul Thomas : https://gcc.gnu.org/g:ad94070689b3fadafca14c188c650aad6b8600e7 commit r15-6021-gad94070689b3fadafca14c188c650aad6b8600e7 Author: Paul Thomas Date: Mon Dec 9 07:32:22 2024 + Fortran: Fix testsuite regressions after r15-5897 [PR116261/PR117901] 2024-12-09 Paul Thomas gcc/fortran PR fortran/116261 * trans-array.cc (gfc_array_init_size): New arg 'explicit_ts', to suppress the use of the expr3 element size in the descriptor dtype. (gfc_array_allocate): New arg 'explicit_ts', used in call to gfc_array_init_size. * trans-array.h : Modify prototype for gfc_array_allocate for new bool argument. * trans-stmt.cc (gfc_trans_allocate): Set new argument if the typespec is explicit. gcc/testsuite/ PR fortran/117901 * gfortran.dg/class_transformational_1.f90: Temporary fix for ICE with some compile options by setting dummy arg of 'unlimited rebar' to be allocatable.
[Bug target/117946] ICE: maximum number of generated reload insns per insn achieved (90) with -O -favoid-store-forwarding -mavx10.1 -mprefer-avx128 --param=store-forwarding-max-distance=128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117946 --- Comment #5 from Hongtao Liu --- (In reply to Hongtao Liu from comment #4) > The insn is generated by avoid_store_fowarding, and it is valid but failed > reload Reload want to find a insn to move data from GPR to SSE_REGS but *movti_internal only support INDEX_GPR16 to SSE_REGS, that confuses reload.
[Bug sanitizer/117959] New: Address Sanitizer misses 'global-buffer-overflow' for a[-1]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117959
Bug ID: 117959
Summary: Address Sanitizer misses 'global-buffer-overflow' for
a[-1]
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: 652023330028 at smail dot nju.edu.cn
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
Target Milestone: ---
For the following code (https://godbolt.org/z/4zrPdT777), GCC's ASan seems to
have missed 'global-buffer-overflow' (a[-1] at line 4):
int a[1];
int b;
int main() {
b=a[-1];
}
There is no report from AddressSanitizer.
[Bug target/117946] ICE: maximum number of generated reload insns per insn achieved (90) with -O -favoid-store-forwarding -mavx10.1 -mprefer-avx128 --param=store-forwarding-max-distance=128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117946 Hongtao Liu changed: What|Removed |Added Assignee|liuhongt at gcc dot gnu.org|unassigned at gcc dot gnu.org Status|ASSIGNED|NEW --- Comment #9 from Hongtao Liu --- Looks like an RA issue to me.
[Bug target/117946] ICE: maximum number of generated reload insns per insn achieved (90) with -O -favoid-store-forwarding -mavx10.1 -mprefer-avx128 --param=store-forwarding-max-distance=128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117946
--- Comment #7 from Hongtao Liu ---
5024 Choosing alt 6 in insn 295: (0) ?jc (1) Yd {*movti_internal}
(sp_off=-128)
5025 Change to class INDEX_GPR16 for r273
5026 Creating newreg=274, assigning class ALL_SSE_REGS to r274
5027 295: r273:TI=r274:TI
5028Inserting insn reload before:
5029 296: r274:TI=r208:SI#0
Why class is changed to INDEX_GPR16 for r273
[Bug target/117946] ICE: maximum number of generated reload insns per insn achieved (90) with -O -favoid-store-forwarding -mavx10.1 -mprefer-avx128 --param=store-forwarding-max-distance=128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117946 --- Comment #8 from Hongtao Liu --- > Why class is changed to INDEX_GPR16 for r273 Note with -mapxf, ICE disappears
[Bug fortran/117901] [ 15 regression] class_transformational_1.f90 with -O3 and -fcheck=bounds gives ICE in make_ssa_name_fn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117901 --- Comment #6 from GCC Commits --- The master branch has been updated by Paul Thomas : https://gcc.gnu.org/g:ad94070689b3fadafca14c188c650aad6b8600e7 commit r15-6021-gad94070689b3fadafca14c188c650aad6b8600e7 Author: Paul Thomas Date: Mon Dec 9 07:32:22 2024 + Fortran: Fix testsuite regressions after r15-5897 [PR116261/PR117901] 2024-12-09 Paul Thomas gcc/fortran PR fortran/116261 * trans-array.cc (gfc_array_init_size): New arg 'explicit_ts', to suppress the use of the expr3 element size in the descriptor dtype. (gfc_array_allocate): New arg 'explicit_ts', used in call to gfc_array_init_size. * trans-array.h : Modify prototype for gfc_array_allocate for new bool argument. * trans-stmt.cc (gfc_trans_allocate): Set new argument if the typespec is explicit. gcc/testsuite/ PR fortran/117901 * gfortran.dg/class_transformational_1.f90: Temporary fix for ICE with some compile options by setting dummy arg of 'unlimited rebar' to be allocatable.
[Bug rtl-optimization/117248] gcc/libgcc/libgcc2.h:232:25: internal compiler error: Arithmetic exception
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117248 --- Comment #17 from John David Anglin --- The original problem on hppa64-hp-hpux11.11 is fixed. The related problem on linux reported in comments 5 and 6 is also fixed. Only the testsuite fail reported in comment 16 remains.
[Bug rtl-optimization/117951] FAIL: 20_util/variant/run.cc -std=gnu++17 (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117951 --- Comment #2 from John David Anglin --- Similar fails: FAIL: std/ranges/cartesian_product/1.cc -std=gnu++23 (test for excess errors) FAIL: std/ranges/cartesian_product/1.cc -std=gnu++26 (test for excess errors)
[Bug tree-optimization/117935] [14/15 Regression] [[likely]] attribute is lost by phiopt1 in some cases since r14-203-ga2339e0fe9dbef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117935 --- Comment #5 from Jan Hubicka --- Note that propagation of branch probabilities from callee to caller works only by kind of accident. I originally made branch prediction to be done after early inlining since it makes some patterns branch predictors looks for to appear. with the likely attribute it will only happen with early inlinng and not with late inlining, since there is a chicken-egg problem. To make good inline decisions you already need profile to be computed. So I am not sure we want to convince users these hints are going to be used. Pehraps with allways_inline functions.
[Bug tree-optimization/117957] New: vectorization pesimises std::vector push/pop test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117957
Bug ID: 117957
Summary: vectorization pesimises std::vector push/pop test
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: hubicka at gcc dot gnu.org
Target Milestone: ---
my synthetic push/pop minibenchmark regressed due to vectorization:
jh@ryzen3:~> cat t.C
#include
typedef unsigned int uint32_t;
std::pair pair;
void
test()
{
std::vector> stack;
stack.push_back (pair);
while (!stack.empty()) {
std::pair cur = stack.back();
stack.pop_back();
if (!cur.first)
{
cur.second++;
stack.push_back (cur);
}
if (cur.second > 1)
break;
}
}
int
main()
{
for (int i = 0; i < 1; i++)
test();
}
jh@ryzen3:~> ~/trunk-install2/bin/g++ -O3 t.C ; time ./a.out
real0m0.250s
user0m0.250s
sys 0m0.000s
jh@ryzen3:~> ~/trunk-install2/bin/g++ -O3 t.C -fno-tree-vectorize ; time
./a.out
real0m0.044s
user0m0.044s
sys 0m0.000s
This is regression since gcc14
jh@ryzen3:~> g++ -O3 t.C ; time ./a.out
real0m0.044s
user0m0.044s
sys 0m0.000s
jh@ryzen3:~> g++ --version
g++ (SUSE Linux) 14.2.1 20241007 [revision
4af44f2cf7d281f3e4f3957efce10e8b2ccb2ad3]
Copyright (C) 2024 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.
with clang I get 0.066s.
perf shows:
Percent│ nop ▒
│ 30:┌─→add $0x1,%ebx ▒
0.00 ││ cmp %rsi,%rdx ▒
││↓ je90 ▒
││ movdqa%xmm1,%xmm0 ▒
││ movd %ebx,%xmm2 ▒
8.23 ││ punpckldq %xmm2,%xmm0 ◆
24.84 ││ movq %xmm0,-0x8(%rax)▒
│ 49:│ cmp $0x2710,%ebx▒
││↓ ja73 ▒
│ 51:│ cmp %rbp,%rax ▒
││↓ je150 ▒
│ 5a:│ mov -0x8(%rax),%ecx ▒
58.52 ││ mov -0x4(%rax),%ebx ▒
0.01 ││ lea -0x8(%rax),%rdx ▒
│├──test %ecx,%ecx ▒
8.39 │└──je30 ▒
[Bug ada/117956] Assert failure in precondition, sinfo-nodes.ads
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117956 --- Comment #1 from simon at pushface dot org --- It’s the -gnatX.
[Bug target/117957] vectorization pesimises std::vector push/pop test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117957 Andrew Pinski changed: What|Removed |Added Component|tree-optimization |target Keywords||missed-optimization --- Comment #1 from Andrew Pinski --- I suspect this is cost model issue.
