[Bug tree-optimization/93780] New: [10 Regression] ICE in SET_TYPE_VECTOR_SUBPARTS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93780
Bug ID: 93780
Summary: [10 Regression] ICE in SET_TYPE_VECTOR_SUBPARTS
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: kretz at kde dot org
Target Milestone: ---
Target: x86_64-*-*, i?86-*-*
Test case (https://godbolt.org/z/ic8eXp):
#include
using V [[gnu::vector_size(32)]] = float;
float f() {
const float init[6] = {};
V v{};
__builtin_memcpy(, init, 6 * sizeof(float));
return std::legendre(0, v[0]);
}
Compile with `-std=c++17 -O1 -march=skylake-avx512`. Fails with:
In function 'float f()':
internal compiler error: in SET_TYPE_VECTOR_SUBPARTS, at tree.h:3860
0x82d1d0 SET_TYPE_VECTOR_SUBPARTS(tree_node*, poly_int<1u, unsigned long>)
/home/mkretz/src/gcc/gcc/tree.h:3860
0x82d1d0 make_vector_type
/home/mkretz/src/gcc/gcc/tree.c:9931
0x122d55b non_rewritable_lvalue_p
/home/mkretz/src/gcc/gcc/tree-ssa.c:1559
0x122e6c7 execute_update_addresses_taken()
/home/mkretz/src/gcc/gcc/tree-ssa.c:1725
0x10b6adc execute
/home/mkretz/src/gcc/gcc/tree-into-ssa.c:2436
[Bug analyzer/93779] ICE: unhandled tree code in region_model::get_lvalue_1: 'function_decl'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93779 --- Comment #1 from Arseny Solokha --- Apparently worked around by g:f76a88ebf089871dcce215aa0cb1956ccc060895?
[Bug analyzer/93779] New: ICE: unhandled tree code in region_model::get_lvalue_1: 'function_decl'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93779 Bug ID: 93779 Summary: ICE: unhandled tree code in region_model::get_lvalue_1: 'function_decl' Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: analyzer Assignee: dmalcolm at gcc dot gnu.org Reporter: asolokha at gmx dot com Target Milestone: --- gfortran-10.0.1-alpha20200216 snapshot (g:6e37e49616d429c5d922324ebd72ae95f12a079f) ICEs when compiling gcc/testsuite/gfortran.fortran-torture/compile/pr88304-2.f90 w/ -O1 -fanalyzer: % powerpc-e300c3-linux-gnu-gfortran-10.0.1 -O1 -fanalyzer -c gcc/testsuite/gfortran.fortran-torture/compile/pr88304-2.f90 during IPA pass: analyzer gcc/testsuite/gfortran.fortran-torture/compile/pr88304-2.f90:25:0: 25 | q = foo (p, r(u), w = baz) | internal compiler error: unhandled tree code in region_model::get_lvalue_1: 'function_decl' 0x126e32d ana::region_model::get_lvalue_1(ana::path_var, ana::region_model_context*) /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-10.0.1_alpha20200216/work/gcc-10-20200216/gcc/analyzer/region-model.cc:4644 0x126e413 ana::region_model::get_lvalue(ana::path_var, ana::region_model_context*) /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-10.0.1_alpha20200216/work/gcc-10-20200216/gcc/analyzer/region-model.cc:4774 0x1275e96 ana::region_model::on_assignment(gassign const*, ana::region_model_context*) /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-10.0.1_alpha20200216/work/gcc-10-20200216/gcc/analyzer/region-model.cc:3941 0x124cf77 ana::exploded_node::on_stmt(ana::exploded_graph&, ana::supernode const*, gimple const*, ana::program_state*, ana::state_change*) const /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-10.0.1_alpha20200216/work/gcc-10-20200216/gcc/analyzer/engine.cc:971 0x124d929 ana::exploded_graph::process_node(ana::exploded_node*) /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-10.0.1_alpha20200216/work/gcc-10-20200216/gcc/analyzer/engine.cc:2449 0x124ddd2 ana::exploded_graph::process_worklist() /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-10.0.1_alpha20200216/work/gcc-10-20200216/gcc/analyzer/engine.cc:2267 0x124f94a ana::impl_run_checkers(ana::logger*) /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-10.0.1_alpha20200216/work/gcc-10-20200216/gcc/analyzer/engine.cc:3627 0x1250f11 ana::run_checkers() /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-10.0.1_alpha20200216/work/gcc-10-20200216/gcc/analyzer/engine.cc:3684 0x1245568 execute /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-10.0.1_alpha20200216/work/gcc-10-20200216/gcc/analyzer/analyzer-pass.cc:84 (While my target here is powerpc, the ICE is not target-specific.)
[Bug analyzer/93388] ensure -fanalyzer works with our C code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93388 --- Comment #13 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:f76a88ebf089871dcce215aa0cb1956ccc060895 commit r10-6667-gf76a88ebf089871dcce215aa0cb1956ccc060895 Author: David Malcolm Date: Thu Feb 13 21:17:11 2020 -0500 analyzer: fix ICEs in region_model::get_lvalue_1 [PR 93388] There have been various ICEs with -fanalyzer involving unhandled tree codes in region_model::get_lvalue_1; PR analyzer/93388 reports various others e.g. for IMAGPART_EXPR, REALPART_EXPR, and VIEW_CONVERT_EXPR seen when running the testsuite with -fanalyzer forcibly enabled. Whilst we could implement lvalue-handling in the region model for every tree code, for some of these we're straying far from my primary goal for GCC 10 of implementing a double-free checker for C. This patch implements a fallback for unimplemented tree codes: create a dummy region, but mark the new state as being invalid, and stop exploring state along this path. It also implements VIEW_CONVERT_EXPR. Doing so fixes the ICEs, whilst effectively turning off the analyzer along code paths that use such tree codes. Hopefully this compromise is sensible for GCC 10. gcc/analyzer/ChangeLog: PR analyzer/93388 * engine.cc (impl_region_model_context::on_unknown_tree_code): New. (exploded_graph::get_or_create_node): Reject invalid states. * exploded-graph.h (impl_region_model_context::on_unknown_tree_code): New decl. (point_and_state::point_and_state): Assert that the state is valid. * program-state.cc (program_state::program_state): Initialize m_valid to true. (program_state::operator=): Copy m_valid. (program_state::program_state): Likewise for move constructor. (program_state::print): Print m_valid. (program_state::dump_to_pp): Likewise. * program-state.h (program_state::m_valid): New field. * region-model.cc (region_model::get_lvalue_1): Implement the default case by returning a new symbolic region and calling the context's on_unknown_tree_code, rather than issuing an internal_error. Implement VIEW_CONVERT_EXPR. * region-model.h (region_model_context::on_unknown_tree_code): New vfunc. (test_region_model_context::on_unknown_tree_code): New. gcc/testsuite/ChangeLog: PR analyzer/93388 * gcc.dg/analyzer/torture/20060625-1.c: New test. * gcc.dg/analyzer/torture/pr51628-30.c: New test. * gcc.dg/analyzer/torture/pr59037.c: New test.
[Bug analyzer/93778] New: ICE in get_region, at analyzer/region-model.h:1732
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93778 Bug ID: 93778 Summary: ICE in get_region, at analyzer/region-model.h:1732 Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: analyzer Assignee: dmalcolm at gcc dot gnu.org Reporter: asolokha at gmx dot com Target Milestone: --- gfortran-10.0.1-alpha20200216 snapshot (g:6e37e49616d429c5d922324ebd72ae95f12a079f) ICEs when compiling the following testcase, reduced from gcc/testsuite/gfortran.dg/namelist_60.f90, w/ -fanalyzer: program h0 type bl integer jq end type bl type qn type (bl), dimension(3) :: xi end type qn type (qn) ro namelist /i2/ ro read(10, nml = i2) end program h0 % powerpc-e300c3-linux-gnu-gfortran-10.0.1 -fanalyzer -c vbdlscyi.f90 during IPA pass: analyzer vbdlscyi.f90:10:0: 10 | read(10, nml = i2) | internal compiler error: in get_region, at analyzer/region-model.h:1732 0x74c477 ana::struct_or_union_region* ana::region_model::get_region(ana::region_id) const /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-10.0.1_alpha20200216/work/gcc-10-20200216/gcc/analyzer/region-model.h:1732 0x74c477 ana::region_model::get_field_region(ana::region_id, tree_node*) /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-10.0.1_alpha20200216/work/gcc-10-20200216/gcc/analyzer/region-model.cc:5102 0x126e413 ana::region_model::get_lvalue(ana::path_var, ana::region_model_context*) /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-10.0.1_alpha20200216/work/gcc-10-20200216/gcc/analyzer/region-model.cc:4774 0x126f78d ana::region_model::get_rvalue_1(ana::path_var, ana::region_model_context*) /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-10.0.1_alpha20200216/work/gcc-10-20200216/gcc/analyzer/region-model.cc:4817 0x126f7d3 ana::region_model::get_rvalue(ana::path_var, ana::region_model_context*) /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-10.0.1_alpha20200216/work/gcc-10-20200216/gcc/analyzer/region-model.cc:4854 0x125b91b ana::sm_state_map::purge_for_unknown_fncall(ana::exploded_graph const&, ana::state_machine const&, gcall const*, tree_node*, ana::region_model*) /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-10.0.1_alpha20200216/work/gcc-10-20200216/gcc/analyzer/program-state.cc:416 0x124d2d6 ana::exploded_node::on_stmt(ana::exploded_graph&, ana::supernode const*, gimple const*, ana::program_state*, ana::state_change*) const /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-10.0.1_alpha20200216/work/gcc-10-20200216/gcc/analyzer/engine.cc:1062 0x124d929 ana::exploded_graph::process_node(ana::exploded_node*) /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-10.0.1_alpha20200216/work/gcc-10-20200216/gcc/analyzer/engine.cc:2449 0x124ddd2 ana::exploded_graph::process_worklist() /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-10.0.1_alpha20200216/work/gcc-10-20200216/gcc/analyzer/engine.cc:2267 0x124f94a ana::impl_run_checkers(ana::logger*) /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-10.0.1_alpha20200216/work/gcc-10-20200216/gcc/analyzer/engine.cc:3627 0x1250f11 ana::run_checkers() /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-10.0.1_alpha20200216/work/gcc-10-20200216/gcc/analyzer/engine.cc:3684 0x1245568 execute /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-10.0.1_alpha20200216/work/gcc-10-20200216/gcc/analyzer/analyzer-pass.cc:84 (While my target here is powerpc, the ICE is not target-specific.)
[Bug analyzer/93777] New: ICE in maybe_cast_1, at analyzer/region-model.cc:5064
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93777 Bug ID: 93777 Summary: ICE in maybe_cast_1, at analyzer/region-model.cc:5064 Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: analyzer Assignee: dmalcolm at gcc dot gnu.org Reporter: asolokha at gmx dot com Target Milestone: --- gfortran-10.0.1-alpha20200216 snapshot (g:6e37e49616d429c5d922324ebd72ae95f12a079f) ICEs when compiling the following testcase, reduced from gcc/testsuite/gfortran.dg/block_13.f08, w/ -fanalyzer: program cb implicit none type :: jn real, allocatable :: ie character(len = :), allocatable :: e5 end type jn real, parameter :: gm = 5.0 block type(jn) :: r2 r2 = jn (gm, "") call vz (r2%ie, gm) end block contains subroutine vz (arg1, arg2) real :: arg1, arg2 if (arg1 .ne. arg2) STOP 1 end subroutine vz end program cb % powerpc-e300c3-linux-gnu-gfortran-10.0.1 -fanalyzer -c mouy3agw.f08 during IPA pass: analyzer mouy3agw.f08:13:0: 13 | call vz (r2%ie, gm) | internal compiler error: in maybe_cast_1, at analyzer/region-model.cc:5064 0x74b5ef ana::region_model::maybe_cast_1(tree_node*, ana::svalue_id) /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-10.0.1_alpha20200216/work/gcc-10-20200216/gcc/analyzer/region-model.cc:5064 0x1264da0 ana::region_model::maybe_cast(tree_node*, ana::svalue_id, ana::region_model_context*) /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-10.0.1_alpha20200216/work/gcc-10-20200216/gcc/analyzer/region-model.cc:5085 0x1267671 ana::region::set_value(ana::region_model&, ana::region_id, ana::svalue_id, ana::region_model_context*) /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-10.0.1_alpha20200216/work/gcc-10-20200216/gcc/analyzer/region-model.cc:1012 0x126cd35 ana::root_region::push_frame(ana::region_model*, function*, vec*, ana::region_model_context*) /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-10.0.1_alpha20200216/work/gcc-10-20200216/gcc/analyzer/region-model.cc:2894 0x1270ce6 ana::region_model::update_for_call_superedge(ana::call_superedge const&, ana::region_model_context*) /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-10.0.1_alpha20200216/work/gcc-10-20200216/gcc/analyzer/region-model.cc:5740 0x1270e47 ana::region_model::maybe_update_for_edge(ana::superedge const&, gimple const*, ana::region_model_context*) /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-10.0.1_alpha20200216/work/gcc-10-20200216/gcc/analyzer/region-model.cc:5678 0x125aba3 ana::program_state::on_edge(ana::exploded_graph&, ana::exploded_node const&, ana::superedge const*, ana::state_change*) /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-10.0.1_alpha20200216/work/gcc-10-20200216/gcc/analyzer/program-state.cc:781 0x124726b ana::exploded_node::on_edge(ana::exploded_graph&, ana::superedge const*, ana::program_point*, ana::program_state*, ana::state_change*) const /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-10.0.1_alpha20200216/work/gcc-10-20200216/gcc/analyzer/engine.cc:1104 0x124d7e0 ana::exploded_graph::process_node(ana::exploded_node*) /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-10.0.1_alpha20200216/work/gcc-10-20200216/gcc/analyzer/engine.cc:2516 0x124ddd2 ana::exploded_graph::process_worklist() /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-10.0.1_alpha20200216/work/gcc-10-20200216/gcc/analyzer/engine.cc:2267 0x124f94a ana::impl_run_checkers(ana::logger*) /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-10.0.1_alpha20200216/work/gcc-10-20200216/gcc/analyzer/engine.cc:3627 0x1250f11 ana::run_checkers() /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-10.0.1_alpha20200216/work/gcc-10-20200216/gcc/analyzer/engine.cc:3684 0x1245568 execute /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-10.0.1_alpha20200216/work/gcc-10-20200216/gcc/analyzer/analyzer-pass.cc:84 (While my target here is powerpc, the ICE is not target-specific.)
[Bug analyzer/93774] ICE in lhd_incomplete_type_error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93774 --- Comment #1 from David Malcolm --- (In reply to Arseny Solokha from comment #0) > Is it OK now to report analyzer ICEs when testing it w/ languages other than > C? Yes, though I'm likely to treat them as lower priority for now.
[Bug tree-optimization/93776] [10 Regression] ICE in verify_sra_access_forest, at tree-sra.c:2326
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93776 Andrew Pinski changed: What|Removed |Added Depends on||93667 --- Comment #1 from Andrew Pinski --- Looks similar to PR 93667. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93667 [Bug 93667] [10 regression] ICE in esra with nested [[no_unique_address]] field
[Bug tree-optimization/93776] [10 Regression] ICE in verify_sra_access_forest, at tree-sra.c:2326
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93776 Andrew Pinski changed: What|Removed |Added Keywords||ice-on-valid-code Target Milestone|--- |10.0
[Bug tree-optimization/93776] New: [10 Regression] ICE in verify_sra_access_forest, at tree-sra.c:2326
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93776
Bug ID: 93776
Summary: [10 Regression] ICE in verify_sra_access_forest, at
tree-sra.c:2326
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
Target: powerpc-*-linux-gnu
gcc-10.0.1-alpha20200216 snapshot (g:6e37e49616d429c5d922324ebd72ae95f12a079f)
ICEs when compiling the following testcase w/ -O1 for 32-bit BE powerpc:
struct ue {
};
struct ed {
int al;
struct ue pr;
int j2;
};
void
mc (void)
{
struct ed g0, d7;
g0.j2 = 0;
__builtin_memcpy (, , sizeof (g0));
d7.pr = (struct ue) {};
}
% powerpc-e300c3-linux-gnu-gcc-10.0.1 -O1 -c unei3zh3.c
during GIMPLE pass: esra
unei3zh3.c: In function 'mc':
unei3zh3.c:18:1: internal compiler error: in verify_sra_access_forest, at
tree-sra.c:2326
18 | }
| ^
0x6d33e8 verify_sra_access_forest(access*)
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-10.0.1_alpha20200216/work/gcc-10-20200216/gcc/tree-sra.c:2326
0xf2af32 verify_all_sra_access_forests()
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-10.0.1_alpha20200216/work/gcc-10-20200216/gcc/tree-sra.c:2387
0xf2ccec analyze_all_variable_accesses
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-10.0.1_alpha20200216/work/gcc-10-20200216/gcc/tree-sra.c:3398
0xf2eace perform_intra_sra
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-10.0.1_alpha20200216/work/gcc-10-20200216/gcc/tree-sra.c:4451
[Bug analyzer/93775] New: ICE in cgraph_node::get(tree_node const*)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93775 Bug ID: 93775 Summary: ICE in cgraph_node::get(tree_node const*) Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: analyzer Assignee: dmalcolm at gcc dot gnu.org Reporter: asolokha at gmx dot com Target Milestone: --- gcc-10.0.1-alpha20200216 snapshot (g:6e37e49616d429c5d922324ebd72ae95f12a079f) ICEs when compiling gcc/testsuite/gcc.c-torture/compile/20020129-1.c w/ -fanalyzer: % gcc-10.0.1 -fanalyzer -c gcc/testsuite/gcc.c-torture/compile/20020129-1.c during IPA pass: analyzer gcc/testsuite/gcc.c-torture/compile/20020129-1.c: In function 'foo': gcc/testsuite/gcc.c-torture/compile/20020129-1.c:17:3: internal compiler error: Segmentation fault 17 | bar (); | ^~~~ 0xd8a51f crash_signal /var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200216/work/gcc-10-20200216/gcc/toplev.c:328 0x110a317 cgraph_node::get(tree_node const*) /var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200216/work/gcc-10-20200216/gcc/cgraph.h:1378 0x110a317 ana::region_model::get_fndecl_for_call(gcall const*, ana::region_model_context*) /var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200216/work/gcc-10-20200216/gcc/analyzer/region-model.cc:6680 0x110e58b ana::region_model::on_call_pre(gcall const*, ana::region_model_context*) /var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200216/work/gcc-10-20200216/gcc/analyzer/region-model.cc:4175 0x10e8298 ana::exploded_node::on_stmt(ana::exploded_graph&, ana::supernode const*, gimple const*, ana::program_state*, ana::state_change*) const /var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200216/work/gcc-10-20200216/gcc/analyzer/engine.cc:1035 0x10e87fb ana::exploded_graph::process_node(ana::exploded_node*) /var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200216/work/gcc-10-20200216/gcc/analyzer/engine.cc:2449 0x10e8c92 ana::exploded_graph::process_worklist() /var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200216/work/gcc-10-20200216/gcc/analyzer/engine.cc:2267 0x10e93b9 ana::impl_run_checkers(ana::logger*) /var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200216/work/gcc-10-20200216/gcc/analyzer/engine.cc:3627 0x10e9e5c ana::run_checkers() /var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200216/work/gcc-10-20200216/gcc/analyzer/engine.cc:3684 0x10df858 execute /var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200216/work/gcc-10-20200216/gcc/analyzer/analyzer-pass.cc:84
[Bug analyzer/93774] New: ICE in lhd_incomplete_type_error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93774 Bug ID: 93774 Summary: ICE in lhd_incomplete_type_error Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: analyzer Assignee: dmalcolm at gcc dot gnu.org Reporter: asolokha at gmx dot com Target Milestone: --- Is it OK now to report analyzer ICEs when testing it w/ languages other than C? gfortran-10.0.1-alpha20200216 snapshot (g:6e37e49616d429c5d922324ebd72ae95f12a079f) ICEs when compiling gcc/testsuite/gfortran.dg/deferred_character_25.f90 w/ -O1 -fanalyzer: % powerpc-e300c3-linux-gnu-gfortran-10.0.1 -O1 -fanalyzer -c gcc/testsuite/gfortran.dg/deferred_character_25.f90 during IPA pass: analyzer gcc/testsuite/gfortran.dg/deferred_character_25.f90:28:0: 28 | if (s%c(3) .ne. str(3)) stop 4 | internal compiler error: in lhd_incomplete_type_error, at langhooks.c:205 0x6514ec lhd_incomplete_type_error(unsigned int, tree_node const*, tree_node const*) /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-10.0.1_alpha20200216/work/gcc-10-20200216/gcc/langhooks.c:205 0x1188419 size_in_bytes_loc(unsigned int, tree_node const*) /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-10.0.1_alpha20200216/work/gcc-10-20200216/gcc/tree.c:3264 0x126797d size_in_bytes(tree_node const*) /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-10.0.1_alpha20200216/work/gcc-10-20200216/gcc/tree.h:4633 0x126797d ana::region_model::convert_byte_offset_to_array_index(tree_node*, ana::svalue_id) /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-10.0.1_alpha20200216/work/gcc-10-20200216/gcc/analyzer/region-model.cc:6508 0x126dbb1 ana::region_model::get_or_create_mem_ref(tree_node*, ana::svalue_id, ana::svalue_id, ana::region_model_context*) /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-10.0.1_alpha20200216/work/gcc-10-20200216/gcc/analyzer/region-model.cc:6606 0x1276233 ana::region_model::on_assignment(gassign const*, ana::region_model_context*) /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-10.0.1_alpha20200216/work/gcc-10-20200216/gcc/analyzer/region-model.cc:4000 0x124cf77 ana::exploded_node::on_stmt(ana::exploded_graph&, ana::supernode const*, gimple const*, ana::program_state*, ana::state_change*) const /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-10.0.1_alpha20200216/work/gcc-10-20200216/gcc/analyzer/engine.cc:971 0x124d929 ana::exploded_graph::process_node(ana::exploded_node*) /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-10.0.1_alpha20200216/work/gcc-10-20200216/gcc/analyzer/engine.cc:2449 0x124ddd2 ana::exploded_graph::process_worklist() /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-10.0.1_alpha20200216/work/gcc-10-20200216/gcc/analyzer/engine.cc:2267 0x124f94a ana::impl_run_checkers(ana::logger*) /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-10.0.1_alpha20200216/work/gcc-10-20200216/gcc/analyzer/engine.cc:3627 0x1250f11 ana::run_checkers() /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-10.0.1_alpha20200216/work/gcc-10-20200216/gcc/analyzer/engine.cc:3684 0x1245568 execute /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-10.0.1_alpha20200216/work/gcc-10-20200216/gcc/analyzer/analyzer-pass.cc:84 (While my target here is powerpc, the ICE is not target-specific.)
[Bug analyzer/93773] New: Analyzer probably fails to recognize end of C macros in some cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93773 Bug ID: 93773 Summary: Analyzer probably fails to recognize end of C macros in some cases Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: analyzer Assignee: dmalcolm at gcc dot gnu.org Reporter: asolokha at gmx dot com Target Milestone: --- Created attachment 47857 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47857=edit Compiler output I failed to come up w/ a reduced testcase and can only provide instructions to reproduce the issue, so this PR is technically invalid. The issue, however, is real. It can be seen when compiling gawk and perl, and probably any complex bison-generated parser. When emitting "note: in expansion of macro 'YYSTACK_BYTES'" (five times in the attached output), analyzer quotes the code from the macro expansion point all the way down to the point where it is used in a file, potentially printing hundreds or thousands of unrelated lines, which is clearly wrong. It probably fails to discern end of the macro. The attached output was produced when building gawk 5.0.1 w/ -O1 -fanalyzer, particularly when compiling awkgram.c: CC=gcc-10.0.1 CFLAGS="-O1 -fanalyzer" ./configure make -k or, specifically, gcc-10.0.1 -DHAVE_CONFIG_H -DGAWK -I"./support" -I. -O1 -fanalyzer -DNDEBUG -c -o awkgram.o awkgram.c
[Bug target/93047] frename-registers does not work well with __builtin_return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93047 Jiu Fu Guo changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Jiu Fu Guo --- Patch committed.
[Bug target/93047] frename-registers does not work well with __builtin_return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93047 --- Comment #5 from CVS Commits --- The master branch has been updated by Jiu Fu Guo : https://gcc.gnu.org/g:a8532e9927ad6e4bbedbb957b02ca413aedf9098 commit r10-6664-ga8532e9927ad6e4bbedbb957b02ca413aedf9098 Author: Jiufu Guo Date: Mon Feb 17 10:48:39 2020 +0800 rs6000: mark clobber for registers changed by untpyed_call As PR93047 said, __builtin_apply/__builtin_return does not work well with -frename-registers. This is caused by return register(e.g. r3) is used to rename another register, before return register is stored to stack. This patch fix this issue by emitting clobber for those egisters which maybe changed by untyped call. gcc/ 2020-02-17 Jiufu Guo PR target/93047 * config/rs6000/rs6000.md (untyped_call): Add emit_clobber. gcc/testsuite 2020-02-17 Jiufu Guo PR target/93047 * gcc.dg/torture/stackalign/builtin-return-2.c: New test case.
[Bug target/93047] frename-registers does not work well with __builtin_return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93047 Jiu Fu Guo changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2020-02-17 Assignee|unassigned at gcc dot gnu.org |guojiufu at gcc dot gnu.org Ever confirmed|0 |1
[Bug target/82199] __builtin_shuffle sometimes should produce zip1 rather than TBL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82199 Andrew Pinski changed: What|Removed |Added Attachment #47850|0 |1 is obsolete|| --- Comment #4 from Andrew Pinski --- Created attachment 47856 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47856=edit New patch (with testcases) New patch with testcases. I will be submitting this by Friday.
[Bug target/93720] [10 Regression] vector creation from two parts of two vectors produces TBL rather than ins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93720 Andrew Pinski changed: What|Removed |Added Attachment #47853|0 |1 is obsolete|| --- Comment #10 from Andrew Pinski --- Created attachment 47855 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47855=edit New patch with testcases added Note some of the testcases depend on PR 82199. I will be submitting both by the end of next week.
[Bug target/93720] [10 Regression] vector creation from two parts of two vectors produces TBL rather than ins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93720 Andrew Pinski changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org --- Comment #9 from Andrew Pinski --- Mine.
[Bug lto/93772] ICE in cgraph.c with lto when symbol not defined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93772 --- Comment #2 from Daniel Santos --- (In reply to Andrew Pinski from comment #1) > See https://gcc.gnu.org/wiki/A_guide_to_testcase_reduction on how to reduce > the sources down to something which you might be able to share with us. Hello Andrew. I can give it a try, but up against time constraints at the moment. :( This looks like a nice guide btw! I've been a bit of a stranger on gcc lately. Also this project has a mix of C and C++ sources, the later built as follows: g++ -DHAVE_CONFIG_H -O2 -march=native -g3 -flto -std=gnu++11 -Wall -Wextra -Wno-unused-parameter -Wno-ignored-qualifiers -MT my_file.o -MD -MP -MF .deps/my_file.Tpo -c -o my_file.o my_file.cc
[Bug lto/93772] ICE in cgraph.c with lto when symbol not defined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93772 Andrew Pinski changed: What|Removed |Added Keywords||ice-on-valid-code Status|UNCONFIRMED |WAITING Last reconfirmed||2020-02-17 Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- See https://gcc.gnu.org/wiki/A_guide_to_testcase_reduction on how to reduce the sources down to something which you might be able to share with us.
[Bug lto/93772] New: ICE in cgraph.c with lto when symbol not defined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93772
Bug ID: 93772
Summary: ICE in cgraph.c with lto when symbol not defined
Product: gcc
Version: 9.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: daniel.santos at pobox dot com
CC: marxin at gcc dot gnu.org
Target Milestone: ---
I'm getting an ICE when I try to link while a symbol is used but not defined.
Unfortunately, the project is closed source, so this is about as much as I can
give:
from cgraph.c:
bool
cgraph_edge::possibly_call_in_translation_unit_p (void)
{
...
/* Otherwise we need to lookup prevailing symbol (symbol table is not merged,
yet) and see if it is a definition. In fact we may also resolve aliases,
but that is probably not too important. */
symtab_node *node = callee;
for (int n = 10; node->previous_sharing_asm_name && n ; n--)
node = node->previous_sharing_asm_name;
if (node->previous_sharing_asm_name)
node = symtab_node::get_for_asmname (DECL_ASSEMBLER_NAME (callee->decl));
gcc_assert (TREE_PUBLIC (node->decl)); /* <-- line 3825 */
return node->get_availability () >= AVAIL_AVAILABLE;
}
soures built with:
gcc -DHAVE_CONFIG_H -O2 -march=native -g3 -flto -ansi -std=c89
-Wall -Wextra -Wno-unused-parameter -Wno-ignored-qualifiers -Werror=implicit
-MT gpio/my_file.o -MD -MP -MF gpio/.deps/my_file.Tpo -c -o gpio/my_file.o
gpio/my_file.c
link command:
g++ -O2 -march=native -g3 -flto -std=gnu++11 -Wall -Wextra
-Wno-unused-parameter -Wno-ignored-qualifiers -flto -O2 -o my_file -lrt -lpthread -Wl,-Bstatic -lboost_date_time -lboost_program_options
-lboost_regex -lboost_system -lboost_thread -Wl,-Bdynamic -lftdi -lusb
-lusb-1.0
during IPA pass: cp
lto1: internal compiler error: in possibly_call_in_translation_unit_p, at
cgraph.c:3825
0x583655 cgraph_edge::possibly_call_in_translation_unit_p()
/usr/src/debug/sys-devel/gcc-9.2.0-r4/gcc-9.2.0/gcc/cgraph.c:3825
0x583655 ipa_read_edge_info
/usr/src/debug/sys-devel/gcc-9.2.0-r4/gcc-9.2.0/gcc/ipa-prop.c:4378
0x583655 ipa_read_node_info
/usr/src/debug/sys-devel/gcc-9.2.0-r4/gcc-9.2.0/gcc/ipa-prop.c:4455
0x583655 ipa_prop_read_section
/usr/src/debug/sys-devel/gcc-9.2.0-r4/gcc-9.2.0/gcc/ipa-prop.c:4539
0x583655 ipa_prop_read_jump_functions()
/usr/src/debug/sys-devel/gcc-9.2.0-r4/gcc-9.2.0/gcc/ipa-prop.c:4565
0xda927f ipa_read_summaries_1
/usr/src/debug/sys-devel/gcc-9.2.0-r4/gcc-9.2.0/gcc/passes.c:2842
0xd79167 read_cgraph_and_symbols
/usr/src/debug/sys-devel/gcc-9.2.0-r4/gcc-9.2.0/gcc/lto/lto.c:2972
0xd79167 lto_main()
/usr/src/debug/sys-devel/gcc-9.2.0-r4/gcc-9.2.0/gcc/lto/lto.c:3387
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug debug/93751] -g1 does not behave per manual
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93751 --- Comment #7 from Andrew Pinski --- >All the other formats are effectively deprecated at this point I think. Right; as I mentioned this has been an issue since dwarf2 support was added; since 1996. Which means if someone depdended on this, it would have broke when dwarf2 became default for x86 over 15 years ago.
[Bug debug/93751] -g1 does not behave per manual
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93751
--- Comment #6 from Eric Botcazou ---
> But it turned out that we cannot go to -g1, exactly because we need the
> ability to find the addresses/locations of all exported objects - both
> functions and data.
Do you really need debug information for this?
> First, I am not sure that fixing a manual is a good idea: that would require
> removing generation of such debug info for older formats to align with
> current DWARF behavior ("-g1 makes GCC generate debug info only for
> functions"), which is much likelier to break existing users which depend on
> it.
All the other formats are effectively deprecated at this point I think.
> Also I think most typical executables have fewer exported data objects than
> they do have functions (note that for functions, DIEs are generated even for
> static ones, so the increase in size of the debugging info should be fairly
> negligible. Users concerned about even such minor increases typically strip
> the debug information from the binaries altogether.
People use -g1 precisely because they cannot strip all the debug information,
otherwise they would just use -g0. And they don't use -g2 because it's bloated
so we must be careful not to do the same for -g1. To sum up, I think that we
would need some figures before changing a behavior that has been there for 25
years.
[Bug debug/93751] -g1 does not behave per manual
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93751
--- Comment #5 from Alexey Neyman ---
Well, that's exactly how I encountered this bug. We have some built-in
introspection in our binary and we noticed that GCC generates a lot of debug
info for local variables; the difference between -g and -g1 was ~75% decrease
in the size of the debugging information.
But it turned out that we cannot go to -g1, exactly because we need the ability
to find the addresses/locations of all exported objects - both functions and
data.
First, I am not sure that fixing a manual is a good idea: that would require
removing generation of such debug info for older formats to align with current
DWARF behavior ("-g1 makes GCC generate debug info only for functions"), which
is much likelier to break existing users which depend on it.
Also I think most typical executables have fewer exported data objects than
they do have functions (note that for functions, DIEs are generated even for
static ones, so the increase in size of the debugging info should be fairly
negligible. Users concerned about even such minor increases typically strip the
debug information from the binaries altogether.
But if the size is a concern, maybe have a finer-grained knobs for enabling
debug info? E.g.
`-gpublic-functions`
`-gpublic-data`
`-gall-functions`
`-gall-data`
`-gmacros`
and have `-gX` implemented as aliases to sets of these options? `-g1` would be
then translated to `-gall-functions -gpublic-data` (if implemented per manual)
or just `-gall-functions` (if current behavior is kept).
[Bug target/93743] [9/10 Regression] swapped arguments in atan2l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93743 Uroš Bizjak changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Uroš Bizjak --- Fixed for gcc-9.3+.
[Bug target/93743] [9/10 Regression] swapped arguments in atan2l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93743 --- Comment #6 from CVS Commits --- The releases/gcc-9 branch has been updated by Uros Bizjak : https://gcc.gnu.org/g:bfa537a2ffb30c0d537bb74ade124ca07e9712fe commit r9-8243-gbfa537a2ffb30c0d537bb74ade124ca07e9712fe Author: Uros Bizjak Date: Sun Feb 16 23:43:22 2020 +0100 i386: Fix atan2l argument order [PR93743] PR target/93743 * config/i386/i386.md (atan2xf3): Swap operands 1 and 2. (atan23): Update operand order in the call to gen_atan2xf3. testsuite/ChangeLog: PR target/93743 * gcc.target/i386/pr93743.c : New test.
[Bug tree-optimization/93771] SLP produces VEC_PERM when should have used vector generation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93771
--- Comment #1 from Andrew Pinski ---
If t[3] was an unrelated load, then SLP does the correct thing.
E.g.
void f(double *a, double *t, double *t0, double *d)
{
double t1 = t[0] + d[0];
double t2 = t0[0] + d[1];
a[0] = t1;
a[1] = t2;
}
Note this was reduced from PR 93720 comment #2.
[Bug target/93709] [10 regression] fortran.dg/minlocval_4.f90 fails on power 9 after r10-4160
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93709 --- Comment #1 from Bill Schmidt --- r10-4160 is the "daily bump" commit. How confident are you in your bisection? :-)
[Bug target/93720] [10 Regression] vector creation from two parts of two vectors produces TBL rather than ins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93720 --- Comment #8 from Andrew Pinski --- (In reply to Andrew Pinski from comment #7) > Yes we still have the extra mov, but that seems to be a register allocator > issue. I have not looked into it further. But the original SLP issue is what produces the bad TBL in the first place, I filed that as PR 93771.
[Bug tree-optimization/93771] New: SLP produces VEC_PERM when should have used vector generation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93771
Bug ID: 93771
Summary: SLP produces VEC_PERM when should have used vector
generation
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Target Milestone: ---
Take:
void f(double *a, double *t, double *d)
{
double t1 = t[0] + d[0];
double t2 = t[3] + d[1];
a[0] = t1;
a[1] = t2;
}
CUT ---
This produces:
vect__1.13_14 = MEM [(double *)t_6(D)];
vect__1.14_16 = MEM [(double *)t_6(D) + 16B];
vect__1.15_17 = VEC_PERM_EXPR ;
vect__2.18_19 = MEM [(double *)d_7(D)];
vect_t1_8.19_20 = vect__1.15_17 + vect__2.18_19;
MEM [(double *)a_10(D)] = vect_t1_8.19_20;
BUT that VEC_PERM_EXPR is not so good here. we only need to load t[0] and t[1]
and create a vector from those two.
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #188 from dave.anglin at bell dot net --- On 2020-02-15 3:32 p.m., peter.bisroev at groundlabs dot com wrote: > I have not had a chance to look through these in great detail, will do this > later today, but some things I've noticed (not sure how important they are > yet): > - aCC seems to use PCREL21BI relocations while GCC PCREL21B. That may be the clue. With GNU ld, only PCREL21BI goes through PLT. Need to look at when GNU as uses PCREL21BI instead of PCREL21B. I believe this selection is done in assembler.
[Bug libstdc++/93770] New: std::tuple::operator< sometimes does needless extra work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93770
Bug ID: 93770
Summary: std::tuple::operator< sometimes does needless extra
work
Product: gcc
Version: 9.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: gnu at kosak dot com
Target Milestone: ---
Hello,
In the simple program below, tuple::operator< calls the underlying
Foo::operator< twice (10 < 9, then 9 < 10), even though only the first call is
needed to get the correct answer. The same thing can happen with tuples of
larger dimension: if the prefix (all but the final element) compares equal, but
the final element compares greater-or-equal, we will do two calls to operator<
on the final element even though only the first one is needed to get the right
answer.
I have an example, and a suggested fix.
My example is a tuple of dimension 1:
$ g++ -O2 qwe.cc && ./a.out
Calculating 10 < 9
Calculating 9 < 10
!(t1 < t2)
Source:
===
#include
#include
struct Foo {
explicit Foo(int data) : data_(data) {}
int data_;
};
bool operator<(const Foo , const Foo ) {
std::cout << "Calculating " << lhs.data_ << " < " << rhs.data_ << std::endl;
return lhs.data_ < rhs.data_;
}
int main() {
auto t1 = std::make_tuple(Foo(10));
auto t2 = std::make_tuple(Foo(9));
if (t1 < t2) {
std::cout << "t1 < t2" << std::endl;
} else {
std::cout << "!(t1 < t2)" << std::endl;
}
}
The culprit is this code in /usr/include/c++/9/tuple:L1388
template
struct __tuple_compare
{
...
static constexpr bool
__less(const _Tp& __t, const _Up& __u)
{
return bool(std::get<__i>(__t) < std::get<__i>(__u))
|| (!bool(std::get<__i>(__u) < std::get<__i>(__t))
&& __tuple_compare<_Tp, _Up, __i + 1, __size>::__less(__t, __u));
}
};
The extra work happens at the final step of the recursion, when (__i + 1 ==
__size). In this case, due to template specialization, the right side of the
&& (namely __tuple_compare<_Tp, _Up, __i + 1, __size>::__less(__t, __u))
evaluates to the constant false regardless of __t and __u. Therefore the && is
always false, and the left side of the && (namely !bool(std::get<__i>(__u) <
std::get<__i>(__t)) is wasted effort.
One easy fix would be to test for the base case explicitly, as in
static constexpr bool
__less(const _Tp& __t, const _Up& __u)
{
return bool(std::get<__i>(__t) < std::get<__i>(__u))
|| (__i + 1 != __size // *** THIS LINE IS NEW ***
&& !bool(std::get<__i>(__u) < std::get<__i>(__t))
&& __tuple_compare<_Tp, _Up, __i + 1, __size>::__less(__t, __u));
}
$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/9/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:hsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 9.2.1-9ubuntu2'
--with-bugurl=file:///usr/share/doc/gcc-9/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,gm2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-9
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib
--with-target-system-zlib=auto --enable-multiarch --disable-werror
--with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32
--enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none,hsa
--without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 9.2.1 20191008 (Ubuntu 9.2.1-9ubuntu2)
[Bug c++/93752] internal compiler error: in pop_local_binding, at cp/name-lookup.c:2036
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93752 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-02-16 CC||msebor at gcc dot gnu.org Ever confirmed|0 |1 Known to fail||10.0, 4.1.3, 4.3.5, 4.4.7, ||4.8.5, 4.9.4, 5.4.0, 6.4.0, ||7.3.0, 8.3.0, 9.1.0 --- Comment #1 from Martin Sebor --- Confirmed. Looks like GCC has always failed with an ICE on this test case, at least going as far back as 4.1.
[Bug ipa/93763] [10 Regression] ice in propagate_vals_across_arith_jfunc, at ipa-cp.c:2039
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93763 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-02-16 CC||fxue at os dot amperecomputing.com ||, msebor at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Martin Sebor --- Bisection points to r10-6540: commit a0f6a8cb414b687f22c9011a894d5e8e398c4be0 Author: Feng Xue Date: Tue Jan 21 20:53:38 2020 +0800 Generalized value pass-through for self-recusive function (PR ipa/93203)
[Bug tree-optimization/93745] [8/9/10 Regression] Redundant store not eliminated with intermediate instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93745
Martin Sebor changed:
What|Removed |Added
Summary|Redundant store not |[8/9/10 Regression]
|eliminated with |Redundant store not
|intermediate instruction|eliminated with
||intermediate instruction
--- Comment #5 from Martin Sebor ---
In the example p cannot point to d because of the assignment i=*p which would
be undefined if it did. Other compilers (Clang an ICC) eliminate the accesses
via *p and emit optimal code, as do versions of GCC prior to 6, so this seems
like an unnecessary pessimization. Bisection points to r233453 which deals
with allocated objects, which are the only kind of objects whose type can
change in C. But I'll let Richard confirm whether this is necessary for some
reason.
commit 87440c298eb2ed47166b8d57a4afc90d310f3a8f
Author: Richard Biener
Date: Tue Feb 16 15:00:45 2016 +
re PR tree-optimization/69776 (Wrong optimization with aliasing)
2016-02-16 Richard Biener
PR tree-optimization/69776
* tree-ssa-alias.c (indirect_ref_may_alias_decl_p): Get alias
sets from caller.
(indirect_refs_may_alias_p): Likewise.
(refs_may_alias_p_1): Pass alias sets as from ao_ref.
* tree-ssa-sccvn.c (vn_reference_lookup): Also adjust vr alias-set
according to tbaa_p.
* tree-ssa-dom.c (lookup_avail_expr): Add tbaa_p flag.
(optimize_stmt): For redundant store discovery do not allow tbaa.
* gcc.dg/torture/pr69776-2.c: New testcase.
From-SVN: r233453
Since GCC eliminates the test in the modified example below it must assume that
p doesn't point to d, and so it should likewise be able to eliminate the *p=i
assignment as Marc expects.
double d;
void f(long*p){
long i=*p;
d=3.;
if (*p != i) // folded to false
abort ();
}
[Bug fortran/93599] [9/10 regression] Bug in fortran asynchronous I/O wait function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93599 Thomas Koenig changed: What|Removed |Added Attachment #47800|0 |1 is obsolete|| Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |tkoenig at gcc dot gnu.org --- Comment #11 from Thomas Koenig --- Created attachment 47854 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47854=edit Another attempt This patch is not ready for submission (style, marco arguments) but it seems to fix the problem; I have run async_4.f90 around 3e5 times on a POWER machine on which it failed previously. Bill, can you confirm that this fixes things? If so, I could clean this up and submit.
[Bug target/93743] [9/10 Regression] swapped arguments in atan2l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93743 --- Comment #5 from CVS Commits --- The master branch has been updated by Uros Bizjak : https://gcc.gnu.org/g:6e37e49616d429c5d922324ebd72ae95f12a079f commit r10-6662-g6e37e49616d429c5d922324ebd72ae95f12a079f Author: Uros Bizjak Date: Sun Feb 16 21:38:39 2020 +0100 i386: Fix atan2l argument order [PR93743] PR target/93743 * config/i386/i386.md (atan2xf3): Swap operands 1 and 2. (atan23): Update operand order in the call to gen_atan2xf3. testsuite/ChangeLog: PR target/93743 * gcc.target/i386/pr93743.c : New test.
[Bug c++/93769] New: Slightly wrong error message for static_asserts with no message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93769
Bug ID: 93769
Summary: Slightly wrong error message for static_asserts with
no message
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gennaro.prota+gccbugzilla at gmail dot com
Target Milestone: ---
Compiling with -std=c++14 --pedantic, the following translation unit:
static_assert(true);
int
main()
{
}
yields:
:1:15: warning: static_assert without a message only available with
'-std=c++17' or '-std=gnu++17' [-Wpedantic]
This is not true, because the compiler accepts it even with -std=c++11 or
-std=c++14.
Assuming this is intentional (but, if not, the message would still need
tweaking: e.g. it will be accepted with std=c++20, as well), I suggest to
reword the error message to:
static_assert without a message is non-standard before C++17
[Bug target/93720] [10 Regression] vector creation from two parts of two vectors produces TBL rather than ins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93720 --- Comment #7 from Andrew Pinski --- Created attachment 47853 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47853=edit A better version This attached patch is generalized version of the vec_perm to insert. We don't need need patterns in the .md file as there are already enough to do the correct thing. Yes we still have the extra mov, but that seems to be a register allocator issue. I have not looked into it further.
[Bug target/93768] New: Use vpternlog for composite logical operations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93768 Bug ID: 93768 Summary: Use vpternlog for composite logical operations Product: gcc Version: unknown Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: rth at gcc dot gnu.org Target Milestone: --- We should pattern-match multiple logical operations into the ternary logical operator. While there are lots of obscure combinations available, probably the most useful are Two-input inverted logicals: 0x11 ~(B|C) 0x77 ~(B) 0x99 ~(B^C) 0xbb C|~B 0xdd B|~C Three-input simple logicals: 0x80 A 0x96 A^B^C 0xfe A|B|C Multiple alternatives of the ?: operation, which allows the memory-capable operand, C, in various positions, and allows the input-output operand, A, in various positions: 0xe2 B?A:C 0xe4 C?A:B 0xb8 B?C:A 0xd8 C?B:A 0xca A?B:C 0xac A?C:B
[Bug c++/93585] Linker resolves variable with extern variable of same name but different type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93585 --- Comment #4 from Norman Goldstein --- I've received an explanation from bug-gnu-ut...@gnu.org. The C++11 standard 3.5/10 states that "... the types specified by all declarations referring to a given variable or function shall be identical ...", so no diagnostic is required. OK, so the two supplied source files do not constitute a proper C++ program, and it is outside the purview of the C++ compiler to catch such errors. This makes sense. Would it be a reasonable option to have the linker check for such mismatches? The name mangling must be dropped at some point in the link process, for the two symbols to resolve each other at link time.
[Bug target/93743] [9/10 Regression] swapped arguments in atan2l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93743 --- Comment #4 from Uroš Bizjak --- Created attachment 47852 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47852=edit Patch in testing.
[Bug c++/61414] enum class bitfield size-checking needs a separate warning flag controlling it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61414 --- Comment #30 from Eric Gallager --- (In reply to Jakub Jelinek from comment #29) > Fixed for 8.4+ and 9.3+ too. As far as I can tell, the commits in question just silenced the main false positives from that warning that people were complaining about, they didn't actually create a separate warning flag controlling the warning in question... I still think that's worth doing anyways.
[Bug target/93720] [10 Regression] vector creation from two parts of two vectors produces TBL rather than ins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93720 --- Comment #6 from Dmitrij Pochepko --- Created attachment 47851 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47851=edit current patch version
[Bug middle-end/90354] Skip the not first insn when traversing the insn node
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90354 --- Comment #8 from vfdff --- I have a method to fix this issue: check the egde with bb_has_eh_pred, and avoid bundling the jump insn when it is true.
[Bug tree-optimization/93767] New: wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93767
Bug ID: 93767
Summary: wrong code at -O3 on x86_64-linux-gnu
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: qrzhang at gatech dot edu
Target Milestone: ---
It appears to be a regression in 8.X. Gcc-7.4 works fine.
Bisection points to: g:a57776a11369621f9e9e8a8a3db6cb406c8bf27b
$ gcc-trunk -v
gcc version 10.0.1 20200216 (experimental) [master revision
93b8cfce27a:6bc9d585053:9a3d019a74d8d49fb6e6d75a00bd79fdb936a2e1] (GCC)
$ gcc-trunk abc.c ; ./a.out
1
$ gcc-trunk -O3 abc.c ; ./a.out
0
$ gcc-8 -O3 abc.c ; ./a.out
0
$ cat abc.c
int printf(const char *, ...);
int a[10];
short b;
int main() {
b = 6;
for (; b >= 3; b--) {
a[b] = 0 <= 0;
a[b + 2] = a[3];
}
printf("%d\n", a[5]);
}
[Bug go/93679] [10 regression] gccgo cannot bootstrap go1.14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93679 Ian Lance Taylor changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Ian Lance Taylor --- Should be fixed. Thanks for reporting it.
[Bug go/93679] [10 regression] gccgo cannot bootstrap go1.14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93679 --- Comment #1 from CVS Commits --- The master branch has been updated by Ian Lance Taylor : https://gcc.gnu.org/g:72700543b67561ab6a466e93b4c0d4fa8e6530e6 commit r10-6661-g72700543b67561ab6a466e93b4c0d4fa8e6530e6 Author: Ian Lance Taylor Date: Sat Feb 15 15:57:29 2020 -0800 libgo: install internal/reflectlite.gox This makes it possible to use gccgo to bootstrap Go 1.14. If we don't install this, gccgo can't compile the sort package. Fixes GCC PR go/93679 Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/219617
[Bug target/82199] __builtin_shuffle sometimes should produce zip1 rather than TBL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82199 --- Comment #3 from Andrew Pinski --- Created attachment 47850 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47850=edit Patch without testcases My patch but without testcases. I will try to add a few in a little bit.
[Bug target/93720] [10 Regression] vector creation from two parts of two vectors produces TBL rather than ins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93720 --- Comment #5 from Andrew Pinski --- (In reply to Andrew Pinski from comment #4) > Note the __builtin_shuffle expansion can be generialized to handle the case > where there is more than elements but only one element insert: Note this should be done after zip expansion has happened.
[Bug target/93720] [10 Regression] vector creation from two parts of two vectors produces TBL rather than ins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93720
--- Comment #4 from Andrew Pinski ---
Note the __builtin_shuffle expansion can be generialized to handle the case
where there is more than elements but only one element insert:
#define vector __attribute__((vector_size(16) ))
vector float f(vector float a, vector float b)
{
return __builtin_shuffle (a, b, (vector int){0, 4, 2, 3});
}
This function should generate:
ins v0.s[1], v1.s[0]
ret
#define vector __attribute__((vector_size(16) ))
vector float f1(vector float a, vector float b)
{
return __builtin_shuffle (b, a, (vector int){4, 0, 6, 7});
}
This function should also generate:
ins v0.s[1], v1.s[0]
ret
Even this:
#define vector __attribute__((vector_size(16) ))
vector float f(vector float a, vector float b)
{
return __builtin_shuffle (a, a, (vector int){0, 0, 2, 3});
}
Should generate:
ins v0.s[1], v0.s[0]
ret
[Bug tree-optimization/87313] attribute malloc not used for alias analysis when it could be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87313
pskocik at gmail dot com changed:
What|Removed |Added
CC||pskocik at gmail dot com
--- Comment #4 from pskocik at gmail dot com ---
If (when?) this optimization is implemented, it would also be great if
returning `type *restrict`, `struct somestruct { /*...*/ type *restrict p;
/*...*/ }`, or an equivalent of these via a pointer (e.g., as in `void
my_malloc(void *restrict*Result, size_t Sz);`) resulted in the same
optimization being applied ( unless I'm mistaken in that `restrict` applied in
these context implies the same (__attribute((malloc))-like) semantics).
[Bug target/82199] __builtin_shuffle sometimes should produce zip1 rather than TBL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82199
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2020-02-16
Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot
gnu.org
Ever confirmed|0 |1
--- Comment #2 from Andrew Pinski ---
I have a patch which goes in and re-encodes {0, 1, 4,5} to {0, 2} and uses V2DI
as the mode.
[Bug debug/93751] -g1 does not behave per manual
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93751 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-02-16 CC||ebotcazou at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #4 from Eric Botcazou --- > Well, why not fix it then? :) It should be a fairly low risk change, since > it does not remove any DIEs - I think it is quite unlikely that any user > depends on the *absence* of DIEs. And it aligns DWARF with stabs and other > formats, and with the manual. > > Do you see any problem with the proposed patch? Yes, it increases the size of the executable, which is generally a concern for people using -g1 over -g. I'd rather see the manual be fixed instead.
[Bug gcov-profile/93766] New: [GCOV] incorrect coverage when compiled with option '-fsanitize=undefined' for struct assignment statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93766
Bug ID: 93766
Summary: [GCOV] incorrect coverage when compiled with option
'-fsanitize=undefined' for struct assignment statement
Product: gcc
Version: 9.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: gcov-profile
Assignee: unassigned at gcc dot gnu.org
Reporter: yangyibiao at hust dot edu.cn
CC: marxin at gcc dot gnu.org
Target Milestone: ---
$ gcov -v
gcov (GCC) 9.2.0
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or
FITNESS FOR A PARTICULAR PURPOSE.
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib
--libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++,d --enable-shared
--enable-threads=posix --with-system-zlib --with-isl --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch
--disable-libssp --enable-gnu-unique-object --enable-linker-build-id
--enable-lto --enable-plugin --enable-install-libiberty
--with-linker-hash-style=gnu --enable-gnu-indirect-function --enable-multilib
--disable-werror --enable-checking=release --enable-default-pie
--enable-default-ssp --enable-cet=auto gdc_include_dir=/usr/include/dlang/gdc
Thread model: posix
gcc version 9.2.0 (GCC)
$ cat small.c
#include
typedef struct
{
int e;
} S;
inline __attribute__ ((always_inline)) void foo (S *y)
{
S c = *y;
}
void main (void)
{
S y;
memset (, 0, sizeof (y));
foo();
}
$ gcc -O0 --coverage -fsanitize=undefined small.c; ./a.out; gcov small.c; cat
small.c.gcov
File 'small.c'
Lines executed:100.00% of 5
Creating 'small.c.gcov'
-:0:Source:small.c
-:0:Graph:small.gcno
-:0:Data:small.gcda
-:0:Runs:1
-:1:#include
-:2:
-:3:typedef struct
-:4:{
-:5: int e;
-:6:} S;
-:7:
-:8:inline __attribute__ ((always_inline)) void foo (S *y)
-:9:{
2: 10: S c = *y;
1: 11:}
-: 12:
1: 13:void main (void)
-: 14:{
-: 15: S y;
1: 16: memset (, 0, sizeof (y));
-: 17: foo();
1: 18:}
We can find that Line #10 is wrongly marked as executed twice.
When compiling without "-fsanitize=undefined", the coverage will be correct.
[Bug bootstrap/93765] New: Bootstrap comparison failure; gcc/tree-vect-loop.o differs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93765 Bug ID: 93765 Summary: Bootstrap comparison failure; gcc/tree-vect-loop.o differs Product: gcc Version: 9.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: anton at mips dot complang.tuwien.ac.at Target Milestone: --- Host: powerpc64-unknown-linux-gnu Target: powerpc64-unknown-linux-gnu Build: powerpc64-unknown-linux-gnu The build log ends with: Comparing stages 2 and 3 Bootstrap comparison failure! gcc/tree-vect-loop.o differs The system is a Debian 6 system, in particular: gcc 4.4.5 (should not play a role for stages 2 and 3) glibc 2.11.3 binutils 2.20.1-system.20100303 contrib/download_prerequisites used for gmp, isl, mpc, mpfr
