Date: Tue, 23 Sep 2014 11:58:49 +0200 From: Dimitry Andric <dim@FreeBSD.org> To: Pasi Parviainen <pasi.parviainen@iki.fi> Cc: Dmitry Marakasov <amdmi3@amdmi3.ru>, freebsd-stable@FreeBSD.org, freebsd-toolchain@freebsd.org Subject: Re: clang (both 3.3 and 3.4) OOM crashes on HEAD Message-ID: <98949B82-4109-4628-BE4E-9817D5614D8A@FreeBSD.org> In-Reply-To: <542105A3.4090507@iki.fi> References: <20140228143606.GD29171@hades.panopticon> <E5857DB5-65CE-4A55-9DF4-B82B86EA7DBB@FreeBSD.org> <20140228154328.GA13454@hades.panopticon> <20140922231016.GA1301@hades.panopticon> <542105A3.4090507@iki.fi>
next in thread | previous in thread | raw e-mail | index | archive | help
On 23 Sep 2014, at 07:31, Pasi Parviainen <pasi.parviainen@iki.fi> = wrote: > On 23.9.2014 2:10, Dmitry Marakasov wrote: >> * Dmitry Marakasov (amdmi3@amdmi3.ru) wrote: >>>>> I've been getting some failure mails from pkg building cluster = related >>>>> to clang crashes: >>>>>=20 >>>>> = http://beefy2.isc.freebsd.org/bulk/head-amd64-default/2014-02-28_01h43m56s= /logs/arx-libertatis-1.0.3_2.log >>>>> = http://beefy1.isc.freebsd.org/bulk/head-i386-default/2014-02-21_03h01m36s/= logs/supertuxkart-0.8.1.log ... >>> http://people.freebsd.org/~amdmi3/clang-eats-mem-bug.tar.bz2 >>>=20 >>> The bug is reproducible on my 10.x with both system clang 3.3 (after >>> removing -vectorize-loops -vectorize-slp options) and with clang 3.4 >>> from ports. >>=20 >> I'll just remind that this is still an issue, and it's getting into >> 10.1. Could we maybe disable compiler features with lead to these >> crashes? >>=20 >=20 > This seems to be same issue as in = http://llvm.org/bugs/show_bug.cgi?id=3D20893 for which there is patch = review going = onhttp://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20140922/236= 415.html. >=20 > Your test case is reproducible with the trunk of llvm/clang and the = patch in review resolves it. Other workaround is to disable generation = of debug information by removing -g flag. Hm, I had assumed this problem was fixed by importing r203311 from upstream llvm trunk, in head r263313. But apparently it is not. The upstream patch seems to fix your specific test case, but it is still in review, so I prefer to wait until it is actually committed, before I import it. -Dimitry
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?98949B82-4109-4628-BE4E-9817D5614D8A>