similar to: [LLVMdev] Minor warning reduction in lib/CodeGen/SpillPlacement.cpp

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

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

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

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

On Fri, Dec 24, 2010 at 10:32 AM, NAKAMURA Takumi wrote: > me2. I don't know why too slow. I know now. It was a debug build (enable-optimized=no) created only for trying out your patch on Util.py. Doh! -- GCS a+ e++ d- C++ ULS$ L+$ !E- W++ P+++$ w++$ tv+ b++ DI D++ 5++ Life is complex, with real and imaginary parts. "Ok, it boots. Which means it must be bug-free and perfect. "

On Wed, Apr 20, 2011 at 11:24 AM, Csaba Raduly <rcsaba at gmail.com> wrote: > 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

On 11/14/11, Alan Garny wrote: > For what is worth, I have been able to trace my problem (thanks Kevin Kelley > for the indirect help!). The 'culprit' was DLL Expert Viewer > (http://www.nirsoft.net/utils/dll_export_viewer.html). It kept reporting > that there were no exported functions, so I (wrongly) assumed that something > had gone wrong while, using PEInfo >

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

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

On Mon, Jun 18, 2012 at 11:46 AM, Chandler Carruth wrote: > On Mon, Jun 18, 2012 at 2:32 AM, Mikael Lyngvig wrote: >> >> Hi, >> >> The docs state that you can do a "make update" to update all top-level and >> embedded projects from Subversion. > > > This is a feature of the configure+make build system, and not a feature of > the CMake build

Hi, I haven't seen those errors. Clang and LLVM both build with no warnings on the 3 versions of GCC I test with. MSVC reports loads of warnings however. Cheers, James ________________________________________ From: Csaba Raduly [rcsaba at gmail.com] Sent: 23 October 2011 18:44 To: James Molloy Cc: Paul Berube; llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] build warnings On Sat, Oct 22,

In llvm/lib/MC/MachObjectWriter.cpp, there's assert(OS.tell() - Start == is64Bit() ? macho::Header64Size : macho::Header32Size); Shouldn't that be assert(OS.tell() - Start == (is64Bit() ? macho::Header64Size : macho::Header32Size)); MSVC emits a warning, and it doesn't seem right to compare a boolean with a difference of two integers. Csaba -- GCS a+

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 Yuri! On Sat, Jun 11, 2011 at 5:49 PM, Yuri wrote: > This page says that llvm works on MinGW: > http://llvm.org/docs/GettingStarted.html > I tried to build llvm trunk. llvm build now requires Python: > llvm[2]: Creating 'llvm-lit' script... > /bin/sh: python: command not found > > And current stable python version (3.2) doesn't even build on MinGW (see >

On Wed, Sep 21, 2011 at 7:31 PM, Jim Grosbach wrote: > Why shouldn't they accept paths with spaces in them? *nix supports that, generally. So long as the paths are properly escaped in any input, things should work. If they don't, it's a bug. GNU Make doesn't handle embedded spaces: $ cat Makefile all: foo\ bar foo\ bar: foo\ bar.o $ ls foo bar.c Makefile $ make make: ***

Mac G4. The non-POD stuff was cleared out by Michael Spencer's refactoring of llmv-objdump. Thanks Michael! Now I just have to figure out how to get Debug+Asserts to build on Mac G4. Cheers, Joe Abbey Software Architect Arxan Technologies, Inc. 1305 Cumberland Ave, Ste 215 West Lafayette, IN 47906 W: 765-889-4756 x2 C: 765-464-9893 jabbey at arxan.com<mailto:jabbey at arxan.com>