Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 23 Sep 2014 11:58:49 +0200
From:      Dimitry Andric <dim@FreeBSD.org>
To:        Pasi Parviainen <pasi.parviainen@iki.fi>
Cc:        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>