Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 11 Nov 2016 23:55:49 +0000
From:      bugzilla-noreply@freebsd.org
To:        freebsd-bugs@FreeBSD.org
Subject:   [Bug 214431] head -r308247 for powerpc: clang 3.8.0 toolchain rejects "bc+" assembler notation
Message-ID:  <bug-214431-8@https.bugs.freebsd.org/bugzilla/>

next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D214431

            Bug ID: 214431
           Summary: head -r308247 for powerpc: clang 3.8.0 toolchain
                    rejects "bc+" assembler notation
           Product: Base System
           Version: CURRENT
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Only Me
          Priority: ---
         Component: bin
          Assignee: freebsd-bugs@FreeBSD.org
          Reporter: markmi@dsl-only.net

[This would also apply to release/11.0.* , releng/11.0 , and stable/11 --th=
at
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 power=
pc
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=3Dcompile --tag=3DCC ../mpn/m4-ccas --m4=3D"m4" c=
c -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=3Dm4 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+=
=20=20=20=20
12, 28, L(9)
/usr/obj/portswork/usr/ports/math/gmp/work/gmp-5.1.3/mpn/divrem_2.asm:  bc+=
=20=20=20=20
12, 28, L(13)
/usr/obj/portswork/usr/ports/math/gmp/work/gmp-5.1.3/mpn/tmp-divrem_2.s:=20=
=20=20=20=20=20=20
bc+     12, 28, .L9
/usr/obj/portswork/usr/ports/math/gmp/work/gmp-5.1.3/mpn/tmp-divrem_2.s:=20=
=20=20=20=20=20=20
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/Re=
ference/Assembler/050-PowerPC_Addressing_Modes_and_Assembler_Instructions/p=
pc_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 l=
lvm
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 t=
he
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 w=
as
added (enabling libstand builds). Again I'll wait for the fix to be applied=
 in
the 3.9.0 project.

--=20
You are receiving this mail because:
You are the assignee for the bug.=



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-214431-8>