Is the insn you're dying with contain FP operands?  I know the backend for 64-bit PowerPC assumes/requires 64-bit FP hardware is available and since you're using -msoft-float, I can imagine that you're running afoul of that somehow.

FYI, I tried logging into gcc67 but couldn't for some reason.  I have no problems logging into other gcc farm systems.

(In reply to Peter Bergner from comment #1)
> Is the insn you're dying with contain FP operands?  I know the backend for
> 64-bit PowerPC assumes/requires 64-bit FP hardware is available and since
> you're using -msoft-float, I can imagine that you're running afoul of that
> somehow.

Is -msoft-float supported on 64-bit PowerPC? It is not important for us. I just copied the 32-bit multilibs without much thought.

> 
> FYI, I tried logging into gcc67 but couldn't for some reason.  I have no
> problems logging into other gcc farm systems.

My SSH config for gcc67 is:

Compression yes
Host gcc67
  User sh
  Hostname gcc67.fsffrance.org

(In reply to Sebastian Huber from comment #2)
> Is -msoft-float supported on 64-bit PowerPC? It is not important for us. I
> just copied the 32-bit multilibs without much thought.

It is used by the linux kernel, but they also explicitly do not use float/double types.  If you have float/double types in your source code and compile for 64-bit using -msoft-float, I could guess that you would run into some of the assumptions in the 64-bit backend that floating point hardware is always available.  It's just a guess though, without knowing what the insn / operand you're having problems with looks like.

(In reply to Peter Bergner from comment #3)
> (In reply to Sebastian Huber from comment #2)
> > Is -msoft-float supported on 64-bit PowerPC? It is not important for us. I
> > just copied the 32-bit multilibs without much thought.
> 
> It is used by the linux kernel, but they also explicitly do not use
> float/double types.  If you have float/double types in your source code and
> compile for 64-bit using -msoft-float, I could guess that you would run into
> some of the assumptions in the 64-bit backend that floating point hardware
> is always available.  It's just a guess though, without knowing what the
> insn / operand you're having problems with looks like.

If I remove the -msoft-float, the two example source files compile (-mno-altivec seems to cause no harm).

How can I dump the instruction? I don't know Ada well enough to figure it out from the source code.

(In reply to Sebastian Huber from comment #4)
> If I remove the -msoft-float, the two example source files compile
> (-mno-altivec seems to cause no harm).

Well the first question, is do you really need to use -msoft-float?  Looking at the E6500 hardware doc seems to show that it has both hardware FP and Altivec units.


> How can I dump the instruction? I don't know Ada well enough to figure it
> out from the source code.

I don't know Ada as well, but I mean what does the RTL insn look like?  You'll probably  need a debug build of your gcc for that so it isn't optimized away and then you can print it from gdb.

(In reply to Peter Bergner from comment #5)
> (In reply to Sebastian Huber from comment #4)
> > If I remove the -msoft-float, the two example source files compile
> > (-mno-altivec seems to cause no harm).
> 
> Well the first question, is do you really need to use -msoft-float?  Looking
> at the E6500 hardware doc seems to show that it has both hardware FP and
> Altivec units.

For some applications fast context switches are important and the FP/AltiVec context is quite huge. It affects also the interrupt latency. I have to discuss this with the application developers. We probably don't need it in a 64-bit configuration.

> 
> 
> > How can I dump the instruction? I don't know Ada well enough to figure it
> > out from the source code.
> 
> I don't know Ada as well, but I mean what does the RTL insn look like? 
> You'll probably  need a debug build of your gcc for that so it isn't
> optimized away and then you can print it from gdb.

Ok, I will try to do this. I am not sure how it works with the cross compiler build:

https://gcc.gnu.org/wiki/DebuggingGCC#gccbuilddebug

It seems to be a general problem with -msoft-float on PowerPC64. I built a native GCC on gcc112:

[sh@gcc2-power8 ~]$ cd /home/sh/b-gcc-git/gcc/ada/rts
[sh@gcc2-power8 rts]$ gdb --args /home/sh/b-gcc-git/gcc/gnat1 -gnatwa -quiet -nostdinc -nostdinc -dumpbase a-coteio.ads -auxbase-strip a-coteio.o -O2 -Wextra -Wall -g -gnatpg -msoft-float -gnatO a-coteio.o a-coteio.ads -o -
GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-100.el7
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "ppc64le-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Warning: /home/sh/gcc-7-20161030/gcc: No such file or directory.
Warning: /home/sh/gcc-7-20161030/gcc/ada: No such file or directory.
Warning: /home/sh/gcc-7-20161030/gcc/c: No such file or directory.
Warning: /home/sh/gcc-7-20161030/gcc/cp: No such file or directory.
Warning: /home/sh/gcc-7-20161030/gcc/fortran: No such file or directory.
Warning: /home/sh/gcc-7-20161030/gcc/go: No such file or directory.
Warning: /home/sh/gcc-7-20161030/gcc/jit: No such file or directory.
Warning: /home/sh/gcc-7-20161030/gcc/lto: No such file or directory.
Warning: /home/sh/gcc-7-20161030/gcc/objc: No such file or directory.
Warning: /home/sh/gcc-7-20161030/gcc/objcp: No such file or directory.
Traceback (most recent call last):
  File "<string>", line 1, in <module>
ImportError: No module named gdbhooks
/home/sh/.gdbinit:13: Error in sourced command file:
Error while executing Python code.
Reading symbols from /home/sh/b-gcc-git/gcc/gnat1...done.
(gdb) r
Starting program: /home/sh/b-gcc-git/gcc/gnat1 -gnatwa -quiet -nostdinc -nostdinc -dumpbase a-coteio.ads -auxbase-strip a-coteio.o -O2 -Wextra -Wall -g -gnatpg -msoft-float -gnatO a-coteio.o a-coteio.ads -o -
        .file   "a-coteio.ads"
        .machine power7
        .abiversion 2
        .section        ".text"
.Ltext0:
        .globl __truncdfsf2
^C
Program received signal SIGINT, Interrupt.
0x00000000108158a0 in bitmap_and_compl_into (a=0x12c7a0b0, b=<optimized out>) at /home/sh/gcc-git/gcc/bitmap.c:1181
1181      gcc_checking_assert (!a->current == !a->first
Missing separate debuginfos, use: debuginfo-install glibc-2.17-196.el7.ppc64le
(gdb) bt
#0  0x00000000108158a0 in bitmap_and_compl_into (a=0x12c7a0b0, b=<optimized out>) at /home/sh/gcc-git/gcc/bitmap.c:1181
#1  0x0000000010c83208 in spill_pseudos () at /home/sh/gcc-git/gcc/bitmap.h:806
#2  lra_spill () at /home/sh/gcc-git/gcc/lra-spills.c:595
#3  0x0000000010c56998 in lra (f=<optimized out>) at /home/sh/gcc-git/gcc/lra.c:2514
#4  0x0000000010bf216c in do_reload () at /home/sh/gcc-git/gcc/ira.c:5443
#5  (anonymous namespace)::pass_reload::execute (this=<optimized out>) at /home/sh/gcc-git/gcc/ira.c:5627
#6  0x0000000010d36f20 in execute_one_pass (pass=0x12a04650) at /home/sh/gcc-git/gcc/passes.c:2497
#7  0x0000000010d38114 in execute_pass_list_1 (pass=0x12a04650) at /home/sh/gcc-git/gcc/passes.c:2586
#8  0x0000000010d3812c in execute_pass_list_1 (pass=0x12a03570) at /home/sh/gcc-git/gcc/passes.c:2587
#9  0x0000000010d381b8 in execute_pass_list (fn=<optimized out>, pass=<optimized out>) at /home/sh/gcc-git/gcc/passes.c:2597
#10 0x00000000108cb178 in cgraph_node::expand (this=0x3fffaf680000) at /home/sh/gcc-git/gcc/context.h:48
#11 0x00000000108ccf44 in expand_all_functions () at /home/sh/gcc-git/gcc/cgraphunit.c:2275
#12 symbol_table::compile (this=0x3fffaf420000) at /home/sh/gcc-git/gcc/cgraphunit.c:2623
#13 0x00000000108d084c in compile (this=0x3fffaf420000) at /home/sh/gcc-git/gcc/cgraphunit.c:2716
#14 symbol_table::finalize_compilation_unit (this=0x3fffaf420000) at /home/sh/gcc-git/gcc/cgraphunit.c:2716
#15 0x0000000010e564b4 in compile_file () at /home/sh/gcc-git/gcc/toplev.c:480
#16 0x0000000010277938 in do_compile () at /home/sh/gcc-git/gcc/toplev.c:2063
#17 toplev::main (this=0x3fffffffef50, argc=<optimized out>, argv=<optimized out>) at /home/sh/gcc-git/gcc/toplev.c:2198
#18 0x00000000102798a8 in main (argc=<optimized out>, argv=0x3ffffffff378) at /home/sh/gcc-git/gcc/main.c:39

Building a debug ada compiler, I see the same thing.  This does look like you're hitting an assumption that 64-bit compiles assume they have hw FP.  If I add -fdump-rtl-expand-all to the compile command and then look at the generated dump file, I see:

;; Generating RTL for gimple basic block 2

;; P.0 = ada.text_io.complex_aux.get (file_2(D), width_3(D));

(insn 7 6 8 (set (reg:DI 4 4)
        (reg/v:DI 134 [ widthD.3010 ])) "a-ticoio.adb":58 -1
     (nil))

(insn 8 7 9 (set (reg:DI 3 3)
        (reg/v/f:DI 133 [ fileD.3006 ])) "a-ticoio.adb":58 -1
     (nil))

(call_insn 9 8 10 (parallel [
            (set (parallel:TI [
                        (expr_list:REG_DEP_TRUE (reg:DF 33 1)
                            (const_int 0 [0]))
                        (expr_list:REG_DEP_TRUE (reg:DF 34 2)
                            (const_int 8 [0x8]))
                    ])
                (call (mem:SI (symbol_ref:DI ("ada__text_io__complex_aux__get") [flags 0x41] <function_decl 0x3fff8dcbbe00 ada__text_io__complex_aux__get>) [0 ada__text_io__complex_aux__getD.3060 S4 A8])
                    (const_int 0 [0])))
            (clobber (reg:DI 65 lr))
        ]) "a-ticoio.adb":58 -1
     (expr_list:REG_EH_REGION (const_int 2 [0x2])
        (expr_list:REG_CALL_DECL (symbol_ref:DI ("ada__text_io__complex_aux__get") [flags 0x41] <function_decl 0x3fff8dcbbe00 ada__text_io__complex_aux__get>)
            (nil)))
    (expr_list (use (reg:DI 2 2))
        (expr_list:DI (use (reg:DI 3 3))
            (expr_list:SI (use (reg:DI 4 4))
                (nil)))))

(insn 10 9 11 (set (reg:DF 135)
        (reg:DF 33 1)) "a-ticoio.adb":58 -1
     (nil))

(insn 11 10 12 (set (reg:DF 136)
        (reg:DF 34 2)) "a-ticoio.adb":58 -1
     (nil))

This shows we pass in the FP arguments in integer registers (regs 3 and 4) that we'd expect with -msoft-float, but the return values and the call pattern itself make mention of FP regs f1 and f2 (ie, regs 33 and 34), which it shouldn't when we've disabled hw FP.  Then LRA has no way to spill those, since FP regs don't exist with -msoft-float, so it loops forever.

...and the parallel with the  FP reg use (33 and 34) come from:

expand_call():
  valreg = hard_function_value (build_pointer_type (rettype),
                                fndecl, NULL, (pass == 0));

  hard_function_value():
    val = targetm.calls.function_value (valtype, func ? func : fntype, outgoing);

    rs6000_function_value():
      
  /* The ELFv2 ABI returns homogeneous VFP aggregates in registers.  */
  if (rs6000_discover_homogeneous_aggregate (mode, valtype, &elt_mode, &n_elts))
    {
      int first_reg, n_regs;

      if (SCALAR_FLOAT_MODE_NOT_VECTOR_P (elt_mode))
        {
          /* _Decimal128 must use even/odd register pairs.  */
          first_reg = (elt_mode == TDmode) ? FP_ARG_RETURN + 1 : FP_ARG_RETURN;
          n_regs = (GET_MODE_SIZE (elt_mode) + 7) >> 3;
        }
      else
        {
          first_reg = ALTIVEC_ARG_RETURN;
          n_regs = 1;
        }

      return rs6000_parallel_return (mode, n_elts, elt_mode, first_reg, n_regs);
    }

Here, you can see that on ELFv2, we always assume HW FP regs are avialable, because we're forcing usage of HW FP registers (FP_ARG_RETURN, ie, f1, aka reg 33).  I'm afraid that are going to be a *LOT* of these assumptions builtin into the backend and tracking them all down and fixing them is not going to be easy.  That's why I asked earlier, if you really really need to disable HW FP for your builds.  If you do, then good luck to you finding them all.

Author: sh
Date: Tue Dec 19 08:16:34 2017
New Revision: 255809

URL: https://gcc.gnu.org/viewcvs?rev=255809&root=gcc&view=rev
Log:
RTEMS/PowerPC: Remove 64-bit soft-float multilib

gcc/
	PR target/83387
	* config/rs6000/t-rtems (MULTILIB_REQUIRED): Remove 64-bit soft-float
	multilib.


Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/config/rs6000/t-rtems

Author: sh
Date: Tue Dec 19 08:20:05 2017
New Revision: 255810

URL: https://gcc.gnu.org/viewcvs?rev=255810&root=gcc&view=rev
Log:
RTEMS/PowerPC: Remove 64-bit soft-float multilib

gcc/
	PR target/83387
	* config/rs6000/t-rtems (MULTILIB_REQUIRED): Remove 64-bit soft-float
	multilib.

Modified:
    branches/gcc-7-branch/gcc/ChangeLog
    branches/gcc-7-branch/gcc/config/rs6000/t-rtems

(In reply to Peter Bergner from comment #9)
[...]
> Here, you can see that on ELFv2, we always assume HW FP regs are avialable,
> because we're forcing usage of HW FP registers (FP_ARG_RETURN, ie, f1, aka
> reg 33).  I'm afraid that are going to be a *LOT* of these assumptions
> builtin into the backend and tracking them all down and fixing them is not
> going to be easy.  That's why I asked earlier, if you really really need to
> disable HW FP for your builds.  If you do, then good luck to you finding
> them all.

Thanks for your investigations. I removed the 64-bit soft-float multilib.

Would it be possible to generate a proper ICE with a user friendly error message if someone uses -msoft-float on this target?

(In reply to Sebastian Huber from comment #12)
> (In reply to Peter Bergner from comment #9)
> [...]
> > Here, you can see that on ELFv2, we always assume HW FP regs are avialable,
> > because we're forcing usage of HW FP registers (FP_ARG_RETURN, ie, f1, aka
> > reg 33).  I'm afraid that are going to be a *LOT* of these assumptions
> > builtin into the backend and tracking them all down and fixing them is not
> > going to be easy.  That's why I asked earlier, if you really really need to
> > disable HW FP for your builds.  If you do, then good luck to you finding
> > them all.
> 
> Thanks for your investigations. I removed the 64-bit soft-float multilib.

I can't promise this is all you need, but does the following patch help?

Index: gcc/config/rs6000/rs6000.c
===================================================================
--- gcc/config/rs6000/rs6000.c	(revision 255700)
+++ gcc/config/rs6000/rs6000.c	(working copy)
@@ -11095,7 +11095,8 @@ rs6000_discover_homogeneous_aggregate (m
      homogeneous aggregates; these types are handled via the
      targetm.calls.split_complex_arg mechanism.  Complex types
      can be elements of homogeneous aggregates, however.  */
-  if (DEFAULT_ABI == ABI_ELFv2 && type && AGGREGATE_TYPE_P (type))
+  if (TARGET_HARD_FLOAT && DEFAULT_ABI == ABI_ELFv2 && type
+      && AGGREGATE_TYPE_P (type))
     {
       machine_mode field_mode = VOIDmode;
       int field_count = rs6000_aggregate_candidate (type, &field_mode);



> Would it be possible to generate a proper ICE with a user friendly error
> message if someone uses -msoft-float on this target?

We cannot, because we support building the 64-bit linux kernel (both ELFv1 and ELFv2 - ie, BE and LE) using -msoft-float.  The reason they don't see a problem is that the linux kernel doesn't have any explicit FP code/type usage in its C source files.

(In reply to Peter Bergner from comment #13)
> (In reply to Sebastian Huber from comment #12)
> > (In reply to Peter Bergner from comment #9)
> > [...]
> > > Here, you can see that on ELFv2, we always assume HW FP regs are avialable,
> > > because we're forcing usage of HW FP registers (FP_ARG_RETURN, ie, f1, aka
> > > reg 33).  I'm afraid that are going to be a *LOT* of these assumptions
> > > builtin into the backend and tracking them all down and fixing them is not
> > > going to be easy.  That's why I asked earlier, if you really really need to
> > > disable HW FP for your builds.  If you do, then good luck to you finding
> > > them all.
> > 
> > Thanks for your investigations. I removed the 64-bit soft-float multilib.
> 
> I can't promise this is all you need, but does the following patch help?
> 
> Index: gcc/config/rs6000/rs6000.c
> ===================================================================
> --- gcc/config/rs6000/rs6000.c	(revision 255700)
> +++ gcc/config/rs6000/rs6000.c	(working copy)
> @@ -11095,7 +11095,8 @@ rs6000_discover_homogeneous_aggregate (m
>       homogeneous aggregates; these types are handled via the
>       targetm.calls.split_complex_arg mechanism.  Complex types
>       can be elements of homogeneous aggregates, however.  */
> -  if (DEFAULT_ABI == ABI_ELFv2 && type && AGGREGATE_TYPE_P (type))
> +  if (TARGET_HARD_FLOAT && DEFAULT_ABI == ABI_ELFv2 && type
> +      && AGGREGATE_TYPE_P (type))
>      {
>        machine_mode field_mode = VOIDmode;
>        int field_count = rs6000_aggregate_candidate (type, &field_mode);
> 
> 
> 

With this patch I can build an Ada compiler with a -m64 and -msoft-float multilib.

(In reply to Sebastian Huber from comment #14)
> (In reply to Peter Bergner from comment #13)
> > (In reply to Sebastian Huber from comment #12)
> > > (In reply to Peter Bergner from comment #9)
> > > [...]
> > > > Here, you can see that on ELFv2, we always assume HW FP regs are avialable,
> > > > because we're forcing usage of HW FP registers (FP_ARG_RETURN, ie, f1, aka
> > > > reg 33).  I'm afraid that are going to be a *LOT* of these assumptions
> > > > builtin into the backend and tracking them all down and fixing them is not
> > > > going to be easy.  That's why I asked earlier, if you really really need to
> > > > disable HW FP for your builds.  If you do, then good luck to you finding
> > > > them all.
> > > 
> > > Thanks for your investigations. I removed the 64-bit soft-float multilib.
> > 
> > I can't promise this is all you need, but does the following patch help?
> > 
> > Index: gcc/config/rs6000/rs6000.c
> > ===================================================================
> > --- gcc/config/rs6000/rs6000.c	(revision 255700)
> > +++ gcc/config/rs6000/rs6000.c	(working copy)
> > @@ -11095,7 +11095,8 @@ rs6000_discover_homogeneous_aggregate (m
> >       homogeneous aggregates; these types are handled via the
> >       targetm.calls.split_complex_arg mechanism.  Complex types
> >       can be elements of homogeneous aggregates, however.  */
> > -  if (DEFAULT_ABI == ABI_ELFv2 && type && AGGREGATE_TYPE_P (type))
> > +  if (TARGET_HARD_FLOAT && DEFAULT_ABI == ABI_ELFv2 && type
> > +      && AGGREGATE_TYPE_P (type))
> >      {
> >        machine_mode field_mode = VOIDmode;
> >        int field_count = rs6000_aggregate_candidate (type, &field_mode);
> > 
> > 
> > 
> 
> With this patch I can build an Ada compiler with a -m64 and -msoft-float
> multilib.

How do we want to continue with this PR? Close it as WONTFIX or apply the patch and close it as FIXED?

> > > --- gcc/config/rs6000/rs6000.c	(revision 255700)
> > > +++ gcc/config/rs6000/rs6000.c	(working copy)
> > > @@ -11095,7 +11095,8 @@ rs6000_discover_homogeneous_aggregate (m
> > >       homogeneous aggregates; these types are handled via the
> > >       targetm.calls.split_complex_arg mechanism.  Complex types
> > >       can be elements of homogeneous aggregates, however.  */
> > > -  if (DEFAULT_ABI == ABI_ELFv2 && type && AGGREGATE_TYPE_P (type))
> > > +  if (TARGET_HARD_FLOAT && DEFAULT_ABI == ABI_ELFv2 && type
> > > +      && AGGREGATE_TYPE_P (type))
> > >      {
> > >        machine_mode field_mode = VOIDmode;
> > >        int field_count = rs6000_aggregate_candidate (type, &field_mode);
> > > 
> > > 
> > > 
> > 
> > With this patch I can build an Ada compiler with a -m64 and -msoft-float
> > multilib.
> 
> How do we want to continue with this PR? Close it as WONTFIX or apply the
> patch and close it as FIXED?

If it works, and doesn't regress anything, it is pre-approved.  So please
test it on powerp64le-linux (gcc112 for example).

(In reply to Segher Boessenkool from comment #16)
>> How do we want to continue with this PR? Close it as WONTFIX or apply the
>> patch and close it as FIXED?
> 
> If it works, and doesn't regress anything, it is pre-approved.  So please
> test it on powerp64le-linux (gcc112 for example).

Sorry, I'm just getting back up to speed after the long holiday.  I can kick off a regression test and then commit when it comes back clean.  Thanks.

Author: bergner
Date: Thu Jan  4 14:36:35 2018
New Revision: 256250

URL: https://gcc.gnu.org/viewcvs?rev=256250&root=gcc&view=rev
Log:
	PR target/83387
	* config/rs6000/rs6000.c (rs6000_discover_homogeneous_aggregate): Do not
	allow arguments in FP registers if TARGET_HARD_FLOAT is false.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/config/rs6000/rs6000.c

Patch committed.

Closing as fixed.