Displaying 20 results from an estimated 3000 matches similar to: "[LLVMdev] cmake build system doesn't produce libLLVM-<major>.<minor>.so"
2014 May 12
2
[LLVMdev] Lots of regtest failures on PPC64/Linux
----- 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
2014 May 12
2
[LLVMdev] Build failure with libcxx
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
2013 Nov 22
3
[LLVMdev] [3.4 branch] SystemZ regressions
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
2014 Jun 04
2
[LLVMdev] Lots of regtest failures on PPC64/Linux
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
2014 Apr 01
2
[LLVMdev] Lots of regtest failures on PPC64/Linux
Hi,
On Tue, Apr 1, 2014 at 3:26 PM, Hal Finkel <hfinkel at anl.gov> wrote:
> İsmail,
>
> I still don't see these errors locally. Can you try with an autoconf-based
> build and see if they're somehow related to (triggered by) the way that
> cmake builds LLVM?
>
>
On the same machine autoconf build is fine where as cmake has failures,
reproduced simply with
2014 Mar 26
3
[LLVMdev] Lots of regtest failures on PPC64/Linux
Hi,
On Wed, Mar 26, 2014 at 3:26 PM, Hal Finkel <hfinkel at anl.gov> wrote:
> ----- 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: Wednesday, March 26, 2014 8:20:31 AM
>
2014 Mar 26
3
[LLVMdev] Lots of regtest failures on PPC64/Linux
----- 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
2013 Nov 26
0
[LLVMdev] [3.4 branch] SystemZ regressions
İ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
2014 Mar 26
2
[LLVMdev] Lots of regtest failures on PPC64/Linux
Hi Hal,
On Wed, Mar 26, 2014 at 3:17 PM, Hal Finkel <hfinkel at anl.gov> wrote:
> İsmail,
>
> These are self-hosted builds? It seems like a lot of crashes in
> llvm::sys::AtomicIncrement.
Yes. stage1 clang is used in stage2.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
2013 May 13
2
[LLVMdev] ASan unit test/libcxx build break
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
2014 Dec 12
2
[LLVMdev] [cfe-dev] Phabricator update
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
>
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
2017 Aug 02
2
ubsan no longer compiles when libc++ is the default
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
2012 Apr 24
0
[LLVMdev] compiler_rt fails to build in release_31 branch
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
2013 May 13
0
[LLVMdev] ASan unit test/libcxx build break
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
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: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
2013 Oct 08
2
[LLVMdev] basic-arm-instruction tests fail on trunk
Hi,
On Tue, Oct 8, 2013 at 4:07 PM, Renato Golin <renato.golin at linaro.org>wrote:
> On 8 October 2013 14:01, İsmail Dönmez <ismail at donmez.ws> wrote:
>
>> I was using a 1 week old clang to boostrap, switched to gcc and the bug
>> gone away. Now I'll boostrap again with the new clang to see if the
>> regression is there or not.
>>
>
> Are
2013 Oct 08
2
[LLVMdev] basic-arm-instruction tests fail on trunk
Hi Renato,
On Tue, Oct 8, 2013 at 3:57 PM, Renato Golin <renato.golin at linaro.org>wrote:
> On 7 October 2013 18:33, İsmail Dönmez <ismail at donmez.ws> wrote:
>
>> This is with Linux on BeagleBone Black (Cortex-A8), regressed recently:
>>
>
> Hi Ismail,
>
> Are you running this regularly? Do you know which commit regressed? Or at
> least a window?
2015 Jan 30
2
[LLVMdev] ARM regression between r223766 and r223925
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