similar to: [LLVMdev] Internalize or build broken?

On Tue, 18 Oct 2005, Robert L. Bocchino Jr. wrote: > I just updated my tree, and when I do a clean rebuild, I get errors like > this: > > WARNING: Internalize couldn't load file '/comp_genericeh.lst'! > WARNING: Internalize couldn't load file '/comp_main.lst'! > WARNING: Internalize couldn't load file '/comp_sjljeh.lst'! > WARNING:

I also updated the code and did a clean build with VS. I get the following error: \llvm\include\llvm\Transforms\LinkAllPasses.h(79) : error C2660: 'llvm::createInternalizePass' : function does not take 0 arguments Is this also related? Wayne At 02:45 PM 10/18/2005, you wrote: >On Tue, 18 Oct 2005, Robert L. Bocchino Jr. wrote: >>I just updated my tree, and when I do a clean

grumble, grumble, MS does not have llabs() llabs() is not defined in Visual Studio, however, _abs64() is. But if I switch to _abs64() the linker does not resolve __abs64(). I thought _abs64() was suppose to be in the CRT library. Any hints for a solution? c:\devwl\llvm\lib\CodeGen\SelectionDAG\DAGCombiner.cpp(295) : error C3861: 'llabs': identifier not found, even with argument-dependent

Hi Jeff and others, When building the llvm runtime, I always get this error message: 'Can't destroy file: The process cannot access the file because it is being used by another process.' The file is destoyed anyway. I think that the the real error is the path for the file (*/\file.tmp). However, I can't find the bug in the source. Do you have any clue?:

It looks like what you're getting is a sharing violation. Although, I don't understand why. The llvm-ar.exe when its building an archive file always builds it in a temporary. Only when that is complete does it remove the old one and rename the temporary. Perhaps this is a result of doing parallel build and the "lib3.tmp" file (that name looks wrong to me) is being accessed by

Hi Reid, I don't think I've initiated a parallel build by this command: ------------------------ make TOOLLINKOPTSB+=-ldbghelp TOOLLINKOPTSB+=-lpsapi LDFLAGS+='-Wl,--no-keep-memory' -r VERBOSE=1 ------------------------ Henrik. >From: Reid Spencer Date: Wed, 26 Jan 2005 12:05:51 -0800 > >It looks like what you're getting is a sharing violation. Although, I

Hi Chris, > Also note, LLVM 1.4 will be released in the next few days, so if waiting is > an option, you might choose to do so. Alright, I've got llvm and llvm-gcc from RELEASE_14 cvs and tried building it under cygwin. 1) The first problem is with llvm in SysUtils.c: int executeProgram(const char *filename, char *const argv[], char *const envp[]) { ................ execveTy

I'm another new person to LLVM. I can't successfully compile and execute a simple C++ program. The compiler seems to work, as it produces a.out and a.out.bc files, but I get a whole bunch of warnings: WARNING: Found global types that are not compatible: "struct.std::messages<wchar_t>"* %_ZN9__gnu_cxx10messages_cE [16 x sbyte]*

On Wed, 2004-08-18 at 22:14, Jeff Cohen wrote: > I'm another new person to LLVM. Hi Jeff. Welcome. > I can't successfully compile and > execute a simple C++ program. The compiler seems to work, as it > produces a.out and a.out.bc files, but I get a whole bunch of warnings: > > WARNING: Found global types that are not compatible: >

Hi, I'm changing bytecode format a little bit, i.e. for 2 operands Instructions, the original is like this: 01-00:Opcode type 07-02:Opcode 15-08: Instruction type 23-16: Operand#1 31-24: Operand#2 My change is like this: 01-00:Opcode type 07-02:Opcode 15-08: Instruction type 16: myflag1 17: myflag2 24-18: Operand#1 31-25: Operand#2 I do

>From: Reid Spencer Date: Wed, 26 Jan 2005 12:23:49 -0800 > >Nope, unless "make" is an alias for "make -j 4" (like I have) make is make for me. > >Could you try using TOOL_VERBOSE=1 with make to get more output ? I've attached an output. Henrik. >Did you try just running the llvm-ar command by itself ? >If not, could you and give it the V (capital

On Fri, May 27, 2016 at 3:43 AM, Umesh Kalappa via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi All , > > We are in process of exploring the LTO and found that internalize > pass is the replacement for whole program optimisation > (-fwhole-program in gcc) in clang and in the below case > > define i32 @test() #0 { > > entry: > > ret i32 0 >

Hi All , We are in process of exploring the LTO and found that internalize pass is the replacement for whole program optimisation (-fwhole-program in gcc) in clang and in the below case define i32 @test() #0 { entry: ret i32 0 } define i32 @main() #0 { entry: %retval = alloca i32, align 4 store i32 0, i32* %retval, align 4 %call = call i32 @test() ret i32 %call } ***

> On May 27, 2016, at 9:57 AM, Duncan P. N. Exon Smith via llvm-dev <llvm-dev at lists.llvm.org> wrote: > >> >> On 2016-May-27, at 05:55, Teresa Johnson via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> >> >> On Fri, May 27, 2016 at 3:43 AM, Umesh Kalappa via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> Hi All ,

> On 2016-May-27, at 05:55, Teresa Johnson via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > > > On Fri, May 27, 2016 at 3:43 AM, Umesh Kalappa via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Hi All , > > We are in process of exploring the LTO and found that internalize > pass is the replacement for whole program optimisation > (-fwhole-program

> On 2016-May-27, at 10:47, Mehdi Amini <mehdi.amini at apple.com> wrote: > >> >> On May 27, 2016, at 9:57 AM, Duncan P. N. Exon Smith via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >>> >>> On 2016-May-27, at 05:55, Teresa Johnson via llvm-dev <llvm-dev at lists.llvm.org> wrote: >>> >>> >>>

On Sep 30, 2009, at 12:06 AM, Talin wrote: > I'm playing around with different combinations of LTO passes, and > I've run into a strange problem: > > I have a 'main' function that looks like this: > > define i32 @"main(tart.core.Array[tart.core.String])- > >int"(%"tart.core.Array[tart.core.String]"* %args) { > entry: > call

Sounds like LLVM thinks the calling conventions or declarations are mismatched. See: http://llvm.org/docs/FAQ.html#callconvwrong Reid On Sat, Oct 3, 2009 at 1:16 AM, Talin <viridia at gmail.com> wrote: > Well, after some investigation I have a few more clues as to what is > going on. > > I have a module which contains a call to an external native function. > This native

Hi all, I was looking at the Internalize patch, and decided to clean it up a bit. The attached patch makes two functional changes to the pass: 1. If both -internalize-public-api-file and -internalize-public-api-list options are given on the commandline, only -file was used. Now, all options are respected and the contents of the file merged with the items given with the -list option(s). I

Well, after some investigation I have a few more clues as to what is going on. I have a module which contains a call to an external native function. This native function lives in a static library, and there is an external declaration for it in the module. I find that I can run "llvm-ld -disable-opts -native -l mylibrary test.bc" and it works fine. That is, llvm-ld is able to