Displaying 7 results from an estimated 7 matches for "r223766".
2015 Jan 30
0
[LLVMdev] ARM regression between r223766 and r223925
...(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
2014 Dec 13
2
[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.
2015 Jan 30
2
[LLVMdev] ARM regression between r223766 and r223925
...s 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 compl...
2015 Jan 30
0
[LLVMdev] ARM regression between r223766 and r223925
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
2015 Jan 30
0
[LLVMdev] ARM regression between r223766 and r223925
On 30 January 2015 at 17:23, İsmail Dönmez <ismail at donmez.ws> wrote:
> 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
2015 Jan 30
2
[LLVMdev] ARM regression between r223766 and r223925
On Fri, Jan 30, 2015 at 7:27 PM, Renato Golin <renato.golin at linaro.org> wrote:
> On 30 January 2015 at 17:23, İsmail Dönmez <ismail at donmez.ws> wrote:
>> 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
2015 Jan 30
2
[LLVMdev] ARM regression between r223766 and r223925
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