Thanks.  I'm working on capturing a self-contained reproducer.

This bug appears to have been reported against 'rawhide' during the Fedora 28 development cycle.
Changing version to '28'.

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?

(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:

void
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" ""))]
  "VECTOR_MEM_ALTIVEC_OR_VSX_P (<MODE>mode)"
{
  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]);
    }
  if (!BYTES_BIG_ENDIAN
      && 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);
      DONE;
    }
})

(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?

(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.

Reducing now.

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).

Does gcc-8.0.1-0.17 or later fix this for you?

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

When can we have this in F28?

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:
  https://koji.fedoraproject.org/koji/buildinfo?buildID=1057492

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

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).

please add gcc package to bodhi updates , FYI I already asked the same in bug #1554279

Proposed as a Freeze Exception for 28-beta by Fedora user sergiomb using the blocker tracking app because:

 gcc fixes

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/

gcc-8.0.1-0.19.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-4ed9ddeead

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

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.