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 ?

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:

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 :confused:

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... :confused:

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... :confused:

Thanks for debugging this :slight_smile:

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. :slight_smile:

cheers,
--renato

Hah so my original suspect commit range was right! :slight_smile: Thanks for fixing it, meanwhile I’ll continue my native and cross builds.

Regards,
İsmail