[Bug target/58139] New: PowerPC volatile VSX register live across call

[Bug target/58139] New: PowerPC volatile VSX register live across call

[dje at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58139

            Bug ID: 58139
           Summary: PowerPC volatile VSX register live across call
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: dje at gcc dot gnu.org

void tightness3_intrinsics2(double* A, double* B, int N) {
 __vector double * vA = (__vector double*)A;
 __vector double * vB = (__vector double*)B;
 __vector double va0, va1;
 double b0, b1, b2, b3;
 va0 = vA[0];
 va1 = vA[1];
 b0 = log(vec_extract(va0, 0));
 b1 = log(vec_extract(va0, 1));
 b2 = log(vec_extract(va1, 0));
 b3 = log(vec_extract(va1, 1));
 __vector double vb0 = {b0, b1};
 __vector double vb1 = {b2, b3};
 vB[0] = vb0;
 vB[1] = vb1;
}

         xxpermdi 1,63,63,2
         xxpermdi 30,30,29,0
         bl log
         nop
         addi 1,1,192
         li 0,-80
         stxvd2x 30,0,30

GCC should not expect VSX 30 to be preserved across the call to log().

[Bug target/58139] PowerPC volatile VSX register live across call

[dje at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58139

David Edelsohn <dje at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|                            |powerpc*-*-*
             Status|UNCONFIRMED                 |NEW
           Keywords|                            |wrong-code
   Last reconfirmed|                            |2013-08-12
                 CC|                            |bergner at gcc dot gnu.org
               Host|                            |powerpc*-*-*
     Ever confirmed|0                           |1
      Known to fail|                            |4.6.3, 4.7.3, 4.8.1
              Build|                            |powerpc*-*-*

--- Comment #1 from David Edelsohn <dje at gcc dot gnu.org> ---
Confirmed.

[Bug target/58139] PowerPC volatile VSX register live across call

[bergner at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58139

--- Comment #2 from Peter Bergner <bergner at gcc dot gnu.org> ---
This looks like a scheduling bug.  Just before sched2, we have:

(call_insn 29 28 31 2 (parallel [
            (set (reg:DF 33 1)
                (call (mem:SI (symbol_ref:DI ("log") [flags 0x41] 
<function_decl 0xfff92c41200 log>) [0 __builtin_log S4 A8])
                    (const_int 64 [0x40])))
            (use (const_int 0 [0]))
            (clobber (reg:SI 65 lr))
        ]) bug.c:17 509 {*call_value_nonlocal_aix64}
     (expr_list:REG_EH_REGION (const_int 0 [0])
        (nil))
    (expr_list:REG_NON_LOCAL_GOTO (use (reg:DF 33 1))
        (nil)))
(insn 31 29 34 2 (set (reg:V2DF 62 30 [orig:140 vb0 ] [140])
        (unspec:V2DF [
                (reg/v:DF 62 30 [orig:123 b0 ] [123])
                (reg/v:DF 61 29 [orig:125 b1 ] [125])
            ] UNSPEC_VSX_CONCAT)) bug.c:18 920 {vsx_concat_v2df}
     (expr_list:REG_DEAD (reg/v:DF 61 29 [orig:125 b1 ] [125])
        (expr_list:REG_EQUIV (mem:V2DF (reg/v/f:DI 30 30 [orig:133 B ] [133])
[2 MEM[(__vector double *)B_2(D)]+0 S16 A128])
            (nil))))

Here, insn 31 sets VSX reg 62 (ie, fpr30,vsr30).  In DFmode, reg 62 is a
non-volatile register, but in V2DFmode, it is volatile.  After sched2, we have:

insn:TI 31 28 29 2 (set (reg:V2DF 62 30 [orig:140 vb0 ] [140])
        (unspec:V2DF [
                (reg/v:DF 62 30 [orig:123 b0 ] [123])
                (reg/v:DF 61 29 [orig:125 b1 ] [125])
            ] UNSPEC_VSX_CONCAT)) bug.c:18 920 {vsx_concat_v2df}
     (expr_list:REG_DEAD (reg/v:DF 61 29 [orig:125 b1 ] [125])
        (expr_list:REG_EQUIV (mem:V2DF (reg/v/f:DI 30 30 [orig:133 B ] [133])
[2 MEM[(__vector double *)B_2(D)]+0 S16 A128])
            (nil))))
(call_insn 29 31 72 2 (parallel [
            (set (reg:DF 33 1)
                (call (mem:SI (symbol_ref:DI ("log") [flags 0x41] 
<function_decl 0xfff92c41200 log>) [0 __builtin_log S4 A8])
                    (const_int 64 [0x40])))
            (use (const_int 0 [0]))
            (clobber (reg:SI 65 lr))
        ]) bug.c:17 509 {*call_value_nonlocal_aix64}
     (expr_list:REG_EH_REGION (const_int 0 [0])
        (nil))
    (expr_list:REG_NON_LOCAL_GOTO (use (reg:DF 33 1))
        (nil)))

So it looks like the scheduler is somehow thinking that reg 62 is non-volatile
when it's really volatile in V2DFmode and moving it before the call which ends
up clobbering it.

Still digging.

[Bug target/58139] PowerPC volatile VSX register live across call

[bergner at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58139

Peter Bergner <bergner at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED

--- Comment #3 from Peter Bergner <bergner at gcc dot gnu.org> ---
The problem is that hardreg 62 (aka FPR30/VSR30) is not set in
CALL_USED_REGISTERS[] because the ABI states it is non-volatile.  But it is
only non-volatile in S[DF]mode and D[DF]mode modes.  It is volatile in V2DFmode
or any other mode where that uses doubleword 1 of the VSR.

Since hardreg 62 is not mentioned in CALL_USED_REGISTERS, df does not detect
the dependency between the xxpermdi setting hardreg 62 and the log() call that
clobbers half of it.  With no dependency between the insns, sched2 goes ahead
and moves the xxpermdi above the call.

[Bug target/58139] PowerPC volatile VSX register live across call

[bergner at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58139

--- Comment #4 from Peter Bergner <bergner at gcc dot gnu.org> ---
Author: bergner
Date: Thu Sep  5 14:09:07 2013
New Revision: 202286

URL: http://gcc.gnu.org/viewcvs?rev=202286&root=gcc&view=rev
Log:
    PR target/58139
    * reginfo.c (choose_hard_reg_mode): Scan through all mode classes
    looking for widest mode.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/reginfo.c

[Bug target/58139] PowerPC volatile VSX register live across call

[bergner at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58139

Peter Bergner <bergner at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED
           Assignee|unassigned at gcc dot gnu.org      |bergner at gcc dot gnu.org

--- Comment #5 from Peter Bergner <bergner at gcc dot gnu.org> ---
Fixed.  Will wait a couple of weeks for any fall out before committing to the
FSF 4.8 branch.

[Bug target/58139] PowerPC volatile VSX register live across call

[dominiq at lps dot ens.fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58139

--- Comment #6 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
> New Revision: 202286

This seems to break bootstrap on *86*-*-*, see

http://gcc.gnu.org/ml/gcc-regression/2013-09/

[Bug target/58139] PowerPC volatile VSX register live across call

[meissner at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58139

--- Comment #7 from Michael Meissner <meissner at gcc dot gnu.org> ---
FWIW, I was able to bootstrap subversion id 202295 on my x86_68 laptop running
RHEL 6.4, building c, c++, fortran languages, and using --enable-lto
--without-ppl --without-cloog.

[Bug target/58139] PowerPC volatile VSX register live across call

[dominiq at lps dot ens.fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58139

--- Comment #8 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
> FWIW, I was able to bootstrap subversion id 202295 on my x86_68 laptop 
> running RHEL 6.4, building c, c++, fortran languages, and using 
> --enable-lto --without-ppl --without-cloog.

The failure is in libobj:

libtool: compile:  /opt/gcc/build_w/./gcc/xgcc -B/opt/gcc/build_w/./gcc/
-B/opt/gcc/gcc4.9w/x86_64-apple-darwin10.8.0/bin/
-B/opt/gcc/gcc4.9w/x86_64-apple-darwin10.8.0/lib/ -isystem
/opt/gcc/gcc4.9w/x86_64-apple-darwin10.8.0/include -isystem
/opt/gcc/gcc4.9w/x86_64-apple-darwin10.8.0/sys-include
/opt/gcc/work/libobjc/sendmsg.c -c -I. -I/opt/gcc/work/libobjc -g -O2 -W -Wall
-Wwrite-strings -Wstrict-prototypes -DIN_GCC -DIN_TARGET_LIBS
-fno-strict-aliasing -fexceptions -I/opt/gcc/work/libobjc/../gcc
-I/opt/gcc/work/libobjc/../gcc/config -I../.././gcc
-I/opt/gcc/work/libobjc/../libgcc -I../libgcc
-I/opt/gcc/work/libobjc/../include  -fno-common -DPIC -o .libs/sendmsg.o
xgcc: internal compiler error: Segmentation fault (program cc1)

This may be related to pr58269: compiling the reduced test in comment #2 with
the buid compiler gives the following ICE

[macbook] f90/bug% /opt/gcc/build_w/./gcc/xgcc -B/opt/gcc/build_w/./gcc/
pr58269.c
xgcc: internal compiler error: Segmentation fault (program cc1)
Abort

I am currently bootstrapping with r202295 reverted (2hours to go).

[Bug target/58139] PowerPC volatile VSX register live across call

[hjl.tools at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58139

--- Comment #9 from H.J. Lu <hjl.tools at gmail dot com> ---
You can try this:

diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index a8d70bc..ab4dc6c 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -34466,7 +34466,7 @@ ix86_hard_regno_mode_ok (int regno, enum machine_mode
mode)

       /* OImode move is available only when AVX is enabled.  */
       return ((TARGET_AVX && mode == OImode)
-          || VALID_AVX256_REG_MODE (mode)
+          || (TARGET_AVX && VALID_AVX256_REG_MODE (mode))
           || VALID_SSE_REG_MODE (mode)
           || VALID_SSE2_REG_MODE (mode)
           || VALID_MMX_REG_MODE (mode)

[Bug target/58139] PowerPC volatile VSX register live across call

[bergner at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58139

--- Comment #10 from Peter Bergner <bergner at gcc dot gnu.org> ---
Reading the comments above and pr58269, does this mean my patch just exposed a
latent bug?  ...and the supplied patches fix the latent bug?

[Bug target/58139] PowerPC volatile VSX register live across call

[dominiq at lps dot ens.fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58139

--- Comment #11 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
Boostrap with obj* completed successfully with r202295 reverted. I start again
with the patch in comment#9.

[Bug target/58139] PowerPC volatile VSX register live across call

[bergner at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58139

--- Comment #12 from Peter Bergner <bergner at gcc dot gnu.org> ---
Author: bergner
Date: Thu Jan 16 14:57:00 2014
New Revision: 206664

URL: http://gcc.gnu.org/viewcvs?rev=206664&root=gcc&view=rev
Log:
    Backport from mainline
    2014-01-15  Uros Bizjak  <ubizjak@gmail.com>

    * config/i386/i386.c (ix86_hard_regno_mode_ok): Use
    VALID_AVX256_REG_OR_OI_MODE.

    2013-09-05  Peter Bergner  <bergner@vnet.ibm.com>

    PR target/58139
    * reginfo.c (choose_hard_reg_mode): Scan through all mode classes
    looking for widest mode.

Modified:
    branches/gcc-4_8-branch/gcc/ChangeLog
    branches/gcc-4_8-branch/gcc/config/i386/i386.c
    branches/gcc-4_8-branch/gcc/reginfo.c

[Bug target/58139] PowerPC volatile VSX register live across call

[macro@linux-mips.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58139

Maciej W. Rozycki <macro@linux-mips.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |macro@linux-mips.org

--- Comment #13 from Maciej W. Rozycki <macro@linux-mips.org> ---
This breaks Power SPE targets, at least the Linux OS, almost surely EABI
too.  Seen in 4.8 powerpc-linux-gnu g++ and libstdc++ testing as some 700
regressions e.g. with these compiler options:

-mcpu=8540 -mfloat-gprs=single -mspe=yes -mabi=spe

The cause is a DWARF2 unwinder abort triggered by:

gcc_assert (size == sizeof(_Unwind_Word));

in _Unwind_SetSpColumn and the cause is with this change applied `size'
is 8 whereas `sizeof(_Unwind_Word)' is 4.  Previously `size' was 4.

For 4.8 please revert unless a better fix can be made within the
available time frame.  Let me know if I can assist with testing.

[Bug target/58139] PowerPC volatile VSX register live across call

[bergner at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58139

--- Comment #14 from Peter Bergner <bergner at gcc dot gnu.org> ---
(In reply to Maciej W. Rozycki from comment #13)
> This breaks Power SPE targets, at least the Linux OS, almost surely EABI
> too.  Seen in 4.8 powerpc-linux-gnu g++ and libstdc++ testing as some 700
> regressions e.g. with these compiler options:
> 
> -mcpu=8540 -mfloat-gprs=single -mspe=yes -mabi=spe
> 
> The cause is a DWARF2 unwinder abort triggered by:
> 
> gcc_assert (size == sizeof(_Unwind_Word));
> 
> in _Unwind_SetSpColumn and the cause is with this change applied `size'
> is 8 whereas `sizeof(_Unwind_Word)' is 4.  Previously `size' was 4.
> 
> For 4.8 please revert unless a better fix can be made within the
> available time frame.  Let me know if I can assist with testing.

My guess is that the fix is correct and is just exposing a latent bug for SPE.
Can you attach a preprocessed source file that exibits the ICE and I'll have a
look.

[Bug target/58139] PowerPC volatile VSX register live across call

[macro@linux-mips.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58139

--- Comment #15 from Maciej W. Rozycki <macro@linux-mips.org> ---
There is no ICE, this is target code in libgcc_s.so.1 calling abort at
run time whenever the DWARF2 unwinder is called.  Shall I send you
binaries?

NB SPE GPRs indeed are 64-bit wide even on 32-bit targets with the extra
32 bits only used for SPE data types, traditionally V2SI mode integers.
This makes a change in the ABI though such that any GPRs stored in stack
frames are held there as 64-bit quantities, with `evstdd' and `evldd'
intructions used to manipulate them.  For regular, non-vector integer
operations GPRs remain 32-bit, with the most significant 32 bits unused.

So this may or may not be a latent bug for SPE that, if so, I'd love to
see fixed in trunk, however speaking of 4.8 this is a serious regression
as the DWARF2 unwinder used to work and now it does not, making exception
handling non-functional.

Of course if you are able to fix 4.8 properly right away, then it would
be most welcome!