Bug 1546743 - gfortran internal compiler error when compiling cp2k-5.1 on ppc64le
Summary: gfortran internal compiler error when compiling cp2k-5.1 on ppc64le
Alias: None
Product: Fedora
Classification: Fedora
Component: gcc
Version: 28
Hardware: ppc64le
OS: Unspecified
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact: Fedora Extras Quality Assurance
URL: https://koji.fedoraproject.org/koji/t...
Whiteboard: AcceptedFreezeException
Depends On:
Blocks: PPCTracker F28BetaFreezeException 1555681
TreeView+ depends on / blocked
Reported: 2018-02-19 13:48 UTC by Dominik 'Rathann' Mierzejewski
Modified: 2018-03-26 22:30 UTC (History)
15 users (show)

Clone Of:
Last Closed: 2018-03-26 22:30:36 UTC

Attachments (Terms of Use)
Non-minimized reproducer (73.10 KB, text/plain)
2018-02-21 01:46 UTC, Dave Malcolm
no flags Details

External Trackers
Tracker ID Priority Status Summary Last Updated
GNU Compiler Collection 84499 None None None 2019-06-04 09:30 UTC

Description Dominik 'Rathann' Mierzejewski 2018-02-19 13:48:31 UTC
Description of problem:
gfortran fails to compile cp2k-5.1 with an internal compiler error.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Try building current rpms/cp2k master branch (0cabef25fb7780662279b24f72c0510f755e86d3)

Actual results:
gfortran -c -D__FFTW3 -D__LIBINT -D__LIBXC -D__HAS_IEEE_EXCEPTIONS -D__LIBINT_MAX_AM=11 -D__LIBDERIV_MAX_AM1=7 -D__MAX_CONTR=4 -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mcpu=power8 -mtune=power8 -fstack-clash-protection -fPIC -I/usr/lib64/gfortran/modules -ffree-form -ffree-line-length-none -D__COMPILE_ARCH="\"Linux-ppc64le-gfortran\"" -D__COMPILE_DATE="\"Mon Feb 19 12:17:07 UTC 2018\"" -D__COMPILE_HOST="\"buildvm-ppc64le-13.ppc.fedoraproject.org\"" -D__COMPILE_REVISION="\"svn:18091\"" -D__DATA_DIR="\"/usr/share/cp2k\"" -D__SHORT_FILE__="\"eri_mme/eri_mme_lattice_summation.F\"" -I'/builddir/build/BUILD/cp2k-5.1/src/eri_mme/' eri_mme_lattice_summation.F90 
*** WARNING *** there are active plugins, do not report this as a bug unless you can reproduce it without enabling any plugins.
Event                            | Plugins
PLUGIN_FINISH_UNIT               | annobin: Generate final annotations
PLUGIN_START_UNIT                | annobin: Generate global annotations
PLUGIN_ALL_PASSES_END            | annobin: Generate per-function annotations
during RTL pass: reload
    END SUBROUTINE pgf_sum_product_3c_gspace_3d
internal compiler error: in rs6000_emit_le_vsx_store, at config/rs6000/rs6000.c:10367
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://bugzilla.redhat.com/bugzilla> for instructions.
make[3]: *** [/builddir/build/BUILD/cp2k-5.1/makefiles/Makefile:427: eri_mme_lattice_summation.o] Error 1

Expected results:
Successful compilation.

Comment 1 Dave Malcolm 2018-02-19 15:33:47 UTC
Thanks.  I'm working on capturing a self-contained reproducer.

Comment 2 Fedora End Of Life 2018-02-20 15:39:24 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 28 development cycle.
Changing version to '28'.

Comment 3 Dave Malcolm 2018-02-21 01:46 UTC
Created attachment 1398473 [details]
Non-minimized reproducer

This ICEs when compiled with:
  gfortran -c -O1 -fstack-protector-strong -m64 -mcpu=power8 -mtune=power8 test.F90 -L../obj/Linux-ppc64le-gfortran/ssmp -I../obj/Linux-ppc64le-gfortran/ssmp

...but needs e.g. ao_util.mod etc in those -L/-I locations to compile.

Jakub/Marek: is there an easy way to "bake" all of the modules used in a Fortran source file into one self-contained reproducer?

Comment 4 Dave Malcolm 2018-02-21 01:47:46 UTC
(gdb) bt
#0  0x00000000107b5254 in fancy_abort (file=0x115f7ef8 "../../gcc/config/rs6000/rs6000.c", line=10361, 
    function=0x115f6da0 <rs6000_emit_le_vsx_store(rtx_def*, rtx_def*, machine_mode)::__FUNCTION__> "rs6000_emit_le_vsx_store")
    at ../../gcc/diagnostic.c:1499
#1  0x00000000113c0c7c in rs6000_emit_le_vsx_store (dest=<optimized out>, source=<optimized out>, mode=<optimized out>)
    at ../../gcc/config/rs6000/rs6000.c:10372
#2  0x00000000113ff0cc in gen_movv4si (operand0=0x7fffef107a88, operand1=<optimized out>) at ../../gcc/config/rs6000/vector.md:142
#3  0x0000000010a8b2a0 in insn_gen_fn::operator() (this=<optimized out>, a1=<optimized out>, a0=0xa78) at ../../gcc/recog.h:301
#4  emit_move_ccmode (y=<optimized out>, x=<optimized out>, mode=<optimized out>) at ../../gcc/expr.c:3540
#5  emit_move_insn_1 (y=<optimized out>, x=0x7fffef107a88) at ../../gcc/expr.c:3680
#6  emit_move_insn (x=0x7fffef107a88, y=<optimized out>) at ../../gcc/expr.c:3757
#7  0x0000000010c0e42c in lra_emit_move (x=0x7fffef107a88, y=0x7fffef132370) at ../../gcc/lra.c:497
#8  0x0000000010c1967c in curr_insn_transform (check_only_p=false) at ../../gcc/lra-constraints.c:4285
#9  0x0000000010c16fb8 in lra_constraints (first_p=<optimized out>) at ../../gcc/lra-constraints.c:4871
#10 0x0000000010bfe334 in lra (f=<optimized out>) at ../../gcc/lra.c:2416
#11 0x0000000010b821f8 in do_reload () at ../../gcc/ira.c:5465
#12 (anonymous namespace)::pass_reload::execute (this=<optimized out>) at ../../gcc/ira.c:5649
#13 0x0000000010c582f0 in execute_one_pass (pass=0x11bf7450) at ../../gcc/passes.c:2497
#14 0x0000000010c5bb00 in execute_pass_list_1 (pass=0x11bf7450) at ../../gcc/passes.c:2586
#15 execute_pass_list_1 (pass=0x11bf6310) at ../../gcc/passes.c:2587
#16 execute_pass_list (fn=0x7fffee470420, pass=<optimized out>) at ../../gcc/passes.c:2597
#17 0x00000000112f5eec in cgraph_node::expand (this=0x7fffee4908a0) at ../../gcc/context.h:48
#18 expand_all_functions () at ../../gcc/cgraphunit.c:2275
#19 symbol_table::compile (this=0x7fffee2a0000) at ../../gcc/cgraphunit.c:2624
#20 0x000000001099fb10 in symbol_table::finalize_compilation_unit (this=0x7fffee2a0000) at ../../gcc/cgraphunit.c:2717
#21 0x00000000113746f4 in compile_file () at ../../gcc/toplev.c:481
#22 0x00000000107f6178 in do_compile () at ../../gcc/toplev.c:2133
#23 toplev::main (this=0x7fffffffe9d6, argc=<optimized out>, argv=<optimized out>) at ../../gcc/toplev.c:2268
#24 0x00000000107f81c4 in main (argc=<optimized out>, argv=0x7fffffffedf8) at ../../gcc/main.c:39

It's hitting this assertion:

rs6000_emit_le_vsx_store (rtx dest, rtx source, machine_mode mode)
  /* This should never be called during or after LRA, because it does
     not re-permute the source register.  It is intended only for use
     during expand.  */
  gcc_assert (!lra_in_progress && !reload_completed);

called from here in vector.md line 142:

;; Vector move instructions.  Little-endian VSX loads and stores require
;; special handling to circumvent "element endianness."
(define_expand "mov<mode>"
  [(set (match_operand:VEC_M 0 "nonimmediate_operand" "")
	(match_operand:VEC_M 1 "any_operand" ""))]
  if (can_create_pseudo_p ())
      if (CONSTANT_P (operands[1]))
	  if (FLOAT128_VECTOR_P (<MODE>mode))
	      if (!easy_fp_constant (operands[1], <MODE>mode))
		operands[1] = force_const_mem (<MODE>mode, operands[1]);
	  else if (!easy_vector_constant (operands[1], <MODE>mode))
	    operands[1] = force_const_mem (<MODE>mode, operands[1]);

      if (!vlogical_operand (operands[0], <MODE>mode)
	  && !vlogical_operand (operands[1], <MODE>mode))
	operands[1] = force_reg (<MODE>mode, operands[1]);
      && VECTOR_MEM_VSX_P (<MODE>mode)
      && !TARGET_P9_VECTOR
      && !gpr_or_gpr_p (operands[0], operands[1])
      && (memory_operand (operands[0], <MODE>mode)
          ^ memory_operand (operands[1], <MODE>mode)))
      rs6000_emit_le_vsx_move (operands[0], operands[1], <MODE>mode);

Comment 5 Dave Malcolm 2018-02-21 01:48:44 UTC
(In reply to Dave Malcolm from comment #3)
> Jakub/Marek: is there an easy way to "bake" all of the modules used in a
> Fortran source file into one self-contained reproducer?

Comment 6 Jakub Jelinek 2018-02-21 07:25:46 UTC
(In reply to Dave Malcolm from comment #5)
> (In reply to Dave Malcolm from comment #3)
> > Jakub/Marek: is there an easy way to "bake" all of the modules used in a
> > Fortran source file into one self-contained reproducer?

No.  Which is why I'm quite afraid of C++ modules too.

Comment 7 Jakub Jelinek 2018-02-21 11:23:45 UTC
Reducing now.

Comment 8 Dave Malcolm 2018-03-09 14:36:14 UTC
Upstream bug was fixed in r258251 on 2018-03-05; that fix is not yet in our rpms (which I believe are currently are using the 2018-02-22 tarball).

Comment 9 Dave Malcolm 2018-03-14 22:17:28 UTC
Does gcc-8.0.1-0.17 or later fix this for you?

Comment 10 Dominik 'Rathann' Mierzejewski 2018-03-15 12:51:13 UTC
Scratch build [1] with gcc-8.0.1-0.18.fc29 succeeded, thank you very much!

[1] https://koji.fedoraproject.org/koji/taskinfo?taskID=25721063

Comment 11 Dominik 'Rathann' Mierzejewski 2018-03-16 11:41:53 UTC
When can we have this in F28?

Comment 12 Dave Malcolm 2018-03-16 12:24:40 UTC
gcc-8.0.1-0.18.fc28 (or indeed -0.17) ought to fix this, and it's been built in Koji for Fedora 28:

I don't know what the status of this being in the Fedora 28 build root is (and the procedure for doing so).

Comment 13 Dominik 'Rathann' Mierzejewski 2018-03-16 13:48:29 UTC
I've requested a buildroot override for now: https://bodhi.fedoraproject.org/overrides/gcc-8.0.1-0.18.fc28 , but to get it into the buildroot permanently during the current beta freeze, you have to submit it as an update and nominate for freeze exception: https://qa.fedoraproject.org/blockerbugs/propose_bug (https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process).

Comment 14 Sergio Monteiro Basto 2018-03-21 00:09:38 UTC
please add gcc package to bodhi updates , FYI I already asked the same in bug #1554279

Comment 15 Fedora Blocker Bugs Application 2018-03-21 00:23:05 UTC
Proposed as a Freeze Exception for 28-beta by Fedora user sergiomb using the blocker tracking app because:

 gcc fixes

Comment 16 František Zatloukal 2018-03-22 18:47:49 UTC
Discussed during blocker review [1]:

AcceptedFreezeException (Beta) - accepted on the same principle as the annobin bug (1557511) - buildroot/compose consistency

[1] https://meetbot-raw.fedoraproject.org/fedora-meeting-1/2018-03-22/

Comment 17 Fedora Update System 2018-03-22 18:53:23 UTC
gcc-8.0.1-0.19.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-4ed9ddeead

Comment 18 Fedora Update System 2018-03-23 14:44:10 UTC
gcc-8.0.1-0.19.fc28 has been pushed to the Fedora 28 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-4ed9ddeead

Comment 19 Fedora Update System 2018-03-26 22:30:36 UTC
gcc-8.0.1-0.19.fc28 has been pushed to the Fedora 28 stable repository. If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.