[Bug 216117] clang 4.0.0 crashes trying to build lld on i386
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216117 Dimitry Andric changed: What|Removed |Added Status|New |In Progress --- Comment #5 from Dimitry Andric --- I managed to figure out that upstream https://reviews.llvm.org/rL291671 caused a use-after-free issue, which is why it doesn't always crash. I had to run it under valgrind to see relatively clearly where it came from. Hal Finkel has put up a review for a fix here: https://reviews.llvm.org/D28749 -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
[Bug 216117] clang 4.0.0 crashes trying to build lld on i386
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216117 Dimitry Andric changed: What|Removed |Added CC||d...@freebsd.org --- Comment #4 from Dimitry Andric --- Hm, yes, I'm seeing this too, while building llvm38 even. Something is rotten, but it's hard to figure out what. For some reason, a cleanly built release_40 r292009 on universe12a.f.o works fine, but on my local system, it doesn't. I'm trying valgrind to figure out what is going wrong, and it gives me: ==1793== Invalid read of size 8 ==1793==at 0x227C9BE: llvm::ValueHandleBase::AddToUseList() (in /usr/obj/share/dim/src/freebsd/base/projects/clang400-import/usr.bin/clang/clang/clang.full) ==1793==by 0x29A3F2D: llvm::AssumptionCache::AffectedValueCallbackVH::allUsesReplacedWith(llvm::Value*) (in /usr/obj/share/dim/src/freebsd/base/projects/clang400-import/usr.bin/clang/clang/clang.full) ==1793==by 0x227A884: llvm::ValueHandleBase::ValueIsRAUWd(llvm::Value*, llvm::Value*) (in /usr/obj/share/dim/src/freebsd/base/projects/clang400-import/usr.bin/clang/clang/clang.full) ==1793==by 0x227A504: llvm::Value::doRAUW(llvm::Value*, bool) (in /usr/obj/share/dim/src/freebsd/base/projects/clang400-import/usr.bin/clang/clang/clang.full) ==1793==by 0x1C9791E: llvm::sroa::AllocaSliceRewriter::visitLoadInst(llvm::LoadInst&) (in /usr/obj/share/dim/src/freebsd/base/projects/clang400-import/usr.bin/clang/clang/clang.full) ==1793==by 0x1C880FD: llvm::sroa::AllocaSliceRewriter::visit((anonymous namespace)::Slice const*) (in /usr/obj/share/dim/src/freebsd/base/projects/clang400-import/usr.bin/clang/clang/clang.full) ==1793==by 0x1C86C9A: llvm::SROA::rewritePartition(llvm::AllocaInst&, llvm::sroa::AllocaSlices&, llvm::sroa::Partition&) (in /usr/obj/share/dim/src/freebsd/base/projects/clang400-import/usr.bin/clang/clang/clang.full) ==1793==by 0x1C88584: llvm::SROA::splitAlloca(llvm::AllocaInst&, llvm::sroa::AllocaSlices&) (in /usr/obj/share/dim/src/freebsd/base/projects/clang400-import/usr.bin/clang/clang/clang.full) ==1793==by 0x1C89A1D: llvm::SROA::runOnAlloca(llvm::AllocaInst&) (in /usr/obj/share/dim/src/freebsd/base/projects/clang400-import/usr.bin/clang/clang/clang.full) ==1793==by 0x1C8B309: llvm::SROA::runImpl(llvm::Function&, llvm::DominatorTree&, llvm::AssumptionCache&) (in /usr/obj/share/dim/src/freebsd/base/projects/clang400-import/usr.bin/clang/clang/clang.full) ==1793==by 0x1C9C239: llvm::sroa::SROALegacyPass::runOnFunction(llvm::Function&) (in /usr/obj/share/dim/src/freebsd/base/projects/clang400-import/usr.bin/clang/clang/clang.full) ==1793==by 0x22B78D9: llvm::FPPassManager::runOnFunction(llvm::Function&) (in /usr/obj/share/dim/src/freebsd/base/projects/clang400-import/usr.bin/clang/clang/clang.full) ==1793== Address 0x5a5a5a5a5a5a5a62 is not stack'd, malloc'd or (recently) free'd ==1793== pid 1793 (memcheck-amd64-free): sigreturn rflags = 0x4 ==1793== ==1793== Process terminating with default action of signal 10 (SIGBUS): dumping core ==1793== Hardware error at address 0x40F7A495F ==1793==at 0x227C9BE: llvm::ValueHandleBase::AddToUseList() (in /usr/obj/share/dim/src/freebsd/base/projects/clang400-import/usr.bin/clang/clang/clang.full) ==1793==by 0x29A3F2D: llvm::AssumptionCache::AffectedValueCallbackVH::allUsesReplacedWith(llvm::Value*) (in /usr/obj/share/dim/src/freebsd/base/projects/clang400-import/usr.bin/clang/clang/clang.full) ==1793==by 0x227A884: llvm::ValueHandleBase::ValueIsRAUWd(llvm::Value*, llvm::Value*) (in /usr/obj/share/dim/src/freebsd/base/projects/clang400-import/usr.bin/clang/clang/clang.full) ==1793==by 0x227A504: llvm::Value::doRAUW(llvm::Value*, bool) (in /usr/obj/share/dim/src/freebsd/base/projects/clang400-import/usr.bin/clang/clang/clang.full) ==1793==by 0x1C9791E: llvm::sroa::AllocaSliceRewriter::visitLoadInst(llvm::LoadInst&) (in /usr/obj/share/dim/src/freebsd/base/projects/clang400-import/usr.bin/clang/clang/clang.full) ==1793==by 0x1C880FD: llvm::sroa::AllocaSliceRewriter::visit((anonymous namespace)::Slice const*) (in /usr/obj/share/dim/src/freebsd/base/projects/clang400-import/usr.bin/clang/clang/clang.full) ==1793==by 0x1C86C9A: llvm::SROA::rewritePartition(llvm::AllocaInst&, llvm::sroa::AllocaSlices&, llvm::sroa::Partition&) (in /usr/obj/share/dim/src/freebsd/base/projects/clang400-import/usr.bin/clang/clang/clang.full) ==1793==by 0x1C88584: llvm::SROA::splitAlloca(llvm::AllocaInst&, llvm::sroa::AllocaSlices&) (in /usr/obj/share/dim/src/freebsd/base/projects/clang400-import/usr.bin/clang/clang/clang.full) ==1793==by 0x1C89A1D: llvm::SROA::runOnAlloca(llvm::AllocaInst&) (in /usr/obj/share/dim/src/freebsd/base/projects/clang400-import/usr.bin/clang/clang/clang.full) ==1793==by 0x1C8B309: llvm::SROA::runImpl(llvm::Function&, llvm::DominatorTree&, llvm::AssumptionCache&) (in /usr/
[Bug 216117] clang 4.0.0 crashes trying to build lld on i386
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216117 Ed Maste changed: What|Removed |Added CC||ema...@freebsd.org Summary|devel/llvm39: clang crashes |clang 4.0.0 crashes trying |trying to build lld on i386 |to build lld on i386 -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
[Bug 216117] devel/llvm39: clang crashes trying to build lld on i386
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216117 Jan Beich (mail not working) changed: What|Removed |Added Attachment #178924|application/x-shellscript |text/plain mime type|| -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
[Bug 216117] devel/llvm39: clang crashes trying to build lld on i386
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216117 --- Comment #3 from Jan Beich (mail not working) --- Created attachment 178924 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=178924&action=edit OutputSections-8d5025.sh -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
[Bug 216117] devel/llvm39: clang crashes trying to build lld on i386
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216117 --- Comment #2 from Jan Beich (mail not working) --- Created attachment 178923 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=178923&action=edit OutputSections-8d5025.cpp (compressed) -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
[Bug 216117] devel/llvm39: clang crashes trying to build lld on i386
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216117 Jan Beich (mail not working) changed: What|Removed |Added Version|Latest |CURRENT Product|Ports & Packages|Base System Flags|maintainer-feedback?(brooks | |@FreeBSD.org) | Assignee|bro...@freebsd.org |freebsd-toolchain@FreeBSD.o ||rg Component|Individual Port(s) |bin --- Comment #1 from Jan Beich (mail not working) --- Oops, this is for /projects/clang400-import@312229. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: qemu-arm-static appears to have problems with signal delivery during (at least) poudrirer-devel based cross builds of some ports with ALLOW_MAKE_JOBS=yes
On 2017-Jan-14, at 10:53 PM, Mark Millard wrote:
> [Context: head (12) -r312009 and ports head -r431413.]
>
> I've been experimenting on amd64 with poudriere-devel with -x
> for -a arm.armv6 and I ran into:
>
>> TCG temporary leak before 00021826
>> qemu: uncaught target signal 4 (Illegal instruction) - core dumped
>
> in 3 of the 31 ports for the build, but 4 skipped so 3 of 27
> attempted. The 00021826 is the same number in all the examples
> so far (whatever its base).
>
> These seem to be the only TCG messages and each failure starts with
> one and then reports the qemu message. (Also true for the below.)
> As far as I can tell the TCG notice is the report of an internal
> qemu problem that is then translated into an Illegal instruction.
>
> This was with ALLOW_MAKE_JOBS=yes but -J 1 for poudriere.
>
> For 2 of the problem ports retries worked, still using
> ALLOW_MAKE_JOBS=yes and -J 1 .
>
> But the 3rd port failed each time tried with ALLOW_MAKE_JOBS=yes
> --but in a different step each time.
>
> In all failure cases it was gmake that got the "illegal instruction".
>
> But disabling ALLOW_MAKE_JOBS=yes appears (so far) to avoid the
> issue. For example, that 3rd failing port built fine. (I've
> been doing more ports since, with ALLOW_MAKE_JOBS=yes repeatedly
> failing and lack of it working.)
>
> My guess is SIGCHLD delivery sometimes touches something (or a timing)
> that is not handled well in qemu-arm-static. I've had not problems
> on an rpi2 or bpim3 in the past.
>
> (I have seen some analogous "soemtimes" issues on powerpc under
> and version of lang that mishandled the stack part of the ABI
> FreeBSD uses, SIGCHLD sometimes getting on the stack at a bad-time
> for the messed up code generation, leading to stack corruption. Code
> not getting signals had no problems.)
>
> Note: The amd64 context is FreeBSD under VirtualBox under macOS
> and it has had no problem for native builds of world, kernel,
> or ports.
Avoiding ALLOW_MAKE_JOBS=yes is not sufficient to guarantee builds
will work. Here is one that got near the end before failing the
same way:
. . .
install -m 0644
/wrkdirs/usr/ports/devel/arm-none-eabi-gcc/work/gcc-6.3.0/gcc/cp/type-utils.h
/wrkdirs/usr/ports/devel/arm-none-eabi-gcc/work/stage/usr/local/lib/gcc/arm-none-eabi/6.3.0/plugin/include/cp/type-utils.h
install: DONTSTRIP set - will not strip installed binaries
TCG temporary leak before 00021826
qemu: uncaught target signal 4 (Illegal instruction) - core dumped
gmake[1]: *** [Makefile:4176: install-gcc] Illegal instruction
gmake[1]: Leaving directory
'/wrkdirs/usr/ports/devel/arm-none-eabi-gcc/work/.build'
*** Error code 2
Stop.
make: stopped in /usr/ports/devel/arm-none-eabi-gcc
>> Cleaning up wrkdir
===> Cleaning for arm-none-eabi-gcc-6.3.0
build of devel/arm-none-eabi-gcc ended at Sun Jan 15 00:04:02 PST 2017
build time: 02:52:28
!!! build failure encountered !!!
Going back to the earlier initial problem (that I happen to have the
material for handy): expanding the .tbz of the failed build and finding
the core showed:
# find . -name "*.core" -exec file {} \;
./work/binutils-2.27/ld/qemu_gmake.core: ELF 32-bit LSB
core file ARM, version 1 (FreeBSD), FreeBSD-style, from 'ke'
[I've not figured out what I can do with that --or how.]
One thing unusual on my part is that I use -mcpu=cortex-a7 . That
matches how I historically buildworld buildkernel for installation
on the rpi2 and bpim3. I've never had problems like this with
builds on the rpi2 or the bpim3 (buildworld, buildkernel, port
builds). It might be that qemu-arm-static has a problem with
-mcpu=cortex-a7 code that is generated --but not always.
Using the make.conf as an example:
# more /usr/local/etc/poudriere.d/head-cortex-a7-make.conf
WANT_QT_VERBOSE_CONFIGURE=1
#
DEFAULT_VERSIONS+=perl5=5.24
WITH_DEBUG=
WITH_DEBUG_FILES=
MALLOC_PRODUCTION=
#
#system clang 3.8+ (gcc6 rejects -march=armv7a):
#CFLAGS+= -march=armv7-a -mcpu=cortex-a7
#CXXFLAGS+= -march=armv7-a -mcpu=cortex-a7
#CPPFLAGS+= -march=armv7-a -mcpu=cortex-a7
#
#lang/gcc6's xgcc stage considers the above conflicting so use just:
CFLAGS+= -mcpu=cortex-a7
CXXFLAGS+= -mcpu=cortex-a7
CPPFLAGS+= -mcpu=cortex-a7
For my context poudriere with -x for -a arm.armv6 and the use of
qemu-arm-static does not look reliable enough to depend on. It is
not obvious that the -x use contributes to the problem: it may well
not.
===
Mark Millard
markmi at dsl-only.net
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
[Bug 216080] science/bddsolve: fails to build with libc++ 4.0
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216080 --- Comment #4 from Ed Schouten --- Because the good() member function isn't the exact opposite of the fail() member function. See the table at the bottom of this page: http://en.cppreference.com/w/cpp/io/basic_ios/fail Changing it to use good() alters the code's behaviour. -- You are receiving this mail because: You are on the CC list for the bug. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
[Bug 216080] science/bddsolve: fails to build with libc++ 4.0
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216080
Jan Beich (mail not working) changed:
What|Removed |Added
CC||freebsd-toolchain@FreeBSD.o
||rg
--- Comment #3 from Jan Beich (mail not working) ---
> bool exists_file(const std::string& filename)
> {
>std::ifstream from(filename.c_str());
> - return (from);
> + return !from.fail();
Why not "return from.good()" instead similar to textproc/libxml++26 upstream
fix? Otherwise, ask toolchain@ whether to convert or not. I don't know much
C++.
--
You are receiving this mail because:
You are on the CC list for the bug.
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
