similar to: [LLVMdev] LLVM on Cygwin: why tests don't run

Good evening, Csaba! I think rather, Cygwin does not need to know what PATHEXT would be. A patch(0001) is attached. Another patch is for unittests. Lit does not find *Tests.exe in unittests on ToT. 2010/12/24 Csaba Raduly <rcsaba at gmail.com>: > P.S. > With the above change, "make check-all" starts to run. Estimated run > time: 40 hours on my 1.8GHz single-core

Hi, For a couple of days now, one of the tests fails: FAIL: LLVM :: MC/R600/sopp.s (16225 of 19902) ******************** TEST 'LLVM :: MC/R600/sopp.s' FAILED ******************** Script: -- /home/csabaraduly/workspace/LLVM/build/Release+Asserts/bin/llvm-mc -arch=r600 -mcpu=SI -show-encoding /home/csabaraduly/workspace/LLVM/llvm/test/MC/R600/sopp.s |

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

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)

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

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

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

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:

> So... Are 40 and 41 the only legal behaviors or are there more? Since the program invokes undefined behavior, anything goes. The compiler is perfectly within its rights to send a rude email to your department chair if you compile that code. John

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

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

lit.py: ~/workspace/LLVM/llvm/tools/clang/test/lit.cfg:200: note: using clang: '~/workspace/LLVM/ninjacmake/./bin/clang' -- Testing: 37268 tests, 8 threads -- Testing: 0 .. FAIL: Builtins-i386-linux :: divsc3_test.c (4326 of 37268) ******************** TEST 'Builtins-i386-linux :: divsc3_test.c' FAILED ******************** Script: -- ~/workspace/LLVM/ninjacmake/./bin/clang

I installed LLVM3.7.0 according to the LLVM document. I can use "clang","LLVM-dis"commands ,and so on. but when I execute commad "make" at llvm/lib/Transform/Hello directory, the error is : ../../../Makefile.common:60:../../../Makefile.config:don't have that file or directory ../../../Makefile.common:68:../../../Makefile.rules:don't have that file or

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

Any input on this? I cleaned up the whole directory and re-build. still get the error. I am builing on x86. downloaded clang from llvm.org. Should I pick up an older version? 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 file

clang version 2.9 (trunk 123166) Target: x86_64-unknown-linux-gnu Thread model: posix Fails to compile ctags 5.8 (also 5.6), specifically eiffel.c: $ clang -v -c e.c -O2 -Wno-unused-value clang version 2.9 (trunk 123166) Target: x86_64-unknown-linux-gnu Thread model: posix "/home/csaba/bin/clang" -cc1 -triple x86_64-unknown-linux-gnu -emit-obj -disable-free -main-file-name e.c

This code is undefined, meaning that all bets are off, don't do it. I.e. It reads the value of I between two sequence points and uses it for something other than determining the value written. From: Csaba Raduly Sent: Tuesday, April 19, 2011 3:44 AM To: Joe Armstrong Cc: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] Is this a bug in clang? Hi Joe On Tue, Apr 19, 2011 at 10:59 AM, Joe

~/workspace/LLVM/llvm/projects/compiler-rt/lib/tsan/rtl/tsan_report.cc: In function ‘const char* __tsan::ReportTypeString(__tsan::ReportType, __sanitizer::uptr)’: ~/workspace/LLVM/llvm/projects/compiler-rt/lib/tsan/rtl/tsan_report.cc:95:41: warning: ISO C++ does not allow ?: with omitted middle operand [-Wpedantic] return GetReportHeaderFromTag(tag) ?: "race on external object";

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