[Bug middle-end/109258] [13 Regression] go.test/test/fixedbugs/bug207.go ICEs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109258 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |13.0
[Bug middle-end/109258] New: [13 Regression] go.test/test/fixedbugs/bug207.go ICEs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109258 Bug ID: 109258 Summary: [13 Regression] go.test/test/fixedbugs/bug207.go ICEs Product: gcc Version: 13.0 Status: UNCONFIRMED Keywords: ice-on-valid-code, testsuite-fail Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: pinskia at gcc dot gnu.org Target Milestone: --- Target: x86_64-linux-gnu FAIL: go.test/test/fixedbugs/bug207.go, -O2 -g (internal compiler error: in emit_move_insn, at expr.cc:4224) Started after r13-6667-g1526ecd739f and at or before r13-6696-gcd394c542b7 .
[Bug target/109257] New: `-masm=intel` generates weird syntax for indirect jumps
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109257
Bug ID: 109257
Summary: `-masm=intel` generates weird syntax for indirect
jumps
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: lh_mouse at 126 dot com
Target Milestone: ---
https://gcc.godbolt.org/z/Tc8v5qfv1
a proper tail call:
```
extern int (*foo)(int, int);
int ptc_to_foo(int a, int b) { return foo(a, b); }
```
GCC compiles it to this:
```
ptc_to_foo:
jmp [QWORD PTR foo[rip]]
```
The outer pair of brackets are superfluous.
The `foo[rip]` part is also invalid but it's a common issue for all addressing
operands for x86_64, not specifically about jmp.
[Bug driver/108865] gcc on Windows fails with Unicode path to source file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108865 --- Comment #26 from LIU Hao --- (In reply to Costas Argyris from comment #23) > Created attachment 54730 [details] > Make symbol optional > > Could you please try this patch? Works for me. I have checked that cpp.exe, cc1.exe, cc1plus.exe all contain the desired UTF-8 manifest in their resources.
[Bug tree-optimization/98350] Reassociation breaks FMA chains
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98350 --- Comment #4 from Di Zhao --- I've found the same problem with gcc-12 and gcc-13 (trunk). By improving the workaround in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84114, more FMAs can be inserted for vector mode. For the testcase in this tracker, 6 "fmla" can be generated with attachment 54735. The compile option I used is "-Ofast -mcpu=neoverse-n1".
[Bug target/109256] Error: failed to link 'linked_maps2.bpf.o': Cannot allocate memory (12)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109256 --- Comment #2 from James Hilliard --- (In reply to Andrew Pinski from comment #1) > Even a bad input should cause an error reported rather than a double free. > So you should at least report it to libbpf too libbpf bug report: https://lore.kernel.org/bpf/cadvtj4o7zwuikkwntwfq0o_aax+46t_+ca9gvwmydwdrttg...@mail.gmail.com/
[Bug tree-optimization/98350] Reassociation breaks FMA chains
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98350 Di Zhao changed: What|Removed |Added CC||dizhao at os dot amperecomputing.c ||om --- Comment #3 from Di Zhao --- Created attachment 54735 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54735=edit move-FLOAT_MODE_P-ahead-to-insert-more-FMAs
[Bug target/109256] Error: failed to link 'linked_maps2.bpf.o': Cannot allocate memory (12)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109256 --- Comment #1 from Andrew Pinski --- Even a bad input should cause an error reported rather than a double free. So you should at least report it to libbpf too
[Bug target/109256] New: Error: failed to link 'linked_maps2.bpf.o': Cannot allocate memory (12)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109256 Bug ID: 109256 Summary: Error: failed to link 'linked_maps2.bpf.o': Cannot allocate memory (12) Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: james.hilliard1 at gmail dot com Target Milestone: --- I'm seeing this gen object error which does not occur in llvm for a bpf test(which uses both linked_maps1.c and linked_maps2.c) in bpf-next. It seems this is triggering a double free in libbpf, not entirely clear if this is a gcc issue or libbpf issue. GCC gen object failure: ==2125110== Command: /home/buildroot/bpf-next/tools/testing/selftests/bpf/tools/sbin/bpftool --debug gen object /home/buildroot/bpf-next/tools/testing/selftests/bpf/bpf_gcc/linked_maps.linked1.o /home/buildroot/bpf-next/tools/testing/selftests/bpf/bpf_gcc/linked_maps1.bpf.o /home/buildroot/bpf-next/tools/testing/selftests/bpf/bpf_gcc/linked_maps2.bpf.o ==2125110== libbpf: linker: adding object file '/home/buildroot/bpf-next/tools/testing/selftests/bpf/bpf_gcc/linked_maps1.bpf.o'... libbpf: linker: adding object file '/home/buildroot/bpf-next/tools/testing/selftests/bpf/bpf_gcc/linked_maps2.bpf.o'... Error: failed to link '/home/buildroot/bpf-next/tools/testing/selftests/bpf/bpf_gcc/linked_maps2.bpf.o': Cannot allocate memory (12) ==2125110== Invalid free() / delete / delete[] / realloc() ==2125110==at 0x484B0C4: free (vg_replace_malloc.c:884) ==2125110==by 0x17F8AB: bpf_linker__free (linker.c:204) ==2125110==by 0x12833C: do_object (gen.c:1608) ==2125110==by 0x12CDAB: cmd_select (main.c:206) ==2125110==by 0x129B53: do_gen (gen.c:2332) ==2125110==by 0x12CDAB: cmd_select (main.c:206) ==2125110==by 0x12DB9E: main (main.c:539) ==2125110== Address 0xda4b420 is 0 bytes after a block of size 0 free'd ==2125110==at 0x484B027: free (vg_replace_malloc.c:883) ==2125110==by 0x484D6F8: realloc (vg_replace_malloc.c:1451) ==2125110==by 0x181FA3: extend_sec (linker.c:1117) ==2125110==by 0x182326: linker_append_sec_data (linker.c:1201) ==2125110==by 0x1803DC: bpf_linker__add_file (linker.c:453) ==2125110==by 0x12829E: do_object (gen.c:1593) ==2125110==by 0x12CDAB: cmd_select (main.c:206) ==2125110==by 0x129B53: do_gen (gen.c:2332) ==2125110==by 0x12CDAB: cmd_select (main.c:206) ==2125110==by 0x12DB9E: main (main.c:539) ==2125110== Block was alloc'd at ==2125110==at 0x484876A: malloc (vg_replace_malloc.c:392) ==2125110==by 0x484D6EB: realloc (vg_replace_malloc.c:1451) ==2125110==by 0x181FA3: extend_sec (linker.c:1117) ==2125110==by 0x182326: linker_append_sec_data (linker.c:1201) ==2125110==by 0x1803DC: bpf_linker__add_file (linker.c:453) ==2125110==by 0x12829E: do_object (gen.c:1593) ==2125110==by 0x12CDAB: cmd_select (main.c:206) ==2125110==by 0x129B53: do_gen (gen.c:2332) ==2125110==by 0x12CDAB: cmd_select (main.c:206) ==2125110==by 0x12DB9E: main (main.c:539)
[Bug target/109255] New: libbpf: global 'input_data1': section mismatch 4 vs 5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109255 Bug ID: 109255 Summary: libbpf: global 'input_data1': section mismatch 4 vs 5 Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: james.hilliard1 at gmail dot com Target Milestone: --- I'm seeing this gen object error which does not occur in llvm for a bpf test(which uses both linked_vars1.c and linked_vars2.c) in bpf-next. GCC gen object failure: $ /home/buildroot/bpf-next/tools/testing/selftests/bpf/tools/sbin/bpftool --debug gen object /home/buildroot/bpf-next/tools/testing/selftests/bpf/bpf_gcc/linked_vars.linked1.o /home/buildroot/bpf-next/tools/testing/selftests/bpf/bpf_gcc/linked_vars1.bpf.o /home/buildroot/bpf-next/tools/testing/selftests/bpf/bpf_gcc/linked_vars2.bpf.o libbpf: linker: adding object file '/home/buildroot/bpf-next/tools/testing/selftests/bpf/bpf_gcc/linked_vars1.bpf.o'... libbpf: linker: adding object file '/home/buildroot/bpf-next/tools/testing/selftests/bpf/bpf_gcc/linked_vars2.bpf.o'... libbpf: global 'input_data1': section mismatch 4 vs 5 Error: failed to link '/home/buildroot/bpf-next/tools/testing/selftests/bpf/bpf_gcc/linked_vars2.bpf.o': Invalid argument (22) In broken GCC linked_vars1.bpf.o BTF I see: [6900] VAR 'input_data1' type_id=8, linkage=global [7129] DATASEC '.data' size=0 vlen=2 type_id=7020 offset=0 size=4 (VAR 'input_data_weak') type_id=6900 offset=0 size=4 (VAR 'input_data1') In broken GCC linked_vars2.bpf.o BTF I see: [7068] VAR 'input_data1' type_id=8, linkage=extern [7126] DATASEC '.bss' size=0 vlen=8 type_id=7068 offset=0 size=4 (VAR 'input_data1') type_id=6921 offset=0 size=4 (VAR 'input_bss1') type_id=6912 offset=0 size=4 (VAR 'output_sink2') type_id=7092 offset=0 size=4 (VAR 'output_rodata2') type_id=7006 offset=0 size=4 (VAR 'output_data2') type_id=6899 offset=0 size=4 (VAR 'output_bss2') type_id=6919 offset=0 size=4 (VAR 'input_bss_weak') type_id=6979 offset=0 size=4 (VAR 'input_bss2') In working LLVM linked_vars1.bpf.o BTF I see: [8] VAR 'input_data1' type_id=4, linkage=global [36] DATASEC '.data' size=0 vlen=2 type_id=8 offset=0 size=4 (VAR 'input_data1') type_id=12 offset=0 size=4 (VAR 'input_data_weak') In working LLVM linked_vars2.bpf.o BTF I see: [31] VAR 'input_data1' type_id=4, linkage=extern In working LLVM linked_vars.linked1.o(output of gen object) BTF I see: [8] VAR 'input_data1' type_id=4, linkage=global [42] DATASEC '.data' size=16 vlen=3 type_id=8 offset=0 size=4 (VAR 'input_data1') type_id=12 offset=4 size=4 (VAR 'input_data_weak') type_id=32 offset=8 size=4 (VAR 'input_data2')
[Bug target/109228] warning: implicit declaration of function '__riscv_vlenb'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109228 Kito Cheng changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #5 from Kito Cheng --- Fixed!
[Bug c++/109241] [13 Regression] ICE Segmentation fault for statement expression with a local type inside inside a generic lambda inside a generic lambda since r13-6722-gb323f52ccf966800
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109241 --- Comment #2 from CVS Commits --- The trunk branch has been updated by Jason Merrill : https://gcc.gnu.org/g:4872e46e080c6695dfe1f9dc9db26b4703bc348c commit r13-6824-g4872e46e080c6695dfe1f9dc9db26b4703bc348c Author: Jason Merrill Date: Wed Mar 22 16:11:47 2023 -0400 c++: local class in nested generic lambda [PR109241] In this testcase, the tree walk to look for bare parameter packs was confused by finding a type with no TREE_BINFO. But it should be fine that it's unset; we already checked for unexpanded packs at parse time. I also tried doing the partial instantiation of the local class, which is probably the long-term direction we want to go, but for stage 4 let's go with this safer change. PR c++/109241 gcc/cp/ChangeLog: * pt.cc (find_parameter_packs_r): Handle null TREE_BINFO. gcc/testsuite/ChangeLog: * g++.dg/cpp1y/lambda-generic-local-class2.C: New test.
[Bug target/109244] internal compiler error: in setup_preferred_alternate_classes_for_new_pseudos, at ira.cc:2892
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109244 Kito Cheng changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #6 from Kito Cheng --- Fixed, let us know if you got any issue on compiling or testing highway!
[Bug target/109244] internal compiler error: in setup_preferred_alternate_classes_for_new_pseudos, at ira.cc:2892
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109244 --- Comment #5 from CVS Commits --- The master branch has been updated by Kito Cheng : https://gcc.gnu.org/g:cd0c433e5faba9a18f64881cd761a53a530aa798 commit r13-6823-gcd0c433e5faba9a18f64881cd761a53a530aa798 Author: Ju-Zhe Zhong Date: Wed Mar 22 10:49:56 2023 +0800 RISC-V: Fix LRA issue for LMUL < 1 vector spillings [PR109244] In order to decrease the memory traffic, we don't use whole register load/store for the LMUL less than 1 and mask mode, so those case will require one extra general purpose register for setting up VL register, but it's not allowed during LRA process, so we defined few special move patterns used for LRA, which will defer the expansion after LRA. gcc/ChangeLog: PR target/109244 * config/riscv/riscv-protos.h (emit_vlmax_vsetvl): Define as global. (emit_vlmax_op): Ditto. * config/riscv/riscv-v.cc (get_sew): New function. (emit_vlmax_vsetvl): Adapt function. (emit_pred_op): Ditto. (emit_vlmax_op): Ditto. (emit_nonvlmax_op): Ditto. (legitimize_move): Fix LRA ICE. (gen_no_side_effects_vsetvl_rtx): Adapt function. * config/riscv/vector.md (@mov_lra): New pattern. (@mov_lra): Ditto. (*mov_lra): Ditto. (*mov_lra): Ditto. gcc/testsuite/ChangeLog: PR target/109244 * g++.target/riscv/rvv/base/pr109244.C: New test. * gcc.target/riscv/rvv/base/binop_vv_constraint-4.c: Adapt testcase. * gcc.target/riscv/rvv/base/binop_vv_constraint-6.c: Ditto. * gcc.target/riscv/rvv/base/binop_vx_constraint-127.c: Ditto. * gcc.target/riscv/rvv/base/spill-1.c: Ditto. * gcc.target/riscv/rvv/base/spill-2.c: Ditto. * gcc.target/riscv/rvv/base/spill-3.c: Ditto. * gcc.target/riscv/rvv/base/spill-5.c: Ditto. * gcc.target/riscv/rvv/base/spill-7.c: Ditto. * g++.target/riscv/rvv/base/bug-18.C: New test. * gcc.target/riscv/rvv/base/merge_constraint-3.c: New test. * gcc.target/riscv/rvv/base/merge_constraint-4.c: New test.
[Bug target/109254] Bug in gcc (13.0.1) support for ARM SVE, which randomly modifies the prediction register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109254 --- Comment #1 from Andrew Pinski --- -fno-rename-registers is the workaround
[Bug target/109228] warning: implicit declaration of function '__riscv_vlenb'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109228 --- Comment #4 from CVS Commits --- The master branch has been updated by Kito Cheng : https://gcc.gnu.org/g:116a8678840f9f52ec14639ff07e302a8c429f32 commit r13-6822-g116a8678840f9f52ec14639ff07e302a8c429f32 Author: Ju-Zhe Zhong Date: Wed Mar 22 13:06:23 2023 +0800 RISC-V: Implement __riscv_vlenb PR109228 __riscv_vlenb is defined in RVV intrinsic spec 0.11 and used in some project like google/highway. gcc/ChangeLog: PR target/109228 * config/riscv/riscv-vector-builtins-bases.cc (class vlenb): Add __riscv_vlenb support. (BASE): Ditto. * config/riscv/riscv-vector-builtins-bases.h: Ditto. * config/riscv/riscv-vector-builtins-functions.def (vlenb): Ditto. * config/riscv/riscv-vector-builtins-shapes.cc (struct vlenb_def): Ditto. (SHAPE): Ditto. * config/riscv/riscv-vector-builtins-shapes.h: Ditto. * config/riscv/riscv-vector-builtins.cc: Ditto. gcc/testsuite/ChangeLog: PR target/109228 * gcc.target/riscv/rvv/base/vlenb-1.c: New test.
[Bug target/109254] New: Bug in gcc (13.0.1) support for ARM SVE, which randomly modifies the prediction register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109254
Bug ID: 109254
Summary: Bug in gcc (13.0.1) support for ARM SVE, which
randomly modifies the prediction register
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: wumingchuan1992 at foxmail dot com
Target Milestone: ---
func_demo.c
#include
#include
svfloat32_t func_demo(svfloat32_t x, svfloat32_t y, svbool_t pg)
{
svfloat32_t z = svadd_f32_x(pg, x, svdup_f32(0x1.800fep19f));
svbool_t cmp = svcmplt_f32(pg, z, svdup_f32(0.0f));
svfloat32_t zM1 = svsub_f32_x(pg, z, svdup_n_f32(1.0f));
z = svsel_f32(cmp, zM1, z);
svfloat32_t sum = svadd_f32_x(pg, z, y);
return sum;
}
Run gcc(10.3.0 and 13.0.1 20230314) with the following command:
$ gcc -std=c99 -O2 -funroll-loops -march=armv8.3-a+fp+sve -o func_demo.o -c
func_demo.c
After objdump func_demo.o, the result is as follows:
:
0: 9000 adrp x0, 0
4: 2518e3e1 ptrue p1.b
8: 9101 add x1, x0, #0x0
c: 8540c422 ld1rw {z2.s}, p1/z, [x1]
10: 65808002 fadd z2.s, p0/m, z2.s, z0.s
14: 65912040 fcmlt p0.s, p0/z, z2.s, #0.0
18: 0420bc43 movprfx z3, z2
1c: 65998023 fsub z3.s, p0/m, z3.s, #1.0
20: 05a2c060 sel z0.s, p0, z3.s, z2.s
24: 65808020 fadd z0.s, p0/m, z0.s, z1.s
28: d65f03c0 ret
In the compilation of the 14 lines, the fcmlt operation covers the value of the
p0 register, resulting in subsequent fsubs and fadd using the wrong prediction
register. This results in an error in the program result.
For comparison, use llvm for compilation：
clang -std=c99 -O2 -funroll-loops -march=armv8.3-a+fp+sve -o func_demo1.o -c
func_demo.c
the result is as follows:
:
0: 5280fe08 mov w8, #0x7f0 // #2032
4: 72a92808 movk w8, #0x4940, lsl #16
8: 05a03902 mov z2.s, w8
c: 65808040 fadd z0.s, p0/m, z0.s, z2.s
10: 04603002 mov z2.d, z0.d
14: 65912001 fcmlt p1.s, p0/z, z0.s, #0.0
18: 65998022 fsub z2.s, p0/m, z2.s, #1.0
1c: 05a0c440 mov z0.s, p1/m, z2.s
20: 65808020 fadd z0.s, p0/m, z0.s, z1.s
24: d65f03c0 ret
Line 14 is correct.
Any suggestions to proceed?
[Bug debug/109253] New: libbpf: failed to find BTF info for global/extern symbol '__divdi3'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109253 Bug ID: 109253 Summary: libbpf: failed to find BTF info for global/extern symbol '__divdi3' Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug Assignee: unassigned at gcc dot gnu.org Reporter: james.hilliard1 at gmail dot com Target Milestone: --- I'm seeing this gen object error which does not occur in llvm for a bpf test(tcp_ca_write_sk_pacing.c) in bpf-next. GCC gen object failure: $ /home/buildroot/bpf-next/tools/testing/selftests/bpf/tools/sbin/bpftool --debug gen object /home/buildroot/bpf-next/tools/testing/selftests/bpf/bpf_gcc/tcp_ca_write_sk_pacing.bpf.linked1.o /home/buildroot/bpf-next/tools/testing/selftests/bpf/bpf_gcc/tcp_ca_write_sk_pacing.bpf.o libbpf: linker: adding object file '/home/buildroot/bpf-next/tools/testing/selftests/bpf/bpf_gcc/tcp_ca_write_sk_pacing.bpf.o'... libbpf: failed to find BTF info for global/extern symbol '__divdi3' Error: failed to link '/home/buildroot/bpf-next/tools/testing/selftests/bpf/bpf_gcc/tcp_ca_write_sk_pacing.bpf.o': No such file or directory (2)
[Bug c/84900] [10/11/12/13 Regression] cast of compound literal does not cause the code to become a non-lvalue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84900 --- Comment #8 from Andrew Pinski --- Obvious one line fix: ``` diff --git a/gcc/fold-const.cc b/gcc/fold-const.cc index 02a24c5fe65..5b9982e3651 100644 --- a/gcc/fold-const.cc +++ b/gcc/fold-const.cc @@ -2646,6 +2646,7 @@ maybe_lvalue_p (const_tree x) case LABEL_DECL: case FUNCTION_DECL: case SSA_NAME: + case COMPOUND_LITERAL_EXPR: case COMPONENT_REF: case MEM_REF: ``` Basically when COMPOUND_LITERAL_EXPR was made a non-language specific tree, the check inside maybe_lvalue_p dealing with language specific trees became ignored and we just need to mark COMPOUND_LITERAL_EXPR as being a maybe_lvalue now.
[Bug c/84900] [10/11/12/13 Regression] cast of compound literal does not cause the code to become a non-lvalue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84900 Andrew Pinski changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org --- Comment #7 from Andrew Pinski --- Caused by r0-92187-g2ec5deb5c3146c .
[Bug target/109244] internal compiler error: in setup_preferred_alternate_classes_for_new_pseudos, at ira.cc:2892
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109244
--- Comment #4 from Kito Cheng ---
Gonna commit the fix soon, and following code is the reduced case which is
reduced from your attachment.
Reduced case (reduced by creduce)
typedef int a;
using c = float;
template < typename > using e = int;
#pragma riscv intrinsic "vector"
template < typename, int, int f > struct aa {
using g = int;
template < typename > static constexpr int h() { return f; }
template < typename i > using ab = aa< i, 0, h< i >() >;
};
template < int f > struct p { using j = aa< float, 6, f >; };
template < int f > struct k { using j = typename p< f >::j; };
template < typename, int f > using ac = typename k< f >::j;
template < class ad > using l = typename ad::g;
template < class g, class ad > using ab = typename ad::ab< g >;
template < class ad > using ae = ab< e< ad >, ad >;
template < int m > vuint32mf2_t ai(aa< a, m, -1 >, a aj) {
return __riscv_vmv_v_x_u32mf2(aj, 0);
}
template < int m > vfloat32mf2_t ai(aa< c, m, -1 >, c);
template < class ad > using ak = decltype(ai(ad(), l< ad >()));
template < class ad > ak< ad > al(ad d) {
ae< decltype(d) > am;
return an(d, ai(am, 0));
}
template < typename g, int m > vuint8mf2_t ao(aa< g, m, -1 >, vuint32mf2_t n) {
return __riscv_vreinterpret_v_u32mf2_u8mf2(n);
}
template < int m > vuint32mf2_t ap(aa< a, m, -1 >, vuint8mf2_t n) {
return __riscv_vreinterpret_v_u8mf2_u32mf2(n);
}
template < typename g, int m > vuint8mf2_t ao(aa< g, m, -1 >, vfloat32mf2_t n)
{
return __riscv_vreinterpret_v_u32mf2_u8mf2(
__riscv_vreinterpret_v_f32mf2_u32mf2(n));
}
template < int m > vfloat32mf2_t ap(aa< c, m, -1 >, vuint8mf2_t);
template < class ad, class aq > ak< ad > an(ad d, aq n) {
return ap(d, ao(d, n));
}
vbool64_t av(vuint32mf2_t, vuint32mf2_t);
template < class ad > bool ba(ad, vbool64_t);
template < class ad > using bb = decltype(al(ad()));
template < typename g > using be = ac< g, -1 >;
struct bf {
template < class ad > bool bh(ad, bb< ad > bi) {
ae< ad > am;
return ba(am, av(an(am, bi), al(am)));
}
};
int bo;
template < class ad, class bl, typename g > void o(ad d, bl bn, g) {
bb< ad > bq = al(d);
for (; bo;) {
int br = bn.bh(d, bq);
if (__builtin_expect(br, 0))
for (;;)
;
}
}
template < class ad, class bl, typename g > void bs(ad d, bl bn, g) {
g bu;
o(d, bn, bu);
}
template < class ad, class bl, typename g >
void bv(ad d, bl bn, g *, int, g *bt) {
bs(d, bn, bt);
}
float by;
int bz;
float ca;
void b() {
be< float > d;
bf bn;
bv(d, bn, , bz, );
}
[Bug c/66341] Some casts wrongly produce a lvalue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66341 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |6.0
[Bug driver/108865] gcc on Windows fails with Unicode path to source file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108865 --- Comment #25 from Costas Argyris --- Some more specific info: Host x86_64-w64-mingw32 in general didn't fail.What failed was building it as an MSYS2 package using the PKGBUILD script.For example, cross-compiling with standard configure + make didn't fail. On the reason of the MSYS2 package build failure: When building using that approach, the following executables build/genchecksum.exebuild/genmodes.exebuild/genversion.exe build/gengenrtl.exe are borrowing the $(COMPILERS) flags, so this included -Wl,--require-defined=HOST_EXTRA_OBJS_SYMBOL because of +$(COMPILERS) : override LDFLAGS += -Wl,--require-defined=HOST_EXTRA_OBJS_SYMBOL Since '--require-defined' results in an error if the symbol is not found, the failure happens.This shouldn't be an error though, because this flag was only meant for the compilers, hence the $(COMPILERS) variable.I don't know why these executables use the compiler flags in this build setup.It didn't happen when cross-compiling using configure + make. The proposed patch simply switches '--require-defined' to '--undefined' and makes the symbol definition optional, so these executables don't fail to build. The compilers will still pull it in, so we still get the UTF-8 feature. With the proposed patch, the MSYS2 gcc package builds fine.Also confirmed for the cross-compilation case with configure + make.
[Bug target/105953] [12/13 Regression] ICE in extract_insn, at recog.cc:2791
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105953 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|12.3|12.2 --- Comment #5 from Andrew Pinski --- .
[Bug ipa/107670] Suspicious redundant code in ipa-cp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107670 Martin Jambor changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jamborm at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #2 from Martin Jambor --- ipa_check_create_node_params and ipa_check_create_edge_args are mostly left-overs from when summarries were arrays indexed by cgraph_node and cgraph_edge uids. Those arrays then sometimes needed to be properly resized, which is not the case any more with hash-table based summary holder classes. Currently these functions just make sure that ipa_node_params_sum and ipa_edge_args_sum (and the hash tables for value ranges and bit information in it) have been allocated. This can probably be done much less often, let me review all the places where they are called next stage 1. Their comments are also from a different era ;-)
[Bug d/109231] [13 regression] Comparison failure in libphobos/libdruntime/rt/util/typeinfo.o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109231 --- Comment #15 from Jakub Jelinek --- So, after installing gcc 11 I've tried PATH=/export/home/jakub/gcc-11-inst/bin:$PATH LD_LIBRARY_PATH=/export/home/jakub/gcc-11-inst/lib/ ../configure --prefix=/export/home/jakub/gcc-inst --enable-languages=c,c++,d --disable-libssp --disable-libsanitizer --disable-nls --with-gmp=/opt/csw --with-ld=/usr/ccs/bin/ld --without-gnu-ld --with-as=/opt/csw/bin/gas --with-gnu-as --with-libiconv-prefix=/opt/csw --with-mpfr=/opt/csw --enable-libphobos --disable-multilib --enable-obsolete PATH=/export/home/jakub/gcc-11-inst/bin:$PATH LD_LIBRARY_PATH=/export/home/jakub/gcc-11-inst/lib/ gmake -j16 > LOG 2>&1 but that failed miserably during stage1: g++ -std=c++11 -no-pie -g -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format -Wmissing-format-attribute -Wconditionally-supported -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -static-libstdc++ -static-libgcc -o lto1 lto/lto-lang.o lto/lto.o lto/lto-object.o attribs.o lto/lto-partition.o lto/lto-symtab.o lto/lto-common.o libbackend.a main.o libcommon-target.a libcommon.a ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a -lisl -L/opt/csw/lib -L/opt/csw/lib -lmpc -lmpfr -lgmp -L./../zlib -lz libcommon.a ../libcpp/libcpp.a /opt/csw/lib/libiconv.so -R/opt/csw/lib ../libbacktrace/.libs/libbacktrace.a ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a Undefined first referenced symbol in file _ZSt28__throw_bad_array_new_lengthv libbackend.a(auto-profile.o) ld: fatal: symbol referencing errors collect2: error: ld returned 1 exit status gmake[3]: *** [../../gcc/lto/Make-lang.in:96: lto1] Error 1 Strangely, /export/home/jakub/gcc-11-inst/lib/gcc/sparc*/11*/ directory only contains *.a libraries and no *.so symlinks, I've linked there ../../../lib*.so but it still fails with that. Is that because the various --with-*=/opt/csw options added -L/opt/csw/lib and that directory contains the oldish libstdc++.a? Do I need to use CC='gcc -L/export/home/jakub/gcc-11-inst/lib -R/export/home/jakub/gcc-11-inst/lib/' CXX='g++ -L/export/home/jakub/gcc-11-inst/lib -R/export/home/jakub/gcc-11-inst/lib/' as workaround?
[Bug modula2/109248] gm2 should include cwd to the module search path
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109248 Gaius Mulley changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #2 from Gaius Mulley --- closing as the patch has been applied.
[Bug modula2/109248] gm2 should include cwd to the module search path
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109248 Gaius Mulley changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2023-03-22 Status|UNCONFIRMED |ASSIGNED
[Bug testsuite/105959] new test case c-c++-common/diagnostic-format-sarif-file-4.c from r13-967-g6cf276ddf22066 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105959 David Malcolm changed: What|Removed |Added Resolution|--- |FIXED Status|WAITING |RESOLVED --- Comment #17 from David Malcolm --- Should be fixed by the above commit
[Bug testsuite/105959] new test case c-c++-common/diagnostic-format-sarif-file-4.c from r13-967-g6cf276ddf22066 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105959 --- Comment #16 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:6b2740946d26ffde7e1318f24bae00443ece387d commit r13-6815-g6b2740946d26ffde7e1318f24bae00443ece387d Author: David Malcolm Date: Wed Mar 22 16:48:27 2023 -0400 testsuite: always use UTF-8 in scan-sarif-file[-not] [PR105959] c-c++-common/diagnostic-format-sarif-file-4.c is a test case for quoting non-ASCII source code in a SARIF diagnostic log. The SARIF standard mandates that .sarif files are UTF-8 encoded. PR testsuite/105959 notes that the test case fails when the system encoding is not UTF-8, such as when the "make" invocation is prefixed with LC_ALL=C, whereas it works with in a UTF-8-locale. The root cause is that dg-scan opens the file for reading using the "system" encoding; I believe it is falling back to treating all files as effectively ISO 8859-1 in a non-UTF-8 locale. This patch fixes things by adding a mechanism to dg-scan to allow callers to (optionally) specify an encoding to use when reading the file, and updating scan-sarif-file (and the -not variant) to always use UTF-8 when calling dg-scan, fixing the test case with LC_ALL=C. gcc/testsuite/ChangeLog: PR testsuite/105959 * gcc.dg-selftests/dg-final.exp (dg_final_directive_check_num_args): Update expected maximum number of args for the various directives using dg-scan. * lib/scanasm.exp (append_encoding_arg): New procedure. (dg-scan): Add optional 3rd argument: the encoding to use when reading from the file. * lib/scansarif.exp (scan-sarif-file): Treat the file as UTF-8 encoded when reading it. (scan-sarif-file-not): Likewise. Signed-off-by: David Malcolm
[Bug c++/109241] [13 Regression] ICE Segmentation fault for statement expression with a local type inside inside a generic lambda inside a generic lambda since r13-6722-gb323f52ccf966800
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109241 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED CC||jason at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug c++/108390] [10/11/12/13 Regression] ICE in fold_convert_loc, at fold-const.cc:2504 partial ordering between array types since r8-4678-g6296cf8e099aae43
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108390 --- Comment #4 from CVS Commits --- The trunk branch has been updated by Jason Merrill : https://gcc.gnu.org/g:5a1717fbdfd1242a5beb3ac8300766a3534d3f88 commit r13-6813-g5a1717fbdfd1242a5beb3ac8300766a3534d3f88 Author: Jason Merrill Date: Wed Mar 22 11:12:57 2023 -0400 c++: array bound partial ordering [PR108390] fold_convert doesn't work with a dependent argument, and problematically differed from the corresponding fold+build_nop further down in the function. So change it to match. PR c++/108390 gcc/cp/ChangeLog: * pt.cc (unify): Use fold of build_nop instead of fold_convert. gcc/testsuite/ChangeLog: * g++.dg/template/partial-order3.C: New test.
[Bug fortran/104572] ICE in gfc_resolve_finalizers, at fortran/resolve.cc:13646
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104572
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Target Milestone|--- |13.0
Resolution|--- |FIXED
Status|NEW |RESOLVED
--- Comment #5 from anlauf at gcc dot gnu.org ---
(In reply to Steve Kargl from comment #3)
> I'm fine with gfortran emitting either error message.
> As we've both put eyes on the bug, go ahead and use
> your error message and commit.
When using -std=f2018, the new testcase emits:
gcc/testsuite/gfortran.dg/pr104572.f90:12:17:
12 | subroutine s(*) ! { dg-error "Argument of FINAL procedure" }
| 1
Warning: Obsolescent feature: Alternate-return argument at (1)
gcc/testsuite/gfortran.dg/pr104572.f90:12:14:
12 | subroutine s(*) ! { dg-error "Argument of FINAL procedure" }
| 1
Error: Argument of FINAL procedure at (1) must be of type 't'
The error message is also close to that emitted by other brands.
***
Closing.
[Bug driver/109234] gcc refuses compilation with implausible error when using -fprofile-arcs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109234 Andrew Pinski changed: What|Removed |Added See Also||https://launchpad.net/bugs/ ||2012497 Resolution|INVALID |MOVED
[Bug driver/109234] gcc refuses compilation with implausible error when using -fprofile-arcs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109234 konstantin.priesnitz at de dot bosch.com changed: What|Removed |Added Resolution|--- |INVALID Status|WAITING |RESOLVED --- Comment #3 from konstantin.priesnitz at de dot bosch.com --- I think you are right. It is an Ubuntu binary issue. 12.2.0 built from source works fine on the same system. Ubuntu report: https://bugs.launchpad.net/ubuntu/+source/gcovr/+bug/2012497
[Bug fortran/104572] ICE in gfc_resolve_finalizers, at fortran/resolve.cc:13646
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104572 --- Comment #4 from CVS Commits --- The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:3e791f45ded89626bc1f9f8013728f6e035801b2 commit r13-6812-g3e791f45ded89626bc1f9f8013728f6e035801b2 Author: Harald Anlauf Date: Wed Mar 22 19:20:41 2023 +0100 Fortran: improve checking of FINAL subroutine arguments [PR104572] gcc/fortran/ChangeLog: PR fortran/104572 * resolve.cc (gfc_resolve_finalizers): Argument of a FINAL subroutine cannot be an alternate return. gcc/testsuite/ChangeLog: PR fortran/104572 * gfortran.dg/pr104572.f90: New test. Co-authored-by: Steven G. Kargl
[Bug fortran/103506] [10/11/12 Regression] ICE in gfc_free_namespace, at fortran/symbol.c:4039 since r10-2798-ge68a35ae4a65d2b3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103506 anlauf at gcc dot gnu.org changed: What|Removed |Added Summary|[10/11/12/13 Regression]|[10/11/12 Regression] ICE |ICE in gfc_free_namespace, |in gfc_free_namespace, at |at fortran/symbol.c:4039|fortran/symbol.c:4039 since |since |r10-2798-ge68a35ae4a65d2b3 |r10-2798-ge68a35ae4a65d2b3 | --- Comment #16 from anlauf at gcc dot gnu.org --- Fixed for gcc-13 so far.
[Bug analyzer/109252] New: RFE: make use of existing GCC loop analysis within -fanalyzer (or otherwise revamp loop handling)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109252 Bug ID: 109252 Summary: RFE: make use of existing GCC loop analysis within -fanalyzer (or otherwise revamp loop handling) Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: analyzer Assignee: dmalcolm at gcc dot gnu.org Reporter: dmalcolm at gcc dot gnu.org Target Milestone: --- Currently the analyzer uses its widening_svalue and complexity limits on svalues/regions to attempt to have the symbolic execution terminate due to hitting already-visited nodes in the exploded_graph, but this doesn't work well (see the various loop-related bugs here in bugzilla...) Some ideas for improvement (not necessarily mutually exclusive): (A) GCC's middle-end code already has code to analyze a CFG in gimple-SSA form and determine a tree of nested loops, find iterator SSA names, loop bounds etc. IIRC we're not currently making any use of this within -fanalyzer. Maybe we should make use of it; for example, see bug 108432. (B) Rework the program_point or supergraph code to have a notion of * "1st iteration of loop", * "2nd iteration of loop", * "subsequent iterations", or similar, so that the analyzer can explore those cases differently (on the assumption that such symbolically executing such iterations precisely will simulate the most interesting differences in behavior and thus help catch bugs). (C) Detect common patterns like: for (int i = LOWER; i < UPPER; i++) do_something_that_doesnt_touch (i) and raises them to a higher-level representation, so that e.g.: for (int i = LOWER; i < UPPER; i++) arr[i] = 0; gets raised to: fill_arr(LOWER, UPPER, 0) or somesuch
[Bug fortran/99036] [11/12/13 Regression] ICE in gfc_current_interface_head, at fortran/interface.c:4699
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99036 --- Comment #12 from CVS Commits --- The releases/gcc-12 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:7eb94c5adfd85c38e4ed7a7fff74b59087ddb813 commit r12-9311-g7eb94c5adfd85c38e4ed7a7fff74b59087ddb813 Author: Harald Anlauf Date: Tue Mar 21 19:58:31 2023 +0100 Fortran: reject MODULE PROCEDURE outside generic module interface [PR99036] gcc/fortran/ChangeLog: PR fortran/99036 * decl.cc (gfc_match_modproc): Reject MODULE PROCEDURE if not in a generic module interface. gcc/testsuite/ChangeLog: PR fortran/99036 * gfortran.dg/pr99036.f90: New test. (cherry picked from commit dd282b16bfd3c6e218dffb7798a375365b10ae22)
[Bug fortran/109186] nearest(huge(x),-1.0_kind(x)) half of correct value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109186 --- Comment #7 from CVS Commits --- The releases/gcc-12 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:f1342c21b2acbdd1daa0f2519154f8ac911a800f commit r12-9310-gf1342c21b2acbdd1daa0f2519154f8ac911a800f Author: Harald Anlauf Date: Sun Mar 19 21:29:46 2023 +0100 Fortran: simplification of NEAREST for large argument [PR109186] gcc/fortran/ChangeLog: PR fortran/109186 * simplify.cc (gfc_simplify_nearest): Fix off-by-one error in setting up real kind-specific maximum exponent for mpfr. gcc/testsuite/ChangeLog: PR fortran/109186 * gfortran.dg/nearest_6.f90: New test. (cherry picked from commit 4410a08b80cc40342eeaa5b6af824cd4352b218c)
[Bug fortran/85877] [10/11/12/13 Regression] ICE in fold_convert_loc, at fold-const.c:2449
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85877 --- Comment #13 from CVS Commits --- The releases/gcc-12 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:b6bef857c1e8bde9df2ba53a708ecffded316ec8 commit r12-9309-gb6bef857c1e8bde9df2ba53a708ecffded316ec8 Author: Harald Anlauf Date: Fri Mar 17 22:24:49 2023 +0100 Fortran: procedures with BIND(C) attribute require explicit interface [PR85877] gcc/fortran/ChangeLog: PR fortran/85877 * resolve.cc (resolve_fl_procedure): Check for an explicit interface of procedures with the BIND(C) attribute (F2018:15.4.2.2). gcc/testsuite/ChangeLog: PR fortran/85877 * gfortran.dg/pr85877.f90: New test. (cherry picked from commit 5426ab34643d9e6502f3ee572891a03471fa33ed)
[Bug target/109137] [12/13 regression] Compiling ffmpeg with -m32 on x86_64-pc-linux-gnu hangs on libavcodec/h264_cabac.c since r12-9086-g489c81db7d4f75
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109137 --- Comment #16 from CVS Commits --- The master branch has been updated by Vladimir Makarov : https://gcc.gnu.org/g:81d762cbec9685c2f2571da21d48f42c42eff33b commit r13-6804-g81d762cbec9685c2f2571da21d48f42c42eff33b Author: Vladimir N. Makarov Date: Wed Mar 22 12:33:11 2023 -0400 LRA: Do not repeat inheritance and live range splitting in case of asm error LRA was trying to do live range splitting again and again as there were no enough regs for asm. This patch solves the problem. PR target/109137 gcc/ChangeLog: * lra.cc (lra): Do not repeat inheritance and live range splitting when asm error is found. gcc/testsuite/ChangeLog: * gcc.target/i386/pr109137.c: New.
[Bug c/109233] [12/13 Regression] warning: array subscript 5 is above array bounds of ‘struct tg3_napi[5]’ since r12-2591
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109233 --- Comment #11 from Andrew Macleod --- (In reply to Aldy Hernandez from comment #10) > (In reply to Jakub Jelinek from comment #8) > > > And on the ranger side why we have determined the [0, 5] range rather than > > [0, 4], whether it is related to inaccurate number of iterations estimation, > > or ranger using it incorrectly, ... > > The [0, 5] is actually coming from SCEV, which ranger is using to refine the > range. Presumably, ranger is doing worse than SCEV, because it doesn't > improve it. > > $ grep 'Loops range fo' a.c.*evrp >Loops range found for i_3: [irange] int [0, 5] NONZERO 0x7 and calculated > range :[irange] int [-2147483647, +INF] >Loops range found for i_3: [irange] int [0, 5] NONZERO 0x7 and calculated > range :[irange] int [0, 6] NONZERO 0x7 > > Perhaps Andrew can pontificate on the recalculations / iterations / etc. Im not sure what to add. SCEV tells us its [0,5] . Statement MEM [(struct S *)t_9(D)].f[i_3].y = 1; is executed at most 4 (bounded by 4) + 1 times in loop 1. Induction variable (int) 0 + 1 * iteration does not wrap in statement MEM [(struct S *)t_9(D)].f[i_3].z = 2; in loop 1. Statement MEM [(struct S *)t_9(D)].f[i_3].z = 2; is executed at most 4 (bounded by 4) + 1 times in loop 1. Induction variable (int) 0 + 1 * iteration does not wrap in statement MEM [(struct S *)t_9(D)].f[i_3].x = 3; in loop 1. Statement MEM [(struct S *)t_9(D)].f[i_3].x = 3; is executed at most 4 (bounded by 4) + 1 times in loop 1. Induction variable (int) 0 + 1 * iteration does not wrap in statement MEM [(struct S *)t_9(D)].f[i_3].z = 2; in loop 1. Statement MEM [(struct S *)t_9(D)].f[i_3].z = 2; is executed at most 4 (bounded by 4) + 1 times in loop 1. Trying to walk loop body to reduce the bound. Found better loop bound 5 I see nothing else in the IL to help ranger make any other decision, so it defers to SCEV, and the transformtion to rewrite the array index to [5] seems spot on, its the only possible value that can be there... THe branch condition is: _1 = t_9(D)->h; i.0_2 = (unsigned int) i_3; if (_1 > i.0_2) goto ; Ranger knows nothing of the value of _1, and with i_3 being [0,5] there is nothing that I can see that ranger could do Why does scev decide 5 is a better bound?
[Bug fortran/99982] INTERFACE selects wrong module procedure involving C_PTR and C_FUNPTR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99982 --- Comment #5 from Scot Breitenfeld --- I removed the c_funptr interface in CGNS since it was not being used.
[Bug d/109231] [13 regression] Comparison failure in libphobos/libdruntime/rt/util/typeinfo.o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109231 --- Comment #14 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #13 from Jakub Jelinek --- > I found I could perhaps use gcc211 on CompilerFarm to try to reproduce it, > currently building GCC 11 for working GDC there. Right, although on Solaris/SPARC GCC 9.3.0 works for me, too. > What exact configure should I use for the trunk gcc? During the reghunt, I used (albeit on Solaris 11.4) configure --without-ppl --without-cloog --enable-languages=d --disable-lto --disable-libatomic --disable-libcc1 --disable-libquadmath --disable-libssp --disable-libitm --disable-libvtv --disable-libsanitizer --disable-libgomp --with-ld=/usr/bin/ld --without-gnu-ld --with-as=/vol/gcc/bin/gas-2.40 --with-gnu-as --disable-multilib All the --disable-* options serve to speed up the build, including --disable-multilib. I'd strongly recommend using /bin/ld; that's what I've been using all the time. > For gcc 11 I'm trying > ../configure --prefix=/export/home/jakub/gcc-11-inst > --enable-languages=c,c++,d > --disable-libssp --disable-nls --enable-threads=posix --with-gmp=/opt/csw > --with-included-gettext --with-ld=/opt/csw/bin/gld --with-gnu-ld > --with-as=/opt/csw/bin/gas --with-gnu-as --with-libiconv-prefix=/opt/csw > --with-mpfr=/opt/csw --with-system-zlib=/opt/csw --enable-libphobos > --disable-bootstrap I don't think you need the explicit --enable-threads=posix --with-included-gettext; likewise I didn't have any need for --with-system-zlib=/opt/csw or similar. I've been working with a self-compiled gas 2.40; I'm uncertain if the /opt/csw one is ok, but guess so. You'll certainly need gmp/mpfr/mpc from /opt/csw; at least for one of the three the bundled version is too old on 11.3.
[Bug target/107848] libbpf: ELF relo #0 in section #7 has unexpected type 12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107848 Andrew Pinski changed: What|Removed |Added Resolution|FIXED |MOVED --- Comment #4 from Andrew Pinski --- .
[Bug target/107848] libbpf: ELF relo #0 in section #7 has unexpected type 12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107848 Jose E. Marchesi changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Jose E. Marchesi --- This was due to a binutils bug. Fixed by the following binutils upstream commits: commit 5f784ec9277e9303eee3ce366c40ce9fa3203f3e Author: Cupertino Miranda Date: Fri Mar 17 15:29:36 2023 + Changed ld and gas BPF tests Recent BPF patch removed and renamed the list of relocations based on the limitations of BPF instruction set. This patch is a correction to the tests. commit 551fde0ae1691a74e1fdfb2bd33e8453106c0c87 Author: Cupertino Miranda Date: Fri Mar 17 15:27:02 2023 + Reloc howto access broken for BPF Forgot to change the logic to access the reloc howto from bpf_elf_relocate_section. Problem was introduced in previous BPF commit. commit 5e4c7a839d1c0d68a4a518cf2dc8e87925575e58 Author: Cupertino Miranda Date: Thu Mar 16 08:39:52 2023 + BPF relocations review / refactoring - Removed not needed relocations. - Renamed relocations to match llvm and linux kernel. Relocation changes: R_BPF_INSN_64 => R_BPF_64_64 R_BPF_INSN_DISP32 => R_BPF_64_32 R_BPF_DATA_32 => R_BPF_64_ABS32 R_BPF_DATA_64 => R_BPF_64_ABS64
[Bug d/109231] [13 regression] Comparison failure in libphobos/libdruntime/rt/util/typeinfo.o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109231 --- Comment #13 from Jakub Jelinek --- I found I could perhaps use gcc211 on CompilerFarm to try to reproduce it, currently building GCC 11 for working GDC there. What exact configure should I use for the trunk gcc? For gcc 11 I'm trying ../configure --prefix=/export/home/jakub/gcc-11-inst --enable-languages=c,c++,d --disable-libssp --disable-nls --enable-threads=posix --with-gmp=/opt/csw --with-included-gettext --with-ld=/opt/csw/bin/gld --with-gnu-ld --with-as=/opt/csw/bin/gas --with-gnu-as --with-libiconv-prefix=/opt/csw --with-mpfr=/opt/csw --with-system-zlib=/opt/csw --enable-libphobos --disable-bootstrap
[Bug fortran/99982] INTERFACE selects wrong module procedure involving C_PTR and C_FUNPTR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99982 --- Comment #4 from Scot Breitenfeld --- Is there an update on this issue, the CGNS fortran wrappers will not work with gfortran as there are no work arounds for this issue. Thanks.
[Bug modula2/109248] gm2 should include cwd to the module search path
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109248
--- Comment #1 from CVS Commits ---
The master branch has been updated by Gaius Mulley :
https://gcc.gnu.org/g:aae0d89e65c5da6ef45ec787e165dccb5ae7e2d0
commit r13-6803-gaae0d89e65c5da6ef45ec787e165dccb5ae7e2d0
Author: Gaius Mulley
Date: Wed Mar 22 16:39:12 2023 +
modula2: Add cwd to include path. Include m2cor before m2pim.
The driver should default to include the current working directory in the
module search path. This patch adds . to the search path provided
-fm2-pathname has not been specified. The patch also reorders the pim
libraries so that the m2cor directory is searched before m2pim.
Coroutine support is visible by default for both -fpim and -fiso
(from their respective SYSTEM modules).
gcc/m2/ChangeLog:
PR modula2/109248
* Make-lang.in (m2/pge-boot/%.o): Add CFLAGS and CXXFLAGS for C
and C++ compiles.
* gm2spec.cc (add_m2_I_path): Indentation.
(lang_specific_driver): New variable seen_pathname.
Detect -fm2-pathname. If not seen then push_back_Ipath (".").
Change non iso library path to "m2cor,m2log,m2pim,m2iso".
Signed-off-by: Gaius Mulley
[Bug libgcc/109245] aarch64 gcc defaults to -moutline-atomics but symbol ‘__aarch64_swp4_sync’ is hidden in libgcc.a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109245 --- Comment #2 from Andrew Pinski --- Can you show how you are doing the link? If you are linking in shared libraries, show how you are linking those too?
[Bug d/109231] [13 regression] Comparison failure in libphobos/libdruntime/rt/util/typeinfo.o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109231 --- Comment #12 from Jakub Jelinek --- BTW, I have also backported the r13-6739 commit to 12 branch in r12-9293, does that branch fail to bootstrap too?
[Bug tree-optimization/107569] [13 Regression] Failure to optimize std::isfinite since r13-3596
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107569 --- Comment #46 from Jakub Jelinek --- And another possibility might be try to keep __builtin_unreachable () in the IL more often; in this testcase nothing from the __builtin_unreachable () is really visible in any global ranges, they all are the same without/with the __builtin_unreachable. So, can't we remove those just in final_p case and not otherwise? Dom would then be able to optimize this.
[Bug ipa/107925] ICE in update_specialized_profile at gcc/ipa-cp.cc:5082 for 531.deepsjeng_r benchmark
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107925 Martin Jambor changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #12 from Martin Jambor --- Fixed on gcc-12 too now.
[Bug middle-end/26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163 Bug 26163 depends on bug 107925, which changed state. Bug 107925 Summary: ICE in update_specialized_profile at gcc/ipa-cp.cc:5082 for 531.deepsjeng_r benchmark https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107925 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c++/108795] [10/11/12/13 Regression] ICE in prep_operand, at cp/call.cc:6325 since r7-2549-gf3365c1201908df5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108795 --- Comment #3 from CVS Commits --- The trunk branch has been updated by Jason Merrill : https://gcc.gnu.org/g:426cab4e3b46abaeae0813042b5addc789e3b2be commit r13-6802-g426cab4e3b46abaeae0813042b5addc789e3b2be Author: Jason Merrill Date: Tue Mar 21 15:15:27 2023 -0400 c++: attribute on dtor in template [PR108795] Since r7-2549 we were throwing away the explicit C:: when we found that ~C has an attribute that we treat as making its type dependent. PR c++/108795 gcc/cp/ChangeLog: * semantics.cc (finish_id_expression_1): Check scope before returning id_expression. gcc/testsuite/ChangeLog: * g++.dg/ext/attr-tsafe1.C: New test.
[Bug ipa/107925] ICE in update_specialized_profile at gcc/ipa-cp.cc:5082 for 531.deepsjeng_r benchmark
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107925 --- Comment #11 from CVS Commits --- The releases/gcc-12 branch has been updated by Martin Jambor : https://gcc.gnu.org/g:c826442f6651bab6f66d3107fb02d38eacbf900e commit r12-9308-gc826442f6651bab6f66d3107fb02d38eacbf900e Author: Martin Jambor Date: Wed Mar 22 16:59:45 2023 +0100 ipa-cp: Fix various issues in update_specialized_profile (PR 107925) The patch below fixes various issues in function update_specialized_profile. The main is removal of the assert which is bogus in the case of recursive cloning. The division of unexplained counts is guesswork, which then leads to updates of counts of recursive edges, which then can be redirected to the new clone and their count subtracted from the count and there simply may not be enough left in the count of the original node - especially when we clone a lot because of using --param ipa-cp-eval-threshold=1. The other issue was omission to drop the count of the original node to ipa count. And when calculating the remainder, we should use lenient_count_portion_handling to account for partial train runs. Finally, the patch adds dumping of the original count which I think is useful. gcc/ChangeLog: 2023-02-17 Martin Jambor PR ipa/107925 * ipa-cp.cc (update_specialized_profile): Drop orig_node_count to ipa count, remove assert, lenient_count_portion_handling, dump also orig_node_count. (cherry picked from commit 68ba253bda74d6c6e77726d98184a6faee5e7337)
[Bug tree-optimization/109238] [13 Regression] tst-realloc.i:42:19: error: pointer ‘p’ may be used after ‘realloc’ [-Werror=use-after-free] in glibc tests
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109238 --- Comment #4 from Andrew Macleod --- I think varying is the correct result tho? the branch is in BB28, but bb 33 is a merge poi9nt again before bb 36, so we can't tell that it is anything but varying? I see: [local count: 428124]: c_24 = realloc (p_17, 18446744073709551615); if (c_24 != 0B) goto ; [99.96%] else goto ; [0.04%] [local count: 427952]: support_exit_failure_impl (1, "tst-realloc.c", 120, "realloc (p, -1) succeeded."); [local count: 2741]: _26 = (sizetype) i_25; _27 = p_17 + _26; _28 = *_27; if (_28 != 255) goto ; [66.00%] else goto ; [34.00%] [local count: 1809]: [local count: 2741]: # ok_48 = PHI i_29 = i_25 + 1; [local count: 2912]: <<-- both sides of BB 28 branch merge here, so c_24 is varying again # i_25 = PHI <0(28), i_29(32)> # ok_49 = PHI <1(28), ok_48(32)> if (i_25 != 16) goto ; [94.12%] else goto ; [5.88%] [local count: 171]: # ok_30 = PHI if (ok_30 == 0) goto ; [0.04%] else goto ; [99.96%] [local count: 0]: support_exit_failure_impl (1, "tst-realloc.c", 132, "first 16 bytes were not correct after failed realloc"); [local count: 171]: p_31 = realloc (p_17, 0); <<-- This is dominated by bb 33 which merged the bb28 branch During the cache dump the bit about CACHE: BB 32 DOM query for c_24, found [irange] unsigned char * VARYING at BB28 CACHE: Range for DOM returns : [irange] unsigned char * VARYING CACHE: Range for DOM returns : [irange] unsigned char * VARYING Is a bit of a misnomer I think, its dumping in the middle of a query and didnt show the fully updated value.. But I will look a bit closer at it.. in theory that should have been non-zero, even tho I dont think it affects the result.
[Bug c++/109177] Call to C++ function marked unavailable gets diagnosed twice
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109177 Alex Coplan changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Alex Coplan --- Fixed for GCC 13. Since this doesn't seem to be a regression (and it's quite a minor issue) I guess it's not worth backporting.
[Bug driver/108865] gcc on Windows fails with Unicode path to source file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108865 --- Comment #24 from LIU Hao --- (In reply to Costas Argyris from comment #23) > Created attachment 54730 [details] > Make symbol optional > > Could you please try this patch? Didn't test this completely, but it did allow the build to continue. The error was caused by the fact that `sym-mingw32.o` was not built. Also the variable in `sym-mingw32.cc` had better have `extern "C"`.
[Bug c++/109250] Invalid configuration `loongarch64-linux-gnu': machine `loongarch64-unknown' not recognized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109250 Xi Ruoyao changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |MOVED --- Comment #7 from Xi Ruoyao --- I'm sending a mail to gmp-bugs.
[Bug c++/109250] Invalid configuration `loongarch64-linux-gnu': machine `loongarch64-unknown' not recognized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109250
--- Comment #6 from Xi Ruoyao ---
(In reply to Andreas Schwab from comment #5)
> There is support for loongarch in longlong.h (added a year ago
> https://gmplib.org/repo/gmp/rev/32dc4af70f95), which may be enough to build
> it, if config.sub is updated from upstream.
Yes, a manual configfsf.{guess,sub} update is enough. All GMP tests passes
(with 6.2.1 and updated config files).
[Bug c++/109250] Invalid configuration `loongarch64-linux-gnu': machine `loongarch64-unknown' not recognized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109250 --- Comment #5 from Andreas Schwab --- There is support for loongarch in longlong.h (added a year ago https://gmplib.org/repo/gmp/rev/32dc4af70f95), which may be enough to build it, if config.sub is updated from upstream.
[Bug tree-optimization/107569] [13 Regression] Failure to optimize std::isfinite since r13-3596
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107569 --- Comment #45 from Jakub Jelinek --- For the #c0 foo function, one simple fix would be something like --- gcc/passes.def.jj 2023-01-02 09:32:39.539037434 +0100 +++ gcc/passes.def 2023-03-22 16:12:57.387652639 +0100 @@ -85,6 +85,7 @@ along with GCC; see the file COPYING3. NEXT_PASS (pass_forwprop); NEXT_PASS (pass_early_thread_jumps, /*first=*/true); NEXT_PASS (pass_sra_early); + NEXT_PASS (pass_dce); /* pass_build_ealias is a dummy pass that ensures that we execute TODO_rebuild_alias at this point. */ NEXT_PASS (pass_build_ealias); The problem there is that ccp1 and forwprop1 passes result in some dead statements: _6 = ABS_EXPR ; _4 = _6 u> 1.79769313486231570814527423731704356798070567525844996599e+308; _8 = ~_4; _12 = _8; _1 = _12; retval.0_5 = ~_1; if (retval.0_5 != 0) by ccp1 into: _6 = ABS_EXPR ; _4 = _6 u> 1.79769313486231570814527423731704356798070567525844996599e+308; _8 = ~_4; if (_4 != 0) and forwprop1: _6 = ABS_EXPR ; _4 = _6 u> 1.79769313486231570814527423731704356798070567525844996599e+308; _8 = ~_4; if (_6 u> 1.79769313486231570814527423731704356798070567525844996599e+308) So, now both _8 and _4 setters are dead. Then comes fre1 and happily uses them again, which results in undesirable _6 = ABS_EXPR ; _4 = _6 u> 1.79769313486231570814527423731704356798070567525844996599e+308; _8 = ~_4; if (_6 u> 1.79769313486231570814527423731704356798070567525844996599e+308) goto ; [INV] else goto ; [INV] : __builtin_unreachable (); : return _8; With the extra dce, we get _6 = ABS_EXPR ; if (_6 u> 1.79769313486231570814527423731704356798070567525844996599e+308) goto ; [INV] else goto ; [INV] : __builtin_unreachable (); : _9 = ABS_EXPR ; _10 = _9 u> 1.79769313486231570814527423731704356798070567525844996599e+308; _11 = ~_10; return _11; before fre1 and optimize that into: _6 = ABS_EXPR ; if (_6 u> 1.79769313486231570814527423731704356798070567525844996599e+308) goto ; [INV] else goto ; [INV] : __builtin_unreachable (); : return 1;
[Bug c++/109177] Call to C++ function marked unavailable gets diagnosed twice
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109177 --- Comment #5 from CVS Commits --- The master branch has been updated by Alex Coplan : https://gcc.gnu.org/g:d3a6f174543816600b1f472997d492088e4e396a commit r13-6801-gd3a6f174543816600b1f472997d492088e4e396a Author: Alex Coplan Date: Wed Mar 22 15:20:49 2023 + c++: Avoid duplicate diagnostic calling unavailable function [PR109177] As the PR shows, we currently emit duplicate diagnostics for calls to functions marked with __attribute__((unavailable)). This patch fixes that. gcc/cp/ChangeLog: PR c++/109177 * call.cc (build_over_call): Use make_temp_override to suppress both unavailable and deprecated warnings when calling build_addr_func. gcc/testsuite/ChangeLog: PR c++/109177 * g++.dg/ext/pr109177.C: New test.
[Bug c++/109250] Invalid configuration `loongarch64-linux-gnu': machine `loongarch64-unknown' not recognized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109250 Xi Ruoyao changed: What|Removed |Added CC||xry111 at gcc dot gnu.org --- Comment #4 from Xi Ruoyao --- (In reply to Jonathan Wakely from comment #3) > Like I said, don't build in the source directory, and try a newer version of > GMP. Even the latest GMP release does not supports LoongArch. This is a GMP issue.
[Bug c/109233] [12/13 Regression] warning: array subscript 5 is above array bounds of ‘struct tg3_napi[5]’ since r12-2591
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109233 --- Comment #10 from Aldy Hernandez --- (In reply to Jakub Jelinek from comment #8) > And on the ranger side why we have determined the [0, 5] range rather than > [0, 4], whether it is related to inaccurate number of iterations estimation, > or ranger using it incorrectly, ... The [0, 5] is actually coming from SCEV, which ranger is using to refine the range. Presumably, ranger is doing worse than SCEV, because it doesn't improve it. $ grep 'Loops range fo' a.c.*evrp Loops range found for i_3: [irange] int [0, 5] NONZERO 0x7 and calculated range :[irange] int [-2147483647, +INF] Loops range found for i_3: [irange] int [0, 5] NONZERO 0x7 and calculated range :[irange] int [0, 6] NONZERO 0x7 Perhaps Andrew can pontificate on the recalculations / iterations / etc.
[Bug tree-optimization/109154] [13 regression] jump threading de-optimizes nested floating point comparisons
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109154 --- Comment #10 from Aldy Hernandez --- (In reply to Andrew Macleod from comment #9) > (In reply to Richard Biener from comment #7) > > (In reply to Richard Biener from comment #6) > > > ah, probably it's the missing CSE there: > > > > > > : > > > _1 = (float) l_10; > > > _2 = _1 < 0.0; > > > zone1_17 = (int) _2; > > > if (_1 < 0.0) BTW, I don't think it helps at all here, but casting from l_10 to a float, we know _1 can't be either -0.0 or +-INF or +-NAN. We could add a range-op entry for NOP_EXPR / CONVERT_EXPR to expose this fact. Well, at the very least that it can't be a NAN...in the current representation for frange's.
[Bug c/109233] [12/13 Regression] warning: array subscript 5 is above array bounds of ‘struct tg3_napi[5]’ since r12-2591
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109233 --- Comment #9 from Jakub Jelinek --- (In reply to Jakub Jelinek from comment #8) > rather than just doing intmbx == 0x8; always. intmbx += 0x8; of course, sorry for the typo.
[Bug c/109233] [12/13 Regression] warning: array subscript 5 is above array bounds of ‘struct tg3_napi[5]’ since r12-2591
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109233
--- Comment #8 from Jakub Jelinek ---
Slightly further reduced:
/* { dg-do compile } */
/* { dg-options "-O2 -Warray-bounds" } */
struct S { unsigned x, y, z; };
struct T { struct S f[5]; unsigned h; };
void foo (void);
void
bar (struct T *t)
{
for (int i = 0; i < t->h; i++)
{
struct S *s = >f[i]; /* { dg-bogus "array subscript 5 is above array
bounds" } */
if (i <= 4)
s->y = 1;
s->z = 2;
if (i)
s->x = 3;
}
}
I guess what is going on is that we thread the body,
if (i > 4)
{
s->z = 2;
goto do_x;
}
else
{
s->y = 1;
s->z = 2;
if (i)
{
do_x:
s->x = 3;
}
}
because if i > 4, we know we don't want to store s->y and know we don't need to
check if i is non-zero further.
Next evrp determines that the range of the i_4 index is [0, 5] for some reason
rather than the [0, 4] for which it is well defined, perhaps because of the
dead
s_15 = _10(D)->f[i_4];
statement that nothing has DCEd yet or what, and everything goes wrong from
that point,
as evrp because of that folds the
MEM [(struct S *)t_10(D)].f[i_4].z = 2;
statement done only for i_4 > 4 into
MEM [(struct S *)t_10(D)].f[5].z = 2;
and later we warn on that very statement.
Now, a question on the kernel side is obviously why when
#define TG3_RSS_MAX_NUM_QS 4
#define TG3_IRQ_MAX_VECS_RSS(TG3_RSS_MAX_NUM_QS + 1)
#define TG3_IRQ_MAX_VECSTG3_IRQ_MAX_VECS_RSS
...
struct tg3_napi napi[TG3_IRQ_MAX_VECS];
it has the
for (i = 0; i < tp->irq_max; i++) {
struct tg3_napi *tnapi = >napi[i];
tnapi->tp = tp;
tnapi->tx_pending = TG3_DEF_TX_RING_PENDING;
tnapi->int_mbox = intmbx;
if (i <= 4)
intmbx += 0x8;
else
intmbx += 0x4;
rather than just doing intmbx == 0x8; always. That introduction of the dead
code there confuses the warning.
And on the ranger side why we have determined the [0, 5] range rather than [0,
4], whether it is related to inaccurate number of iterations estimation, or
ranger using it incorrectly, ...
[Bug c++/109250] Invalid configuration `loongarch64-linux-gnu': machine `loongarch64-unknown' not recognized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109250 Jonathan Wakely changed: What|Removed |Added Last reconfirmed||2023-03-22 Status|UNCONFIRMED |WAITING Ever confirmed|0 |1
[Bug c++/109250] Invalid configuration `loongarch64-linux-gnu': machine `loongarch64-unknown' not recognized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109250 --- Comment #3 from Jonathan Wakely --- Like I said, don't build in the source directory, and try a newer version of GMP.
[Bug c++/109232] Using deduced return type in an unevaluated context leads to codegen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109232 --- Comment #5 from Patrick Palka --- So one workaround is to explicitly declare begin inline, which works because the problematic test in cgraph_node::finalize_function excludes DECL_DECLARED_INLINE_P functions.
[Bug c++/109232] Using deduced return type in an unevaluated context leads to codegen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109232
--- Comment #4 from Patrick Palka ---
Here's another perhaps simpler version that explicitly gives begin internal
linkage, which also fails to link:
namespace {
template
auto begin(T&& r) {
return r.begin();
}
}
struct R {
int* begin();
};
static_assert(__is_same(decltype(begin(R())), int*));
int main() { }
[Bug c/109233] [12/13 Regression] warning: array subscript 5 is above array bounds of ‘struct tg3_napi[5]’ since r12-2591
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109233 --- Comment #7 from Martin Liška --- Note, the linux kernel disables the -Werror of the warning for GCC 11 and 12: https://github.com/torvalds/linux/blob/a1effab7a3a35a837dd9d2b974a1bc4939df1ad5/init/Kconfig#L893-L904 while they still hope it can be enabled for GCC 13.
[Bug c++/109232] Using deduced return type in an unevaluated context leads to codegen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109232 Patrick Palka changed: What|Removed |Added CC||ppalka at gcc dot gnu.org --- Comment #3 from Patrick Palka --- What seems to be happening is determine_visibility correctly notices that begin should have internal linkage due to R having internal linkage, so it proceeds to clear TREE_PUBLIC, DECL_COMDAT, DECL_EXTERN, etc for begin. Later in cgraph_node::finalize for begin, we force its definition to be outputted due to /* When not optimizing, also output the static functions. (see PR24561), but don't do so for always_inline functions, functions declared inline and nested functions. These were optimized out in the original implementation and it is unclear whether we want to change the behavior here. */ if (((!opt_for_fn (decl, optimize) || flag_keep_static_functions || node->no_reorder) && !node->cpp_implicit_alias && !DECL_DISREGARD_INLINE_LIMITS (decl) && !DECL_DECLARED_INLINE_P (decl) && !(DECL_CONTEXT (decl) && TREE_CODE (DECL_CONTEXT (decl)) == FUNCTION_DECL)) && !DECL_COMDAT (decl) && !DECL_EXTERNAL (decl)) node->force_output = 1; I guess we need to somehow refine the above test to exclude implicit instantiations with internal linkage?
[Bug analyzer/109251] New: -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
Bug ID: 109251
Summary: -Wanalyzer-deref-before-check false positives seen in
Linux kernel due to check in macros
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: dmalcolm at gcc dot gnu.org
Target Milestone: ---
Created attachment 54734
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54734=edit
Reduced reproducer
The attached triggers a false positive from -Wanalyzer-deref-before-check:
https://godbolt.org/z/TsrnedsWP
: In function 'sched_slice':
:50:25: warning: check of 'se' for NULL after already dereferencing it
[-Wanalyzer-deref-before-check]
50 | for_each_sched_entity(se) {
| ^~
:32:10: note: in definition of macro 'for_each_sched_entity'
32 | for (; se; se = NULL)
| ^~
'sched_slice': event 1
|
| 48 | slice = __sched_period(nr_running + !se->on_rq);
| |~~^~~
| | |
| | (1) pointer 'se' is
dereferenced here
|
'sched_slice': event 2
|
| 50 | for_each_sched_entity(se) {
| | ^~
| | |
| | (2) pointer 'se' is checked for NULL here
but it was already dereferenced at (1)
:32:10: note: in definition of macro 'for_each_sched_entity'
| 32 | for (; se; se = NULL)
| | ^~
|
Looks similar to PR 108745, but that one's marked as fixed, whereas this one is
still firing.
[Bug d/109231] [13 regression] Comparison failure in libphobos/libdruntime/rt/util/typeinfo.o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109231 --- Comment #11 from Jakub Jelinek --- (In reply to r...@cebitec.uni-bielefeld.de from comment #9) > > --- Comment #8 from ro at CeBiTec dot Uni-Bielefeld.DE > Uni-Bielefeld.DE> --- > >> --- Comment #7 from Jakub Jelinek --- > >> No luck reproducing this using a cross. > > > > Ok, so I'll continue with the reghunt. > > It's finished now and identified your patch > > commit 24c06560a7fa39049911eeb8777325d112e0deb9 > Author: Jakub Jelinek > Date: Fri Mar 17 18:59:56 2023 +0100 > > tree-inline: Fix up multiversioning with vector arguments [PR105554] > > as the culprit. That is just weird. Looking at the cross case, I see tree_function_versioning being called 5 times, but in all cases DECL_FUNCTION_SPECIFIC_TARGET and DECL_FUNCTION_SPECIFIC_OPTIMIZATION of both old_decl and new_decl are NULL, 4 times from that from cgraph_node::create_version_clone_with_body with NULL target_attributes. So I don't much see how it could make a difference. So, do you really see changes with that commit, if so, are they in the -fno-checking or -fchecking=1 case (r13-6738 vs. r13-6739), do any changes appear in -fdump-tree-optimized, or if not, where things differ first with -fdump-noaddr -fdump-rtl-all?
[Bug tree-optimization/109154] [13 regression] jump threading de-optimizes nested floating point comparisons
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109154 --- Comment #9 from Andrew Macleod --- (In reply to Richard Biener from comment #7) > (In reply to Richard Biener from comment #6) > > ah, probably it's the missing CSE there: > > > > : > > _1 = (float) l_10; > > _2 = _1 < 0.0; > > zone1_17 = (int) _2; > > if (_1 < 0.0) > > > > we are not considering to replace the FP compare control if (_1 < 0.0) > > with an integer compare control if (_2 != 0). Maybe we should do that? > That would resolve the issue from VRPs point of view. _2 has no involvement in the condition, sonother _2 nor zone1_17 are considered direct exports. We do however recognize that it can be recomputed as it depends on _1. I have not yet had a chance to extend relations to recomputations, (its probably not a win very often as we assume CSE takes care fo those things) I see we do make an attempt to recompute: 13 GORI recomputation attempt on edge 3->4 for _2 = _1 < 0.0; 14 GORIoutgoing_edge for _1 on edge 3->4 15 GORI compute op 1 (_1) at if (_1 < 0.0) GORILHS =[irange] _Bool [1, 1] GORIComputes _1 = [frange] float [-Inf, -0.0 (-0x0.0p+0)] intersect Known range : [frange] float VARYING +-NAN GORI TRUE : (15) produces (_1) [frange] float [-Inf, -0.0 (-0x0.0p+0)] GORITRUE : (14) outgoing_edge (_1) [frange] float [-Inf, -0.0 (-0x0.0p+0)] GORI TRUE : (13) recomputation (_2) [irange] _Bool VARYING folding _2 using the true edge value: [-Inf, -0.0 (-0x0.0p+0)] < 0.0 is returning false, so we dont recognize that _2 is always true. I assume this has something to do with the wonders of floating point and +/- 0:-)
[Bug tree-optimization/109238] [13 Regression] tst-realloc.i:42:19: error: pointer ‘p’ may be used after ‘realloc’ [-Werror=use-after-free] in glibc tests
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109238
Richard Biener changed:
What|Removed |Added
CC||amacleod at redhat dot com
--- Comment #3 from Richard Biener ---
For the given CFG where
dominated_by_p (CDI_DOMINATORS, gimple_bb (use_stmt), gimple_bb (stmt));
and we have
[local count: 428124]:
c_24 = realloc (p_17, 18446744073709551615);
if (c_24 != 0B)
goto ; [99.96%]
else
goto ; [0.04%]
.. on the 28->33 edge intermediate blocks, including a CFG cycle ...
[local count: 171]:
p_31 = realloc (p_17, 0);
but range_of_expr (vr, c_24, use_stmt) doesn't give us [0,0], instead we
get VARYING.
It looks like we go range_of_stmt of the c_24 def and then m_cache.block_range
has a VARYING entry range as well and then we're done.
176 range_of_expr(c_24) at stmt p_31 = realloc (p_17, 0);
177range_on_entry (c_24) to BB 36
178 range_of_stmt (c_24) at stmt c_24 = realloc (p_17,
18446744073709551615);
GLOBAL : UPDATE cache for c_24 in BB 28 : successors : : No updates!
TRUE : (178) range_of_stmt (c_24) [irange] unsigned char * VARYING
c_24 : CACHE: BB 36 DOM query for c_24, found [irange] unsigned char * VARYING
at BB28
179 GORI outgoing_edge for c_24 on edge 28->33
180 GORIcompute op 1 (c_24) at if (c_24 != 0B)
GORI LHS =[irange] _Bool [0, 0] NONZERO 0x0
GORI Computes c_24 = [irange] unsigned char * [0, 0] NONZERO 0x0
intersect Known range : [irange] unsigned char * VARYING
GORITRUE : (180) produces (c_24) [irange] unsigned char * [0, 0]
NONZERO 0x0
GORI TRUE : (179) outgoing_edge (c_24) [irange] unsigned char * [0, 0]
NONZERO 0x0
CACHE: BB 32 DOM query for c_24, found [irange] unsigned char * VARYING at BB28
CACHE: Range for DOM returns : [irange] unsigned char * VARYING
CACHE: Range for DOM returns : [irange] unsigned char * VARYING
Filled from dominator! : [irange] unsigned char * VARYING
TRUE : (177) range_on_entry (c_24) [irange] unsigned char * VARYING
TRUE : (176) range_of_expr (c_24) [irange] unsigned char * VARYING
181 range_of_expr(c_24) at stmt _27 = p_17 + _26;
182range_on_entry (c_24) to BB 30
183 range_of_stmt (c_24) at stmt c_24 = realloc (p_17,
18446744073709551615);
TRUE : (183) cached (c_24) [irange] unsigned char * VARYING
c_24 : CACHE: BB 30 DOM query for c_24, found [irange] unsigned char * VARYING
at BB33
CACHE: Range for DOM returns : [irange] unsigned char * VARYING
Filled from dominator! : [irange] unsigned char * VARYING
TRUE : (182) range_on_entry (c_24) [irange] unsigned char * VARYING
...
(not sure where relevant dumps stop).
A reduced testcase like the following doesn't exhibit this issue - the
range is successfully computed as [0,0] there. So to me this looks like
a ranger issue? Andrew?
#include
int do_test(void *p)
{
unsigned char *c = realloc (p, -1);
if (c != 0)
abort ();
c = p;
int ok = 1;
for (int i = 0; i < 16; i++)
{
if (c[i] != 0xff)
ok = 0;
}
if (!ok)
abort ();
p = realloc (p, 0);
if (p != NULL)
abort ();
return ok;
}
[Bug c++/109250] Invalid configuration `loongarch64-linux-gnu': machine `loongarch64-unknown' not recognized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109250 --- Comment #2 from Liu Aifu --- (In reply to Jonathan Wakely from comment #1) > (In reply to Liu Aifu from comment #0) > > I am trying to compile GCC v12.2.0 on the Kylin Desktop Operating System V10 > > (SP1), with a loongson-3A5000 CPU. The current GCC version is v8.3, but I am > > encountering errors during the compilation process. Can you please help me > > take a look? > > > > Kernel: linux 5.4.18-28.23-bj-generic > > > > $lscpu > > Architecture:loongarch64 > > Byte Order: Little Endian > > CPU(s): 4 > > On-line CPU(s) list: 0-3 > > Thread(s) per core: 1 > > Core(s) per socket: 4 > > Socket(s): 1 > > NUMA node(s):1 > > CPU family: Loongson-64bit > > Model name: Loongson-3A5000 > > BogoMIPS:5000.00 > > L1d cache: 256 KiB > > L1i cache: 256 KiB > > L2 cache:1 MiB > > L3 cache:16 MiB > > NUMA node0 CPU(s): 0-3 > > Flags: cpucfg lam ual fpu lsx lasx complex crypto lvz > > > > $gcc -v > > Using built-in specs. > > COLLECT_GCC=gcc > > COLLECT_LTO_WRAPPER=/usr/lib/gcc/loongarch64-linux-gnu/8/lto-wrapper > > Target: loongarch64-linux-gnu > > Configured with: ../src/configure -v --with-pkgversion='Loongnix > > 8.3.0-6.lnd.vec.24' --with-bugurl=file:///usr/share/doc/gcc-8/README.Bugs > > --enable-languages=c,c++,fortran --prefix=/usr --with-gcc-major-version-only > > --program-suffix=-8 --program-prefix=loongarch64-linux-gnu- --enable-shared > > --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext > > --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-clocale=gnu > > --enable-libstdcxx-debug --enable-libstdcxx-time=yes > > --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-libitm > > --disable-libsanitizer --disable-libquadmath --disable-libquadmath-support > > --enable-plugin --with-system-zlib --enable-multiarch --disable-werror > > --with-arch=loongarch64 --with-abi=lp64 --enable-tls --enable-initfini-array > > --enable-gnu-indirect-function --disable-host-shared --disable-emultls > > --with-fix-loongson3-llsc --enable-checking=release > > --build=loongarch64-linux-gnu --host=loongarch64-linux-gnu > > --target=loongarch64-linux-gnu > > Thread model: posix > > gcc version 8.3.0 (Loongnix 8.3.0-6.lnd.vec.24) > > > > $./configure --enable-languages=c,c++ --prefix=/opt/gcc-12.2.0 > > Don't build in the source directory. > https://gcc.gnu.org/wiki/FAQ#configure > > > --program-suffix=-8 --program-prefix=loongarch64-linux-gnu- --enable-shared > > --enable-linker-build-id --without-included-gettext --enable-threads=posix > > --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug > > --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new > > --enable-gnu-unique-object --disable-libitm --disable-libsanitizer > > --disable-libquadmath --disable-libquadmath-support --enable-plugin > > --with-system-zlib --enable-multiarch --disable-werror > > --with-arch=loongarch64 --with-abi=lp64 --enable-tls --enable-initfini-array > > --enable-gnu-indirect-function --disable-host-shared --disable-emultls > > --with-fix-loongson3-llsc --enable-checking=release > > --build=loongarch64-linux-gnu --host=loongarch64-linux-gnu > > --target=loongarch64-linux-gnu > > Why are you including all these options, most of which are already implied > by default? > > https://gcc.gnu.org/wiki/InstallingGCC > > "If your build fails and your configure command has lots of complicated > options you should try removing options and keep it simple. Do not add lots > of configure options you don't understand, they might be the reason your > build fails." > > e.g. why do you want the suffix to be -8 when you're building gcc-12? > > > Anyway, the error is in the gmp sub-directory, so you probably need a more > recent version of gmp to get loongarch support. The above command line was copied from the output of "gcc -v". I tried shorter parameters at the beginning, but the same error was reported. $./configure --prefix=/opt/gcc-12.2.0 --disable-multilib --enable-language=c,c++ --enable-checking=release
[Bug c++/109235] nodiscard attribute on class not copied to the constructors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109235 --- Comment #6 from Jonathan Wakely --- (In reply to Teis Johansen from comment #0) > I have tried implementing std::experimental::scope_exit N.B. this is already present in the upcoming GCC 13: https://gcc.gnu.org/gcc-13/changes.html#libstdcxx
[Bug d/109231] [13 regression] Comparison failure in libphobos/libdruntime/rt/util/typeinfo.o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109231 --- Comment #10 from Jakub Jelinek --- (In reply to r...@cebitec.uni-bielefeld.de from comment #8) > Sure. Even compressed with xz, the tarballs are too large for bugzilla, > so I've placed them at > > https://www.cebitec.uni-bielefeld.de/~ro/files/ti.s2.tar.xz > https://www.cebitec.uni-bielefeld.de/~ro/files/ti.s3.tar.xz > > > Also, check if you are using the same d21 binary, another possibility might > > be > > miscompiled d21. > > Both the dumps and the objects/assembler output were created with the > same d21 binary, just the -fno-checking/-fchecking=1 difference. But the typeinfo.s is the same in both tarballs, optimized dump too, and while some RTL dumps differ slightly in used addresses, I see no code changes in those either.
[Bug c++/109250] Invalid configuration `loongarch64-linux-gnu': machine `loongarch64-unknown' not recognized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109250 --- Comment #1 from Jonathan Wakely --- (In reply to Liu Aifu from comment #0) > I am trying to compile GCC v12.2.0 on the Kylin Desktop Operating System V10 > (SP1), with a loongson-3A5000 CPU. The current GCC version is v8.3, but I am > encountering errors during the compilation process. Can you please help me > take a look? > > Kernel: linux 5.4.18-28.23-bj-generic > > $lscpu > Architecture:loongarch64 > Byte Order: Little Endian > CPU(s): 4 > On-line CPU(s) list: 0-3 > Thread(s) per core: 1 > Core(s) per socket: 4 > Socket(s): 1 > NUMA node(s):1 > CPU family: Loongson-64bit > Model name: Loongson-3A5000 > BogoMIPS:5000.00 > L1d cache: 256 KiB > L1i cache: 256 KiB > L2 cache:1 MiB > L3 cache:16 MiB > NUMA node0 CPU(s): 0-3 > Flags: cpucfg lam ual fpu lsx lasx complex crypto lvz > > $gcc -v > Using built-in specs. > COLLECT_GCC=gcc > COLLECT_LTO_WRAPPER=/usr/lib/gcc/loongarch64-linux-gnu/8/lto-wrapper > Target: loongarch64-linux-gnu > Configured with: ../src/configure -v --with-pkgversion='Loongnix > 8.3.0-6.lnd.vec.24' --with-bugurl=file:///usr/share/doc/gcc-8/README.Bugs > --enable-languages=c,c++,fortran --prefix=/usr --with-gcc-major-version-only > --program-suffix=-8 --program-prefix=loongarch64-linux-gnu- --enable-shared > --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext > --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-clocale=gnu > --enable-libstdcxx-debug --enable-libstdcxx-time=yes > --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-libitm > --disable-libsanitizer --disable-libquadmath --disable-libquadmath-support > --enable-plugin --with-system-zlib --enable-multiarch --disable-werror > --with-arch=loongarch64 --with-abi=lp64 --enable-tls --enable-initfini-array > --enable-gnu-indirect-function --disable-host-shared --disable-emultls > --with-fix-loongson3-llsc --enable-checking=release > --build=loongarch64-linux-gnu --host=loongarch64-linux-gnu > --target=loongarch64-linux-gnu > Thread model: posix > gcc version 8.3.0 (Loongnix 8.3.0-6.lnd.vec.24) > > $./configure --enable-languages=c,c++ --prefix=/opt/gcc-12.2.0 Don't build in the source directory. https://gcc.gnu.org/wiki/FAQ#configure > --program-suffix=-8 --program-prefix=loongarch64-linux-gnu- --enable-shared > --enable-linker-build-id --without-included-gettext --enable-threads=posix > --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug > --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new > --enable-gnu-unique-object --disable-libitm --disable-libsanitizer > --disable-libquadmath --disable-libquadmath-support --enable-plugin > --with-system-zlib --enable-multiarch --disable-werror > --with-arch=loongarch64 --with-abi=lp64 --enable-tls --enable-initfini-array > --enable-gnu-indirect-function --disable-host-shared --disable-emultls > --with-fix-loongson3-llsc --enable-checking=release > --build=loongarch64-linux-gnu --host=loongarch64-linux-gnu > --target=loongarch64-linux-gnu Why are you including all these options, most of which are already implied by default? https://gcc.gnu.org/wiki/InstallingGCC "If your build fails and your configure command has lots of complicated options you should try removing options and keep it simple. Do not add lots of configure options you don't understand, they might be the reason your build fails." e.g. why do you want the suffix to be -8 when you're building gcc-12? Anyway, the error is in the gmp sub-directory, so you probably need a more recent version of gmp to get loongarch support.
[Bug rtl-optimization/109187] [13 Regression] ICE: qsort checking failed: qsort comparator non-negative on sorted output: 1736258160 at -O2 since r13-5154-g733a1b777f16cd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109187
--- Comment #3 from Alexander Monakov ---
The reduced case is offsetting stack variables in a manner that seems too
invalid for my taste, so I plan to send a patch with a following testcase
instead (needs -O2 --param sched-autopref-queue-depth=1, ICEs on amd64):
void f(int *a)
{
for (;;)
asm("" :: "r"(a[-0x1000]), "r"(a[0x1000]), "r"(a[0]) : "memory");
}
[Bug tree-optimization/109246] Missed optimization for 2-dimensional array with equal values accessed through Enums
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109246 Jakub Jelinek changed: What|Removed |Added CC||aldyh at gcc dot gnu.org, ||amacleod at redhat dot com, ||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Dunno if we had a PR for it, I think it is roughly what https://gcc.gnu.org/pipermail/gcc-patches/2017-April/thread.html#472759 was trying to do. But at this point, it would need to be completely rewritten to be done in the ranger, and as a bonus could handle floating point etc. as well which it previously could only for singletons.
[Bug tree-optimization/109154] [13 regression] jump threading de-optimizes nested floating point comparisons
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109154 --- Comment #8 from Aldy Hernandez --- (In reply to avieira from comment #5) > Im slightly confused here, on entry to BB 5 we know the opposite of _1 < 0.0 > no? if we branch to BB 5 we know !(_1 < 0.0) so we can't fold _1 <= 1.0, we > just know that the range of _1 is >= 0.0 . Or am I misreading, I've not > tried compiling myself just going off the code both of you posted here. Sorry, I should've been more clear. _1 is < 0.0 on entry to BB5, but only on the 4->5->?? path which is what's being analyzed.
[Bug c++/109250] New: Invalid configuration `loongarch64-linux-gnu': machine `loongarch64-unknown' not recognized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109250 Bug ID: 109250 Summary: Invalid configuration `loongarch64-linux-gnu': machine `loongarch64-unknown' not recognized Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: laf163 at hotmail dot com Target Milestone: --- I am trying to compile GCC v12.2.0 on the Kylin Desktop Operating System V10 (SP1), with a loongson-3A5000 CPU. The current GCC version is v8.3, but I am encountering errors during the compilation process. Can you please help me take a look? Kernel: linux 5.4.18-28.23-bj-generic $lscpu Architecture:loongarch64 Byte Order: Little Endian CPU(s): 4 On-line CPU(s) list: 0-3 Thread(s) per core: 1 Core(s) per socket: 4 Socket(s): 1 NUMA node(s):1 CPU family: Loongson-64bit Model name: Loongson-3A5000 BogoMIPS:5000.00 L1d cache: 256 KiB L1i cache: 256 KiB L2 cache:1 MiB L3 cache:16 MiB NUMA node0 CPU(s): 0-3 Flags: cpucfg lam ual fpu lsx lasx complex crypto lvz $gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/loongarch64-linux-gnu/8/lto-wrapper Target: loongarch64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Loongnix 8.3.0-6.lnd.vec.24' --with-bugurl=file:///usr/share/doc/gcc-8/README.Bugs --enable-languages=c,c++,fortran --prefix=/usr --with-gcc-major-version-only --program-suffix=-8 --program-prefix=loongarch64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-libitm --disable-libsanitizer --disable-libquadmath --disable-libquadmath-support --enable-plugin --with-system-zlib --enable-multiarch --disable-werror --with-arch=loongarch64 --with-abi=lp64 --enable-tls --enable-initfini-array --enable-gnu-indirect-function --disable-host-shared --disable-emultls --with-fix-loongson3-llsc --enable-checking=release --build=loongarch64-linux-gnu --host=loongarch64-linux-gnu --target=loongarch64-linux-gnu Thread model: posix gcc version 8.3.0 (Loongnix 8.3.0-6.lnd.vec.24) $./configure --enable-languages=c,c++ --prefix=/opt/gcc-12.2.0 --program-suffix=-8 --program-prefix=loongarch64-linux-gnu- --enable-shared --enable-linker-build-id --without-included-gettext --enable-threads=posix --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-libitm --disable-libsanitizer --disable-libquadmath --disable-libquadmath-support --enable-plugin --with-system-zlib --enable-multiarch --disable-werror --with-arch=loongarch64 --with-abi=lp64 --enable-tls --enable-initfini-array --enable-gnu-indirect-function --disable-host-shared --disable-emultls --with-fix-loongson3-llsc --enable-checking=release --build=loongarch64-linux-gnu --host=loongarch64-linux-gnu --target=loongarch64-linux-gnu $make .. Configuring stage 1 in host-loongarch64-linux-gnu/gmp configure: loading cache ./config.cache checking build system type... Invalid configuration `loongarch64-linux-gnu': machine `loongarch64-unknown' not recognized configure: error: /bin/bash ../.././gmp/config.sub loongarch64-linux-gnu failed ..
[Bug tree-optimization/109249] Missed optimization for table lookups
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109249 Richard Biener changed: What|Removed |Added Ever confirmed|0 |1 Keywords||missed-optimization Last reconfirmed||2023-03-22 Status|UNCONFIRMED |NEW Component|middle-end |tree-optimization --- Comment #3 from Richard Biener --- switch conversion could tackle these "two-dimensional" lookups somehow.
[Bug tree-optimization/109246] Missed optimization for 2-dimensional array with equal values accessed through Enums
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109246 Richard Biener changed: What|Removed |Added Component|middle-end |tree-optimization Last reconfirmed||2023-03-22 Ever confirmed|0 |1 Blocks||85316 Status|UNCONFIRMED |NEW Keywords||missed-optimization --- Comment #1 from Richard Biener --- This is a duplicate of an old bug about VRP not folding reads from static initializers if all elements possibly read have the same value. But I can't currently find it. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85316 [Bug 85316] [meta-bug] VRP range propagation missed cases
[Bug analyzer/109239] -Wanalyzer-deref-before-check seen on Linux kernel due to inlining with -fno-delete-null-pointer-checks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109239 David Malcolm changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #2 from David Malcolm --- Should be fixed by the above patch
[Bug middle-end/109249] Missed optimization for table lookups
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109249
--- Comment #2 from Andre Schackier ---
I'm soryy will keep that in mind for the future :)
Example #1:
#include
#include
enum class Type {
None,
Bug,
Dark,
Dragon,
Electric,
Fighting,
Fire,
Flying,
Ghost,
Grass,
Ground,
Ice,
Normal,
Poison,
Psychic,
Rock,
Steel,
Water,
Count,
};
static constexpr const std::size_t NumberOfTypes =
static_cast(Type::Count);
namespace detail {
constexpr float GetTypeDamageMultiplierImpl(Type defending_type,
Type attacking_type) noexcept {
switch (defending_type) {
case Type::None:
return 1.0f;
case Type::Bug:
switch (attacking_type) {
case Type::Fighting:
case Type::Grass:
case Type::Ground:
return 0.5f;
case Type::Fire:
case Type::Flying:
case Type::Rock:
return 2.0f;
default:
return 1.0f;
}
case Type::Dark:
switch (attacking_type) {
case Type::Psychic:
return 0.0f;
case Type::Dark:
case Type::Ghost:
return 0.5f;
case Type::Bug:
case Type::Fighting:
return 2.0f;
default:
return 1.0f;
}
case Type::Dragon:
switch (attacking_type) {
case Type::Electric:
case Type::Fire:
case Type::Grass:
case Type::Water:
return 0.5f;
case Type::Dragon:
case Type::Ice:
return 2.0f;
default:
return 1.0f;
}
case Type::Electric:
switch (attacking_type) {
case Type::Electric:
case Type::Flying:
case Type::Steel:
return 0.5f;
case Type::Ground:
return 2.0f;
default:
return 1.0f;
}
case Type::Fighting:
switch (attacking_type) {
case Type::Bug:
case Type::Dark:
case Type::Rock:
return 0.5f;
case Type::Flying:
case Type::Psychic:
return 2.0f;
default:
return 1.0f;
}
case Type::Fire:
switch (attacking_type) {
case Type::Bug:
case Type::Fire:
case Type::Grass:
case Type::Ice:
case Type::Steel:
return 0.5f;
case Type::Ground:
case Type::Rock:
case Type::Water:
return 2.0f;
default:
return 1.0f;
}
case Type::Flying:
switch (attacking_type) {
case Type::Ground:
return 0.0f;
case Type::Bug:
case Type::Fighting:
case Type::Grass:
return 0.5f;
case Type::Electric:
case Type::Ice:
case Type::Rock:
return 2.0f;
default:
return 1.0f;
}
case Type::Ghost:
switch (attacking_type) {
case Type::Normal:
case Type::Fighting:
return 0.0f;
case Type::Bug:
case Type::Poison:
return 0.5f;
case Type::Dark:
case Type::Ghost:
return 2.0f;
default:
return 1.0f;
}
case Type::Grass:
switch (attacking_type) {
case Type::Electric:
case Type::Grass:
case Type::Ground:
case Type::Water:
return 0.5f;
case Type::Bug:
case Type::Fire:
case Type::Flying:
case Type::Ice:
case Type::Poison:
return 2.0f;
default:
return 1.0f;
}
case Type::Ground:
switch (attacking_type) {
case Type::Electric:
return 0.0f;
case Type::Poison:
case Type::Rock:
return 0.5f;
case Type::Grass:
case Type::Ice:
case Type::Water:
return 2.0f;
[Bug tree-optimization/109154] [13 regression] jump threading de-optimizes nested floating point comparisons
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109154 --- Comment #7 from Richard Biener --- (In reply to Richard Biener from comment #6) > ah, probably it's the missing CSE there: > > : > _1 = (float) l_10; > _2 = _1 < 0.0; > zone1_17 = (int) _2; > if (_1 < 0.0) > > we are not considering to replace the FP compare control if (_1 < 0.0) > with an integer compare control if (_2 != 0). Maybe we should do that? Just to note it's forwprop which introudces the FP control stmt: _1 = (float) l_10; _2 = _1 < 0.0; zone1_17 = (int) _2; - zone1.1_18 = zone1_17; - if (zone1.1_18 != 0) + if (_1 < 0.0) goto ; [INV] else goto ; [INV] : - iftmp.0_20 = zone1.1_18; : - # iftmp.0_11 = PHI + # iftmp.0_11 = PHI that makes the situation more difficult for VRP, I suppose that relations should still allow us to see zone1_17(4) is 1 on the edge 3->4? For value-numbering the situation is not easily resovable.
[Bug middle-end/109249] Missed optimization for table lookups
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109249 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org --- Comment #1 from Martin Liška --- Please, always provide a test-case, not a link to an external service.
[Bug analyzer/109239] -Wanalyzer-deref-before-check seen on Linux kernel due to inlining with -fno-delete-null-pointer-checks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109239 --- Comment #1 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:0c652ebbf79bd168766097f3ac4c1b3b79d68a43 commit r13-6800-g0c652ebbf79bd168766097f3ac4c1b3b79d68a43 Author: David Malcolm Date: Wed Mar 22 08:40:34 2023 -0400 analyzer: fix false +ves from -Wanalyzer-deref-before-check due to inlining [PR109239] The patch has this effect on my integration tests of -fanalyzer: Comparison: GOOD: 129(17.70% -> 17.92%) BAD: 600 -> 591 (-9) which is purely due to improvements to -Wanalyzer-deref-before-check on the Linux kernel: -Wanalyzer-deref-before-check: GOOD: 1(4.55% -> 7.69%) BAD: 21 -> 12 (-9) Known false positives: 16 -> 10 (-6) linux-5.10.162: 7 -> 1 (-6) Suspected false positives: 3 -> 0 (-3) linux-5.10.162: 3 -> 0 (-3) gcc/analyzer/ChangeLog: PR analyzer/109239 * program-point.cc: Include "analyzer/inlining-iterator.h". (program_point::effectively_intraprocedural_p): New function. * program-point.h (program_point::effectively_intraprocedural_p): New decl. * sm-malloc.cc (deref_before_check::emit): Use it when rejecting interprocedural cases, so that we reject interprocedural cases that have become intraprocedural due to inlining. gcc/testsuite/ChangeLog: PR analyzer/109239 * gcc.dg/analyzer/deref-before-check-pr109239-linux-bus.c: New test. Signed-off-by: David Malcolm
[Bug middle-end/109249] New: Missed optimization for table lookups
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109249 Bug ID: 109249 Summary: Missed optimization for table lookups Product: gcc Version: 12.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: andre.schackier at gmail dot com Target Milestone: --- Example #1 - https://godbolt.org/z/95GjPo9bs gcc: GetTypeDamageMultiplier(Type, Type): sub rsp, 1184 movsx rax, edi movsx rdx, esi mov ecx, 162 lea rdi, [rsp-120] mov esi, OFFSET FLAT:.LC0 lea rax, [rax+rax*8] rep movsq lea rax, [rdx+rax*2] movss xmm0, DWORD PTR [rsp-120+rax*4] add rsp, 1184 ret clang: GetTypeDamageMultiplier(Type, Type): # @GetTypeDamageMultiplier(Type, Type) movsxd rax, edi lea rax, [rax + 8*rax] movsxd rcx, esi lea rax, [rcx + 2*rax] lea rcx, [rip + .L__const.GetTypeDamageMultiplier(Type, Type).table] movss xmm0, dword ptr [rcx + 4*rax] # xmm0 = mem[0],zero,zero,zero ret Example #2 - https://godbolt.org/z/sqocKjYco gcc: GetTypeDamageMultiplier(Type, Type): sub rsp, 144 movsx rdi, edi movsx rsi, esi movaps xmm1, XMMWORD PTR .LC2[rip] movss xmm0, DWORD PTR .LC1[rip] movaps xmm2, XMMWORD PTR .LC6[rip] lea rax, [rsi+rdi*8] movaps XMMWORD PTR [rsp-72], xmm1 movaps xmm1, XMMWORD PTR .LC3[rip] shufps xmm0, xmm0, 0 movaps XMMWORD PTR [rsp-120], xmm0 movaps XMMWORD PTR [rsp-104], xmm0 movaps XMMWORD PTR [rsp-88], xmm0 movaps XMMWORD PTR [rsp+8], xmm0 movaps xmm0, XMMWORD PTR .LC7[rip] movaps XMMWORD PTR [rsp-56], xmm1 movaps xmm1, XMMWORD PTR .LC4[rip] movaps XMMWORD PTR [rsp+24], xmm0 movaps xmm0, XMMWORD PTR .LC8[rip] movaps XMMWORD PTR [rsp-40], xmm1 movaps xmm1, XMMWORD PTR .LC5[rip] movaps XMMWORD PTR [rsp+40], xmm0 movaps xmm0, XMMWORD PTR .LC9[rip] movaps XMMWORD PTR [rsp-24], xmm1 movaps XMMWORD PTR [rsp+56], xmm1 movaps xmm1, XMMWORD PTR .LC10[rip] movaps XMMWORD PTR [rsp+72], xmm0 movaps XMMWORD PTR [rsp+104], xmm0 movaps xmm0, XMMWORD PTR .LC11[rip] movaps XMMWORD PTR [rsp-8], xmm2 movaps XMMWORD PTR [rsp+88], xmm1 movaps XMMWORD PTR [rsp+120], xmm0 movss xmm0, DWORD PTR [rsp-120+rax*4] add rsp, 144 ret clang: GetTypeDamageMultiplier(Type, Type): # @GetTypeDamageMultiplier(Type, Type) movsxd rax, edi movsxd rcx, esi lea rax, [rcx + 8*rax] lea rcx, [rip + .L__const.GetTypeDamageMultiplier(Type, Type).table] movss xmm0, dword ptr [rcx + 4*rax] # xmm0 = mem[0],zero,zero,zero ret
[Bug tree-optimization/109154] [13 regression] jump threading de-optimizes nested floating point comparisons
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109154 --- Comment #6 from Richard Biener --- We have if (_1 < 0.0) # PHI < .., ..> // the if above only controls which PHI arg we take ... code ... if (_1 < 1.0e+0) # PHI < .., ...> // likewise and are threading _1 < 0.0 -> _1 < 1.0e+0 So on the _1 < 0.0 path we are eliding one conditional jump. The main pessimization would be that we now have an additional entry to the 2nd PHI, but with the same value as the _1 < 1.0 path, so a forwarder would be able to "solve" that IL detail. The only heuristic I can imagine doing is to avoid extra entries into a diamond that's really just a simple COND_EXPR. What's odd is that with -fno-thread-jumps it's the dom2 pass optimizes the branching of the first compare: _1 = (float) l_21; _2 = _1 < 0.0; zone1_15 = (int) _2; - if (_1 < 0.0) -goto ; [41.00%] - else -goto ; [59.00%] - - [local count: 391808389]: - - [local count: 955630225]: - # iftmp.0_10 = PHI fasten_main_natpro_chrg_init.2_3 = fasten_main_natpro_chrg_init; - _4 = fasten_main_natpro_chrg_init.2_3 * iftmp.0_10; - _5 = (float) _4; + _4 = fasten_main_natpro_chrg_init.2_3; + _5 = (float) fasten_main_natpro_chrg_init.2_3; but we fail to see this opportunity earlier (maybe the testcase is too simplified?). When we thread the jump this simplification opportunity is lost. I wonder if exactly how DOM handles this - it does Visiting conditional with predicate: if (_1 < 0.0) With known ranges _1: [frange] float VARYING +-NAN Predicate evaluates to: DON'T KNOW LKUP STMT _1 lt_expr 0.0 FIND: _2 Replaced redundant expr '_1 < 0.0' with '_2' 0>>> COPY _2 = 0 COPY _2 = 0 Optimizing block #4 1>>> STMT 1 = _1 ordered_expr 0.0 1>>> STMT 1 = _1 ltgt_expr 0.0 1>>> STMT 1 = _1 le_expr 0.0 1>>> STMT 1 = _1 ne_expr 0.0 1>>> STMT 0 = _1 eq_expr 0.0 1>>> STMT 0 = truth_not_expr _1 < 0.0 0>>> COPY _2 = 1 Match-and-simplified (int) _2 to 1 0>>> COPY zone1_15 = 1 how does it go backwards adjusting zone1_15?! Anyhow - EVRP doesn't seem to handle any of this (replacing PHI arguments by values on edges to see if the PHI becomes singleton, or even handling the PHI "properly"): Visiting conditional with predicate: if (_1 < 0.0) With known ranges _1: [frange] float VARYING +-NAN Predicate evaluates to: DON'T KNOW Not folded Global Exported: iftmp.0_11 = [irange] int [0, 1] NONZERO 0x1 Folding PHI node: iftmp.0_11 = PHI No folding possible ah, probably it's the missing CSE there: : _1 = (float) l_10; _2 = _1 < 0.0; zone1_17 = (int) _2; if (_1 < 0.0) we are not considering to replace the FP compare control if (_1 < 0.0) with an integer compare control if (_2 != 0). Maybe we should do that? So to me it doesn't look like a bug in jump threading but at most a phase ordering issue or an early missed optimization. Yes, we could eventually tame down jump threading with some additional heuristic. But IMHO optimizing the above earlier would be better?
[Bug modula2/109248] New: gm2 should include cwd to the module search path
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109248 Bug ID: 109248 Summary: gm2 should include cwd to the module search path Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: modula2 Assignee: gaius at gcc dot gnu.org Reporter: gaius at gcc dot gnu.org Target Milestone: --- gm2 should include the current working directory to the search path by default.
[Bug libstdc++/108178] Filesystem::copy_file can't copy from /proc on Linux machines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108178 --- Comment #6 from Jonathan Wakely --- Patch: https://gcc.gnu.org/pipermail/gcc-patches/2023-March/614415.html
[Bug c++/109247] [13 Regression] error: converting to ‘optional’ from initializer list would use explicit constructor ‘optional<_Tp>::optional(_Up) [with _Up = int; _Tp =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109247 Martin Liška changed: What|Removed |Added Priority|P3 |P1 Target Milestone|--- |13.0 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2023-03-22
