similar to: ../../../Makefile.common:60:../../../Makefile.config:don't have that file or directory

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

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 |

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

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:

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

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

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

On Thursday, December 08, 2011 02:46:39 AM Csaba Raduly wrote: > On Wed, Dec 7, 2011 at 9:43 PM, Richard Pennington wrote: > > I compiled a program and standard library using clang/LLVM and found the > > results interesting: > > > > text data bss dec hex filename > > 141312 4076 16668 162056 27908 bzip2.arm > > 131764 4076

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

I compiled a program and standard library using clang/LLVM and found the results interesting: text data bss dec hex filename 141312 4076 16668 162056 27908 bzip2.arm 131764 4076 16668 152508 253bc bzip2.armv7 134748 4048 16624 155420 25f1c bzip2.i386 259112 4028 16732 279872 44540 bzip2.microblaze 168044 4040 16816 188900 2e1e4

On 11.01.2011, at 12:02, Csaba Raduly wrote: > 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) […] > bool<unnamed>::LoopRotate::rotateLoop(llvm::Loop*): Assertion `DidIt >

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