similar to: [LLVMdev] PATCH: regarding PR1546

Hi all, can anybody confirm that llvm-gcc is broken? After following all the instructions, make gets stuck while: ggreif$ gmake gmake \ CFLAGS="-g -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute -fno-common " \ CONFIG_H="config.h auto-host.h

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

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

Hi all! I gave a shot at compiling core llvm with a Solaris 9 machine. The compiler is FSF gcc 3.4.6. I am building trunk in the release version. So far I did not run tests (no dejagnu installed). Here are my findings: 0) Configuring. I had to suppress the solaris tools by: env AR=/opt/gnu/bin/ar NM=/opt/gnu/bin/nm RANLIB=/opt/gnu/bin/ranlib STRIP=/opt/gnu/bin/strip ../llvm/configure

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

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"

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

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

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,

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

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

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

> 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

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

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:

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 > >>> passes with this patch :) > > >> I have never run llvm-test in the past. Is it just checking it

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 >>> passes with this patch :) >>> >> I have never run llvm-test in the past. Is it just checking it out and >> following a readme? >> > > > After

Gabor Greif <ggreif at gmail.com> wrote: > as of v3.3 the integrated assembler seems to work fine. > But it is not on by default. What is the obstacle for this last step? Well, it's support is not complete ... The integrated assembler supports all general-purpose instructions the compiler itself generates, but has only partial support for all the rest, in particular nearly no

On 03/07/2011 08:30 PM, Anton Korobeynikov wrote: > Hi David > >> I think the trouble with branches is the lockdown of the root repository >> directory. > Surely not (at the server) > >> git svn init --stdlayout https://<user>@llvm.org/svn/llvm-project/llvm \ >>

On Apr 16, 2:13 am, Dan Gohman <goh... at apple.com> wrote: > Hi Gabor, > > Can you provide performance data for this? I'd > like to know what affect these changes have on > compile time. Hi Dan, Unfortunately, no. I can feed you with some speculation, though, see below. The reason why I cannot do measurements (at the moment) is that - I have no experience with