On Linux/x86-64, r221769 caused: g++ -O3 -funroll-loops -ffast-math -fwhole-program -flto=jobserver -fuse-linker-plugin -DSPEC_CPU_LP64 auto_derivative_function.o block_sparse_matrix.o block_sparse_matrix_ez.o block_sparsity_pattern.o block_vector.o compressed_sparsity_pattern.o data_out.o data_out_base.o data_out_faces.o data_out_rotation.o data_out_stack.o derivative_approximation.o dof_accessor.o dof_constraints.o dof_handler.o dof_levels.o dof_renumbering.o dof_tools.o error_estimator.o exceptions.o fe.o fe_data.o fe_dgp.o fe_dgp_1d.o fe_dgp_2d.o fe_dgp_3d.o fe_dgp_nonparametric.o fe_dgq.o fe_dgq_1d.o fe_dgq_2d.o fe_dgq_3d.o fe_nedelec.o fe_nedelec_1d.o fe_nedelec_2d.o fe_nedelec_3d.o fe_q.o fe_q_1d.o fe_q_2d.o fe_q_3d.o fe_q_hierarchical.o fe_raviart_thomas.o fe_system.o fe_tools.o fe_values.o filtered_matrix.o full_matrix.double.o full_matrix.float.o function.o function_derivative.o function_lib.o function_lib_cutoff.o function_time.o geometry_info.o grid_generator.o grid_in.o grid_out.all_dimensions.o grid_out.o grid_refinement.o grid_reordering.o histogram.o intergrid_map.o job_identifier.o log.o mapping.o mapping_c1.o mapping_cartesian.o mapping_q.o mapping_q1.o mapping_q1_eulerian.o matrices.all_dimensions.o matrices.o matrix_lib.o matrix_out.o memory_consumption.o mg_base.o mg_dof_accessor.o mg_dof_handler.o mg_dof_tools.o mg_smoother.o mg_transfer_block.o mg_transfer_prebuilt.o mg_transfer_block.all_dimensions.o multigrid.all_dimensions.o multithread_info.o parameter_handler.o persistent_tria.o polynomial.o polynomial_space.o programid.o quadrature.o quadrature_lib.o solution_transfer.o solver_control.o sparse_matrix.double.o sparse_matrix.float.o sparse_matrix_ez.double.o sparse_matrix_ez.float.o sparsity_pattern.o step-14.o subscriptor.o swappable_vector.o tensor.o tensor_product_polynomials.o tria.all_dimensions.o tria.o tria_accessor.o tria_boundary.o tria_boundary_lib.o vector.o vector.long_double.o vectors.all_dimensions.o fe_dgp_monomial.o fe_poly.o polynomials_bdm.o polynomials_p.o vectors.o -o dealII lto1: internal compiler error: in inline_call, at ipa-inline-transform.c:386 Please submit a full bug report, with preprocessed source if appropriate. See <http://gcc.gnu.org/bugs.html> for instructions. lto-wrapper: fatal error: g++ returned 1 exit status compilation terminated. /usr/local/bin/ld: error: lto-wrapper failed collect2: error: ld returned 1 exit status specmake: *** [dealII] Error 1
I will take a look, too.
OK, it reproduces for me. The size difference is 2 Caller size is: Inline summary for set_laplace_on_hex_vector/158341 inlinable self time: 1602 global time: 1602 self size: 43 global size: 43 min size: 31 self stack: 8 global stack: 8 estimated growth:23 size:24.500000, time:1436.340500, predicate:(true) size:5.500000, time:146.532500, predicate:(not inlined) size:0.500000, time:0.500000, predicate:(op0[ref offset: 960] changed) && (not inlined) size:4.500000, time:4.500000, predicate:(op0[ref offset: 960] changed) size:0.500000, time:0.423500, predicate:(op0[ref offset: 1024] changed) && (not inlined) size:0.500000, time:0.423500, predicate:(op0[ref offset: 1024] changed) size:0.500000, time:0.423500, predicate:(op0[ref offset: 992] changed) && (not inlined) size:0.500000, time:0.423500, predicate:(op0[ref offset: 992] changed) calls: compute_laplace_vector/158368 --param large-stack-frame-growth limit reached loop depth: 0 freq: 110 size: 3 time: 12 callee size:120 stack:920 reinit/13143 --param max-inline-insns-auto limit reached loop depth: 0 freq: 616 size: 3 time: 12 callee size:29 stack: 0 op1 is compile time invariant While callee summary has a lot of calls Inline summary for compute_laplace_vector/158368 inlinable self time: 10734 global time: 8632 self size: 228 global size: 240 min size: 224 self stack: 912 global stack: 920 estimated growth:-16 size:156.500000, time:8055.395000, predicate:(true) size:12.500000, time:302.000000, predicate:(not inlined) size:0.500000, time:0.500000, predicate:(op0[ref offset: 960] changed) && (not inlined) size:1.500000, time:1.500000, predicate:(op0[ref offset: 960] changed) calls: ... My guess is that this actualy is an roundoff issue with updating. There is nothing interesting propagated and/or optimized out. This code will change early next stage with conversion to sreals, so I tend to believe we can drop the assert for this stage4
I am testing the following: Index: ipa-inline-transform.c =================================================================== --- ipa-inline-transform.c (revision 221859) +++ ipa-inline-transform.c (working copy) @@ -304,7 +304,8 @@ inline_call (struct cgraph_edge *e, bool struct cgraph_node *callee = e->callee->ultimate_alias_target (); bool new_edges_found = false; -#ifdef ENABLE_CHECKING + /* This is used only for assert bellow. */ +#if 0 int estimated_growth = estimate_edge_growth (e); bool predicated = inline_edge_summary (e)->predicate != NULL; #endif @@ -375,7 +376,10 @@ inline_call (struct cgraph_edge *e, bool to->calls_comdat_local = false; } -#ifdef ENABLE_CHECKING + /* FIXME: This assert suffers from roundoff errors, disable it for GCC 5 + and revisit it after conversion to sreals in GCC 6. + See PR 65654. */ +#if 0 /* Verify that estimated growth match real growth. Allow off-by-one error due to INLINE_SIZE_SCALE roudoff errors. */ gcc_assert (!update_overall_summary || !overall_size || new_edges_found
Retargetting to next stage1 for proper fix. No longer an GCC 5 regression.
Author: hubicka Date: Fri Apr 3 20:25:01 2015 New Revision: 221861 URL: https://gcc.gnu.org/viewcvs?rev=221861&root=gcc&view=rev Log: PR ipa/65648 * ipa-inline-transform.c (inline_call): Skip sanity check to work around the ICE Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-inline-transform.c
Hmm, I did not manage to get in the conversion to sreal this stage1 either. I may still try for stage3, but this is not very critical. Since this is just heuristic bookeeping bug and we do not ICE I would suggest not considering it as P1.
It was made P1 to make you fix it during stage1 of GCC 6 ;) But yes, re-targeting to GCC 7.
> It was made P1 to make you fix it during stage1 of GCC 6 ;) Yep, I even made patch in last P3 for turning to sreals, but then did not have time to pull it out. I will look it up - it needed some changes to gengtype because it fails on classes with certain operators. Those stages1 are too short... Honza
Here I also propose postpone again for GCC 8. I will try to give it priority next stage1 :(
Retaretting to GCC 8. I have verified that the inline metrics is mostly fine and those roundoff errors cumulating can not be easily fixed without migration to sreals which I will finally do early next stage1.
The inliner implementation has sufficiently changed so this sanity check makes no longer sense, thus closing this big as fixed :)