powerpc64 graphics/mesa-dri build failure in poudriere, system clang's /usr/bin/cc got assert failure: "Target supports vector op, but scalar requires expansion?"

[Mark Millard]

On 2019-May-24, at 00:10, Ralf Wenk <iz-rpi03 at hs-karlsruhe.de> wrote:

> On 2019-05-23, at 12:31 -0700, Mark Millard wrote:
>> On 2019-May-23, at 11:47, Jan Beich <jbeich at FreeBSD.org> wrote:
>> 
>>> Mark Millard <marklmi at yahoo.com> writes:
>>> 
>>>> Unfortunately poudiere bulk tar archives of failures do not
>>>> catch the /tmp/* material from:
>>>> 
>>>> cc: error: unable to execute command: Abort trap (core dumped)
>>>> cc: error: clang frontend command failed due to signal (use -v to see invocation)
>>>> FreeBSD clang version 8.0.0 (tags/RELEASE_800/final 356365) (based on LLVM 8.0.0)
>>>> Target: powerpc64-unknown-freebsd13.0
>>>> Thread model: posix
>>>> InstalledDir: /usr/bin
>>> 
>>> Do you have the build log? Maybe it's possible to reproduce simply by adding
>>> -target powerpc64-unknown-freebsd13.0 while cross-building that particular file
>>> using otherwise the same command line options as native build.
>> 
>> I have expanded the poudriere bulk's tar of the failure and rerun the
>> command from there. The problem reproduced:
>> 
>> # ls -lTdt /tmp/nir_constant_expressions-9b094e.*
>> -rw-r--r--  1 root  wheel    11069 May 23 12:08:35 2019 /tmp/nir_constant_expressions-9b094e.sh
>> -rw-r--r--  1 root  wheel  1951892 May 23 12:08:35 2019 /tmp/nir_constant_expressions-9b094e.c
>> 
>> 
>> So I gzip'd the .c and created:
>> 
>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=238082
>> 
>> with the two files as 2 attachments.
> 
> This looks familiar to me. Is the kernel you are using at r348115 or newer?

No, based on head -r347549 :

# uname -apKU
FreeBSD FBSDG5L 13.0-CURRENT FreeBSD 13.0-CURRENT #0 r347549M: Wed May 22 15:14:43 PDT 2019     markmi at FBSDG5L:/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/powerpc.powerpc64/sys/GENERIC64vtsc-NODBG  powerpc powerpc64 1300025 1300025


> r348115 triggers such kind of "unable to execute" compiler errors on my
> system. See https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=238084

I've had no troubles with buildworld or buildkernel.

"Unable to execute" is very generic, meaning little more
than did-not-finish for whatever reason. In my case it
did not finish because:

	      assert(!TLI.isOperationLegalOrCustom(N->getOpcode(), WideVecVT) &&
	             "Target supports vector op, but scalar requires expansion?");

failed the test and assert called abort, whihc in  turn sent a
SIGABRT to the process. Nothing about this suggests a kernel
issue. It is more likely a error in handling code generation
related to powerpc64 vector operations.

I used the core file produced to get the backtrace via gdb:

Core was generated by `/usr/bin/cc -cc1 -triple powerpc64-unknown-freebsd13.0 -emit-obj -disable-free -'.
Program terminated with signal SIGABRT, Aborted.
#0  .__sys_thr_kill () at thr_kill.S:3
3	RSYSCALL(thr_kill)
(gdb) bt
#0  .__sys_thr_kill () at thr_kill.S:3
#1  0x00000000133072d0 in __raise (s=330578472) at /usr/src/lib/libc/gen/raise.c:52
#2  0x00000000132c7898 in abort () at /usr/src/lib/libc/stdlib/abort.c:79
#3  0x00000000132f6c64 in __assert (func=<optimized out>, file=<optimized out>, line=<optimized out>, failedexpr=<optimized out>) at /usr/src/lib/libc/gen/assert.c:51
#4  0x00000000130f7c18 in WidenVectorResult () at /usr/src/contrib/llvm/lib/CodeGen/SelectionDAG/LegalizeVectorTypes.cpp:2531
#5  0x0000000012ad91f0 in run () at /usr/src/contrib/llvm/lib/CodeGen/SelectionDAG/LegalizeTypes.cpp:281
#6  0x0000000012adfa5c in LegalizeTypes () at /usr/src/contrib/llvm/lib/CodeGen/SelectionDAG/LegalizeTypes.cpp:1115
#7  0x000000001297ebb4 in CodeGenAndEmitDAG () at /usr/src/contrib/llvm/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp:776
#8  0x000000001297e114 in SelectBasicBlock () at /usr/src/contrib/llvm/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp:669
#9  0x000000001297cbc4 in SelectAllBasicBlocks () at /usr/src/contrib/llvm/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp:1784
#10 0x0000000000000000 in ?? ()

But I build with debug symbols generally, even for optimized builds.

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)