Displaying 4 results from an estimated 4 matches for "generaten".
Did you mean:
generate
2005 Aug 01
2
[LLVMdev] [patch] gccld not passing -export-dynamic to gcc for link
...e file from the specified bytecode file.
int llvm::GenerateCFile(const std::string &OutputFile,
const std::string &InputFile,
const sys::Path &llc,
@@ -344,7 +343,7 @@
return sys::Program::ExecuteAndWait(llc, &args[0]);
}
-/// GenerateNative - generates a native assembly language source file from the
+/// GenerateNative - generates a native executable file from the
/// specified assembly source file.
///
/// Inputs:
@@ -365,6 +364,7 @@
const std::vector<std::string> &Libraries,...
2005 Aug 02
0
[LLVMdev] [patch] gccld not passing -export-dynamic to gcc for link
...e file from the specified bytecode file.
int llvm::GenerateCFile(const std::string &OutputFile,
const std::string &InputFile,
const sys::Path &llc,
@@ -344,8 +343,8 @@
return sys::Program::ExecuteAndWait(llc, &args[0]);
}
-/// GenerateNative - generates a native assembly language source file from the
-/// specified assembly source file.
+/// GenerateNative - generates a native executable file from the specified
+/// assembly source file.
///
/// Inputs:
/// InputFilename - The name of the output bytecode file.
@@ -365,6 +364,...
2006 Feb 28
3
[LLVMdev] Using llvm-gcc with a simple program and the '-c' option
Chris Lattner wrote:
> On Sun, 26 Feb 2006, Wink Saville wrote:
>> I then do the following in my makefile:
>>
>> llvm-gcc -c t1.c -o t1.bc
>> llvm-gcc -c t1sub1.c -o t1sub1.bc
>> llvm-gcc -c t1sub2.c -o t1sub2.bc
>> llvm-ar r t1.a t1sub1.bc t1sub2.bc
>> llvm-ar: creating t1.a
>> llvm-ld -o t1.app t1.bc t1.a /opt/llvm-1.6/llvm-gcc/lib/libcrtend.a
2007 Jul 05
2
[LLVMdev] PATCH (rest of code changes) "bytecode" --> "bitcode"
Here is the bulk of the sanitizing.
My residual doubts center around the question
whether we still do/want to support (un)compressed *byte*code
in 2.0/2.1.
I need a definitive word on this to proceed.
My understanding is that bytecode is already gone, but there are
still some functions/enums that really deal with *byte*code
(instead of *bit*code).
I did not touch those areas, so the attached