[Bug libgcc/96948] _Unwind_GetIP() and _Unwind_GetIPInfo() empty in _Unwind_Backtrace() with SEH on mingw64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96948 --- Comment #3 from Richard Biener --- Patches should be sent to gcc-patc...@gcc.gnu.org
[Bug debug/96937] Duplicate DW_TAG_formal_parameter in out-of-line DW_TAG_subprogram instance
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96937 Richard Biener changed: What|Removed |Added CC||rguenth at gcc dot gnu.org Last reconfirmed||2020-09-07 Status|UNCONFIRMED |WAITING Ever confirmed|0 |1 --- Comment #3 from Richard Biener --- Hmm, can you point out the issue in the reduced testcase? I can't see it. The only cloning done I see is partial inlining so does -fno-partial-inlining fix the issue for you?
[PATCH v2] rs6000: Expand vec_insert in expander instead of gimple [PR79251]
Hi,
On 2020/9/4 18:23, Segher Boessenkool wrote:
diff --git a/gcc/config/rs6000/rs6000-c.c b/gcc/config/rs6000/rs6000-c.c
index 03b00738a5e..00c65311f76 100644
--- a/gcc/config/rs6000/rs6000-c.c
+++ b/gcc/config/rs6000/rs6000-c.c
/* Build *(((arg1_inner_type*)&(vector type){arg1})+arg2) = arg0. */
@@ -1654,15 +1656,8 @@ altivec_resolve_overloaded_builtin (location_t loc, tree
fndecl,
SET_EXPR_LOCATION (stmt, loc);
stmt = build1 (COMPOUND_LITERAL_EXPR, arg1_type, stmt);
}
-
- innerptrtype = build_pointer_type (arg1_inner_type);
-
- stmt = build_unary_op (loc, ADDR_EXPR, stmt, 0);
- stmt = convert (innerptrtype, stmt);
- stmt = build_binary_op (loc, PLUS_EXPR, stmt, arg2, 1);
- stmt = build_indirect_ref (loc, stmt, RO_NULL);
- stmt = build2 (MODIFY_EXPR, TREE_TYPE (stmt), stmt,
-convert (TREE_TYPE (stmt), arg0));
+ stmt = build_array_ref (loc, stmt, arg2);
+ stmt = fold_build2 (MODIFY_EXPR, TREE_TYPE (arg0), stmt, arg0);
stmt = build2 (COMPOUND_EXPR, arg1_type, stmt, decl);
return stmt;
}
You should make a copy of the vector, not modify the original one in
place? (If I read that correctly, heh.) Looks good otherwise.
Segher, there is already existed code to make a copy of vector as we
discussed offline. Thanks for the reminder.
cat pr79251.c.006t.gimple
__attribute__((noinline))
test (__vector signed int v, int i, size_t n)
{
__vector signed int D.3192;
__vector signed int D.3194;
__vector signed int v1;
v1 = v;
D.3192 = v1;
_1 = n & 3;
VIEW_CONVERT_EXPR(D.3192)[_1] = i;
v1 = D.3192;
D.3194 = v1;
return D.3194;
}
Attached the v2 patch which does:
1) Build VIEW_CONVERT_EXPR for vec_insert (i, v, n) like v[n%4] = i to
unify the gimple code, then expander could use vec_set_optab to expand.
2) Recognize the pattern in expander and use optabs to expand
VIEW_CONVERT_EXPR to vec_insert with variable index to fast instructions:
lvsl+xxperm+xxsel.
Thanks,
Xionghu
From 9a7a47b086579e26ae13f378732cea067b64a4e6 Mon Sep 17 00:00:00 2001
From: Xiong Hu Luo
Date: Wed, 19 Aug 2020 03:54:17 -0500
Subject: [PATCH v2] rs6000: Expand vec_insert in expander instead of gimple
[PR79251]
vec_insert accepts 3 arguments, arg0 is input vector, arg1 is the value
to be insert, arg2 is the place to insert arg1 to arg0. Current expander
generates stxv+stwx+lxv if arg2 is variable instead of constant, which
causes serious store hit load performance issue on Power. This patch tries
1) Build VIEW_CONVERT_EXPR for vec_insert (i, v, n) like v[n%4] = i to
unify the gimple code, then expander could use vec_set_optab to expand.
2) Recognize the pattern in expander and use optabs to expand
VIEW_CONVERT_EXPR to vec_insert with variable index to fast instructions:
lvsl+xxperm+xxsel.
In this way, "vec_insert (i, v, n)" and "v[n%4] = i" won't be expanded too
early in gimple stage if arg2 is variable, avoid generating store hit load
instructions.
For Power9 V4SI:
addi 9,1,-16
rldic 6,6,2,60
stxv 34,-16(1)
stwx 5,9,6
lxv 34,-16(1)
=>
addis 9,2,.LC0@toc@ha
addi 9,9,.LC0@toc@l
mtvsrwz 33,5
lxv 32,0(9)
sradi 9,6,2
addze 9,9
sldi 9,9,2
subf 9,9,6
subfic 9,9,3
sldi 9,9,2
subfic 9,9,20
lvsl 13,0,9
xxperm 33,33,45
xxperm 32,32,45
xxsel 34,34,33,32
Though instructions increase from 5 to 15, the performance is improved
60% in typical cases.
Tested with V2DI, V2DF V4SI, V4SF, V8HI, V16QI on Power9-LE and
Power8-BE, bootstrap tested pass.
gcc/ChangeLog:
2020-09-07 Xionghu Luo
* config/rs6000/altivec.md (altivec_lvsl_reg_2): Rename to
(altivec_lvsl_reg_2) and extend to SDI mode.
* config/rs6000/rs6000-c.c (altivec_resolve_overloaded_builtin):
Ajdust variable index vec_insert to VIEW_CONVERT_EXPR.
* config/rs6000/rs6000-protos.h (rs6000_expand_vector_set_var):
New declare.
* config/rs6000/rs6000.c (rs6000_expand_vector_set_var):
New function.
* config/rs6000/rs6000.md (FQHS): New mode iterator.
(FD): New mode iterator.
p8_mtvsrwz_v16qi2: New define_insn.
p8_mtvsrd_v16qi2: New define_insn.
* config/rs6000/vector.md: Add register operand2 match for
vec_set index.
* config/rs6000/vsx.md: Call gen_altivec_lvsl_reg_di2.
* expr.c (expand_view_convert_to_vec_set): New function.
(expand_assignment): Call expand_view_convert_to_vec_set.
gcc/testsuite/ChangeLog:
2020-09-07 Xionghu Luo
* gcc.target/powerpc/pr79251.c: New test.
* gcc.target/powerpc/pr79251-run.c: New test.
* gcc.target/powerpc/pr79251.h: New header.
---
gcc/config/rs6000/altivec.md | 4 +-
gcc/config/rs6000/rs6000-c.c | 22 ++-
gcc/config/rs6000/rs6000-protos.h | 1 +
[Bug analyzer/96950] New: ICE in apply_ctor_val_to_range, at analyzer/store.cc:475
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96950 Bug ID: 96950 Summary: ICE in apply_ctor_val_to_range, at analyzer/store.cc:475 Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: analyzer Assignee: dmalcolm at gcc dot gnu.org Reporter: asolokha at gmx dot com Target Milestone: --- Target: powerpc-*-linux-gnu gfortran-11.0.0-alpha20200906 snapshot (g:23f8b90c401842afcbaa50a7fd3c2f37818f4396) ICEs when compiling gcc/testsuite/gfortran.dg/alloc_comp_scalar_1.f90, gcc/testsuite/gfortran.dg/associate_13.f90 w/ -fanalyzer: % powerpc-e300c3-linux-gnu-gfortran-11.0.0 -fanalyzer -c gcc/testsuite/gfortran.dg/alloc_comp_scalar_1.f90 -o /dev/null during IPA pass: analyzer gcc/testsuite/gfortran.dg/alloc_comp_scalar_1.f90:11:0: 11 | type(container_t), dimension(1) :: a1, a2 | internal compiler error: in apply_ctor_val_to_range, at analyzer/store.cc:475 0x703084 ana::binding_map::apply_ctor_val_to_range(ana::region const*, ana::region_model_manager*, tree_node*, tree_node*, tree_node*) /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20200906/work/gcc-11-20200906/gcc/analyzer/store.cc:475 0x11fbe35 ana::binding_map::apply_ctor_to_region(ana::region const*, tree_node*, ana::region_model_manager*) /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20200906/work/gcc-11-20200906/gcc/analyzer/store.cc:428 0x11c8a5a ana::decl_region::get_svalue_for_constructor(tree_node*, ana::region_model_manager*) const /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20200906/work/gcc-11-20200906/gcc/analyzer/region.cc:907 0x11cd8ae ana::region_model::get_initial_value_for_global(ana::region const*) const /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20200906/work/gcc-11-20200906/gcc/analyzer/region-model.cc:1283 0x11cf7d3 ana::region_model::get_rvalue(ana::path_var, ana::region_model_context*) /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20200906/work/gcc-11-20200906/gcc/analyzer/region-model.cc:1223 0x11b95a8 ana::impl_sm_context::on_transition(ana::supernode const*, gimple const*, tree_node*, unsigned int, unsigned int, tree_node*) /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20200906/work/gcc-11-20200906/gcc/analyzer/engine.cc:221 0x11ef6a6 on_zero_assignment /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20200906/work/gcc-11-20200906/gcc/analyzer/sm-malloc.cc:916 0x11f0ffb on_stmt /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20200906/work/gcc-11-20200906/gcc/analyzer/sm-malloc.cc:771 0x11b32cb ana::exploded_node::on_stmt(ana::exploded_graph&, ana::supernode const*, gimple const*, ana::program_state*) const /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20200906/work/gcc-11-20200906/gcc/analyzer/engine.cc:1098 0x11b4385 ana::exploded_graph::process_node(ana::exploded_node*) /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20200906/work/gcc-11-20200906/gcc/analyzer/engine.cc:2526 0x11b4be2 ana::exploded_graph::process_worklist() /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20200906/work/gcc-11-20200906/gcc/analyzer/engine.cc:2341 0x11b6cc4 ana::impl_run_checkers(ana::logger*) /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20200906/work/gcc-11-20200906/gcc/analyzer/engine.cc:4107 0x11b7971 ana::run_checkers() /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20200906/work/gcc-11-20200906/gcc/analyzer/engine.cc:4175 0x11ac548 execute /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20200906/work/gcc-11-20200906/gcc/analyzer/analyzer-pass.cc:84 (While my target here is powerpc, the ICE should not be target-specific.)
Re: [patch] Fortran: fix prototype of _gfortran_is_extension_of()
Hi FX, Regtested on x86_64-apple-darwin19 and tested on aarch64-apple-darwin20. OK to commit? Looks good to me. Best regards Thomas
[Bug analyzer/96949] New: ICE in get_bit_offset, at analyzer/analyzer.h:164
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96949 Bug ID: 96949 Summary: ICE in get_bit_offset, at analyzer/analyzer.h:164 Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: analyzer Assignee: dmalcolm at gcc dot gnu.org Reporter: asolokha at gmx dot com Target Milestone: --- Target: powerpc-*-linux-gnu gfortran-11.0.0-alpha20200906 snapshot (g:23f8b90c401842afcbaa50a7fd3c2f37818f4396) ICEs when compiling the following testcase w/ -fanalyzer --param analyzer-max-svalue-depth=0: program n6 integer :: ck(2,2) integer :: ac data ck /4 * 1/ call x9() contains subroutine x9() if (ck(2, 1) == 1) then ac = 1 else ac = 0 end if end subroutine x9 end program n6 % powerpc-e300c3-linux-gnu-gfortran-11.0.0 -fanalyzer --param analyzer-max-svalue-depth=0 -c d6ym5nxs.f90 during IPA pass: analyzer d6ym5nxs.f90:11:0: 11 | if (ck(2, 1) == 1) then | internal compiler error: in get_bit_offset, at analyzer/analyzer.h:164 0x70304f ana::region_offset::get_bit_offset() const /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20200906/work/gcc-11-20200906/gcc/analyzer/analyzer.h:164 0x70304f ana::region_offset::get_bit_offset() const /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20200906/work/gcc-11-20200906/gcc/analyzer/analyzer.h:162 0x70304f ana::binding_map::apply_ctor_val_to_range(ana::region const*, ana::region_model_manager*, tree_node*, tree_node*, tree_node*) /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20200906/work/gcc-11-20200906/gcc/analyzer/store.cc:460 0x11fbe35 ana::binding_map::apply_ctor_to_region(ana::region const*, tree_node*, ana::region_model_manager*) /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20200906/work/gcc-11-20200906/gcc/analyzer/store.cc:428 0x11c8a5a ana::decl_region::get_svalue_for_constructor(tree_node*, ana::region_model_manager*) const /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20200906/work/gcc-11-20200906/gcc/analyzer/region.cc:907 0x11cd8ae ana::region_model::get_initial_value_for_global(ana::region const*) const /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20200906/work/gcc-11-20200906/gcc/analyzer/region-model.cc:1283 0x11cf7d3 ana::region_model::get_rvalue(ana::path_var, ana::region_model_context*) /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20200906/work/gcc-11-20200906/gcc/analyzer/region-model.cc:1223 0x11cfbd7 ana::region_model::on_assignment(gassign const*, ana::region_model_context*) /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20200906/work/gcc-11-20200906/gcc/analyzer/region-model.cc:562 0x11b314a ana::exploded_node::on_stmt(ana::exploded_graph&, ana::supernode const*, gimple const*, ana::program_state*) const /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20200906/work/gcc-11-20200906/gcc/analyzer/engine.cc:1029 0x11b4385 ana::exploded_graph::process_node(ana::exploded_node*) /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20200906/work/gcc-11-20200906/gcc/analyzer/engine.cc:2526 0x11b4be2 ana::exploded_graph::process_worklist() /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20200906/work/gcc-11-20200906/gcc/analyzer/engine.cc:2341 0x11b6cc4 ana::impl_run_checkers(ana::logger*) /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20200906/work/gcc-11-20200906/gcc/analyzer/engine.cc:4107 0x11b7971 ana::run_checkers() /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20200906/work/gcc-11-20200906/gcc/analyzer/engine.cc:4175 0x11ac548 execute /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20200906/work/gcc-11-20200906/gcc/analyzer/analyzer-pass.cc:84 (While my target here is powerpc, the ICE should not be target-specific.)
Re: *Ping*: [PATCH] PR fortran/96711 - ICE on NINT() Function
Hi Harald, *ping* I don't really know about the convert vs. fold_convert issue either, but if it works, it works. Regarding the patch: Could you change the test caes into a run-time test and check for the results both for compile-time simplification and evaluation at run-time? Just to make sure that fold_convert wasn't trying to tell us something that convert doesn't... OK with that change. Thanks for the patch! Best regards Thomas
[Bug libgcc/96948] _Unwind_GetIP() and _Unwind_GetIPInfo() empty in _Unwind_Backtrace() with SEH on mingw64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96948 --- Comment #2 from Kirill Müller --- $ gcc -v Using built-in specs. COLLECT_GCC=C:\rtools40_\mingw64\bin\gcc.exe COLLECT_LTO_WRAPPER=C:/rtools40_/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/8.3.0/lto-wrapper.exe Target: x86_64-w64-mingw32 Configured with: ../gcc-8.3.0/configure --prefix=/mingw64 --with-local-prefix=/mingw64/local --build=x86_64-w64-mingw32 --host=x86_64-w64-mingw32 --target=x86_64-w64-mingw32 --with-native-system-header-dir=/mingw64/x86_64-w64-mingw32/include --libexecdir=/mingw64/lib --enable-bootstrap --with-arch=x86-64 --with-tune=generic --enable-languages=c,lto,c++,fortran --disable-shared --enable-static --enable-libatomic --enable-threads=posix --enable-graphite --enable-fully-dynamic-string --enable-libstdcxx-filesystem-ts=yes --enable-libstdcxx-time=yes --disable-libstdcxx-pch --disable-libstdcxx-debug --disable-isl-version-check --enable-lto --enable-libgomp --disable-multilib --enable-checking=release --disable-rpath --disable-win32-registry --disable-nls --disable-werror --disable-symvers --with-libiconv --with-system-zlib --with-gmp=/mingw64 --with-mpfr=/mingw64 --with-mpc=/mingw64 --with-isl=/mingw64 --with-pkgversion='Built by Jeroen for the R-project' --with-bugurl=https://github.com/r-windows --with-gnu-as --with-gnu-ld Thread model: posix gcc version 8.3.0 (Built by Jeroen for the R-project)
[Bug libgcc/96948] _Unwind_GetIP() and _Unwind_GetIPInfo() empty in _Unwind_Backtrace() with SEH on mingw64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96948 --- Comment #1 from Kirill Müller --- Created attachment 49188 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49188=edit Proposed patch
[Bug libgcc/96948] New: _Unwind_GetIP() and _Unwind_GetIPInfo() empty in _Unwind_Backtrace() with SEH on mingw64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96948 Bug ID: 96948 Summary: _Unwind_GetIP() and _Unwind_GetIPInfo() empty in _Unwind_Backtrace() with SEH on mingw64 Product: gcc Version: 8.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcc Assignee: unassigned at gcc dot gnu.org Reporter: krlmlr+gcc at mailbox dot org Target Milestone: --- Created attachment 49187 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49187=edit Reproducible example The attached program, modeled after `btest.c` in libbacktrace, produces the following output in mingw64 (SEH): 0/0[0] (403180) 0/0[0] (4015da) 0/0[0] (4011a0) 0/0[0] (401510) 0/0[0] (7ffb6e4d7bc0) 0/0[0] (7ffb6e90ce30) The first two numbers are _Unwind_GetIP() and _Unwind_GetIPInfo(). The last number is _Unwind_GetRegionStart(), which appears to be correct. Note how the first address is different from the next three -- this seems to be located in libgcc and should be stripped. Applying https://github.com/gcc-mirror/gcc/pull/48 gives the following: 4015ff/4015ff[0] (4015da) 4013c5/4013c5[0] (4011a0) 40152b/40152b[0] (401510) 7ffb6e4d7bd4/7ffb6e4d7bd4[0] (7ffb6e4d7bc0) 7ffb6e90ce51/7ffb6e90ce51[0] (7ffb6e90ce30) Raw patch attached. Tested on Windows in gcc 8.3.0 in the rtools40 toolchain, a custom msys2 environment: https://cran.r-project.org/bin/windows/Rtools/. The mingw32 (SJLJ) version is not affected.
[PATCH] aarch64: Add cpu cost tables for A64FX
This patch add cost tables for A64FX.
ChangeLog:
2020-09-07 Qian jianhua
gcc/
* config/aarch64/aarch64-cost-tables.h (a64fx_extra_costs): New.
* config/aarch64/aarch64.c (a64fx_addrcost_table): New.
(a64fx_regmove_cost, a64fx_vector_cost): New.
(a64fx_tunings): Use the new added cost tables.
Test Results:
* Bootstrap on aarch64 --- [OK]
* Regression tests --- [OK]
* Compile with -mcpu=a64fx --- [OK]
Regards!
---
gcc/config/aarch64/aarch64-cost-tables.h | 103 +++
gcc/config/aarch64/aarch64.c | 53 +++-
2 files changed, 152 insertions(+), 4 deletions(-)
diff --git a/gcc/config/aarch64/aarch64-cost-tables.h
b/gcc/config/aarch64/aarch64-cost-tables.h
index 8a98bf4278c..c6805717f6e 100644
--- a/gcc/config/aarch64/aarch64-cost-tables.h
+++ b/gcc/config/aarch64/aarch64-cost-tables.h
@@ -541,4 +541,107 @@ const struct cpu_cost_table tsv110_extra_costs =
}
};
+const struct cpu_cost_table a64fx_extra_costs =
+{
+ /* ALU */
+ {
+0, /* arith. */
+0, /* logical. */
+0, /* shift. */
+0, /* shift_reg. */
+COSTS_N_INSNS (1), /* arith_shift. */
+COSTS_N_INSNS (1), /* arith_shift_reg. */
+COSTS_N_INSNS (1), /* log_shift. */
+COSTS_N_INSNS (1), /* log_shift_reg. */
+0, /* extend. */
+COSTS_N_INSNS (1), /* extend_arith. */
+0, /* bfi. */
+0, /* bfx. */
+0, /* clz. */
+0, /* rev. */
+0, /* non_exec. */
+true /* non_exec_costs_exec. */
+ },
+ {
+/* MULT SImode */
+{
+ COSTS_N_INSNS (4), /* simple. */
+ COSTS_N_INSNS (4), /* flag_setting. */
+ COSTS_N_INSNS (4), /* extend. */
+ COSTS_N_INSNS (5), /* add. */
+ COSTS_N_INSNS (5), /* extend_add. */
+ COSTS_N_INSNS (18) /* idiv. */
+},
+/* MULT DImode */
+{
+ COSTS_N_INSNS (4), /* simple. */
+ 0, /* flag_setting (N/A). */
+ COSTS_N_INSNS (4), /* extend. */
+ COSTS_N_INSNS (5), /* add. */
+ COSTS_N_INSNS (5), /* extend_add. */
+ COSTS_N_INSNS (26) /* idiv. */
+}
+ },
+ /* LD/ST */
+ {
+COSTS_N_INSNS (4), /* load. */
+COSTS_N_INSNS (4), /* load_sign_extend. */
+COSTS_N_INSNS (5), /* ldrd. */
+COSTS_N_INSNS (4), /* ldm_1st. */
+1, /* ldm_regs_per_insn_1st. */
+2, /* ldm_regs_per_insn_subsequent. */
+COSTS_N_INSNS (4), /* loadf. */
+COSTS_N_INSNS (4), /* loadd. */
+COSTS_N_INSNS (5), /* load_unaligned. */
+0, /* store. */
+0, /* strd. */
+0, /* stm_1st. */
+1, /* stm_regs_per_insn_1st. */
+2, /* stm_regs_per_insn_subsequent. */
+0, /* storef. */
+0, /* stored. */
+0, /* store_unaligned. */
+COSTS_N_INSNS (1), /* loadv. */
+COSTS_N_INSNS (1) /* storev. */
+ },
+ {
+/* FP SFmode */
+{
+ COSTS_N_INSNS (6), /* div. */
+ COSTS_N_INSNS (1), /* mult. */
+ COSTS_N_INSNS (1), /* mult_addsub. */
+ COSTS_N_INSNS (2), /* fma. */
+ COSTS_N_INSNS (1), /* addsub. */
+ COSTS_N_INSNS (1), /* fpconst. */
+ COSTS_N_INSNS (1), /* neg. */
+ COSTS_N_INSNS (1), /* compare. */
+ COSTS_N_INSNS (2), /* widen. */
+ COSTS_N_INSNS (2), /* narrow. */
+ COSTS_N_INSNS (2), /* toint. */
+ COSTS_N_INSNS (2), /* fromint. */
+ COSTS_N_INSNS (2)/* roundint. */
+},
+/* FP DFmode */
+{
+ COSTS_N_INSNS (11), /* div. */
+ COSTS_N_INSNS (1), /* mult. */
+ COSTS_N_INSNS (1), /* mult_addsub. */
+ COSTS_N_INSNS (2), /* fma. */
+ COSTS_N_INSNS (1), /* addsub. */
+ COSTS_N_INSNS (1), /* fpconst. */
+ COSTS_N_INSNS (1), /* neg. */
+ COSTS_N_INSNS (1), /* compare. */
+ COSTS_N_INSNS (2), /* widen. */
+ COSTS_N_INSNS (2), /* narrow. */
+ COSTS_N_INSNS (2), /* toint. */
+ COSTS_N_INSNS (2), /* fromint. */
+ COSTS_N_INSNS (2)/* roundint. */
+}
+ },
+ /* Vector */
+ {
+COSTS_N_INSNS (1) /* alu. */
+ }
+};
+
#endif
diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index b6d74496cd0..3eaadcfd4ac 100644
--- a/gcc/config/aarch64/aarch64.c
+++
[Bug target/96933] rs6000: inefficient code for char/short vec CTOR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96933 --- Comment #5 from Kewen Lin --- (In reply to Segher Boessenkool from comment #4) > Yes, timing suggests there is some SHL/LHS flush. > > On p9 and later we can use mtvsrdd instead of mtvsrd (moving two > bytes into place at one), which reduces the number of moves from > 16 to 8, and the number of merges from 15 to 7 (and reduces path > length by 1). This sounds like a no-brainer win with that :-) Good idea, it looks better on P9. One thing to double confirm, currently there are no instructions like vmrgob and vmrgoh, so of the mergings you mentioned from vector bytes to vector short and vector short to vector word needs artificial control vector?
Re: ubsan: d-demangle.c:214 signed integer overflow
On Fri, Sep 04, 2020 at 06:23:10PM +0200, Iain Buclaw wrote: > If we're already using limits.h, I guess it should be fine to also add > > #define UINT_MAX ((unsigned) ~0U) Yes, except that I'll use the simpler fall-back #define UINT_MAX (~0U) The habit of using a cast for unsigned constants dates back to K C where a U suffix was not valid. For example, from libiberty/strtol.c #define ULONG_MAX ((unsigned long)(~0L)) Since the code uses ISO/ANSI C features such as prototypes I think we're OK with a U suffix. And if there's something I'm missing then #define UINT_MAX ((unsigned) ~0) would be correct for K > I'll leave it to your judgement on that though. > > Other than that, OK from me. Do I need an OK from Ian too? -- Alan Modra Australia Development Lab, IBM
[Bug tree-optimization/96923] Failure to optimize a select-related bool pattern to or+not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96923 Andrew Pinski changed: What|Removed |Added Depends on||25290 --- Comment #2 from Andrew Pinski --- Note if we spell out the ?:, this would require PR 25290 too. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25290 [Bug 25290] PHI-OPT could be rewritten so that is uses match
[Bug tree-optimization/96923] Failure to optimize a select-related bool pattern to or+not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96923 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement
Re: about souce code location
On 9/4/20 6:26 AM, 易会战 via Gcc wrote: how to check the location corresponding to a gimple statement? My instrument stmt include some memory access, I wish get right source code line. By context it is possible get wrong line. The gimple_location() function returns the location of the GIMPLE statement passed to it as an argument. When the location isn't available (e.g., because the statement corresponds to two or more source lines) there isn't much you can do to retrieve it. Sometimes it's possible to come close by using the location of the next (or previous) GIMPLE statement. Other times the best you can do is point at the function body (either the opening or closing curly). Martin ---Original--- From: "Richard Biener"
[Bug middle-end/95189] [9/10 Regression] memcmp being wrongly stripped like strcmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95189 --- Comment #16 from Martin Sebor --- I think it should be. Let me do it.
Re: Function signatures in extern "C".
GCC has an extension on machaines with cxx_implicit_extern_c (what used to be !NO_IMPLICIT_EXTERN_C). On such targets we'll treat 'extern "C" void Foo ()' as-if the argument list is variadic. (or something approximating that) perhaps that is confusing things? nathan On 9/6/20 4:43 PM, Iain Sandoe wrote: Jonathan Wakely via Gcc wrote: On Sun, 6 Sep 2020 at 16:23, Iain Sandoe wrote: g++.dg/abi/guard3.C has: extern "C" int __cxa_guard_acquire(); Which might not be a suitable declaration, depending on how the ‘extern “C”’ is supposed to affect the function signature generated. IF, the extern C should make this parse as a “K” style function - then the TYPE_ARG_TYPES should be NULL (and the testcase is OK). However, we are parsing the decl as int __cxa_guard_acquire(void) (i.e. C++ rules on the empty parens), which makes the testcase not OK. That is the correct parse. Using extern "C" doesn't mean the code is C, it only affects mangling. It still has to follow C++ rules. In practice you can still link to the definition, because its name is just "__cxa_guard_acquire" irrespective of what parameter list is present in the declaration. Linking isn’t the problem in this case. The problem is that we arrive at “expand_call” with a function decl that says f(void) .. and a call parmeter list containing a pointer type. We happily pass the pointer in the place of the ‘void’ - because the code only counts the number of entries and there’s one - so it happens to work. .. that’s not true in the general case and for all calling conventions. (this is what I mean by it happens to work by luck below). This means that the declaration is now misleading (and it’s just luck that expand_call happens to count the length of the TYPE_ARG_TYPES list without looking to see what the types are) - in this case it happens to work out from this luck - since there’s only one arg so the length of the void args list agrees with what we want. —— So .. the question is “which is wrong, the test-case or the assignment of the TYPE_ARG_TYPES”? [we can’t easily diagnose this at this point, but I do have a patch to diagnose the case where we pass a void-list to expand_call and then try to expand a call to the callee with an inappropriate set of parms] (it’s trivial to fix the test-case as extern "C" int __cxa_guard_acquire(__UINT64_TYPE__ *);, I guess) But PR 45603 is ice-on-invalid triggered by the incorrect declaration of __cxa_guard_acquire. So the incorrect declaration is what originally reproduced the bug, and "fixing" it would make the test useless. Ah OK. It's probably worth adding a comment about that in the test. Yes - that would help (will add it to my TODO). Maybe the test should give a compile-time error and XFAIL, but fixing the declaration doesn't seem right. I guess (because the code is invalid) there’s not much motivation to make it more robust - e.g. diagnose the mismatch in the call(s) synthesized to __cxa_guard_acquire. It seems we only try to build these function decl(s) once - lazily - so that a wrong one will persist for the whole TU (and we don’t seem to check that the decl matches the itanium ABI - perhaps that’s intentional tho). cheers Iain -- Nathan Sidwell
gcc-11-20200906 is now available
Snapshot gcc-11-20200906 is now available on https://gcc.gnu.org/pub/gcc/snapshots/11-20200906/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 11 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch master revision 23f8b90c401842afcbaa50a7fd3c2f37818f4396 You'll find: gcc-11-20200906.tar.xz Complete GCC SHA256=ac017f84cb7ff42f8e7e6fea2bff8b45d586eb4333467c18daa2002a6f2265d0 SHA1=1f502e4603b081268d5440b02d53e6a3aadef587 Diffs from 11-20200830 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-11 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
[Bug ipa/96394] [10/11 Regression] ICE in add_new_edges_to_heap, at ipa-inline.c:1746 (-O3 PGO)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96394 --- Comment #9 from Sergei Trofimovich --- (In reply to Sergei Trofimovich from comment #8) > Might end up being caused by the same bug in PR96913: TOPN streaming > from/for shared libraries is incorrect. > > Proposed patch: > https://gcc.gnu.org/pipermail/gcc-patches/2020-September/553320.html The patch is not enough to fix the ICE. It only converts gcc-11's hangup to the ICE (as as gcc-10). Here is the somewhat selfcontained reproducer of the original bug: https://dev.gentoo.org/~slyfox/bugs/96394-pgo-ipa-ICE/tauthon-repro- gcc-10.tar.bz2 (13MB) The result on gcc-11 with above gcc patch: $ LANG=C ./try.bash ... < takes a while > during IPA pass: inline ../tauthon-2.8.2/Modules/parsermodule.c:3760:1: internal compiler error: in add_new_edges_to_heap, at ipa-inline.c:1754 3760 | } | ^ 0x5ef2b3 add_new_edges_to_heap /usr/src/debug/sys-devel/gcc-11.0.0_pre/gcc-11.0.0_pre/gcc/ipa-inline.c:1754 0x1429b89 inline_small_functions /usr/src/debug/sys-devel/gcc-11.0.0_pre/gcc-11.0.0_pre/gcc/ipa-inline.c:2218 0x1429b89 ipa_inline /usr/src/debug/sys-devel/gcc-11.0.0_pre/gcc-11.0.0_pre/gcc/ipa-inline.c:2697 0x1429b89 execute /usr/src/debug/sys-devel/gcc-11.0.0_pre/gcc-11.0.0_pre/gcc/ipa-inline.c:3099
Re: Function signatures in extern "C".
Jonathan Wakely via Gcc wrote: On Sun, 6 Sep 2020 at 16:23, Iain Sandoe wrote: g++.dg/abi/guard3.C has: extern "C" int __cxa_guard_acquire(); Which might not be a suitable declaration, depending on how the ‘extern “C”’ is supposed to affect the function signature generated. IF, the extern C should make this parse as a “K” style function - then the TYPE_ARG_TYPES should be NULL (and the testcase is OK). However, we are parsing the decl as int __cxa_guard_acquire(void) (i.e. C++ rules on the empty parens), which makes the testcase not OK. That is the correct parse. Using extern "C" doesn't mean the code is C, it only affects mangling. It still has to follow C++ rules. In practice you can still link to the definition, because its name is just "__cxa_guard_acquire" irrespective of what parameter list is present in the declaration. Linking isn’t the problem in this case. The problem is that we arrive at “expand_call” with a function decl that says f(void) .. and a call parmeter list containing a pointer type. We happily pass the pointer in the place of the ‘void’ - because the code only counts the number of entries and there’s one - so it happens to work. .. that’s not true in the general case and for all calling conventions. (this is what I mean by it happens to work by luck below). This means that the declaration is now misleading (and it’s just luck that expand_call happens to count the length of the TYPE_ARG_TYPES list without looking to see what the types are) - in this case it happens to work out from this luck - since there’s only one arg so the length of the void args list agrees with what we want. —— So .. the question is “which is wrong, the test-case or the assignment of the TYPE_ARG_TYPES”? [we can’t easily diagnose this at this point, but I do have a patch to diagnose the case where we pass a void-list to expand_call and then try to expand a call to the callee with an inappropriate set of parms] (it’s trivial to fix the test-case as extern "C" int __cxa_guard_acquire(__UINT64_TYPE__ *);, I guess) But PR 45603 is ice-on-invalid triggered by the incorrect declaration of __cxa_guard_acquire. So the incorrect declaration is what originally reproduced the bug, and "fixing" it would make the test useless. Ah OK. It's probably worth adding a comment about that in the test. Yes - that would help (will add it to my TODO). Maybe the test should give a compile-time error and XFAIL, but fixing the declaration doesn't seem right. I guess (because the code is invalid) there’s not much motivation to make it more robust - e.g. diagnose the mismatch in the call(s) synthesized to __cxa_guard_acquire. It seems we only try to build these function decl(s) once - lazily - so that a wrong one will persist for the whole TU (and we don’t seem to check that the decl matches the itanium ABI - perhaps that’s intentional tho). cheers Iain
Re: Function signatures in extern "C".
On Sun, 6 Sep 2020 at 16:23, Iain Sandoe wrote: > > Hi > > g++.dg/abi/guard3.C > > has: > > extern "C" int __cxa_guard_acquire(); > > Which might not be a suitable declaration, depending on how the ‘extern > “C”’ is supposed to affect the function signature generated. > > IF, the extern C should make this parse as a “K” style function - then > the TYPE_ARG_TYPES should be NULL (and the testcase is OK). > > However, we are parsing the decl as int __cxa_guard_acquire(void) (i.e. C++ > rules on the empty parens), which makes the testcase not OK. That is the correct parse. Using extern "C" doesn't mean the code is C, it only affects mangling. It still has to follow C++ rules. In practice you can still link to the definition, because its name is just "__cxa_guard_acquire" irrespective of what parameter list is present in the declaration. > This means that the declaration is now misleading (and it’s just luck that > expand_call happens to count the length of the TYPE_ARG_TYPES list without > looking to see what the types are) - in this case it happens to work out > from this luck - since there’s only one arg so the length of the void args > list agrees with what we want. > > —— > > So .. the question is “which is wrong, the test-case or the assignment of > the TYPE_ARG_TYPES”? > > [we can’t easily diagnose this at this point, but I do have a patch to > diagnose the case where we pass a void-list to expand_call and then try to > expand a call to the callee with an inappropriate set of parms] > > (it’s trivial to fix the test-case as extern "C" int > __cxa_guard_acquire(__UINT64_TYPE__ *);, I guess) But PR 45603 is ice-on-invalid triggered by the incorrect declaration of __cxa_guard_acquire. So the incorrect declaration is what originally reproduced the bug, and "fixing" it would make the test useless. It's probably worth adding a comment about that in the test. Maybe the test should give a compile-time error and XFAIL, but fixing the declaration doesn't seem right.
Re: Fortran: fix another function argtypes bug for ppc
> OK (you can also put in a quick FIXME there). Actually the decl being declared is using itself as one of the arguments, so I think it’s on purpose that we don’t want to emit a full arglist here… to avoid recursion. So I’m not sure we would want to change that. FX
Re: Fortran: fix another function argtypes bug for ppc
Hi FX, The patch is regtested on x86_64-apple-darwin19. I also tested it on aarch64-apple-darwin20, where it fixes wrong code issues in several testcases. OK (you can also put in a quick FIXME there). Best regards Thomas
[Bug target/53929] Bug in the use of Intel asm syntax when a global is named "and"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53929 Arseny Solokha changed: What|Removed |Added CC||asolokha at gmx dot com --- Comment #2 from Arseny Solokha --- (In reply to tk from comment #1) > the assembly pass also complains if I use a > symbol which happens to be the same as register name, e.g. "bx". It was filed previously as PR87986 and PR95652. BTW, GCC does not include an assembler.
Fortran: fix another function argtypes bug for ppc
This is another function argtypes issue, very similar to This code from proc_ptr_comp_13.f90 : ! PR 40882: [F03] infinite recursion in gfc_get_derived_type with PPC returning derived type. ! At the same time, check that a formal argument does not cause infinite recursion (PR 40870). implicit none type :: t procedure(foo), pointer, nopass :: ppc end type type(t) :: o, o2 o2 = o%ppc(o) contains function foo(arg) type(t) :: foo, arg end function end causes the compiler to emit wrong code for the call to o%ppc(o), because it gets the type of the function wrong. Again, the intent was to emit an incomplete function type, but this time it is on purpose, and I think unavoidable (to avoid infinite recursion). Except, it was done with the wrong middle-end call. The patch fixes it. The patch is regtested on x86_64-apple-darwin19. I also tested it on aarch64-apple-darwin20, where it fixes wrong code issues in several testcases. OK to commit? FX ppc_dt.diff Description: Binary data ppc_dt.ChangeLog Description: Binary data
[Bug fortran/96947] _gfortran_caf_fail_image called with wrong number of arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96947 Francois-Xavier Coudert changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #2 from Francois-Xavier Coudert --- Fixed on trunk.
Re: A couple GIMPLE questions
On September 6, 2020 9:38:45 AM GMT+02:00, Gary Oblock via Gcc
wrote:
>>That's not a question? Are you asking why PHIs exist at all?
>>They are the standard way to represent merging in SSA
>>representations. You can iterate on the PHIs of a basic block, etc.
>
>Marc,
>
>I first worked with the SSA form twenty years ago so yes I am
>aware of what a phi is... I've just never seen a compiler eliminate
>an assignment of a variable to a constant and jam the constant into
>the phi where the SSA variable should be. What a phi is all about
>is representing data flow and a constant in the phi doesn't seem
>to be related to that. I can deal with this but it seems that having to
>crawl the phis looking for constants seems baroque. I would hope
>there is a control that can suppress this or a transformation
>that I can invoke to reverse it...
No, there isn't. We happily propagate constants into PHI nodes.
Richard.
>
>Thanks,
>
>Gary
>
>From: Marc Glisse
>Sent: Saturday, September 5, 2020 11:29 PM
>To: Gary Oblock
>Cc: gcc@gcc.gnu.org
>Subject: Re: A couple GIMPLE questions
>
>[EXTERNAL EMAIL NOTICE: This email originated from an external sender.
>Please be mindful of safe email handling and proprietary information
>protection practices.]
>
>
>On Sat, 5 Sep 2020, Gary Oblock via Gcc wrote:
>
>> First off one of the questions just me being curious but
>> second is quite serious. Note, this is GIMPLE coming
>> into my optimization and not something I've modified.
>>
>> Here's the C code:
>>
>> type_t *
>> do_comp( type_t *data, size_t len)
>> {
>> type_t *res;
>> type_t *x = min_of_x( data, len);
>> type_t *y = max_of_y( data, len);
>>
>> res = y;
>> if ( x < y ) res = 0;
>> return res;
>> }
>>
>> And here's the resulting GIMPLE:
>>
>> ;; Function do_comp.constprop (do_comp.constprop.0, funcdef_no=5,
>decl_uid=4392, cgraph_uid=3, symbol_order=68) (executed once)
>>
>> do_comp.constprop (struct type_t * data)
>> {
>> struct type_t * res;
>> struct type_t * x;
>> struct type_t * y;
>> size_t len;
>>
>> [local count: 1073741824]:
>>
>> [local count: 1073741824]:
>> x_2 = min_of_x (data_1(D), 1);
>> y_3 = max_of_y (data_1(D), 1);
>> if (x_2 < y_3)
>>goto ; [29.00%]
>> else
>>goto ; [71.00%]
>>
>> [local count: 311385128]:
>>
>> [local count: 1073741824]:
>> # res_4 = PHI
>> return res_4;
>>
>> }
>>
>> The silly question first. In the "if" stmt how does GCC
>> get those probabilities? Which it shows as 29.00% and
>> 71.00%. I believe they should both be 50.00%.
>
>See the profile_estimate pass dump. One branch makes the function
>return
>NULL, which makes gcc guess that it may be a bit less likely than the
>other. Those are heuristics, which are tuned to help on average, but of
>course they are sometimes wrong.
>
>> The serious question is what is going on with this phi?
>>res_4 = PHI
>>
>> This makes zero sense practicality wise to me and how is
>> it supposed to be recognized and used? Note, I really do
>> need to transform the "0B" into something else for my
>> structure reorganization optimization.
>
>That's not a question? Are you asking why PHIs exist at all? They are
>the
>standard way to represent merging in SSA representations. You can
>iterate
>on the PHIs of a basic block, etc.
>
>> CONFIDENTIALITY NOTICE: This e-mail message, including any
>attachments, is for the sole use of the intended recipient(s) and
>contains information that is confidential and proprietary to Ampere
>Computing or its subsidiaries. It is to be used solely for the purpose
>of furthering the parties' business relationship. Any unauthorized
>review, copying, or distribution of this email (or any attachments
>thereto) is strictly prohibited. If you are not the intended recipient,
>please contact the sender immediately and permanently delete the
>original and any copies of this email and any attachments thereto.
>
>Could you please get rid of this when posting on public mailing lists?
>
>--
>Marc Glisse
Re: [patch] Fortran: fix prototype for class vptr fields
> Could you maybe put a FIXME at that place, explaining that we are > in fact following K conventions there and what we would need > to correc the function decl to use build_function_type_list? Done. FX
Re: [patch] Fortran: _gfortran_caf_fail_image() should have no argument
> OK! Committed at https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=3489d80fee42764460cb06f7a2e9f126c18602b4 It’s my first commit since GCC moved to git, let me know if I did it correctly :) FX
[Bug fortran/96947] _gfortran_caf_fail_image called with wrong number of arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96947 --- Comment #1 from CVS Commits --- The master branch has been updated by Franथà¤ois-Xavier Coudert : https://gcc.gnu.org/g:3489d80fee42764460cb06f7a2e9f126c18602b4 commit r11-3018-g3489d80fee42764460cb06f7a2e9f126c18602b4 Author: Francois-Xavier Coudert Date: Sun Sep 6 18:24:50 2020 +0200 fortran: caf_fail_image expects no argument gcc/fortran/ChangeLog PR fortran/96947 * trans-stmt.c (gfc_trans_fail_image): caf_fail_image expects no argument. gcc/testsuite/ChangeLog * gfortran.dg/coarray_fail_st.f90: Adjust test.
Re: [patch] Fortran: _gfortran_caf_fail_image() should have no argument
Hi FX, OK to commit? OK! Best regards Thomas
Re: [patch] Fortran: fix prototype for class vptr fields
Am 06.09.20 um 13:12 schrieb FX via Fortran: Hi FX, OK to commit? The patch is OK in principle, I have also regtested it on POWER (which is also somethat picky about calling conventions). However, in an ideal world, this should only be a temporary fix. Could you maybe put a FIXME at that place, explaining that we are in fact following K conventions there and what we would need to correc the function decl to use build_function_type_list? Thanks for the fix! Best regards Thomas
[patch] Fortran: _gfortran_caf_fail_image() should have no argument
Hi, The Fortran front-end, in gfc_trans_fail_image() emits a call to _gfortran_caf_fail_image with one argument (a NULL pointer): return build_call_expr_loc (input_location, gfor_fndecl_caf_fail_image, 1, build_int_cst (pchar_type_node, 0)); while the prototype for the function in libgfortran is clear that it takes no argument: void _gfortran_caf_fail_image (void) __attribute__ ((noreturn)); The bug was filed as https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96947 This obvious patch removes the useless argument (which triggers wrong code generation on aarch64-apple-darwin20). Regtested on x86_64-apple-darwin19 and tested on aarch64-apple-darwin20. OK to commit? FX fail_image.diff Description: Binary data fail_image.ChangeLog Description: Binary data
[patch] Fortran: fix prototype of _gfortran_is_extension_of()
Hi, The problem was reported in detail here: https://gcc.gnu.org/pipermail/fortran/2020-September/055005.html and in previous messages. When resolving select type constructs, the Fortran front-end is trying to use the _gfortran_is_extension_of() library call (which is also used for the EXTENDS_TYPE_OF Fortran intrinsic). However, in doing so, it is constructing the symbol of the function call without proper formal arguments, which leads to the function call being built with a wrong arg-types in the function type tree. This has no known impact on most targets, but it does lead to wrong code generation on aarch64-apple-darwin20, which is how this bug was identified. The attached patch simply adds proper formal argument list to the intrinsic call. Regtested on x86_64-apple-darwin19 and tested on aarch64-apple-darwin20. OK to commit? FX is_extension_of.diff Description: Binary data is_extension_of.ChangeLog Description: Binary data
[PATCH] c++: Further tweaks for new-expression and paren-init [PR77841]
This patch corrects our handling of array new-expression with ()-init:
new int[4](1, 2, 3, 4);
should work even with the explicit array bound, and
new char[3]("so_sad");
should cause an error, but we weren't giving any.
Fixed by handling array new-expressions with ()-init in the same spot
where we deduce the array bound in array new-expression. I'm now
always passing STRING_CSTs to build_new_1 wrapped in { } which allowed
me to remove the special handling of STRING_CSTs in build_new_1. And
since the DIRECT_LIST_INIT_P block in build_new_1 calls digest_init, we
report errors about too short arrays.
I took a stab at cp_complete_array_type's "FIXME: this code is duplicated
from reshape_init", but calling reshape_init there, I ran into issues
with has_designator_problem: when we reshape an already reshaped
CONSTRUCTOR again, d.cur.index has been filled, so we think that we
have a user-provided designator (though there was no designator in the
source code), and report an error.
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
gcc/cp/ChangeLog:
PR c++/77841
* init.c (build_new_1): Don't handle string-initializers here.
(build_new): Handle new-expression with paren-init when the
array bound is known. Always pass string constants to build_new_1
enclosed in braces.
gcc/testsuite/ChangeLog:
PR c++/77841
* g++.old-deja/g++.ext/arrnew2.C: Expect the error only in C++17
and less.
* g++.old-deja/g++.robertl/eb58.C: Adjust dg-error.
* g++.dg/cpp2a/paren-init36.C: New test.
---
gcc/cp/init.c | 37 ++-
gcc/testsuite/g++.dg/cpp2a/paren-init36.C | 14 +++
gcc/testsuite/g++.old-deja/g++.ext/arrnew2.C | 2 +-
gcc/testsuite/g++.old-deja/g++.robertl/eb58.C | 2 +-
4 files changed, 35 insertions(+), 20 deletions(-)
create mode 100644 gcc/testsuite/g++.dg/cpp2a/paren-init36.C
diff --git a/gcc/cp/init.c b/gcc/cp/init.c
index 3268ae4ad3f..537651778b9 100644
--- a/gcc/cp/init.c
+++ b/gcc/cp/init.c
@@ -3596,15 +3596,6 @@ build_new_1 (vec **placement, tree type,
tree nelts,
vecinit = digest_init (arraytype, vecinit, complain);
}
}
- /* This handles code like new char[]{"foo"}. */
- else if (len == 1
- && char_type_p (TYPE_MAIN_VARIANT (type))
- && TREE_CODE (tree_strip_any_location_wrapper ((**init)[0]))
- == STRING_CST)
- {
- vecinit = (**init)[0];
- STRIP_ANY_LOCATION_WRAPPER (vecinit);
- }
else if (*init)
{
if (complain & tf_error)
@@ -3944,9 +3935,9 @@ build_new (location_t loc, vec **placement,
tree type,
}
/* P1009: Array size deduction in new-expressions. */
- if (TREE_CODE (type) == ARRAY_TYPE
- && !TYPE_DOMAIN (type)
- && *init)
+ const bool deduce_array_p = (TREE_CODE (type) == ARRAY_TYPE
+ && !TYPE_DOMAIN (type));
+ if (*init && (deduce_array_p || (nelts && cxx_dialect >= cxx20)))
{
/* This means we have 'new T[]()'. */
if ((*init)->is_empty ())
@@ -3955,16 +3946,20 @@ build_new (location_t loc, vec
**placement, tree type,
CONSTRUCTOR_IS_DIRECT_INIT (ctor) = true;
vec_safe_push (*init, ctor);
}
+ tree array_type = deduce_array_p ? TREE_TYPE (type) : type;
tree = (**init)[0];
/* The C++20 'new T[](e_0, ..., e_k)' case allowed by P0960. */
if (!DIRECT_LIST_INIT_P (elt) && cxx_dialect >= cxx20)
{
- /* Handle new char[]("foo"). */
+ /* Handle new char[]("foo"): turn it into new char[]{"foo"}. */
if (vec_safe_length (*init) == 1
- && char_type_p (TYPE_MAIN_VARIANT (TREE_TYPE (type)))
+ && char_type_p (TYPE_MAIN_VARIANT (array_type))
&& TREE_CODE (tree_strip_any_location_wrapper (elt))
== STRING_CST)
- /* Leave it alone: the string should not be wrapped in {}. */;
+ {
+ elt = build_constructor_single (init_list_type_node, NULL_TREE,
elt);
+ CONSTRUCTOR_IS_DIRECT_INIT (elt) = true;
+ }
else
{
tree ctor = build_constructor_from_vec (init_list_type_node,
*init);
@@ -3977,9 +3972,15 @@ build_new (location_t loc, vec **placement,
tree type,
}
}
/* Otherwise we should have 'new T[]{e_0, ..., e_k}'. */
- if (BRACE_ENCLOSED_INITIALIZER_P (elt))
- elt = reshape_init (type, elt, complain);
- cp_complete_array_type (, elt, /*do_default*/false);
+ if (deduce_array_p)
+ {
+ /* Don't reshape ELT itself: we want to pass a list-initializer to
+build_new_1, even for STRING_CSTs. */
+ tree e = elt;
+ if (BRACE_ENCLOSED_INITIALIZER_P (e))
+ e = reshape_init (type, e,
[PATCH] doc: gcc.c: Update documentation for spec files
There were some differences between the actual code in do_spec_1, its
source comment, and the documentation in doc/invoke.texi. These should
now be resolved.
gcc/ChangeLog:
* gcc.c: document %T spec file directive
* doc/invoke.texi:
remove %p, %P spec file directives
add %M, %R, %V, %nSTR, %>S, %S
+Similar to @samp{% []
+@end smallexample
+
+It returns @code{result} if the comparison evaluates to true, and NULL if it
doesn't.
+The supported @code{comparison-op} values are:
+
+@table @code
+@item >=
+True if @code{switch} is a later (or same) version than @code{arg1}
+
+@item !>
+Opposite of @code{>=}
+
+@item <
+True if @code{switch} is an earlier version than @code{arg1}
+
+@item !<
+Opposite of @code{<}
+
+@item ><
+True if @code{switch} is @code{arg1} or later, and earlier than @code{arg2}
+
+@item <>
+True if @code{switch} is earlier than @code{arg1}, or is @code{arg2} or later
+@end table
+
+If the @code{switch} is not present at all, the condition is false unless the
first character
+of the @code{comparison-op} is @code{!}.
+
+@smallexample
+%:version-compare(>= 10.3 mmacosx-version-min= -lmx)
+@end smallexample
+
+The above example would add @option{-lmx} if
@option{-mmacosx-version-min=10.3.9} was
+passed.
+
+@item @code{include}
+The @code{include} spec function behaves much like @code{%include}, with the
advantage
+that it can be nested inside a spec and thus be conditionalized. It takes one
argument,
+the filename, and looks for it in the startfile path. It always returns NULL.
+
+@smallexample
+%@{static-libasan|static:%:include(libsanitizer.spec)%(link_libasan)@}
+@end smallexample
+
@item @code{pass-through-libs}
The @code{pass-through-libs} spec function takes any number of arguments. It
finds any @option{-l} options and any non-options ending in @file{.a} (which it
@@ -31436,6 +31502,25 @@ Use "-Wa,OPTION" to pass "OPTION" to the assembler.
It is used to separate compiler options from assembler options
in the @option{--target-help} output.
+
+@item @code{gt}
+The @code{gt} spec function takes two or more arguments. It returns @code{""}
(the
+empty string) if the second-to-last argument is greater than the last
argument, and NULL
+otherwise. The following example inserts the @code{link_gomp} spec if the last
+@option{-ftree-parallelize-loops=} option given on the command line is greater
than 1:
+
+@smallexample
+%@{%:gt(%@{ftree-parallelize-loops=*:%*@}
1):%:include(libgomp.spec)%(link_gomp)@}
+@end smallexample
+
+@item @code{debug-level-gt}
+The @code{debug-level-gt} spec function takes one argument and returns
@code{""} (the
+empty string) if @code{debug_info_level} is greater than the specified number,
and NULL
+otherwise.
+
+@smallexample
+%@{%:debug-level-gt(0):%@{gdwarf*:--gdwarf2@}@}
+@end smallexample
@end table
@item %@{S@}
@@ -31450,6 +31535,10 @@ and outputs the command-line option @option{-foo}.
Like %@{@code{S}@} but mark last argument supplied within as a file to be
deleted on failure.
+@item %@@@{S@}
+Like %@{@code{S}@} but puts the result into a @code{FILE} and substitutes
+@code{@@FILE} if an @code{@@file} argument has been supplied.
+
@item %@{S*@}
Substitutes all the switches specified to GCC whose names start
with @code{-S}, but which also take an argument. This is used for
@@ -31532,6 +31621,12 @@ jim.d -bar -boggle
-d jim.d -bar -baz -boggle
@end smallexample
+@item %@{%:@var{function}(@var{args}):X@}
+
+Call function named @var{function} with args @var{args}. If the
+function returns non-NULL, then @code{X} is substituted, if it returns
+NULL, it isn't substituted.
+
@item %@{S:X; T:Y; :D@}
If @code{S} is given to GCC, substitutes @code{X}; else if @code{T} is
diff --git a/gcc/gcc.c b/gcc/gcc.c
index 531f4e02dbd..72490847274 100644
--- a/gcc/gcc.c
+++ b/gcc/gcc.c
@@ -540,6 +540,12 @@ or with constant text in a single argument.
%s current argument is the name of a library or startup file of some sort.
Search for that file in a standard list of directories
and substitute the full name found.
+ %Tcurrent argument is the name of a linker script.
+ Search for that file in the current list of directories to scan for
+ libraries. If the file is located, insert a --script option into the
+ command line followed by the full path name found. If the file is
+ not found then generate an error message.
+ Note: the current working directory is not searched.
%eSTR Print STR as an error message. STR is terminated by a newline.
Use this when inconsistent options are detected.
%nSTR Print STR as a notice. STR is terminated by a newline.
--
2.28.0
[Bug target/96854] [10 Regression] avx vectorizer breaks complex arithmetic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96854 --- Comment #16 from Jakub Jelinek --- If you want bugfixes as in this case. The cadence on the release branches is gradually slowing down, the last release is usually about a year about the one before that. It is already quite a lot of work to backport fixes to release branches, maintaining some 10.1 and 10.2 etc. streams would be significantly more, plus usually you want all bugfixes from the release branch, i.e. there would be no difference between 10.2.fixes and 10.3.
Function signatures in extern "C".
Hi g++.dg/abi/guard3.C has: extern "C" int __cxa_guard_acquire(); Which might not be a suitable declaration, depending on how the ‘extern “C”’ is supposed to affect the function signature generated. IF, the extern C should make this parse as a “K” style function - then the TYPE_ARG_TYPES should be NULL (and the testcase is OK). However, we are parsing the decl as int __cxa_guard_acquire(void) (i.e. C++ rules on the empty parens), which makes the testcase not OK. This means that the declaration is now misleading (and it’s just luck that expand_call happens to count the length of the TYPE_ARG_TYPES list without looking to see what the types are) - in this case it happens to work out from this luck - since there’s only one arg so the length of the void args list agrees with what we want. —— So .. the question is “which is wrong, the test-case or the assignment of the TYPE_ARG_TYPES”? [we can’t easily diagnose this at this point, but I do have a patch to diagnose the case where we pass a void-list to expand_call and then try to expand a call to the callee with an inappropriate set of parms] (it’s trivial to fix the test-case as extern "C" int __cxa_guard_acquire(__UINT64_TYPE__ *);, I guess) thanks Iain
[Bug target/96854] [10 Regression] avx vectorizer breaks complex arithmetic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96854 --- Comment #15 from Michael_S --- Thank you. That does not sound too different from what I assumed in post above. 10.1.0 is release. Expected to be used by "normal" people. 10.1.1 was for purpose of development of 10.2.0. Since release of 10.2.0 it is obsolete. 10.2.0 is release. Expected to be used by "normal" people. 10.2.1 exists for purpose of development of 10.3.0. >> Generally, it is advisable to use snapshots from the release branches, as >> otherwise one misses dozens to hundreds of bugfixes that were fixed since >> the last release. That a little confusing. I am compiler user, not compiler developer. Is it advisable for me to download and compile snapshots ?! I would think that for people like me 3-4 month cadence of gcc releases is already too quick.
[Bug middle-end/87256] hppa spends huge amount of time in synth_mult()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87256 John David Anglin changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- Target|hppa-* |hppa*-* --- Comment #19 from John David Anglin --- hppa64 compiler is still slow: $ hppa64-linux-gnu-gcc -S -O2 hog.c hog.c: In function 'b': hog.c:18:15: warning: integer constant is so large that it is unsigned c = c * 9650029242287828579LL; ^ hog.c:19:15: warning: integer constant is so large that it is unsigned c = c * 9650029242287828579LL; ^ hog.c:20:15: warning: integer constant is so large that it is unsigned c = c * 9650029242287828579LL; /* this line adds 2 seconds: 7->9 */ ^ hog.c:21:15: warning: integer constant is so large that it is unsigned c = c * 9650029242287828579LL; /* this line adds 2 seconds: 9->11 */ ^ dave@mx3210:~/gnu/gcc$ time hppa64-linux-gnu-gcc -S -O2 hog.c hog.c: In function 'b': hog.c:18:15: warning: integer constant is so large that it is unsigned c = c * 9650029242287828579LL; ^ hog.c:19:15: warning: integer constant is so large that it is unsigned c = c * 9650029242287828579LL; ^ hog.c:20:15: warning: integer constant is so large that it is unsigned c = c * 9650029242287828579LL; /* this line adds 2 seconds: 7->9 */ ^ hog.c:21:15: warning: integer constant is so large that it is unsigned c = c * 9650029242287828579LL; /* this line adds 2 seconds: 9->11 */ ^ real1m48.311s user1m47.665s sys 0m0.471s
[Bug target/96854] [10 Regression] avx vectorizer breaks complex arithmetic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96854 --- Comment #14 from Jakub Jelinek --- The versioning is well documented https://gcc.gnu.org/develop.html#num_scheme and the only way how things are fixed is fixing on the mainline and when needed on still open release branches. Those will become an upcoming release at some later point. Generally, it is advisable to use snapshots from the release branches, as otherwise one misses dozens to hundreds of bugfixes that were fixed since the last release.
[Bug target/96854] [10 Regression] avx vectorizer breaks complex arithmetic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96854 --- Comment #13 from Michael_S --- I don't follow gcc versioning policy all that closely. What is the function "micro" versions now? For internal use and experimentation only, but not for public release?
[Bug target/96854] [10 Regression] avx vectorizer breaks complex arithmetic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96854 --- Comment #12 from Jakub Jelinek --- (In reply to Michael_S from comment #11) > Just to understand > Will 10.1 and 10.2 be fixed? No, they were already released, so can't be fixed. You can apply the changes to them if you want. The fix is on the git releases/gcc-10 branch, and will be part of upcoming 10.3.
[Bug ipa/96394] [10/11 Regression] ICE in add_new_edges_to_heap, at ipa-inline.c:1746 (-O3 PGO)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96394 --- Comment #8 from Sergei Trofimovich --- Might end up being caused by the same bug in PR96913: TOPN streaming from/for shared libraries is incorrect. Proposed patch: https://gcc.gnu.org/pipermail/gcc-patches/2020-September/553320.html
[Bug gcov-profile/96913] [10/11 regression] gcov TOPN streaming is incorrect for shared libraries
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96913 Sergei Trofimovich changed: What|Removed |Added Summary|gcc-11: __gcov_merge_topn |[10/11 regression] gcov |hangs |TOPN streaming is incorrect ||for shared libraries Known to work||9.3.0 Known to fail||10.2.0 --- Comment #6 from Sergei Trofimovich --- https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=5f32f9cf13f99f6295591927950aaf98aa8dba91 is probably the first time regression was introduced (gcc10+).
[Bug gcov-profile/96913] gcc-11: __gcov_merge_topn hangs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96913 Sergei Trofimovich changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2020-09-06 Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |slyfox at gcc dot gnu.org --- Comment #5 from Sergei Trofimovich --- (In reply to Sergei Trofimovich from comment #4) > $ x86_64-pc-linux-gnu-nm tauthon | fgrep gcov_merge_top > 0040387f t __gcov_merge_topn > $ x86_64-pc-linux-gnu-nm libtauthon2.8.so.1.0 | fgrep gcov_merge_top > 0029a202 t __gcov_merge_topn > > Don't know yet know where 'gi_ptr->merge' gets filled in to leak > executable's symbol into binary. Having looked at absolute addresses and address maps it's even more complicated that that: call trace: tauthon : main() -> libtauthon2.8.so.1.0 : execve() ->libtauthon2.8.so.1.0 : __gcov_execve() ->libtauthon2.8.so.1.0 : write_one_data() There addresses of: if (gi_ptr->merge[t_ix] == __gcov_merge_topn) are: - gi_ptr->merge[t_ix]: _struct.so:&__gcov_merge_topn - __gcov_merge_topn: libtauthon2.8.so.1.0:&__gcov_merge_topn Sent https://gcc.gnu.org/pipermail/gcc-patches/2020-September/553320.html for review. Claiming the bug.
[Bug fortran/96947] New: _gfortran_caf_fail_image called with wrong number of arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96947 Bug ID: 96947 Summary: _gfortran_caf_fail_image called with wrong number of arguments Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: fxcoudert at gcc dot gnu.org Target Milestone: --- Take the source code gfortran.dg/coarray_fail_st.f90 The tree dump shows that _gfortran_caf_fail_image() is called with one argument: _gfortran_caf_fail_image (0B); This call is generated in gfc_trans_fail_image(), which passes a NULL pointer: if (flag_coarray == GFC_FCOARRAY_LIB) return build_call_expr_loc (input_location, gfor_fndecl_caf_fail_image, 1, build_int_cst (pchar_type_node, 0)); But the prototype for the function in libgfortran is clear that it takes no argument: void _gfortran_caf_fail_image (void) __attribute__ ((noreturn)); I do not know which way this should be fixed. It creates runtime issues with coarrays on aarch64-apple-darwin20.
[PATCH] gcov: fix TOPN streaming from shared libraries
From: Sergei Trofimovich
Before the change gcc did not stream correctly TOPN counters
if counters belonged to a non-local shared object.
As a result zero-section optimization generated TOPN sections
in a form not recognizable by '__gcov_merge_topn'.
The problem happens because in a case of multiple shared objects
'__gcov_merge_topn' function is present in address space multiple
times (once per each object).
The fix is to never rely on function address and predicate on TOPN
counter types.
libgcc/ChangeLog:
PR gcov-profile/96913
* libgcov-driver.c (write_one_data): Avoid function pointer
comparison in TOP streaming decision.
---
libgcc/libgcov-driver.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/libgcc/libgcov-driver.c b/libgcc/libgcov-driver.c
index 58914268d4e..86a6b5ad68a 100644
--- a/libgcc/libgcov-driver.c
+++ b/libgcc/libgcov-driver.c
@@ -424,10 +424,15 @@ write_one_data (const struct gcov_info *gi_ptr,
n_counts = ci_ptr->num;
- if (gi_ptr->merge[t_ix] == __gcov_merge_topn)
+ /* Do not zero-compress top counters because:
+ * - __gcv_merge_topn does not handle such sections
+ * - GCOV_COUNTER_V_INDIR contains non-zero keys
+ */
+ if (t_ix == GCOV_COUNTER_V_TOPN || t_ix == GCOV_COUNTER_V_INDIR)
write_top_counters (ci_ptr, t_ix, n_counts);
else
{
+
/* Do not stream when all counters are zero. */
int all_zeros = 1;
for (unsigned i = 0; i < n_counts; i++)
--
2.28.0
[patch] Fortran: fix prototype for class vptr fields
Hi, Attached is a patch fixing the problem at: https://gcc.gnu.org/pipermail/fortran/2020-September/054978.html the reasoning behind the solution is explained here: https://gcc.gnu.org/pipermail/fortran/2020-September/054997.html In short, calls to class copy functions are made with wrong function type: > SI size constant 32> unit-size constant 4> align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x14461be70 arg-types > pointer_to_this > where the arg-types is (void) instead of being undefined (like K functions). This has no apparent consequences on current targets, but it leads to wrong code generation for aarch64-apple-darwin20. The attached patch fixes this. The patch is regtested on x86_64-apple-darwin19. I also tested it on aarch64-apple-darwin20 (Iain’s current port based on trunk at https://github.com/iains/gcc-darwin-arm64) where it brings the number of test failures down from 811 to 166! OK to commit? FX ppc_type.diff Description: Binary data ppc_type.ChangeLog Description: Binary data
[Bug target/96854] [10 Regression] avx vectorizer breaks complex arithmetic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96854 --- Comment #11 from Michael_S --- Just to understand Will 10.1 and 10.2 be fixed?
[Bug tree-optimization/40771] generated code is ~25% slower when autovectorization is enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40771 --- Comment #3 from Zdenek Sojka --- The vectorized code seems to have improved in gcc-9 over gcc-8.
[Bug gcov-profile/96913] gcc-11: __gcov_merge_topn hangs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96913
--- Comment #4 from Sergei Trofimovich ---
(In reply to Sergei Trofimovich from comment #3)
> Specifically I think this is already a wrong format on disk:
>
> > _json.gcda:01a7: 0:COUNTERS topn 0 counts
> > _json.gcda:01a9: 48:COUNTERS indirect_call 24 counts
> > _json.gcda: 0: 1 1 140325305737168 1 1 140325305737200 0 0
> > _json.gcda: 8: 0 0 0 0 0 0 0 0
> > _json.gcda: 16: 0 0 0 0 0 0 0 0
> > ...
>
> Assuming indirect_call is in a 'hist' value format it should be in form of:
>
> [total_executions, N, value1, counter1, ..., valueN, counterN]
>
> Main problem: we have more than one entry here (which might be ok):
> - record1 (ok): total_executions=1 N=1 value1=140325305737168 counter1=1
> - record2 (bad): total_executions=1 N=140325305737200 counter=0 ...
>
> This is where we trip over enormous N.
Found one of the causes of profiling data corruption. The bug happened earlier
on initial serialization of indirect counters functions. The problematic code
is:
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libgcc/libgcov-driver.c;h=58914268d4ece0b3a3a7dcb9cb21c4fa197fd770;hb=HEAD#l427
"""
417 ci_ptr = gfi_ptr->ctrs;
418 for (t_ix = 0; t_ix < GCOV_COUNTERS; t_ix++)
419 {
420 gcov_position_t n_counts;
421
422 if (!gi_ptr->merge[t_ix])
423 continue;
424
425 n_counts = ci_ptr->num;
426
427 if (gi_ptr->merge[t_ix] == __gcov_merge_topn)
428 write_top_counters (ci_ptr, t_ix, n_counts);
429 else
430 {
431 /* Do not stream when all counters are zero. */
432 int all_zeros = 1;
433 for (unsigned i = 0; i < n_counts; i++)
434 if (ci_ptr->values[i] != 0)
435 {
436 all_zeros = 0;
437 break;
438 }
"""
The problematic line here is 'if (gi_ptr->merge[t_ix] == __gcov_merge_topn)'.
In case of tauthon '__gcov_merge_topn' is defined in two places:
1. in 'tauthon' binary itself
2. in any other shared library loaded by tauthon. Looks like
'libtauthon2.8.so.1.0' is the first one.
'__gcov_merge_topn' is defined as hidden symbol and gets resolved to local
symbol:
$ x86_64-pc-linux-gnu-nm tauthon | fgrep gcov_merge_top
0040387f t __gcov_merge_topn
$ x86_64-pc-linux-gnu-nm libtauthon2.8.so.1.0 | fgrep gcov_merge_top
0029a202 t __gcov_merge_topn
Don't know yet know where 'gi_ptr->merge' gets filled in to leak executable's
symbol into binary.
Re: A couple GIMPLE questions
>Could you please get rid of this when posting on public mailing lists?
No, I have no control over that but I'll give the email of our corporate
IT if you want to complain to them...
From: Marc Glisse
Sent: Saturday, September 5, 2020 11:29 PM
To: Gary Oblock
Cc: gcc@gcc.gnu.org
Subject: Re: A couple GIMPLE questions
[EXTERNAL EMAIL NOTICE: This email originated from an external sender. Please
be mindful of safe email handling and proprietary information protection
practices.]
On Sat, 5 Sep 2020, Gary Oblock via Gcc wrote:
> First off one of the questions just me being curious but
> second is quite serious. Note, this is GIMPLE coming
> into my optimization and not something I've modified.
>
> Here's the C code:
>
> type_t *
> do_comp( type_t *data, size_t len)
> {
> type_t *res;
> type_t *x = min_of_x( data, len);
> type_t *y = max_of_y( data, len);
>
> res = y;
> if ( x < y ) res = 0;
> return res;
> }
>
> And here's the resulting GIMPLE:
>
> ;; Function do_comp.constprop (do_comp.constprop.0, funcdef_no=5,
> decl_uid=4392, cgraph_uid=3, symbol_order=68) (executed once)
>
> do_comp.constprop (struct type_t * data)
> {
> struct type_t * res;
> struct type_t * x;
> struct type_t * y;
> size_t len;
>
> [local count: 1073741824]:
>
> [local count: 1073741824]:
> x_2 = min_of_x (data_1(D), 1);
> y_3 = max_of_y (data_1(D), 1);
> if (x_2 < y_3)
>goto ; [29.00%]
> else
>goto ; [71.00%]
>
> [local count: 311385128]:
>
> [local count: 1073741824]:
> # res_4 = PHI
> return res_4;
>
> }
>
> The silly question first. In the "if" stmt how does GCC
> get those probabilities? Which it shows as 29.00% and
> 71.00%. I believe they should both be 50.00%.
See the profile_estimate pass dump. One branch makes the function return
NULL, which makes gcc guess that it may be a bit less likely than the
other. Those are heuristics, which are tuned to help on average, but of
course they are sometimes wrong.
> The serious question is what is going on with this phi?
>res_4 = PHI
>
> This makes zero sense practicality wise to me and how is
> it supposed to be recognized and used? Note, I really do
> need to transform the "0B" into something else for my
> structure reorganization optimization.
That's not a question? Are you asking why PHIs exist at all? They are the
standard way to represent merging in SSA representations. You can iterate
on the PHIs of a basic block, etc.
> CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is
> for the sole use of the intended recipient(s) and contains information that
> is confidential and proprietary to Ampere Computing or its subsidiaries. It
> is to be used solely for the purpose of furthering the parties' business
> relationship. Any unauthorized review, copying, or distribution of this email
> (or any attachments thereto) is strictly prohibited. If you are not the
> intended recipient, please contact the sender immediately and permanently
> delete the original and any copies of this email and any attachments thereto.
Could you please get rid of this when posting on public mailing lists?
--
Marc Glisse
Re: A couple GIMPLE questions
>That's not a question? Are you asking why PHIs exist at all?
>They are the standard way to represent merging in SSA
>representations. You can iterate on the PHIs of a basic block, etc.
Marc,
I first worked with the SSA form twenty years ago so yes I am
aware of what a phi is... I've just never seen a compiler eliminate
an assignment of a variable to a constant and jam the constant into
the phi where the SSA variable should be. What a phi is all about
is representing data flow and a constant in the phi doesn't seem
to be related to that. I can deal with this but it seems that having to
crawl the phis looking for constants seems baroque. I would hope
there is a control that can suppress this or a transformation
that I can invoke to reverse it...
Thanks,
Gary
From: Marc Glisse
Sent: Saturday, September 5, 2020 11:29 PM
To: Gary Oblock
Cc: gcc@gcc.gnu.org
Subject: Re: A couple GIMPLE questions
[EXTERNAL EMAIL NOTICE: This email originated from an external sender. Please
be mindful of safe email handling and proprietary information protection
practices.]
On Sat, 5 Sep 2020, Gary Oblock via Gcc wrote:
> First off one of the questions just me being curious but
> second is quite serious. Note, this is GIMPLE coming
> into my optimization and not something I've modified.
>
> Here's the C code:
>
> type_t *
> do_comp( type_t *data, size_t len)
> {
> type_t *res;
> type_t *x = min_of_x( data, len);
> type_t *y = max_of_y( data, len);
>
> res = y;
> if ( x < y ) res = 0;
> return res;
> }
>
> And here's the resulting GIMPLE:
>
> ;; Function do_comp.constprop (do_comp.constprop.0, funcdef_no=5,
> decl_uid=4392, cgraph_uid=3, symbol_order=68) (executed once)
>
> do_comp.constprop (struct type_t * data)
> {
> struct type_t * res;
> struct type_t * x;
> struct type_t * y;
> size_t len;
>
> [local count: 1073741824]:
>
> [local count: 1073741824]:
> x_2 = min_of_x (data_1(D), 1);
> y_3 = max_of_y (data_1(D), 1);
> if (x_2 < y_3)
>goto ; [29.00%]
> else
>goto ; [71.00%]
>
> [local count: 311385128]:
>
> [local count: 1073741824]:
> # res_4 = PHI
> return res_4;
>
> }
>
> The silly question first. In the "if" stmt how does GCC
> get those probabilities? Which it shows as 29.00% and
> 71.00%. I believe they should both be 50.00%.
See the profile_estimate pass dump. One branch makes the function return
NULL, which makes gcc guess that it may be a bit less likely than the
other. Those are heuristics, which are tuned to help on average, but of
course they are sometimes wrong.
> The serious question is what is going on with this phi?
>res_4 = PHI
>
> This makes zero sense practicality wise to me and how is
> it supposed to be recognized and used? Note, I really do
> need to transform the "0B" into something else for my
> structure reorganization optimization.
That's not a question? Are you asking why PHIs exist at all? They are the
standard way to represent merging in SSA representations. You can iterate
on the PHIs of a basic block, etc.
> CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is
> for the sole use of the intended recipient(s) and contains information that
> is confidential and proprietary to Ampere Computing or its subsidiaries. It
> is to be used solely for the purpose of furthering the parties' business
> relationship. Any unauthorized review, copying, or distribution of this email
> (or any attachments thereto) is strictly prohibited. If you are not the
> intended recipient, please contact the sender immediately and permanently
> delete the original and any copies of this email and any attachments thereto.
Could you please get rid of this when posting on public mailing lists?
--
Marc Glisse
Re: A couple GIMPLE questions
On Sat, 5 Sep 2020, Gary Oblock via Gcc wrote:
First off one of the questions just me being curious but
second is quite serious. Note, this is GIMPLE coming
into my optimization and not something I've modified.
Here's the C code:
type_t *
do_comp( type_t *data, size_t len)
{
type_t *res;
type_t *x = min_of_x( data, len);
type_t *y = max_of_y( data, len);
res = y;
if ( x < y ) res = 0;
return res;
}
And here's the resulting GIMPLE:
;; Function do_comp.constprop (do_comp.constprop.0, funcdef_no=5,
decl_uid=4392, cgraph_uid=3, symbol_order=68) (executed once)
do_comp.constprop (struct type_t * data)
{
struct type_t * res;
struct type_t * x;
struct type_t * y;
size_t len;
[local count: 1073741824]:
[local count: 1073741824]:
x_2 = min_of_x (data_1(D), 1);
y_3 = max_of_y (data_1(D), 1);
if (x_2 < y_3)
goto ; [29.00%]
else
goto ; [71.00%]
[local count: 311385128]:
[local count: 1073741824]:
# res_4 = PHI
return res_4;
}
The silly question first. In the "if" stmt how does GCC
get those probabilities? Which it shows as 29.00% and
71.00%. I believe they should both be 50.00%.
See the profile_estimate pass dump. One branch makes the function return
NULL, which makes gcc guess that it may be a bit less likely than the
other. Those are heuristics, which are tuned to help on average, but of
course they are sometimes wrong.
The serious question is what is going on with this phi?
res_4 = PHI
This makes zero sense practicality wise to me and how is
it supposed to be recognized and used? Note, I really do
need to transform the "0B" into something else for my
structure reorganization optimization.
That's not a question? Are you asking why PHIs exist at all? They are the
standard way to represent merging in SSA representations. You can iterate
on the PHIs of a basic block, etc.
CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for
the sole use of the intended recipient(s) and contains information that is
confidential and proprietary to Ampere Computing or its subsidiaries. It is to
be used solely for the purpose of furthering the parties' business
relationship. Any unauthorized review, copying, or distribution of this email
(or any attachments thereto) is strictly prohibited. If you are not the
intended recipient, please contact the sender immediately and permanently
delete the original and any copies of this email and any attachments thereto.
Could you please get rid of this when posting on public mailing lists?
--
Marc Glisse
