-mcpu=G5 produces broken code for ppc

[barracuda156]

@iains Could something be done about this? From what I can tell, at least in multiple instances usage of -mcpu=G5 on ppc results in broken executables. We have seen that with OpenBLAS OpenMathLib/OpenBLAS#4376 (you have taken part in discussion there), but I have encountered the same with other ports, and right now with x264. In all the same cases -mtune=G5 works normally, as well as -mcpu=G4.
I am not sure how long back the bug goes, but it affects at least several recent major versions.

[barracuda156]

@iains This is not definitive, but seems that -mcpu=G5 breaks only ppc builds but not ppc64. At least with x264 I do not get Bus error when build it for ppc64 – but did get with ppc.

[iains]

what is the output of otool -hv for an object built that way?

I don't think that the use of 64b instructions in 32b code is really tested very well - it should be possible, in principle (just use the instructions between calls) - but ....

.. and, if it's broken, the best thing is "don't do that" .. without some hardware, there's no realistic chance that I am going to be able to fix it .. and is it a good use of time?

[barracuda156]

@iains Hardware access can be arranged, if it can be scheduled. If you install gsocket (I have a port for it for macOS which builds at least on arm64, or you can install it for Linux), that provides technical means. It works with no special setup, from behind a firewall, etc.

what is the output of otool -hv for an object built that way?

Should this be run on the executable or .o file(s) from which executable is produced?

[iains]

@iains Hardware access can be arranged, if it can be scheduled. If you install gsocket (I have a port for it for macOS which builds at least on arm64, or you can install it for Linux), that provides technical means. It works with no special setup, from behind a firewall, etc.

scheduling is hard - I can only work on this on and off - and bootstrap and test takes ≈ 24h even on a quad g5 .. so ...

what is the output of otool -hv for an object built that way?

Should this be run on the executable or .o file(s) from which executable is produced?

.o (although exe would be interesting too)

[barracuda156]

scheduling is hard - I can only work on this on and off - and bootstrap and test takes ≈ 24h even on a quad g5

We just need to do it once though, right? Then only changed stuff can be rebuilt. (Assuming gcc is built without MacPorts, which is what you will do anyway.)

We can probably run a “permanent back-door” to allow access via gsocket for you, then it will be available any time machine is up. I will ask folks on MacRumors too, if someone has a Quad which is up often. Since mine is semi-dying, it will probably not be accessible much (or at all, depending on luck). I have a back-up option, 2.3 DC, it just needs to be moved to a place with air-conditioning.

and, if it's broken, the best thing is "don't do that"

The problem is that it gonna creep in via -mcpu=native usage, and while I can ensure I do not pass this flag for ppc builds, some software will use it, and if it is unnoticed, we get broken stuff. I am actually wondering now if some existing breakages may be caused by this flag and not anything else.

[barracuda156]

@iains By the way, what is the exact effect of having GCC built with --mtune-cpu=G5? Does it affect only how GCC itself is built or also the code it generates? I build both but normally use the optimized one.

[iains]

@iains By the way, what is the exact effect of having GCC built with --mtune-cpu=G5?

Do you mean --with-mtune=G5 as a configure option?

Does it affect only how GCC itself is built

well .. it alters the defaults, so technically yes - but it should not cause 64b instructions to be used in 32b code.

or also the code it generates? I build both but normally use the optimized one.

AFAIK this is perfectly OK - it will just use tuning for G5 by default - but as noted above - it will not try to use 64b instructions in 32b code.

--with-mcpu=G5 will cause a change in code-gen and that code-gen is not well tested and likely to cause problems. In fact, I would be surprised if the compiler would even bootstrap with that setting.

[barracuda156]

@iains I meant --with-tune-cpu=G5 as GCC configure option. Like you mention here: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43301#c6
What does it imply exactly?

[iains]

@iains I meant --with-tune-cpu=G5 as GCC configure option. Like you mention here: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43301#c6 What does it imply exactly?

that means that when you generate code with the compiler it will use G5 tuning by default - this is fine (and makes sense if you are building a native compiler on a G5 box and don't intend copying it anywhere else).

.. of course, it makes less sense if you are mostly building for ppc7400 .. since you then end up having to put extra options.

[iains]

I am still interested to see the output of otool -hv to confirm the hypothesis that the issue as above.

[barracuda156]

@iains Is this what is needed?

Sergey-Fedorovs-Mac:~ svacchanda\$ /opt/local/var/macports/build/x264-0b9e231d/work/destroot/opt/local/bin/x264 
x264 [error]: No input file. Run x264 --help for a list of options.
Bus error

Sergey-Fedorovs-Mac:~ svacchanda\$ otool -hv /opt/local/var/macports/build/x264-0b9e231d/work/destroot/opt/local/bin/x264 
/opt/local/var/macports/build/x264-0b9e231d/work/destroot/opt/local/bin/x264:
Mach header
      magic cputype cpusubtype  caps    filetype ncmds sizeofcmds      flags
   MH_MAGIC     PPC     ppc970  0x00     EXECUTE    12       1476   NOUNDEFS DYLDLINK TWOLEVEL

Sergey-Fedorovs-Mac:~ svacchanda\$ otool -hv /opt/local/var/macports/build/x264-0b9e231d/work/x264-b35605ace3ddf7c1a5d67a2eb553f034aef41d55/x264.o 
/opt/local/var/macports/build/x264-0b9e231d/work/x264-b35605ace3ddf7c1a5d67a2eb553f034aef41d55/x264.o:
Mach header
      magic cputype cpusubtype  caps    filetype ncmds sizeofcmds      flags
   MH_MAGIC     PPC     ppc970  0x00      OBJECT     3        908 SUBSECTIONS_VIA_SYMBOLS

Sergey-Fedorovs-Mac:~ svacchanda\$ otool -hv /opt/local/var/macports/build/x264-0b9e231d/work/x264-b35605ace3ddf7c1a5d67a2eb553f034aef41d55/libx264.165.dylib 
/opt/local/var/macports/build/x264-0b9e231d/work/x264-b35605ace3ddf7c1a5d67a2eb553f034aef41d55/libx264.165.dylib:
Mach header
      magic cputype cpusubtype  caps    filetype ncmds sizeofcmds      flags
   MH_MAGIC     PPC     ppc970  0x00       DYLIB    10       1208   NOUNDEFS DYLDLINK TWOLEVEL NO_REEXPORTED_DYLIBS

Sergey-Fedorovs-Mac:~ svacchanda\$ sudo gdb /opt/local/var/macports/build/x264-0b9e231d/work/destroot/opt/local/bin/x264
Password:
GNU gdb 6.3.50-20050815 (Apple version gdb-1515) (Sat Jan 15 08:32:01 UTC 2011)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "powerpc-apple-darwin"...Reading symbols for shared libraries .. done

(gdb) run
Starting program: /opt/local/var/macports/build/x264-0b9e231d/work/destroot/opt/local/bin/x264 
Reading symbols for shared libraries +. done
x264 [error]: No input file. Run x264 --help for a list of options.

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x000003ae
0x000138b0 in x264_param_cleanup ()
(gdb) bt
#0  0x000138b0 in x264_param_cleanup ()
#1  0x001c34ac in main ()
(gdb) disassemble
Dump of assembler code for function x264_param_cleanup:
0x000138a0 <x264_param_cleanup+0>:	mflr    r0
0x000138a4 <x264_param_cleanup+4>:	mr      r11,r1
0x000138a8 <x264_param_cleanup+8>:	stw     r0,8(r1)
0x000138ac <x264_param_cleanup+12>:	bl      0x1c31bc <saveGPR+56>
0x000138b0 <x264_param_cleanup+16>:	lwz     r28,936(r3)
0x000138b4 <x264_param_cleanup+20>:	stwu    r1,-96(r1)
0x000138b8 <x264_param_cleanup+24>:	cmpwi   r28,0
0x000138bc <x264_param_cleanup+28>:	beq-    0x13908 <x264_param_cleanup+104>
0x000138c0 <x264_param_cleanup+32>:	lwz     r2,4(r28)
0x000138c4 <x264_param_cleanup+36>:	mr      r27,r3
0x000138c8 <x264_param_cleanup+40>:	cmpwi   r2,0
0x000138cc <x264_param_cleanup+44>:	ble-    0x138f8 <x264_param_cleanup+88>
0x000138d0 <x264_param_cleanup+48>:	addi    r29,r28,4
0x000138d4 <x264_param_cleanup+52>:	li      r30,0
0x000138d8 <x264_param_cleanup+56>:	nop
0x000138dc <x264_param_cleanup+60>:	nop
0x000138e0 <x264_param_cleanup+64>:	lwzu    r3,4(r29)
0x000138e4 <x264_param_cleanup+68>:	bl      0x1c5e4c <dyld_stub_free>
0x000138e8 <x264_param_cleanup+72>:	lwz     r2,4(r28)
0x000138ec <x264_param_cleanup+76>:	addi    r30,r30,1
0x000138f0 <x264_param_cleanup+80>:	cmpw    r2,r30
0x000138f4 <x264_param_cleanup+84>:	bgt+    0x138e0 <x264_param_cleanup+64>
0x000138f8 <x264_param_cleanup+88>:	mr      r3,r28
0x000138fc <x264_param_cleanup+92>:	bl      0x1c5e4c <dyld_stub_free>
0x00013900 <x264_param_cleanup+96>:	li      r2,0
0x00013904 <x264_param_cleanup+100>:	stw     r2,936(r27)
0x00013908 <x264_param_cleanup+104>:	addi    r1,r1,96
0x0001390c <x264_param_cleanup+108>:	mr      r11,r1
0x00013910 <x264_param_cleanup+112>:	b       0x1c325c <restGPRx+56>
0x00013914 <x264_param_cleanup+116>:	nop
0x00013918 <x264_param_cleanup+120>:	nop
0x0001391c <x264_param_cleanup+124>:	nop
End of assembler dump.
(gdb) info registers
r0             0x1c34ac	1848492
r1             0xbfffeff0	3221221360
r2             0x0	0
r3             0x6	6
r4             0x0	0
r5             0xbfffefc8	3221221320
r6             0x2e0a	11786
r7             0x36	54
r8             0x8	8
r9             0x1f40	8000
r10            0xbffff018	3221221400
r11            0xbfffeff0	3221221360
r12            0x90e2f3d4	2430792660
r13            0xbffff890	3221223568
r14            0x1f3350	2044752
r15            0x0	0
r16            0x0	0
r17            0x0	0
r18            0x0	0
r19            0x1	1
r20            0x0	0
r21            0xa0256558	2686805336
r22            0xbffff790	3221223312
r23            0xffffffff	4294967295
r24            0x1cac70	1879152
r25            0x0	0
r26            0x1ef360	2028384
r27            0x1ee678	2025080
r28            0xbffffa38	3221223992
r29            0x1	1
r30            0xffffffffffffffff	18446744073709551615
r31            0x1c3350	1848144
pc             0x138b0	80048
ps             0x100000000000d030	1152921504606900272
cr             0x22000022	570425378
lr             0x138b0	80048
ctr            0x90e2f3d4	2430792660
xer            0x0	0
mq             0x0	0
fpscr          0x0	0
vscr           0x10000	65536
vrsave         0x80000000	2147483648

[iains]

@iains Is this what is needed?

Sergey-Fedorovs-Mac:~ svacchanda\$ /opt/local/var/macports/build/x264-0b9e231d/work/destroot/opt/local/bin/x264 
x264 [error]: No input file. Run x264 --help for a list of options.
Bus error

Sergey-Fedorovs-Mac:~ svacchanda\$ otool -hv /opt/local/var/macports/build/x264-0b9e231d/work/destroot/opt/local/bin/x264 
/opt/local/var/macports/build/x264-0b9e231d/work/destroot/opt/local/bin/x264:
Mach header
      magic cputype cpusubtype  caps    filetype ncmds sizeofcmds      flags
   MH_MAGIC     PPC     ppc970  0x00     EXECUTE    12       1476   NOUNDEFS DYLDLINK TWOLEVEL

Yes .. that is almost certainly the issue - "ppc970" CPU subtype indicates that we are trying to use 64b instructions in a 32b binary. This is theoretically a usable mode, but it is not really tested - and I very much doubt there's any testing upstream either - since almost all the hosts are now powerpc64.

Try to build the code with -mtune=G5 (but make sure that the CPU is G4 or so)