similar to: [LLVMdev] Trunk fails to compile on PPC64 Linux

İsmail, No, but sometimes these problems can be very sensitive to different system factors. Can you file a bug report (and cc me), and include assembly file so that we can see what might be the problem. Thanks again, Hal ----- Original Message ----- > > > Hi, > > > For the last 3 days or so trunk fails to compile on PPC64/Linux with: > [16257s]

I'm using a recent revision of TOT (280704) to build clang/LLVM for PowerPC64 little endian. I'm getting an assembler error when building PPCInstPrinter.cpp: The error is: /tmp/PPCInstPrinter-84c835.s: Assembler messages: /tmp/PPCInstPrinter-84c835.s:7671: Error: operand out of range (0x0000000000008004 is not between 0xffffffffffff8000 and 0x0000000000007ffc) The offending line is

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

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:

----- 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, 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

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

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 >

Hi, On Wed, Mar 26, 2014 at 4:19 PM, Hal Finkel <hfinkel at anl.gov> wrote: > > Okay, interesting. I also did a build with -mcpu=ppc64 and did not observe > these issues. What standard C++ library are you building against? > I disabled assertions and the number of failures halved but Debuginfo failures looks very weird. Don't know if it helps to debug the issue at hand.

----- Original Message ----- > From: "Hal Finkel via llvm-dev" <llvm-dev at lists.llvm.org> > To: "Richard Pennington" <rich at pennware.com> > Cc: llvm-dev at lists.llvm.org > Sent: Wednesday, September 7, 2016 7:37:50 AM > Subject: Re: [llvm-dev] [PowerPC] Recent branch too far breakage > > Hi Rich, > > It is hard to tell, but there

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, On Wed, Mar 26, 2014 at 6:27 PM, Krzysztof Parzyszek < kparzysz at codeaurora.org> wrote: > On 3/26/2014 8:04 AM, İsmail Dönmez wrote: > >> >> Recent trunk has a lot of failures on PPC64/Linux. One seems to be crash >> with a backtrace like: >> > > Is this with "make check"? I can try it on my G5/FreeBSD box when I get > home make

Hi, Its that time of the year again. Here is the results on openSUSE 13.1 PPC64. Total of 3 failures which seems to be due the same problem (the value in brackets is the time counter from the build system): [ 3468s] /home/abuild/rpmbuild/BUILD/llvm/test/CodeGen/PowerPC/ppc32-vacopy.ll:21:10: error: expected string not found in input [ 3468s] ; CHECK: lwz [[REG3:[0-9]+]], {{.*}} [ 3468s]

After some head scratching and debugging it turns out that disabling shared libs fixes the problem. This might be related to http://llvm.org/bugs/show_bug.cgi?id=13124 . It would be nice to get this finally fixed otherwise cmake + shared libs is no go. Thanks. On Mon, Aug 5, 2013 at 11:54 AM, İsmail Dönmez <ismail at donmez.ws> wrote: > Hi, > > I am building llvm 3.3 with cmake

İsmai, Thanks for testing these. Can you please file a bug report (and CC me on it), and attach the full output of these failing tests? (When the test fails you should see the full command -- rerun it without piping the output into FileCheck). Thanks again, Hal ----- Original Message ----- > From: "İsmail Dönmez" <ismail at donmez.ws> > To: "LLVM Developers Mailing

On Thu, Nov 21, 2013 at 10:59 AM, Kostya Serebryany <kcc at google.com> wrote: > +eugenis > (we are dealing with it: primarily we are trying to get hold of some PPC > machine to verify our fix) > > I have a PPC64 machine handy and can test a patch. -------------- next part -------------- An HTML attachment was scrubbed... URL:

Hi, This I believe is a bug in kernel headers on openSUSE PPC64 but maybe there is some workaround. compiler-rt/lib/sanitizer_common/sanitizer_platform_limits_linux.cc includes asm/stat.h which ends up with errors: /usr/include/asm/stat.h:31:2: error: unknown type name 'ino_t' ino_t st_ino; ^ /usr/include/asm/stat.h:34:2: error: unknown type name

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