Date: Fri, 24 May 2019 00:44:14 -0700 From: Mark Millard <marklmi@yahoo.com> To: Ralf Wenk <iz-rpi03@hs-karlsruhe.de> Cc: Jan Beich <jbeich@FreeBSD.org>, FreeBSD Toolchain <freebsd-toolchain@freebsd.org>, ports-list freebsd <freebsd-ports@freebsd.org>, FreeBSD PowerPC ML <freebsd-ppc@freebsd.org> Subject: Re: 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?" Message-ID: <160C4524-F6D0-4F8D-AB9B-334D833E7927@yahoo.com> In-Reply-To: <E1hU4LD-00FbX8-OK@smtp.hs-karlsruhe.de> References: <A0862A43-075F-4760-ABDE-6F3D83C9768F@yahoo.com> <pno9-9ff2-wny@FreeBSD.org> <1C226A5A-147D-4307-89D6-0E88F70ADFD6@yahoo.com> <E1hU4LD-00FbX8-OK@smtp.hs-karlsruhe.de>
next in thread | previous in thread | raw e-mail | index | archive | help
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: >>=20 >>> Mark Millard <marklmi at yahoo.com> writes: >>>=20 >>>> Unfortunately poudiere bulk tar archives of failures do not >>>> catch the /tmp/* material from: >>>>=20 >>>> 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 >>>=20 >>> 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. >>=20 >> I have expanded the poudriere bulk's tar of the failure and rerun the >> command from there. The problem reproduced: >>=20 >> # 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 >>=20 >>=20 >> So I gzip'd the .c and created: >>=20 >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D238082 >>=20 >> with the two files as 2 attachments. >=20 > 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@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=3D238084 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=3D330578472) 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=3D<optimized out>, = file=3D<optimized out>, line=3D<optimized out>, failedexpr=3D<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:253= 1 #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. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?160C4524-F6D0-4F8D-AB9B-334D833E7927>