llvm dev - Dec 2014 - [LLVMdev] ARM regression between r223766 and r223925

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 ?



On Thu, Dec 11, 2014 at 12:41 PM, Renato Golin <renato.golin at
linaro.org> wrote:
> On 11 December 2014 at 10:29, İsmail Dönmez <ismail at donmez.ws>
wrote:
>> #include <iostream>
>>
>> int main() {
>>     std::cout << "Hello World! << std::endl;
>> }
>
> Right, yes, that's what I tested and it "worked", but of
course, I
> hadn't use libc++.
>
> That should restrict to a handful of patches, and we probably need to
> include llvmdev at . :)
>
> cheers,
> --renato

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?

cheers,
--renato

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