similar to: [LLVMdev] Test failure

On Tue, Nov 28, 2017 at 12:16 AM, Kostya Serebryany <kcc at google.com> wrote: > +dvyukov > > On Mon, Nov 27, 2017 at 4:56 AM, Csaba Raduly via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> >> Hi all, >> >> I'm trying to build clang on Ubuntu 17.10 - the build succeeds, but >> testing fails: >> >> ~/wk/LLVM/build_release$

I guess there is lots of stuff that you don't care about besides tsan/go that is built and tested during llvm build, and there is no way to selectively disable each one of that. By design. In the long run we need to fix all failures (please file a proper bug). If you are looking for a temporal workaround, then comment it out. I don't what else to suggest. On Tue, Nov 28, 2017 at 9:47 AM,

Hi all, I'm trying to build clang on Ubuntu 17.10 - the build succeeds, but testing fails: ~/wk/LLVM/build_release$ svn info ../llvm/ Path: /home/csabaraduly/wk/LLVM/llvm Working Copy Root Path: /home/csabaraduly/wk/LLVM/llvm URL: https://llvm.org/svn/llvm-project/llvm/trunk Relative URL: ^/llvm/trunk Repository Root: https://llvm.org/svn/llvm-project Repository UUID:

Hi, Two days ago, the test suite started failing. Initially there were hundreds of failing tests; now only seven remain. They appear to be related to SystemZ. Here's the last failed test: ******************** FAIL: LLVM :: MC/Disassembler/SystemZ/unmapped.txt (11484 of 14435) ******************** TEST 'LLVM :: MC/Disassembler/SystemZ/unmapped.txt' FAILED ******************** Script:

On Thu, May 16, 2013 at 11:30 AM, Renato Golin <renato.golin at linaro.org> wrote: > On 16 May 2013 09:01, Csaba Raduly <rcsaba at gmail.com> wrote: >> >> "s390x--linux-gnu" seems wrong: either there's a dash too many or a >> word too few. > > > Nope, this triple is correct. The canonicalization of the triple (actually a > quadruple)

Hi all, LLVM+clang builds fine under Cygwin 1.7, but "make check-all" fails to run because lit doesn't find the freshly built clang. The reason is as follows: in llvm/utils/lit/lit/Util.py, in the "which" method, there's 66: # Get suffixes to search. 67: pathext = os.environ.get('PATHEXT', '').split(os.pathsep) The problem is, PATHEXT is imported

On Sat, Oct 22, 2011 at 12:24 AM, James Molloy wrote: > Hi Paul, > > That should be easy enough, because the LLVM build has no warnings in it! > > Some of us build with -Werror, and even with those of us that don't warnings are not tolerated. You're already seeing all the warnings that are coming out of the build :) So, all the "variable might be used

On Thu, Nov 14, 2013 at 4:40 AM, Mikael Lyngvig wrote: > Yes, ARM normally runs as a little-endian and it is a 32-bit CPU. It CAN be > configured to be a big-endian system, but that requires hardware support as > far as I know. > > I do have an old, slow Mac Mini G4 PowerPC (big-endian) that I could hook up > as a builder too. I was thinking of it the moment you mentioned big

On Thu, Oct 20, 2011 at 10:59 PM, monica j wrote: > The latest in my problems building clang-only: > > llvm[4]: Linking Debug+Asserts executable clang > /llvm/build/Debug+Asserts/lib/libclangLex.a: could not read symbols: File > format not recognized > collect2: ld returned 1 exit status What is the output of file /llvm/build/Debug+Asserts/lib/libclangLex.a ? Csaba -- GCS

On Wed, Apr 20, 2011 at 10:44 AM, Joe Armstrong wrote: > > It seems very strange to me that the ansi standard says "XXX is > undefined" and that both clang and gcc > can detect that something is undefined and that by default they > compile the offending code without > any feelings of guilt. "The good thing — the only good thing! — about undefined behavior in

Hi Anand On Wed, Feb 9, 2011 at 7:19 PM, Anand Arumugam wrote: > On Wed, Feb 9, 2011 at 9:40 AM, NAKAMURA Takumi wrote: >> >> Anand, >> >> >> I have not tried building llvm-gcc, though, ... >> >> Please show me "/path/to/config.status --version". > > [Anand] Here is the config.status output taken from '/cygdrive/c/llvm-2.8':

Yes, ARM normally runs as a little-endian and it is a 32-bit CPU. It CAN be configured to be a big-endian system, but that requires hardware support as far as I know. I do have an old, slow Mac Mini G4 PowerPC (big-endian) that I could hook up as a builder too. I was thinking of it the moment you mentioned big endian. I actually bought it for testing C++ code on because big-endian machines are

The latest in my problems building clang-only: llvm[4]: Linking Debug+Asserts executable clang /llvm/build/Debug+Asserts/lib/libclangLex.a: could not read symbols: File format not recognized collect2: ld returned 1 exit status Any suggestions appreciated. -------------- next part -------------- An HTML attachment was scrubbed... URL:

I wouldn't say that. I know quite a few systems here around that even try to avoid python where possible. but cmake however, as a build system, is welcomed by all of us (working as a sysop in a unix environment). I'd also (as a non-llvm-dev but llvm-userdev) vote for NOT reinventing the wheel but to use the tool the fits you the best, personally that's even cmake, too. it has a well

******************** FAIL: LLVM :: tools/llvm-dwarfdump/X86/debug-names-find.s (38881 of 41794) ******************** TEST 'LLVM :: tools/llvm-dwarfdump/X86/debug-names-find.s' FAILED ******************** Script: -- /home/csabaraduly/wk/LLVM/build_release/bin/llvm-mc -triple x86_64-pc-linux /home/csabaraduly/wk/LLVM/llvm/test/tools/llvm-dwarfdump/X86/debug-names-find.s -filetype=obj -o

Hello Csaba, Thanks for the heads up. I am the one who wrote that test. I'll look into that shortly. Sorry about the trouble. pl On Mon, 16 Apr 2018 at 11:56, Csaba Raduly via llvm-dev < llvm-dev at lists.llvm.org> wrote: > ******************** > FAIL: LLVM :: tools/llvm-dwarfdump/X86/debug-names-find.s (38881 of 41794) > ******************** TEST 'LLVM :: >

r330121 should fix that. Let me know if you still run into any issues. cheers, pl On Mon, 16 Apr 2018 at 12:07, Pavel Labath <labath at google.com> wrote: > Hello Csaba, > Thanks for the heads up. I am the one who wrote that test. I'll look into > that shortly. Sorry about the trouble. > pl > On Mon, 16 Apr 2018 at 11:56, Csaba Raduly via llvm-dev < > llvm-dev at

For ignore-undefined-symbols.s, the simplest fix ought to be to have the llvm-mc RUN line take the source from <stdin>: # RUN: llvm-mc –filetype=obj –triple=x86_64-pc-linux %s –o %t.o –g becomes # RUN: llvm-mc –filetype=obj –triple=x86_64-pc-linux < %s –o %t.o –g But in this case, llvm-symbolizer still prints the file as $CWD/<stdin> which seems like its own separate bug. --paulr

On Wed, Feb 9, 2011 at 9:40 AM, NAKAMURA Takumi <geek4civic at gmail.com>wrote: > Anand, > > > I have not tried building llvm-gcc, though, ... > > Please show me "/path/to/config.status --version". > [Anand] Here is the config.status output taken from '/cygdrive/c/llvm-2.8': ./config.status --version llvm config.status 2.8 configured by

On 16 May 2013 09:01, Csaba Raduly <rcsaba at gmail.com> wrote: > "s390x--linux-gnu" seems wrong: either there's a dash too many or a > word too few. > Nope, this triple is correct. The canonicalization of the triple (actually a quadruple) always print all fields, empty or not. I'm not sure what's going on, though. How are you building this? Is your