[LLVMdev] Neon code generation problems Re: ARM regression between r223766 and r223925

[İsmail Dönmez]

As expected if I replace -mpfu=neon with -mfpu=vfpv3-d16 then all the
problems go away. This means.

1. I can't build libcxxabi unwinder because of assembly problems under !neon

2. Neon codepath is not tested by the build-bots

Regards,
ismail


On Sat, Dec 13, 2014 at 11:49 AM, İ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 ?
>
>
>
> 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