similar to: [LLVMdev] r55104 build problem

Displaying 20 results from an estimated 30000 matches similar to: "[LLVMdev] r55104 build problem"

2008 Sep 03
0
[LLVMdev] Merge-Cha-Cha
I'm getting the error below on Ubuntu Hardy on ia32 on r55688. John make[3]: Entering directory `/home/regehr/llvm-gcc/build/gcc' gcc -c -g -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wmissing-format-attribute -DHAVE_CONFIG_H -I. -I. -I../../gcc
2008 Aug 21
0
[LLVMdev] LLVM build fails on Linux x86
The build platform is Fedora 9 x86 gcc 4.3. Information dump: make[1]: Entering directory `/home/xzx/llvm/lib/System' make[1]: Nothing to be done for `all'. make[1]: Leaving directory `/home/xzx/llvm/lib/System' make[1]: Entering directory `/home/xzx/llvm/lib/Support' llvm[1]: Compiling raw_ostream.cpp for Debug build In file included from raw_ostream.cpp:15:
2008 Sep 11
1
[LLVMdev] linux llvm-gcc build broken
See below. This is on Ubuntu Hardy on ia32. Thanks, John make[3]: Entering directory `/home/regehr/llvm-gcc/build/gcc' gcc -c -g -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wmissing-format-attribute -DHAVE_CONFIG_H -I. -I. -I../../gcc -I../../gcc/.
2008 Oct 02
1
[LLVMdev] build broken (a different way)
I get the output below on Ubuntu Hardy on ia32 from svn 56984. John make[2]: Entering directory `/home/regehr/llvm-gcc/build/gcc' /home/regehr/llvm-gcc/build/./gcc/xgcc -B/home/regehr/llvm-gcc/build/./gcc/ -B/home/regehr/i686-pc-linux-gnu/bin/ -B/home/regehr/i686-pc-linux-gnu/lib/ -isystem /home/regehr/i686-pc-linux-gnu/include -isystem /home/regehr/i686-pc-linux-gnu/sys-include -O2 -O2
2008 Sep 03
1
[LLVMdev] Merge-Cha-Cha
On Tue, Sep 2, 2008 at 8:21 PM, John Regehr <regehr at cs.utah.edu> wrote: > I'm getting the error below on Ubuntu Hardy on ia32 on r55688. > ... > ../../gcc/postreload-gcse.c:1123: error: > flag_darwin_rtl_pre_ignore_critical_edges undeclared (first use in this > function) This is a Darwin-specific flag. I added a conditional to check for "CONFIG_DARWIN_H"
2008 Aug 08
0
[LLVMdev] llvm-gcc x86-64 build problem
On ubuntu hardy on x86-64, using current svn, llvm builds fine, but I'm getting this when building llvm-gcc: /usr/bin/ld: i386:x86-64 architecture of input file `/usr/lib/../lib/crti.o' is incompatible with i386 output /usr/bin/ld: i386:x86-64 architecture of input file `/usr/lib/../lib/crtn.o' is incompatible with i386 output Searching the web for these messages turned up a few
2008 Aug 10
0
[LLVMdev] random clang install problem
After dropping clang into llvm/tools it builds fine but I get the error below upon "make install". This is on Ubuntu Hardy for ia32. No big deal just giving a heads up... John Regehr make[3]: Entering directory `/home/regehr/llvm/tools/clang/docs' llvm[3]: Installing HTML documentation /usr/bin/install: missing destination file operand after
2009 Jan 20
2
[LLVMdev] linux build problem
I'm away from my Linux machines, if this hasn't been resolved by tonight I'll send more details. THe problem in cplus-dem.c is that CPP is conditionally including code that comes when HAVE_STDLIB is not defined, including an alternate protptype for malloc() that conflicts with the existing one. This is just what causes the error I sent-- no idea what the root cause is. Thanks,
2008 Sep 03
3
[LLVMdev] Merge-Cha-Cha
As you all have undoubtedly noticed, I recently did Yet Another Merge to Apple's GCC top-of-tree. This merge was prompted by several important fixes in the "blocks" implementation. There are still many testcases that need to be moved over, but those can come at our leisure. I compiled both the "Apple way" and the "FSF way". It also passed the tests in
2009 Jan 20
0
[LLVMdev] linux build problem
On Jan 19, 2009, at 5:34 PM, John Regehr wrote: > Since yesterday I've been getting the error below when building llvm- > gcc > on Ubuntu Hardy on x86. For some reason, several instances of > autoconf > are getting confused and failing to detect a stdlib.h. > > John > > > /home/regehr/z/tmp/llvm-gcc-r62547-src/build/./prev-gcc/xgcc >
2009 Jan 20
3
[LLVMdev] linux build problem
Since yesterday I've been getting the error below when building llvm-gcc on Ubuntu Hardy on x86. For some reason, several instances of autoconf are getting confused and failing to detect a stdlib.h. John /home/regehr/z/tmp/llvm-gcc-r62547-src/build/./prev-gcc/xgcc -B/home/regehr/z/tmp/llvm-gcc-r62547-src/build/./prev-gcc/
2009 Aug 28
2
[LLVMdev] can't build w/expensive checks
I get the error below when trying to build clang with expensive checks. Works fine w/o these. Is this a known problem? This is on Ubuntu Hardy using this compiler: regehr at john-home:~$ g++ --version g++ (GCC) 4.2.4 (Ubuntu 4.2.4-1ubuntu4) Thanks, John Regehr make[4]: Entering directory `/home/regehr/z/tmp/llvm-r80385/tools/clang/lib/Basic' llvm[4]: Compiling Builtins.cpp for
2009 Apr 07
2
[Bug 590] New: iptables unknown target data
http://bugzilla.netfilter.org/show_bug.cgi?id=590 Summary: iptables unknown target data Product: iptables Version: CVS (please indicate timestamp) Platform: i386 OS/Version: Ubuntu Status: NEW Severity: normal Priority: P1 Component: iptables AssignedTo: laforge at netfilter.org ReportedBy:
2015 Jul 22
3
[LLVMdev] some superoptimizer results
On 07/22/2015 01:28 PM, Sean Silva wrote: > > > On Wed, Jul 22, 2015 at 12:54 PM, Hal Finkel <hfinkel at anl.gov > <mailto:hfinkel at anl.gov>> wrote: > > One thing that is important to consider is where in the pipeline > these kinds of optimizations fit. We normally try to put the IR > into a canonical simplified form in the mid-level optimizer.
2009 Jan 20
4
[LLVMdev] linux build problem
On 2009-01-20 08:01, Bill Wendling wrote: > On Jan 19, 2009, at 5:34 PM, John Regehr wrote: > > >> Since yesterday I've been getting the error below when building llvm- >> gcc >> on Ubuntu Hardy on x86. For some reason, several instances of >> autoconf >> are getting confused and failing to detect a stdlib.h. >> >> John >>
2015 Jul 22
2
[LLVMdev] some superoptimizer results
One thing that is important to consider is where in the pipeline these kinds of optimizations fit. We normally try to put the IR into a canonical simplified form in the mid-level optimizer. This form is supposed to be whatever is most useful for exposing other optimizations, and for lowering, but only in a generic sense. We do have some optimizations near the end of our pipeline (vectorization,
2009 Oct 20
0
[LLVMdev] slooow compiles
My InlineCost refactoring has been noticed in this aspect; that may or may notbe the culprit here. A quick thing you can do is to compile with -ftime-report and compare the top few passes between versions. Dan On Oct 19, 2009, at 8:47 PM, John Regehr <regehr at cs.utah.edu> wrote: > As part of routine testing, I run clang and llvm-gcc a lot of times. > Something happened
2014 Nov 25
3
[LLVMdev] new set of superoptimizer results
Cool! Looks like we do lots of provably unnecessary alignment checks. :) On Tue, Nov 25, 2014 at 9:03 AM, John Regehr <regehr at cs.utah.edu> wrote: > Actually, let me save you some time by pointing out the thing that is > perhaps immediately useful about our recent work, which is the fact that > Souper now supports "optimization profiling". > > If you build an
2014 Jun 17
5
[LLVMdev] does ENABLE_COVERAGE work?
Hi, I'd like to see what parts of LLVM/Clang are being executed. I know that "make ENABLE_COVERAGE=1" used to just work, but so far (on 64-bit Ubuntu 14.04) I've had no luck building either 3.4.x or SVN head using any of Clang 3.4, Clang head, or a recent GCC. The first error that I get when building with GCC is this:
2014 Nov 26
2
[LLVMdev] new set of superoptimizer results
I strongly suspect pointer union and pointer int pair style classes are the source of these... But perhaps I'm wrong On Nov 26, 2014 9:29 AM, "Michael Zolotukhin" <mzolotukhin at apple.com> wrote: > John, > > That’s a great post and really interesting data, thank you! > > On Nov 25, 2014, at 9:58 AM, Reid Kleckner <rnk at google.com> wrote: > >