[Bug target/27619] wrong code for mixed-mode division with -mpowerpc64 -O1

[Bug target/27619] wrong code for mixed-mode division with -mpowerpc64 -O1

[segher at gcc dot gnu.org]

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

Segher Boessenkool <segher at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
                 CC|                            |segher at gcc dot gnu.org
         AssignedTo|unassigned at gcc dot       |segher at gcc dot gnu.org
                   |gnu.org                     |

--- Comment #15 from Segher Boessenkool <segher at gcc dot gnu.org> 2012-10-23 16:10:34 UTC ---
Things become a little clearer if you compile with -ffast-math, so
that the floatdisf2_internal2 pattern is not used.

The function then starts as:

        stwu 1,-16(1)
        lis 9,i@ha
        lwa 9,i@l(9)
        mflr 0
        std 9,8(1)

and stepi shows that the lwa insn already loads the wrong value!
Of course, GDB will not show the instruction because it does not
want to disassemble 64-bit insns in a 32-bit binary; but it shows

   0x100002fc <+12>:    .long 0xe9290890

which is wrong: it should be e9290892, low two bits zero means it
is an ld insn, not lwa.

The lwa patterns use the wrong constraint (they use "m", should
be "Y", because the low 2 bits of the offset are required to be
zero); but that does not fix it.

For 64-bit binaries, the relocations formed by @l for ld and lwa
and friends are ADDR16_LO_DS relocations; but for 32-bit binaries,
GAS simply makes ADDR16_LO relocations, which do set the low two
vits from the offset.  Oops.

Now of course ADDR16_LO_DS relocations do not exist for the 32-bit
PowerPC ABI, but overwriting the low bits of the instruction isn't
terribly helpful.

On GCC's side, I don't think we have any other choice than to disable
all instructions that need DS relocations when targetting an ABI
that does not have relocations for those; except we can get away
with it for insns that should have the low two bits zero.

So we need to disable (for -m32 -mpowerpc64): lwa, ldu, stdu; but
we can keep: ld, std (and ldx, ldux, stdx, stdux -- those aren't
DS-form, do not need relocations).

[Bug target/27619] wrong code for mixed-mode division with -mpowerpc64 -O1

[amodra at gmail dot com]

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

Alan Modra <amodra at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |amodra at gmail dot com

--- Comment #16 from Alan Modra <amodra at gmail dot com> 2012-10-24 05:35:06 UTC ---
gas is broken. http://sourceware.org/bugzilla/show_bug.cgi?id=14758

[Bug target/27619] wrong code for mixed-mode division with -mpowerpc64 -O1

[amodra at gmail dot com]

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

--- Comment #17 from Alan Modra <amodra at gmail dot com> 2012-10-26 03:51:35 UTC ---
Fixed in gas and ld.  I think the only thing that needs doing in gcc is fixing
the lwa constraint.

[Bug target/27619] wrong code for mixed-mode division with -mpowerpc64 -O1

[segher at gcc dot gnu.org]

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

Segher Boessenkool <segher at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |INVALID

--- Comment #18 from Segher Boessenkool <segher at gcc dot gnu.org> 2012-10-28 13:15:14 UTC ---
Not a GCC bug; fixed in binutils (will be in 2.24).

[Bug target/27619] wrong code for mixed-mode division with -mpowerpc64 -O1

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=27619

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |vincent-gcc at vinc17 dot net

--- Comment #19 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
*** Bug 58429 has been marked as a duplicate of this bug. ***

[Bug target/27619] wrong code for mixed-mode division with -mpowerpc64 -O1

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=27619

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|INVALID                     |MOVED
           See Also|                            |https://sourceware.org/bugz
                   |                            |illa/show_bug.cgi?id=14758

[Bug target/27619] wrong code for mixed-mode division with -mpowerpc64 -O1

[bje at gcc dot gnu dot org]

------- Comment #14 from bje at gcc dot gnu dot org  2009-05-14 03:35 -------
Confirmed with GCC 4.5.0 20090513 (experimental) [trunk revision 147498].


-- 


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

[Bug target/27619] wrong code for mixed-mode division with -mpowerpc64 -O1

[bergner at gcc dot gnu dot org]

------- Comment #13 from bergner at gcc dot gnu dot org  2008-08-28 03:52 -------
There are actually a subset of TARGET_POWERP64 instructions that are safe to
use in 32-bit mode regardless of whether OS_MISSING_POWERPC64 is set or not
(eg, fcfid).  For example, given the code below:

double
di2df (long long *di)
{
  return *di;
}

It should be safe to generate:

  lfd 0,0(3)
  fcfid 1,0
  blr

when compiling with -m32 as long as we are targeting a 64-bit processor (eg,
-mcpu=power6).  However, the floatdidf2 pattern is guarded with
TARGET_POWERPC64, so we end up generating a call to __floatdidf instead.


-- 

bergner at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bergner at gcc dot gnu dot
                   |                            |org


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

[Bug target/27619] wrong code for mixed-mode division with -mpowerpc64 -O1

[dje at gcc dot gnu dot org]

------- Comment #12 from dje at gcc dot gnu dot org  2006-05-18 15:56 -------
Users are suppose to control the architecture and code generation through
-mcpu=XXX, which sets the architecture options in self-consistent ways for the
target.  On Darwin, -mcpu=G5 sets -mpowerpc64; on Linux, -mpowerpc64
specifically is disabled for -mcpu=G5.  64-bit Darwin kernel always performs
64-bit context switch and apparently 64-bit Linux kernel does not.

This all is controlled by the OS_MISSING_POWERPC64 macro.  The macro is defined
for AIX and Linux and PPC64 Linux tests TARGET_64BIT on PPC64 Linux, i.e., it
only works for -m64 on PPC64 Linux.

If you want to add an error, follow the example from SUBTARGET_OVERRIDE_OPTIONS
in aix52.h:

  if (TARGET_POWERPC64 && ! TARGET_64BIT)                               \
    {                                                                   \
      error ("-maix64 required: 64-bit computation with 32-bit addressing not
yet supported"); \
    }


-- 


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

[Bug target/27619] wrong code for mixed-mode division with -mpowerpc64 -O1

[janis at gcc dot gnu dot org]

------- Comment #11 from janis at gcc dot gnu dot org  2006-05-16 22:42 -------
As mentioned above, the Linux kernel does not provide context switching support
needed for "-m32 -mpowerpc64".  I'm looking into disabling it for
powerpc64-linux.


-- 


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

[Bug target/27619] wrong code for mixed-mode division with -mpowerpc64 -O1

[janis at gcc dot gnu dot org]

------- Comment #10 from janis at gcc dot gnu dot org  2006-05-16 18:26 -------
By the way, I found this by running SPEC CPU2000, FreePOOMA, FTensor, and
Blitz++ with several sets of options plus either "-m32", "-m64", or "-m32
-mpowerpc64" and this was the only failure I saw.  This failure happens
consistently.  It seems as if a kernel issue would affect additional tests.


-- 


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

[Bug target/27619] wrong code for mixed-mode division with -mpowerpc64 -O1

[janis at gcc dot gnu dot org]

------- Comment #9 from janis at gcc dot gnu dot org  2006-05-16 17:55 -------
Good grief, if it "might not work with Linux" then it shouldn't be available
for GNU/Linux targets.


-- 

janis at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dje at gcc dot gnu dot org


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

[Bug target/27619] wrong code for mixed-mode division with -mpowerpc64 -O1

[pinskia at gcc dot gnu dot org]

------- Comment #8 from pinskia at gcc dot gnu dot org  2006-05-16 17:34 -------
The only thing I think we can do is warn that -mpowerpc64 might not work with
Linux as the linux kernel does not save and restore the full register while
doing a context switch (it is one reason why -mcpu=G5 -m32 does not turn on
-mpowerpc64 on Linux). 


-- 


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

[Bug target/27619] wrong code for mixed-mode division with -mpowerpc64 -O1

[olh at suse dot de]

------- Comment #7 from olh at suse dot de  2006-05-16 17:30 -------
yes, mpowerpc64 creates 32bit apps.

-m64
(gdb) info float 
f0             274      (raw 0x4071200000000000)
f1             0        (raw 0x0000000000000000)
f2             0        (raw 0x0000000000000000)
f3             0        (raw 0x0000000000000000)
f4             0        (raw 0x0000000000000000)
f5             0        (raw 0x0000000000000000)
f6             0        (raw 0x0000000000000000)
f7             0        (raw 0x0000000000000000)
f8             0        (raw 0x0000000000000000)
f9             0        (raw 0x0000000000000000)
f10            0        (raw 0x0000000000000000)
f11            0        (raw 0x0000000000000000)
f12            0        (raw 0x0000000000000000)
f13            274      (raw 0x4071200000000000)
f14            0        (raw 0x0000000000000000)
f15            0        (raw 0x0000000000000000)
f16            0        (raw 0x0000000000000000)
f17            0        (raw 0x0000000000000000)
f18            0        (raw 0x0000000000000000)
f19            0        (raw 0x0000000000000000)
f20            0        (raw 0x0000000000000000)
f21            0        (raw 0x0000000000000000)
f22            0        (raw 0x0000000000000000)
f23            0        (raw 0x0000000000000000)
f24            0        (raw 0x0000000000000000)
f25            0        (raw 0x0000000000000000)
f26            0        (raw 0x0000000000000000)
f27            0        (raw 0x0000000000000000)
f28            0        (raw 0x0000000000000000)
f29            0        (raw 0x0000000000000000)
f30            0        (raw 0x0000000000000000)
f31            0        (raw 0x0000000000000000)
fpscr          0x2000   8192




mpowerpc64


(gdb) info float 
f0             274      (raw 0x4071200000000000)
f1             0        (raw 0x0000000000000000)
f2             0        (raw 0x0000000000000000)
f3             0        (raw 0x0000000000000000)
f4             0        (raw 0x0000000000000000)
f5             0        (raw 0x0000000000000000)
f6             0        (raw 0x0000000000000000)
f7             0        (raw 0x0000000000000000)
f8             0        (raw 0x0000000000000000)
f9             0        (raw 0x0000000000000000)
f10            0        (raw 0x0000000000000000)
f11            0        (raw 0x0000000000000000)
f12            0        (raw 0x0000000000000000)
f13            1177886392320    (raw 0x427123f800000000)
f14            0        (raw 0x0000000000000000)
f15            0        (raw 0x0000000000000000)
f16            0        (raw 0x0000000000000000)
f17            0        (raw 0x0000000000000000)
f18            0        (raw 0x0000000000000000)
f19            0        (raw 0x0000000000000000)
f20            0        (raw 0x0000000000000000)
f21            0        (raw 0x0000000000000000)
f22            0        (raw 0x0000000000000000)
f23            0        (raw 0x0000000000000000)
f24            0        (raw 0x0000000000000000)
f25            0        (raw 0x0000000000000000)
f26            0        (raw 0x0000000000000000)
f27            0        (raw 0x0000000000000000)
f28            0        (raw 0x0000000000000000)
f29            0        (raw 0x0000000000000000)
f30            0        (raw 0x0000000000000000)
f31            0        (raw 0x0000000000000000)
fpscr          0x4000   16384


-- 


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

[Bug target/27619] wrong code for mixed-mode division with -mpowerpc64 -O1

[rguenth at gcc dot gnu dot org]

------- Comment #6 from rguenth at gcc dot gnu dot org  2006-05-16 17:28 -------
Yes it does:

rguenther@cranberry:/tmp> gcc -o t -O -mpowerpc64 t.c -mregnames
rguenther@cranberry:/tmp> file t
t: ELF 32-bit MSB executable, PowerPC or cisco 4500, version 1 (SYSV), for
GNU/Linux 2.6.4, dynamically linked (uses shared libs), for GNU/Linux 2.6.4,
not stripped

with -mpowerpc64 -m64 it works.


-- 


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

[Bug target/27619] wrong code for mixed-mode division with -mpowerpc64 -O1

[pinskia at gcc dot gnu dot org]

------- Comment #5 from pinskia at gcc dot gnu dot org  2006-05-16 17:27 -------
(In reply to comment #4)
> does -mpowerpc64 default to 32bit by any chance? see stdu vs. stwu in fn
> prologue.
Well I bet you have 32bit as the default. 
Anyways -mpowerpc64 is the 64bit register in 32bit mode.  And the asm is not
different except for differences in loading.  I am wondering if there is
context switch happening somewhere which is messing up the registers. 


-- 


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

[Bug target/27619] wrong code for mixed-mode division with -mpowerpc64 -O1

[olh at suse dot de]

------- Comment #4 from olh at suse dot de  2006-05-16 17:24 -------
Created an attachment (id=11478)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11478&action=view)
pr27619.s.diff

gcc -Wall -o pr27619 -O2 -g --save-temps pr27619.c -m64
vs.
gcc -Wall -o pr27619 -O2 -g --save-temps pr27619.c -mpowerpc64

does -mpowerpc64 default to 32bit by any chance? see stdu vs. stwu in fn
prologue.


-- 


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

[Bug target/27619] wrong code for mixed-mode division with -mpowerpc64 -O1

[rguenth at gcc dot gnu dot org]

------- Comment #3 from rguenth at gcc dot gnu dot org  2006-05-16 17:16 -------
-m64 asm:

.L.main:
        mflr %r0
        std %r0,16(%r1)
        stdu %r1,-128(%r1)
        ld %r9,.LC0@toc(%r2)
        lwa %r0,0(%r9)
        sradi %r9,%r0,53
        rldicl %r11,%r0,0,53
        addi %r9,%r9,1
        addi %r11,%r11,2047
        cmpldi %cr7,%r9,2
        or %r11,%r11,%r0
        rldicr %r11,%r11,0,52
        bge %cr7,.L3
        mr %r11,%r0
.L3:
        std %r11,112(%r1)
        lfd %f0,112(%r1)
        fcfid %f0,%f0
        frsp %f13,%f0
        ld %r9,.LC1@toc(%r2)
        lfs %f0,0(%r9)
        fdivs %f13,%f13,%f0
        lfs %f0,.LC3@toc(%r2)
        fcmpu %cr7,%f13,%f0
        beq %cr7,.L2
        bl abort
        nop
.L2:
        li %r3,0
        addi %r1,%r1,128
        ld %r0,16(%r1)
        mtlr %r0
        blr
        .long 0
        .byte 0,0,0,1,128,0,0,0
        .size   main,.-.L.main
        .globl i
        .section        ".data"
        .align 2
        .type   i, @object
        .size   i, 4
i:
        .long   274
        .globl f
        .align 2
        .type   f, @object
        .size   f, 4
f:
        .long   1065353216


-mpowerpc64:

main:
        stwu %r1,-16(%r1)
        mflr %r0
        stw %r0,20(%r1)
        lis %r9,i@ha
        lwa %r0,i@l(%r9)
        sradi %r9,%r0,53
        rldicl %r11,%r0,0,53
        addi %r9,%r9,1
        addi %r11,%r11,2047
        cmpldi %cr7,%r9,2
        or %r11,%r11,%r0
        rldicr %r11,%r11,0,52
        bge %cr7,.L3
        mr %r11,%r0
.L3:
        std %r11,8(%r1)
        lfd %f0,8(%r1)
        fcfid %f0,%f0
        frsp %f13,%f0
        lis %r9,f@ha
        lfs %f0,f@l(%r9)
        fdivs %f13,%f13,%f0
        lis %r9,.LC1@ha
        lfs %f0,.LC1@l(%r9)
        fcmpu %cr7,%f13,%f0
        beq %cr7,.L2
        bl abort
.L2:
        li %r3,0
        lwz %r0,20(%r1)
        mtlr %r0
        addi %r1,%r1,16
        blr
        .size   main,.-main
        .globl i
        .section        .sdata,"aw",@progbits
        .align 2
        .type   i, @object
        .size   i, 4
i:
        .long   274
        .globl f
        .align 2
        .type   f, @object
        .size   f, 4
f:
        .long   1065353216


-- 


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

[Bug target/27619] wrong code for mixed-mode division with -mpowerpc64 -O1

[pinskia at gcc dot gnu dot org]

------- Comment #2 from pinskia at gcc dot gnu dot org  2006-05-16 17:03 -------
This might turn out to be a kernel issue.


-- 


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

[Bug target/27619] wrong code for mixed-mode division with -mpowerpc64 -O1

[rguenth at gcc dot gnu dot org]

------- Comment #1 from rguenth at gcc dot gnu dot org  2006-05-16 09:28 -------
Confirmed.  Works with -m64, though the docs say "The 64-bit environment sets
int to 32 bits and long and pointer to 64 bits, and generates code for
PowerPC64, as for -mpowerpc64." for the -m64 option.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2006-05-16 09:28:02
               date|                            |


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