MRFP 3.1.4 / gfortran 6.3 compiler bug?

A compiler crash has been observed on a system with MRFP v3.1.4 and gcc 6.3.0 (also reported on same system with gcc 9). The trace is

init2.c:52: MPFR assertion failed: p >= 2 && p <= ((mpfr_prec_t)((mpfr_uprec_t)(~(mpfr_uprec_t)0)>>1))
/home/nrm/codes/gs2/generated_src/dist_fn.f90:3167:0:

   subroutine timeadv (phi, apar, bpar, phinew, aparnew, bparnew, istep, mode)

internal compiler error: Aborted
0xa64edf crash_signal
    ../.././gcc/toplev.c:333
0x70d362 do_mpc_arg2(tree_node*, tree_node*, tree_node*, int, int (*)(__mpc_struct*, __mpc_struct const*, __mpc_struct const*, int))
    ../.././gcc/builtins.c:9698
0x82df7d const_binop
    ../.././gcc/fold-const.c:1305
0x82f176 const_binop(tree_code, tree_node*, tree_node*, tree_node*)
    ../.././gcc/fold-const.c:1554
0xcfd84e gimple_resimplify2(gimple**, code_helper*, tree_node*, tree_node**, tree_node* (*)(tree_node*))
    ../.././gcc/gimple-match-head.c:130
0xd526ba gimple_simplify(gimple*, code_helper*, tree_node**, gimple**, tree_node* (*)(tree_node*), tree_node* (*)(tree_node*))
    ../.././gcc/gimple-match-head.c:636
0x85fa43 gimple_fold_stmt_to_constant_1(gimple*, tree_node* (*)(tree_node*), tree_node* (*)(tree_node*))
    ../.././gcc/gimple-fold.c:4995
0xbd0cd4 record_temporary_equivalences_from_stmts_at_dest
    ../.././gcc/tree-ssa-threadedge.c:329
0xbd1881 thread_through_normal_block
    ../.././gcc/tree-ssa-threadedge.c:872
0xbd2cc0 thread_across_edge(gcond*, edge_def*, bool, const_and_copies*, avail_exprs_stack*, tree_node* (*)(gimple*, gimple*, avail_exprs_stack*))
    ../.././gcc/tree-ssa-threadedge.c:1005
0xc41ee4 identify_jump_threads
    ../.././gcc/tree-vrp.c:10220
0xc41ee4 vrp_finalize
    ../.././gcc/tree-vrp.c:10292
0xc41ee4 execute_vrp
    ../.././gcc/tree-vrp.c:10381
0xc41ee4 execute
    ../.././gcc/tree-vrp.c:10466

‌

The value ((mpfr_prec_t)((mpfr_uprec_t)(~(mpfr_uprec_t)0)>>1)) corresponds to the MRFP macro MRFP_PREC_MAX.

A workaround appears to be to add -fno-tree-ccp to the compiler flags. The bug is triggered when compiling dist_fn so it may be possible to limit the flag to this step.

Comments (1)