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,
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:
22375 – Self-hosted Clang gets miscompiled on ARMv7 with NEON
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
No worries. Do you remember what version you saw the failure for the first time?
--renato
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
Right, I've already checked r223477 (5th Dec) to be green, so that
should do for the good end.
Since you reported on the 13th Dec that "trunk" was broken, I'm
assuming you checked out and built, which would put the bad side
earlier than the 14th Dec.
It's 9 days to look at, but at least it's better than 6 months I was
going for in the beginning...
thanks!
-renato
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.
Right, I've already checked r223477 (5th Dec) to be green, so that
should do for the good end.
Nice!
Since you reported on the 13th Dec that "trunk" was broken, I'm
assuming you checked out and built, which would put the bad side
earlier than the 14th Dec.
Indeed.
It's 9 days to look at, but at least it's better than 6 months I was
going for in the beginning...
Thanks for debugging this 
Hi Ismail,
Just FYI, we fixed this with r228129. Sorry for having taken so long
to actually look at this, but I'll be introducing a few new NEON
buildbots to make sure that will never happen again.
cheers,
--renato
Hah so my original suspect commit range was right! Thanks for fixing it, meanwhile I’ll continue my native and cross builds.
Regards,
İsmail