llvm dev - Jan 2015 - [LLVMdev] ARM regression between r223766 and r223925

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

On 30 January 2015 at 17:18, İsmail Dönmez <ismail at donmez.ws>
wrote:
> 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.
No worries. Do you remember what version you saw the failure for the first time?

--renato

On Fri, Jan 30, 2015 at 7:20 PM, Renato Golin <renato.golin at linaro.org>
wrote:
> On 30 January 2015 at 17:18, İsmail Dönmez <ismail at donmez.ws>
wrote:
>> 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.
>
> No worries. Do you remember what version you saw the failure for the first
time?
No idea because I already had workarounded the original issue with
-no-integrated-as. BUT my build script log shows that I successfully
cross-compiled with NEON on December 4 2014. I usually do basic
testing of those builds on ARMv7. So, I suggest trying to bootstrap
r223339  with NEON. Thats the last commit for Dec 3.

ismail