similar to: [LLVMdev] [cfe-dev] distcc implementation

greened at obbligato.org (David A. Greene) writes: >>> Oh, it's significant. When I build the Cray compiler with only non-LLVM >>> stuff changed, the actual compiles (the Cray stuff) finish before the >>> LLVM figures out nothing has changed. This is a sginificant >>> productivity loss. >> >> How is that? Your compiler builds in less than 3

On Fri, May 24, 2013 at 4:21 PM, Bill Wendling <wendling at apple.com> wrote: > On May 24, 2013, at 1:19 PM, Bill Wendling <wendling at apple.com> wrote: > >> Hi! >> >> The binaries for the 3.3 release candidate 2 are starting to role in. Please take them and give them a go. Please file bug reports for any problems you encounter. >> >> At this point,

On 25 May 2013 04:59, Jeffrey Walton <noloader at gmail.com> wrote: > 4 cd llvm-3.2.src/tools > 5 tar xvf ../../clang-3.2.src.tar.gz > 6 mv clang-3.2.src clang > 7 cd .. > You don't need to do any of it, there are already symlinks on the llvm.src dir to point to all others on the same root. Just unpack each source tar ball and be happy. ;) > 8 ./configure

On 6 Nov 2013, at 19:23, Renato Golin <renato.golin at linaro.org> wrote: > BUT, right now working off a release is painful because of the > integration cost of upgrading to a new release. APIs totally change, > new bugs have to be tracked down, performance regressions fixed, etc. > Integrating our changes is a lot of work but it's not the only hard > part. Dealing with

The sources were csupped ~3 hours ago. My CC is defined as follows: env CCACHE_PREFIX=/usr/local/bin/distcc /usr/local/bin/ccache cc I have done many buildworld, buildkernel and port builds with this setting and it never caused any problems. However today buildworld fails the following way: env CCACHE_PREFIX=/usr/local/bin/distcc /usr/local/bin/ccache env CCACHE_PREFIX=/usr/local/bin/distcc

On Sun, Dec 16, 2018 at 12:29 PM Nadav Amit <namit at vmware.com> wrote: > > > On Dec 15, 2018, at 6:50 PM, Masahiro Yamada <yamada.masahiro at socionext.com> wrote: > > > > Revert the following 9 commits: > > > > [1] 5bdcd510c2ac ("x86/jump-labels: Macrofy inline assembly code to > > work around GCC inlining bugs") > > >

On 6 November 2013 11:02, <dag at cray.com> wrote: > Except that there hasn't been warning at all. The only "warning" is > that "we're going to upgrade to some new toolchain." We need to know > *exactly* which toolchain that is so we can test all of our software > against it. "4.7.x" doesn't help because every point release has new

Richard Smith <richard at metafoo.co.uk> writes: > 1) Switch trunk to C++11 at time T. People whose toolchains aren't > ready stop integrating from LLVM trunk until they are ready. > 2) Switch trunk to C++11 at time T + an extra month. Again, people > whose toolchains aren't ready stop integrating from LLVM trunk until > they are ready. This flies completely in the

Richard Smith <richard at metafoo.co.uk> writes: > I'm objecting to 1 month for svn trunk - 2 months notice is even > pushing it imho. > > 1) This is imho not the small change which it's being presented as > 2) As someone else stated - there are projects tracking svn trunk > and telling them to just stop doing that and follow the previous

Óscar Fuentes <ofv at wanadoo.es> writes: > greened at obbligato.org (David A. Greene) writes: > >> Óscar Fuentes <ofv at wanadoo.es> writes: >> >>> A good measure of how fast a set of Makefile are is to run the build >>> with all targets up-to-date. Both builds takes a few seconds (3 or so) >>> on my Linux quad core box. Whatever

Josh, thanks for answering. I had xmms 1.2.10 . I removed it to see if flac would compile without xmms, and now I get this: gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I../.. -I./include -I../../include -DNDEBUG -funroll-loops -finline-functions -Wall -W -Winline -DFLaC__INLINE=__inline__ -O2 -mcpu=pentium2 -fomit-frame-pointer -c file_decoder.c -MT file_decoder.lo -MD -MP -MF .deps/file_decoder.TPlo

On 04/02/2012 05:41 AM, Patrick Edwards wrote: > Hi, my name is Patrick Edwards, and I'm currently a CS major at Kent > State University. I have always been interested in doing work with > compilers and LLVM seems to be a perfect fit for me to learn more over > the summer, and also contribute to open-source projects at the same > time. However, while browsing through the project

Hi: I downloaded klibc-1.5.17 and try to cross-compiled it for MIPS. Got following errors: usr/klibc/exit.o: In function `exit': exit.c:(.text+0x40): undefined reference to `_exit' usr/klibc/execl.o: In function `execl': execl.c:(.text+0x80): undefined reference to `execve' usr/klibc/execle.o: In function `execle': execle.c:(.text+0x84): undefined reference to `execve

+cfe-dev, +chandlerc On Mon, Apr 2, 2012 at 11:05 AM, Tobias Grosser <tobias at grosser.es> wrote: > On 04/02/2012 05:41 AM, Patrick Edwards wrote: >> >> Hi, my name is Patrick Edwards, and I'm currently a CS major at Kent >> State University. I have always been interested in doing work with >> compilers and LLVM seems to be a perfect fit for me to learn more

On 04/02/2012 11:21 AM, Manuel Klimek wrote: > +cfe-dev, +chandlerc > > On Mon, Apr 2, 2012 at 11:05 AM, Tobias Grosser<tobias at grosser.es> wrote: >> On 04/02/2012 05:41 AM, Patrick Edwards wrote: >>> >>> Hi, my name is Patrick Edwards, and I'm currently a CS major at Kent >>> State University. I have always been interested in doing work with

On Wed, Mar 27, 2013 at 3:57 PM, Michael Gottesman <mgottesman at apple.com>wrote: > 3. Later phases do broader, longer lasting testing than earlier phases. > Thus the 4 phases we currently have are: > > a. Phase 1 (sanity): Phase 1 is a quick non-bootstrapped, non-lto > compiler build, to check the ``basic sanity'' of the code base and build > process.

Hello, hopefully this is the correct place to ask this... We use distcc with clang++ and I have recently added -Wunreachable-code to our set of warnings.  The problem I am seeing is the compile fails with (valid) unreachable code warnings on the slave, but passes (no warning) locally.  All machines have the same compiler version clang version 8.0.1-svn369350-1~exp1~20190820121219.79

AFormat comes from the XMMS headers, maybe the version you have is newer or older than the code currently expects. what version of xmms to you have? Josh --- Rogier Eggers <rogier@r48.sytes.net> wrote: > Hello there. I'm having trouble to compile flac on gentoo linux: > linux-2.6.8 > gcc-3.3.4 > glibc-2.3.4 nptl enabled > > I would be happy if someone could help me

Hi, I have many printers installed under cups on a samba server, so the printers can be used and installed on Mac and PCs. My problem appeared with some new printers I bought and their PPDs. Under Cups, all the PPD options (Page Sizes, Trays, etc..) appear if I looked at them from the cups printer configuration page or if I use it from a Mac. But if I install the printers under windows

Hi, > If you have not already seen it, you (and anyone else working on > OpenCL runtimes) might be interested in this paper from AMD: > http://dl.acm.org/citation.cfm?id=1854302 > In particular, Section 4 describes the implementation approach for > their x86 OpenCL runtime and mentions a number of optimizations they > applied to things like the work-item stack. I know, but I