Hi there,
I am a student considering a compiler design based dissertation with
llvm. I am having problems building llvm on OpenBSD-current. I hope to
make a port of llvm for OpenBSD once I have figured out how to build
it.
Observe:
llvm[3]: Compiling Deserialize.cpp for Release build
In file included from /home/edd/llvm/llvm-2.3/include/llvm/Bitcode/BitstreamRead
er.h:18,
from /home/edd/llvm/llvm-2.3/include/llvm/Bitcode/Deserialize.h
:18,
from Deserialize.cpp:14:
/home/edd/llvm/llvm-2.3/include/llvm/Bitcode/BitCodes.h:158: warning: `class
llvm::BitCodeAbbrev' only defines a private destructor and has no friends
llvm[3]: Compiling DeserializeAPFloat.cpp for Release build
In file included from /home/edd/llvm/llvm-2.3/include/llvm/Bitcode/BitstreamRead
er.h:18,
from /home/edd/llvm/llvm-2.3/include/llvm/Bitcode/Deserialize.h
:18,
from DeserializeAPFloat.cpp:15:
/home/edd/llvm/llvm-2.3/include/llvm/Bitcode/BitCodes.h:158: warning: `class
llvm::BitCodeAbbrev' only defines a private destructor and has no friends
llvm[3]: Compiling DeserializeAPInt.cpp for Release build
In file included from /home/edd/llvm/llvm-2.3/include/llvm/Bitcode/BitstreamRead
er.h:18,
from /home/edd/llvm/llvm-2.3/include/llvm/Bitcode/Deserialize.h
:18,
from DeserializeAPInt.cpp:15:
/home/edd/llvm/llvm-2.3/include/llvm/Bitcode/BitCodes.h:158: warning: `class
llvm::BitCodeAbbrev' only defines a private destructor and has no friends
llvm[3]: Building Release Archive Library libLLVMBitReader.a
gmake[3]: Leaving directory `/home/edd/llvm/llvm-2.3/lib/Bitcode/Reader'
gmake[3]: Entering directory `/home/edd/llvm/llvm-2.3/lib/Bitcode/Writer'
llvm[3]: Compiling BitWriter.cpp for Release build
In file included from /home/edd/llvm/llvm-2.3/include/llvm/Argument.h:18,
from /home/edd/llvm/llvm-2.3/include/llvm/Function.h:23,
from /home/edd/llvm/llvm-2.3/include/llvm/Module.h:17,
from /home/edd/llvm/llvm-2.3/include/llvm-c/Core.h:40,
from /home/edd/llvm/llvm-2.3/include/llvm-c/BitWriter.h:22,
from BitWriter.cpp:10:
/home/edd/llvm/llvm-2.3/include/llvm/ParameterAttributes.h:71: warning: `inline
' is not at beginning of declaration
BitWriter.cpp: In function `int LLVMWriteBitcodeToFileHandle(LLVMOpaqueModule*,
int)':
BitWriter.cpp:40: error: no matching function for call to `
__gnu_cxx::stdio_filebuf<char, std::char_traits<char> >::stdio_filebuf(int&,
std::_Ios_Openmode)'
/usr/include/g++/ext/stdio_filebuf.h:53: error: candidates are:
__gnu_cxx::stdio_filebuf<char, std::char_traits<char> >::stdio_filebuf(const
__gnu_cxx::stdio_filebuf<char, std::char_traits<char> >&)
/usr/include/g++/ext/stdio_filebuf.h:147: error:
__gnu_cxx::stdio_filebuf<_CharT, _Traits>::stdio_filebuf(std::__c_file*,
std::_Ios_Openmode, long unsigned int) [with _CharT = char, _Traits =
std::char_traits<char>] <near match>
/usr/include/g++/ext/stdio_filebuf.h:122: error:
__gnu_cxx::stdio_filebuf<_CharT, _Traits>::stdio_filebuf(int,
std::_Ios_Openmode, bool, long unsigned int) [with _CharT = char, _Traits =
std::char_traits<char>]
gmake[3]: *** [/home/edd/llvm/llvm-2.3/lib/Bitcode/Writer/Release/BitWriter.o] E
rror 1
gmake[3]: Leaving directory `/home/edd/llvm/llvm-2.3/lib/Bitcode/Writer'
gmake[2]: *** [Writer/.makeall] Error 2
gmake[2]: Leaving directory `/home/edd/llvm/llvm-2.3/lib/Bitcode'
gmake[1]: *** [Bitcode/.makeall] Error 2
gmake[1]: Leaving directory `/home/edd/llvm/llvm-2.3/lib'
gmake: *** [all] Error 1
I wonder if anyone can suggest a workaround or fix.
Thanks
I am a student considering a compiler design based dissertation with llvm. I am having problems building llvm on OpenBSD-current. I hope to make a port of llvm for OpenBSD once I have figured out how to build it.
Hi Edd,
Could you please update to r52213 or later in svn and check whether this error is resolved with your gcc?
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20080609/063564.html
If not, I'll just write a configure test for this as the related FIXME suggests.
llvm[3]: Compiling Deserialize.cpp for Release build
BitWriter.cpp: In function `int LLVMWriteBitcodeToFileHandle(LLVMOpaqueModule*,
int)':
BitWriter.cpp:40: error: no matching function for call to `
__gnu_cxx::stdio_filebuf<char, std::char_traits<char> >::stdio_filebuf(int&,
std::_Ios_Openmode)'
/usr/include/g++/ext/stdio_filebuf.h:53: error: candidates are:
__gnu_cxx::stdio_filebuf<char, std::char_traits<char> >::stdio_filebuf(const
__gnu_cxx::stdio_filebuf<char, std::char_traits<char> >&)
/usr/include/g++/ext/stdio_filebuf.h:147: error:
__gnu_cxx::stdio_filebuf<_CharT, _Traits>::stdio_filebuf(std::__c_file*,
std::_Ios_Openmode, long unsigned int) [with _CharT = char, _Traits =
std::char_traits<char>] <near match>
/usr/include/g++/ext/stdio_filebuf.h:122: error:
__gnu_cxx::stdio_filebuf<_CharT, _Traits>::stdio_filebuf(int,
std::_Ios_Openmode, bool, long unsigned int) [with _CharT = char, _Traits =
std::char_traits<char>]
— Gordon
Latest trunk fixes that error. Next problem 
llvm[3]: Building ARM.td register information header with tblgen
llvm[3]: Building ARM.td register names with tblgen
llvm[3]: Building ARM.td register info implementation with tblgen
llvm[3]: Building ARM.td instruction names with tblgen
llvm[3]: Building ARM.td instruction information with tblgen
llvm[3]: Building ARM.td assembly writer with tblgen
llvm[3]: Building ARM.td instruction selector implementation with tblgen
assertion "getOperator()->isSubClassOf("SDNodeXForm") && "Unknown node
type!"" failed: file "CodeGenDAGPatterns.cpp", line 949, function
"ApplyTypeConstraints"
gmake[3]: *** [/tmp/llvm/lib/Target/ARM/Debug/ARMGenDAGISel.inc.tmp]
Abort trap (core dumped)
gmake[3]: Leaving directory `/tmp/llvm/lib/Target/ARM'
gmake[2]: *** [ARM/.makeall] Error 2
gmake[2]: Leaving directory `/tmp/llvm/lib/Target'
gmake[1]: *** [Target/.makeall] Error 2
gmake[1]: Leaving directory `/tmp/llvm/lib'
gmake: *** [all] Error 1
Hello, Edd
> llvm[3]: Building ARM.td instruction selector implementation with tblgen
> assertion "getOperator()->isSubClassOf("SDNodeXForm") && "Unknown node
> type!"" failed: file "CodeGenDAGPatterns.cpp", line 949, function
> "ApplyTypeConstraints"
Could you please try with gcc 4.x and check, whether this problem exists
for you or not.
But it only works fine for svn snapshots. Your most recent release
does not build on OpenBSD with gcc-4.2.
llvm[3]: Building ARM.td instruction selector implementation with tblgen
assertion "getOperator()->isSubClassOf("SDNodeXForm") && "Unknown node
type!"" failed: file "CodeGenDAGPatterns.cpp", line 932, function
"ApplyTypeConstraints"
gmake[3]: *** [/usr/ports/devel/llvm/w-llvm-2.3/llvm-2.3/lib/Target/ARM/Release/ARMGenDAGISel.inc.tmp]
Abort trap (core dumped)
gmake[3]: Leaving directory
`/usr/ports/devel/llvm/w-llvm-2.3/llvm-2.3/lib/Target/ARM'
gmake[2]: *** [ARM/.makeall] Error 2
gmake[2]: Leaving directory
`/usr/ports/devel/llvm/w-llvm-2.3/llvm-2.3/lib/Target'
gmake[1]: *** [Target/.makeall] Error 2
gmake[1]: Leaving directory `/usr/ports/devel/llvm/w-llvm-2.3/llvm-2.3/lib'
gmake: *** [all] Error 1
*** Error code 2
Are you going to make a release anytime soon? I guess not as you just released.
I ask because rolling ones own distfiles is less than ideal when making ports.
LLVM 2.3 is building with no patches and gcc 4.2.1 on FreeBSD (at least
i386, amd64, and sparc64 by current reports) so there's presumably
only a small patch required either to gcc or llvm to make it happy on
OpenBSD.
-- Brooks
Hi,
LLVM 2.3 is building with no patches and gcc 4.2.1 on FreeBSD
OK, so I have taken the changes to BitWriter.cpp from svn and that
builds that section of code OK for llvm-2.3. The next part I will need
help with, as I dont really know where to start:
llvm[3]: Building ARM.td instruction information with tblgen
assertion "getOperator()->isSubClassOf("SDNodeXForm") && "Unknown node type!"" f
ailed: file "CodeGenDAGPatterns.cpp", line 932, function "ApplyTypeConstraints"
gmake[3]: *** [/usr/ports/devel/llvm/w-llvm-2.3/llvm-2.3/lib/Target/ARM/Release/
ARMGenInstrInfo.inc.tmp] Abort trap (core dumped)
gmake[3]: Leaving directory `/usr/ports/devel/llvm/w-llvm-2.3/llvm-2.3/lib/Targe
t/ARM'
gmake[2]: *** [ARM/.makeall] Error 2
gmake[2]: Leaving directory `/usr/ports/devel/llvm/w-llvm-2.3/llvm-2.3/lib/Targe
t'
gmake[1]: *** [Target/.makeall] Error 2
gmake[1]: Leaving directory `/usr/ports/devel/llvm/w-llvm-2.3/llvm-2.3/lib'
gmake: *** [all] Error 1
*** Error code 2
This is not a gcc bug, but the assertion failing. A quick diff against
this file shows a huge amount of changes and I have nowhere near
enough knowledge to start comprehending this code. I am only starting
to learn about compilers for my dissertation
Any help is much appreciated
If you use bison instead of yacc this bug is not exposed.
Is this correct behavior?
If you use bison instead of yacc this bug is not exposed.
Is this correct behavior?
I guess so. bison is quite different to yacc, see "info bison".
llvm depends on bison and this is quite well documented. At
http://llvm.org/releases/2.3/docs/GettingStarted.html#software
it says "bison" and specifically which version of Bison you've
to use.
Im wondering how FreeBSD managed to fluke it. Unless they replaces BSD
yacc with bison in their distribution:
http://www.freebsd.org/cgi/cvsweb.cgi/ports/devel/llvm/Makefile?rev=1.22
No mention of bison.
Sorry, disregard this comment. Bison seems to never be detected
properly even if you set YACC=bison or even YACC=/usr/local/bin/bison.
But thats another story.
Whilst struggling to work out how i got a working build i noticed that
(with gcc 3.3.5) the bus error does not always happen. Onmy last
attempt, the build failed on first attempt and succeeded on second
attempt (without a make clean in-between).
This leads me to believe that something is very wrong.
I am trying the same with gcc-4.2 now.
The above results were infact with gcc-4.2. My apologies.
With 3.3.5 my first test took 5 times to produce a non "bus error"
build. There were no 'make cleans' in between.
What is going on?
With 3.3.5 my first test took 5 times to produce a non "bus
error" build. There were no 'make cleans' in between.
What is going on?
You mean you used your bsd-ports-provided gcc to compile LLVM and
you've got 4 times a bus-error during the build? In this case,
it cannot be a LLVM problem.
In the linux-community, people say that bus-error's are almost
always because of faulty hardware, e.g. problem with DRAM
timing, overheated CPU, power-supply that cannot provide enought
power during current surges, things like that.
At least bus errors that aren't reproducible are likely caused by this. It could be random memory corruption or a bug in the host compiler - then again that compiler is > 8 years old at this point?
-eric
Holger Schurig wrote:
With 3.3.5 my first test took 5 times to produce a non "bus
error" build. There were no 'make cleans' in between.
What is going on?
You mean you used your bsd-ports-provided gcc to compile LLVM and you've got 4 times a bus-error during the build? In this case, it cannot be a LLVM problem.
Ok, to clarify,
I have tried the OpenBSD provided gcc-3.3.5 (which is considered the
least buggy version of gcc) and also with gcc-4.2 from ports.
Sometimes you get a clean build of llvm, sometimes you don't and instead
get a bus error.
In the linux-community, people say that bus-error's are almost always because of faulty hardware, e.g. problem with DRAM timing, overheated CPU, power-supply that cannot provide enought power during current surges, things like that.
That is one reason a bus error might occur, but my more common
understanding of a bus error is data not properly aligned with the byte
boundaries and/or out of range memory at the physical level.
The machine I am building on is my workstation which I use 9-4.30
mon-fri. I run all manner of apps without any problems, so if it were
bad hardware it would have shown itself by now surely.
As a test I got another developer to try on a different machine and he has the same problem. In another test he also tried a more aggressive malloc.conf (a mechanism which causes malloc to do all sorts of randomisation and page filling to test for memory based bugs) and a completely different error was encountered:
SelectionDAG.cpp:2602: warning: converting of negative value
`-1' to `long long
Also we found that without specifying --enable-optimized, the optimisations were still present:
-O3 -fomit-frame-pointer -Woverloaded-virtual -pedantic
-Wall -W -Wwrite-strings -Wno-long-long -Wunused -Wno-unused-parameter
-O3
:¬(
Hi,
Holger Schurig wrote:
>> With 3.3.5 my first test took 5 times to produce a non "bus
>> error" build. There were no 'make cleans' in between.
>>
>> What is going on?
>
> You mean you used your bsd-ports-provided gcc to compile LLVM and
> you've got 4 times a bus-error during the build? In this case,
> it cannot be a LLVM problem.
Ok, to clarify,
I have tried the OpenBSD provided gcc-3.3.5 (which is considered the
least buggy version of gcc) and also with gcc-4.2 from ports.
Sometimes you get a clean build of llvm, sometimes you don't and instead
get a bus error.
if I understand right the problem is that you are unable to build LLVM
because your system gcc (and another gcc you tried) tends to crash during
the build?
> In the linux-community, people say that bus-error's are almost
> always because of faulty hardware, e.g. problem with DRAM
> timing, overheated CPU, power-supply that cannot provide enought
> power during current surges, things like that.
That is one reason a bus error might occur, but my more common
understanding of a bus error is data not properly aligned with the byte
boundaries and/or out of range memory at the physical level.
The machine I am building on is my workstation which I use 9-4.30
mon-fri. I run all manner of apps without any problems, so if it were
bad hardware it would have shown itself by now surely.
gcc is however notorious for exposing bad memory problems.
As a test I got another developer to try on a different machine and he
has the same problem. In another test he also tried a more aggressive
malloc.conf (a mechanism which causes malloc to do all sorts of
randomisation and page filling to test for memory based bugs) and a
completely different error was encountered:
SelectionDAG.cpp:2602: warning: converting of negative value
`-1' to `long long
If I understand right, tweaking your system malloc caused the system
gcc to behave differently when compiling LLVM?
Also we found that without specifying --enable-optimized, the
optimisations were still present:
-O3 -fomit-frame-pointer -Woverloaded-virtual -pedantic
-Wall -W -Wwrite-strings -Wno-long-long -Wunused -Wno-unused-parameter
-O3
--enable-optimized is not about whether or not compiler optimizations
are performed when building LLVM, it is about whether the built version
of LLVM performs internal checks when run.
Ciao,
Duncan.