Bug 214431 - head -r308247 for powerpc: clang 3.8.0 toolchain rejects "bc+" assembler notation
Summary: head -r308247 for powerpc: clang 3.8.0 toolchain rejects "bc+" assembler nota...
Status: Closed Overcome By Events
Alias: None
Product: Base System
Classification: Unclassified
Component: bin (show other bugs)
Version: CURRENT
Hardware: Any Any
: --- Affects Only Me
Assignee: freebsd-toolchain mailing list
Depends on:
Reported: 2016-11-11 23:55 UTC by Mark Millard
Modified: 2019-07-09 02:24 UTC (History)
1 user (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Mark Millard 2016-11-11 23:55:49 UTC
[This would also apply to release/11.0.* , releng/11.0 , and stable/11 --that is if system-clang targeting powerpc was actually supported in 11.]

[Note: I experiment with clang targeting powerpc and powerpc64 and report problems, including to llvm. clang 3.8.0 has various other issues for powerpc and is not for general use yet. For example: I use a modified powerpc kernel that has a so-called "red zone" on the stack for signal handling in order to deal with clang's stack handling ABI violations. This allows me to find and report other issues without waiting for the ABI fix.]

If FreeBSD agrees that bc+ notation should be allowed in the clang toolchain then submittal to llvm would also be appropriate.

On to the details/evidence. . .

cc here is the powerpc system clang 3.8.0 from head -r308247 but I've seen this before for 3.8.0.

The problem showed up in trying to build lang/gcc6, which in turn tried to build math/gmp: it is math/gmp where the failure happens. Other gcc* builds would also try to build math/gmp. The details are. . .

--- divrem_2.lo ---
/bin/sh ../libtool --mode=compile --tag=CC ../mpn/m4-ccas --m4="m4" cc -c -DHAVE_CONFIG_H -I. -I.. -D__GMP_WITHIN_GMP -I..  -DOPERATION_`echo divrem_2 | sed 's/_$//'`     -pipe  -g -fno-strict-aliasing  `test -f 'divrem_2.asm' || echo './'`divrem_2.asm
libtool: compile:  ../mpn/m4-ccas --m4=m4 cc -c -DHAVE_CONFIG_H -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_divrem_2 -pipe -g -fno-strict-aliasing divrem_2.asm  -fPIC -DPIC -o .libs/divrem_2.o
. . .
--- divrem_2.lo ---
m4  -DHAVE_CONFIG_H -D__GMP_WITHIN_GMP -DOPERATION_divrem_2 -DPIC divrem_2.asm >tmp-divrem_2.s
. . .
--- divrem_2.lo ---
 cc -c -DHAVE_CONFIG_H -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_divrem_2 -pipe -g -fno-strict-aliasing tmp-divrem_2.s -fPIC -DPIC -o .libs/divrem_2.o
cc: warning: argument unused during compilation: '-D HAVE_CONFIG_H'
cc: warning: argument unused during compilation: '-D __GMP_WITHIN_GMP'
cc: warning: argument unused during compilation: '-D OPERATION_divrem_2'
cc: warning: argument unused during compilation: '-fno-strict-aliasing'
cc: warning: argument unused during compilation: '-D PIC'
tmp-divrem_2.s:122:2: error: unrecognized instruction mnemonic
        bc+     12, 28, .L9
tmp-divrem_2.s:139:2: error: unrecognized instruction mnemonic
        bc+     12, 28, .L13
*** [divrem_2.lo] Error code 1

make[4]: stopped in /usr/obj/portswork/usr/ports/math/gmp/work/gmp-5.1.3/mpn
1 error

make[4]: stopped in /usr/obj/portswork/usr/ports/math/gmp/work/gmp-5.1.3/mpn
*** [all-recursive] Error code 1

The clang 3.8.0 toolchain does not recognize the "+" notation for branch prediction control (Y-bit encoding) for bc instructions.

# grep bc+ /usr/obj/portswork/usr/ports/math/gmp/work/gmp-5.1.3/mpn/*
/usr/obj/portswork/usr/ports/math/gmp/work/gmp-5.1.3/mpn/divrem_2.asm:	bc+	12, 28, L(9)
/usr/obj/portswork/usr/ports/math/gmp/work/gmp-5.1.3/mpn/divrem_2.asm:	bc+	12, 28, L(13)
/usr/obj/portswork/usr/ports/math/gmp/work/gmp-5.1.3/mpn/tmp-divrem_2.s:	bc+	12, 28, .L9
/usr/obj/portswork/usr/ports/math/gmp/work/gmp-5.1.3/mpn/tmp-divrem_2.s:	bc+	12, 28, .L13

But there are other examples of the + notation in mpn:

diveby3.asm:	blelr+	cr7

divrem_2.asm:	bgt+	cr7, L(4)
divrem_2.asm:	bge+	cr0, L(18)
divrem_2.asm:	blt+	cr7, L(24)
divrem_2.asm:	bgt+	cr7, L(28)

These do not stop the math/gmp build. So it appears that some uses of the + notation are supported, just not bc+ .

See "Branch Prediction" in https://developer.apple.com/library/content/documentation/DeveloperTools/Reference/Assembler/050-PowerPC_Addressing_Modes_and_Assembler_Instructions/ppc_instructions.html#//apple_ref/doc/uid/TP30000824-CJBDFIAE as an example documenting the + notation, including bc+ being allowed.

Removing the two "+"s in divrem_2.asm's "bc+"s allows gmp to build.

But who knows how many other ports or other software might have powerpc assembler notation with bc+ notation.

I've not tried to use clang 3.8.0 for buildkernel for powerpc (or powerpc64), only buildworld and some ports. It could be that buildkernel could run into the bc+ notation issue for all I know.

I have not tried clang 3.9.0 for powerpc (or powerpc64) yet. Of the fixes llvm has made for powerpc and powerpc64, I think FreeBSD's 3.9.0 project has yet to include the two most recent fixes. For powerpc one of the fixes completes the fix of the stack handling ABI violation as I remember. I will wait for that on powerpc for the 3.9.0 project. For powerpc64 it is softfloat support that was added (enabling libstand builds). Again I'll wait for the fix to be applied in the 3.9.0 project.
Comment 1 Ed Maste freebsd_committer 2018-08-01 14:57:31 UTC
Is this still the case with clang 6 in HEAD now?
Comment 2 Mark Millard 2018-08-01 15:58:04 UTC
(In reply to Ed Maste from comment #1)

I currently do not have a context for trying to build
/usr/ports/math/gmp/ (or other such) for a powerpc or
powerpc64 target environment via clang. It will be
some time (unknown) before I'll again have such a
context, possibly weeks or months.
Comment 3 Mark Millard 2019-07-09 02:24:21 UTC
In more modern contexts, math/gmp builds fine for my experimental
system-clang 8.0.0 based powerpc activity.

Marking as Overcome By Events.