similar to: [LLVMdev] does llvm-gcc (4.2) build?

Displaying 20 results from an estimated 600 matches similar to: "[LLVMdev] does llvm-gcc (4.2) build?"

2008 Apr 21
0
[LLVMdev] does llvm-gcc (4.2) build?
On Mon, 21 Apr 2008, Gabor Greif wrote: > Hi all, > > can anybody confirm that llvm-gcc is broken? It builds for me on x86, darwin8 (svn rev: 50048). What are you using to configure it? Whenever I have had problems building llvm-gcc, I usually have to delete my install and obj dir, make clean llvm, and start over from the top. Its a pain, but it works usually. -Tanya > >
2008 Apr 21
1
[LLVMdev] does llvm-gcc (4.2) build?
On Apr 21, 10:59 pm, "Tanya M. Lattner" <to... at nondot.org> wrote: > On Mon, 21 Apr 2008, Gabor Greif wrote: > > Hi all, > > > can anybody confirm that llvm-gcc is broken? > > It builds for me on x86, darwin8 (svn rev: 50048). What are you using to > configure it? This is what gcc/config.log remembered: $ /Users/ggreif/llvm-gcc/gcc/configure
2007 Apr 01
3
[LLVMdev] trouble compiling llvm-gcc4 1.9
I'm having some trouble getting llvm-gcc4 to compile. It's unable to compile darwin-crt3.c. It's mentioning "Complex expression. Absolute segment assumed." but I'm not sure if that's a real error message. Has anyone run into this before? I'm running on a G4 apple 10.4.8, kernel version 8.6.0. I googled around and found a bug with the same error message:
2006 Dec 23
1
[LLVMdev] in Cygwin problems
Problem 2: Configure: ../src/configure --prefix=/tmp/llvm/install --disable-threads --disable-nls --disable-shared --enable-languages=c,c++ --disable-c-mbchar --program-prefix=llvm- $ make make[1]: Entering directory `/tmp/llvm3/llvm/build/libiberty' make[2]: Entering directory `/tmp/llvm3/llvm/build/libiberty/testsuite' make[2]: Nothing to be done for `all'. make[2]: Leaving
2006 Dec 22
0
[LLVMdev] in Cygwin problems
On Sat, 23 Dec 2006, Roman wrote: > How to solve this problem? Java isn't supported. Use --enable-languages=c,c++ -Chris > $ make > make[1]: Entering directory `/tmp/llvm3/llvm/build/libiberty' > make[2]: Entering directory `/tmp/llvm3/llvm/build/libiberty/testsuite' > make[2]: Nothing to be done for `all'. > make[2]: Leaving directory
2008 Apr 15
6
[LLVMdev] PATCH: Use size reduction -- wave2
Hi All, here comes the patch for the second wave of Use class size reduction. I have included all the machinery that is needed, and it is *active*. The User* inside of Use is even sometimes NULL, but the algorithm is able to recover it. If there is a non-null User* present, then I am asserting that it equals the computed value. I did not receive feedback for the algorithmic part yet, so I
2008 Apr 16
0
[LLVMdev] PATCH: Use size reduction -- wave2
Hi Gabor, Can you provide performance data for this? I'd like to know what affect these changes have on compile time. Thanks, Dan On Apr 15, 2008, at 3:32 PM, Gabor Greif wrote: > Hi All, > > here comes the patch for the second wave of Use class size reduction. > > I have included all the machinery that is needed, and it is > *active*. The User* inside of Use is even
2007 Jul 03
2
[LLVMdev] "bytecode" --> "bitcode"
I did this short experiment: ggreif at my [!297] cd /home/ggreif/llvm ggreif at my [!298] find . -name "*.cpp" | xargs grep bytecode | wc -l 143 I guess these are a quick prey for perl's in-place replace. But wait! There are more: ggreif at my [!299] find . -name "*.cpp" | xargs grep -i bytecode | wc -l 291 probably all of the rest is "Bytecode"
2006 Dec 22
5
[LLVMdev] in Cygwin problems
How to solve this problem? $ make make[1]: Entering directory `/tmp/llvm3/llvm/build/libiberty' make[2]: Entering directory `/tmp/llvm3/llvm/build/libiberty/testsuite' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/tmp/llvm3/llvm/build/libiberty/testsuite' make[1]: Leaving directory `/tmp/llvm3/llvm/build/libiberty' make[1]: Entering directory
2009 Nov 12
2
[LLVMdev] Bootstrap Failure
Hi all, There's been a recent bootstrap failure that might be covered up because of another failure. I just wanted to point this out so that people can take a look: -bw Here's the failure from our buildbot: Assertion failed: (DestReg == VirtReg && "Unknown load situation!"), function RewriteMBB, file /Volumes/Sandbox/Buildbot/llvm/build.llvm-
2008 Apr 04
3
[LLVMdev] PATCH: Use size reduction -- wave1
On Apr 4, 8:06 pm, heisenbug <ggr... at gmail.com> wrote: > On Apr 4, 7:51 pm, Török Edwin <edwinto... at gmail.com> wrote: > > > > > heisenbug wrote: > > > On Apr 3, 10:53 pm, Gabor Greif <ga... at mac.com> wrote: > > > ... > > > >>> 3) Make sure that make check and some reasonable subset of llvm-test > > >>>
2007 Jul 11
2
[LLVMdev] PATCH: regarding PR1546
I do not consider PR1546 closed just yet. What I mentioned in the PR was only two of ca. 140 Solaris failures. Most of them complain that llc cannot choose between C and MSIL output formats. The below prototypical patch corrects this type of failure. Is this the right way of handling it? Why does llc only fail on Solaris and not on Darwin? After I understood this problem I am happy to commit
2008 Apr 04
0
[LLVMdev] PATCH: Use size reduction -- wave1
On Fri, 4 Apr 2008, heisenbug wrote: >> point taken. thanks! > > > Whatever I try I get something like this: > > ggreif$ cd MultiSource/ > ggreif$ make > make[2]: *** No rule to make target `Output/be.bc', needed by `Output/ > burg.linked.rbc'. Stop. > make[1]: *** [Burg/.makeall] Error 2 > make: *** [Applications/.makeall] Error 2 This is the
2012 Jul 14
0
[LLVMdev] [llvm-commits] Dealing with a corrupted /proc/self/exe link
Chandler Carruth wrote: > On Fri, Jul 13, 2012 at 1:40 PM, Benjamin Kramer <benny.kra at gmail.com > <mailto:benny.kra at gmail.com>> wrote: > > > On 13.07.2012, at 21:39, Gabor Greif <gabor.greif at alcatel-lucent.com > <mailto:gabor.greif at alcatel-lucent.com>> wrote: > > > Benjamin Kramer wrote: > >> On 13.07.2012,
2012 Jul 13
2
[LLVMdev] [llvm-commits] Dealing with a corrupted /proc/self/exe link
Benjamin Kramer wrote: > On 13.07.2012, at 09:46, Gabor Greif <gabor.greif at alcatel-lucent.com> wrote: > >> Hi all, >> >> I am in charge of the controlled introduction of clang into >> our builds at my workplace. Since all our tools must run from >> a ClearCase view for automatic dependency tracking, we have been >> biten by a Linux bug, and
2012 Jul 13
0
[LLVMdev] [llvm-commits] Dealing with a corrupted /proc/self/exe link
On 13.07.2012, at 21:39, Gabor Greif <gabor.greif at alcatel-lucent.com> wrote: > Benjamin Kramer wrote: >> On 13.07.2012, at 09:46, Gabor Greif <gabor.greif at alcatel-lucent.com> wrote: >> >>> Hi all, >>> >>> I am in charge of the controlled introduction of clang into >>> our builds at my workplace. Since all our tools must run
2012 Jul 13
2
[LLVMdev] [llvm-commits] Dealing with a corrupted /proc/self/exe link
On Fri, Jul 13, 2012 at 1:40 PM, Benjamin Kramer <benny.kra at gmail.com>wrote: > > On 13.07.2012, at 21:39, Gabor Greif <gabor.greif at alcatel-lucent.com> > wrote: > > > Benjamin Kramer wrote: > >> On 13.07.2012, at 09:46, Gabor Greif <gabor.greif at alcatel-lucent.com> > wrote: > >> > >>> Hi all, > >>> >
2008 Apr 16
0
[LLVMdev] PATCH: Use size reduction -- wave2
> Unfortunately I had to introduce a new GlobalVariable::Create > mechanism (I hoped to have nailed all in wave 1, but life is cruel). > I will submit scripts for the easy conversion of external projects > like the last time. One request is to explicity explain the new mechanism so people don't have to read the diffs or extrapolate from the conversion scripts. Please send a
2014 Apr 22
2
[LLVMdev] [RFC] 3-bit Waymarking
On 4/22/14, Chris Lattner <clattner at apple.com> wrote: > > On Apr 22, 2014, at 7:28 AM, Gabor Greif <ggreif at gmail.com> wrote: > >> Hi devs, >> >> after my intentionally "playful" EuroLLVM presentation (*) I think it >> would be time to get serious about merging to ToT. But we should >> probably find out whether an optimized
2014 Apr 22
3
[LLVMdev] [RFC] 3-bit Waymarking
Hi devs, after my intentionally "playful" EuroLLVM presentation (*) I think it would be time to get serious about merging to ToT. But we should probably find out whether an optimized algorithm is desired at all. So I'd solicit comments from the code owners (Use.{h,cpp}) and anybody who is interested. For closer scrutiny, the code is here: