[LLVMdev] ARM regression between r223766 and r223925
İsmail Dönmez
ismail at donmez.ws
Fri Jan 30 09:18:15 PST 2015
Hi,
On Fri, Jan 30, 2015 at 7:15 PM, Renato Golin <renato.golin at linaro.org> wrote:
> On 13 December 2014 at 09:49, İsmail Dönmez <ismail at donmez.ws> wrote:
>> With trunk things got even worse while compiling a simple hello world cpp:
>>
>> 1. /usr/lib/gcc/arm-linux-gnueabihf/4.9/../../../../include/c++/4.9/bits/basic_string.h:114:57:
>> current parser token 'other'
>> 2. /usr/lib/gcc/arm-linux-gnueabihf/4.9/../../../../include/c++/4.9/bits/basic_string.h:45:1:
>> parsing namespace 'std'
>> 3. /usr/lib/gcc/arm-linux-gnueabihf/4.9/../../../../include/c++/4.9/bits/basic_string.h:112:5:
>> parsing struct/union/class body 'basic_string'
>> clang-3.6: error: unable to execute command: Bus error
>>
>> and dmesg agrees:
>>
>> [ 96.272849] Alignment trap: not handling instruction f4400add at [<b4072ffc>]
>> [ 96.280467] Unhandled fault: alignment exception (0x801) at 0x01d7a8cc
>>
>> Might this be due to the fact that I now compile with -mfpu=neon ?
>
> Ismail,
>
> I'm really sorry for not looking into this when I should, you're
> absolutely correct. Here's the bug:
>
> http://llvm.org/bugs/show_bug.cgi?id=22375
>
> I'm self-hosting the release r223766 and found many Clang segfaults,
> though not *that* one. I went back (3000 commits) and found that
> spotting the *right* failure is near impossible... So, I'm wondering
> how did you come up with that range? Did you succeed in self-hosting
> 223766 with NEON?
My analysis was completely wrong because I had -no-integrated-as
sneaked in libcxxabi CMakeLists.txt and then somehow I reverted it
which showed me the initial failure. The Neon failure is completely
unrelated which I figured out after trying to bootstrap with
-mfpu=neon.
Sorry for not being helpful :/
ismail
More information about the llvm-dev
mailing list