similar to: [LLVMdev] ARM regression between r223766 and r223925

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.

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

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

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

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

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

Hi, On Thu, Nov 21, 2013 at 8:16 PM, Richard Sandiford < rsandifo at linux.vnet.ibm.com> wrote: > İsmail Dönmez <ismail at donmez.ws> writes: > > Using openSUSE 13.1 on s390x machine I get two new regressions with llvm > > 3.4rc1: > > Hmm, I don't see this locally. Just to rule out one possibility, > which compiler are you using to build? Do you see the

Ok looks like r207606 regressed this. CC'ing Niko. Niko, please see the messages below. This is on openSUSE 13.1 both on i586 and x86-64. Reverting r207606 fixes the second stage bootstrap. On Sun, May 11, 2014 at 10:19 PM, İsmail Dönmez <ismail at donmez.ws> wrote: > I did a diff -u broken.ii working.ii and the difference explains the > problem: > > @@ -36617,7 +36628,7

On Mon, May 13, 2013 at 11:03 AM, İsmail Dönmez <ismail at donmez.ws> wrote: > Hi, > > > On Mon, May 13, 2013 at 10:49 AM, Evgeniy Stepanov > <eugeni.stepanov at gmail.com> wrote: >> >> A recent change added defined(__linux__) condition to the code below. >> Now it says that on linux with --std=c++0x (or --std=c++11) the system >> stdlib.h header

İsmail Dönmez <ismail at donmez.ws> writes: > On Thu, Nov 21, 2013 at 8:16 PM, Richard Sandiford < > rsandifo at linux.vnet.ibm.com> wrote: >> İsmail Dönmez <ismail at donmez.ws> writes: >> > Using openSUSE 13.1 on s390x machine I get two new regressions with llvm >> > 3.4rc1: >> >> Hmm, I don't see this locally. Just to rule out one

On Fri Dec 12 2014 at 12:55:01 PM İsmail Dönmez <ismail at donmez.ws> wrote: > Hi, > > On Fri, Dec 12, 2014 at 12:05 PM, Manuel Klimek <klimek at google.com> wrote: > > Can you point me at an example? I've spot checked stuff and cannot see > > anything out of the ordinary... > > This is only visible in GMail for me but looks like Phabricator is now >

----- Original Message ----- > From: "İsmail Dönmez" <ismail at donmez.ws> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> > Sent: Monday, May 12, 2014 7:18:48 AM > Subject: Re: Lots of regtest failures on PPC64/Linux > > > Hi Hal, > > > > > > On

Hi, I see the following variables in the CMakeCache.txt: SANITIZER_CXX_ABI:STRING=default //STRINGS property for variable: SANITIZER_CXX_ABI SANITIZER_CXX_ABI-STRINGS:INTERNAL=none;default;libcxxabi;libstdc++ Regards, ismail On Tue, Aug 1, 2017 at 7:32 PM, Vedant Kumar <vsk at apple.com> wrote: > >> On Aug 1, 2017, at 7:07 AM, İsmail Dönmez via llvm-dev <llvm-dev at

----- Original Message ----- > From: "Renato Golin" <renato.golin at linaro.org> > To: "İsmail Dönmez" <ismail at donmez.ws> > Cc: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> > Sent: Wednesday, March 26, 2014 8:14:18 AM > Subject: Re: [LLVMdev] Lots of regtest failures on PPC64/Linux > > Hi Ismail, > > Is

missing-abstract-variable is a recent one I introduced - looking into it. On Wed, Jun 4, 2014 at 2:39 AM, İsmail Dönmez <ismail at donmez.ws> wrote: > Hi Hal, > > These tests failures go away when I disable static libs aka > -DBUILD_SHARED_LIBS=OFF , with that only 2 regtest failures are left: > > > [ 1314s] FAILED: cd /home/abuild/rpmbuild/BUILD/llvm/stage2/test

Hi, Recent trunk has a lot of failures on PPC64/Linux. One seems to be crash with a backtrace like: [ 3149s] -- [ 3149s] 0 libLLVMSupport.so 0x00003fff7ed0b864 llvm::sys::PrintStackTrace(_IO_FILE*) + 4294746876 [ 3149s] 1 libLLVMSupport.so 0x00003fff7ed0bb1c [ 3149s] 2 libLLVMSupport.so 0x00003fff7ed0c520 [ 3149s] 3 linux-vdso64.so.1 0x00003fff7f7b0478 __kernel_sigtramp_rt64 + 0 [ 3149s] 4

ping? Still fails on 3.1 branch. On Tue, Apr 17, 2012 at 5:35 PM, İsmail Dönmez <ismail at namtrac.org> wrote: > > Hi; > > This is on  Linux/x86-64, I get this at stage1: > > make[2]: Entering directory `/home/abuild/rpmbuild/BUILD/llvm/stage1/projects/compiler_rt' > Makefile:6: make/config.mk: No such file or directory > Makefile:7: make/util.mk: No such file or

Hi, On Mon, May 13, 2013 at 11:07 AM, Evgeniy Stepanov < eugeni.stepanov at gmail.com> wrote: > On Mon, May 13, 2013 at 11:03 AM, İsmail Dönmez <ismail at donmez.ws> wrote: > > I am guessing you are running on this on an old system. My glibc version > is > > 2.17 > > Yes. Ubuntu 12.04 LTS with glibc 2.15 does not have aligned_alloc. > Then I guess

You can use #if __GLIBC_PREREQ(2, 17) On Mon, May 13, 2013 at 1:13 PM, İsmail Dönmez <ismail at donmez.ws> wrote: > Hi, > > > On Mon, May 13, 2013 at 11:07 AM, Evgeniy Stepanov < > eugeni.stepanov at gmail.com> wrote: > >> On Mon, May 13, 2013 at 11:03 AM, İsmail Dönmez <ismail at donmez.ws> wrote: >> > I am guessing you are running on this on

Hi; This is on Linux/x86-64, I get this at stage1: make[2]: Entering directory `/home/abuild/rpmbuild/BUILD/llvm/stage1/projects/compiler_rt' Makefile:6: make/config.mk: No such file or directory Makefile:7: make/util.mk: No such file or directory Makefile:16: *** Refusing to build with empty ProjObjRoot variable. Stop. make[2]: Leaving directory