Build errors on trunk for about a week now.

Been trying to build the trunk to test some things for about a week
now using VS8 (VS2k5). Tons of Warnings (like things first being
declared struct, being redefined class and so forth, those need to be
fixed, but are otherwise not harmful), and a *lot* of errors. Being
trunk I figured just the normal trunk-type issues, but it has been
going on for a while now, so figured it would be good to state so it
can be fixed. These errors are with a fresh CMake from a fresh SVN
checkout all into fresh directories, still happens. Full build log is
attached to this email (too big for pastebin uncompressed, but
compressed down to a nice 15kb).

And I was going to put a copy of just the error lines in here, but
that came out to way too long, most of them seem to have been broken
from a couple distinct sources though. Also, some of those warnings
are potentially harmful (not that LLVM ever built clean, most of them
are ignorable anyway). If I get time during this break I may try to
clean up some of those irritating warnings that are simple (assuming
there are no errors stopping me, I do not think I will have time to
donate to those for another few weeks anyway...).

BuildLog_20081204.7z (14.6 KB)

OvermindDL1 a écrit :

Been trying to build the trunk to test some things for about a week
now using VS8 (VS2k5). Tons of Warnings (like things first being
declared struct, being redefined class and so forth, those need to be
fixed, but are otherwise not harmful), and a *lot* of errors. Being
trunk I figured just the normal trunk-type issues, but it has been
going on for a while now, so figured it would be good to state so it
can be fixed. These errors are with a fresh CMake from a fresh SVN
checkout all into fresh directories, still happens. Full build log is
attached to this email (too big for pastebin uncompressed, but
compressed down to a nice 15kb).
  
should be fixed with r60590 (work for me)

I hope this commit is considered as a trivial fix and that I didn't overstep my commit right.
I don't have a working test suit here, so I only checked it compile on VS2008.

That seems to have fixed a large amount of those errors (nicely simple
fix). I went ahead and termserved into my dev box (I will not be able
to get to it for another day or so) and told svn to update, and cmake
to make into a new directory, and build it, but it is still getting
errors. I will just post the error section and a couple surrounding
lines.

While building "LLVMSupport":
Annotation.cpp
f:\Program Files\Microsoft Visual Studio 8\VC\include\xtree(1174) :
error C3848: expression having type 'const
`anonymous-namespace'::StrCmp' would lose some const-volatile
qualifiers in order to call 'bool
`anonymous-namespace'::StrCmp::operator ()(const char *,const char *)'
        f:\Program Files\Microsoft Visual Studio
8\VC\include\xtree(1169) : while compiling class template member
function 'std::_Tree_nod<_Traits>::_Node
*std::_Tree<_Traits>::_Lbound(const char *const &) const'
        with
        [
            _Traits=std::_Tmap_traits<const char *,unsigned
int,`anonymous-namespace'::StrCmp,std::allocator<std::pair<const char
*const ,unsigned int>>,false>
        ]
        f:\Program Files\Microsoft Visual Studio 8\VC\include\map(82)
: see reference to class template instantiation 'std::_Tree<_Traits>'
being compiled
        with
        [
            _Traits=std::_Tmap_traits<const char *,unsigned
int,`anonymous-namespace'::StrCmp,std::allocator<std::pair<const char
*const ,unsigned int>>,false>
        ]
        ..\..\..\trunk\lib\Support\Annotation.cpp(67) : see reference
to class template instantiation 'std::map<_Kty,_Ty,_Pr>' being
compiled
        with
        [
            _Kty=const char *,
            _Ty=unsigned int,
            _Pr=`anonymous-namespace'::StrCmp
        ]
Allocator.cpp
APSInt.cpp

I cannot really look at it well since the termserv connection is
effectively less then modem speed, but I looked at Annotation.cpp from
the svn (also not fun, downloading at ~400bytes a second), but from a
quick look-see, I would bet that on line 34, changing:
    bool operator()(const char *a, const char *b) {
To:
    bool operator()(const char *a, const char *b) const {
Will fix that error. Which makes sense, all functor adapters for the
STL things like map are supposed to be const qualified anyway. Yes, I
have encountered that error before, yes that was the exact type of fix
that fixed it any time I have ever encountered it.

I do not know if there are any others errors yet. I will try to look
again once the build finishes and I can transfer the build log to
local (thankfully not needing the screen updates now that I have the
build started).

Yep, it looks like it was broken on 60174 from my perusing (which was
a fix to ). Once I fixed that const as stated above and told it to
compile again, no errors with the library. There is still one more
error though when trying to build "debug bugpoint", a missing external
for basic_string, no biggie, probably just need to rebuild in full,
will try later.

Still tons of warnings, lots of "type seen as struct, now as class"
and vice-versa errors and so forth. As stated, if I get some time
soon I may try to go through all of those and just clean up a lot of
those little warnings that really should not exist anyway (I like
warning-less builds...).

Actually, rebuilding it makes "debug tblgen" fail with the errors at
the end of this email, and as such everything that depends on it, how
odd...
When I get back to that computer then I will clean its directory,
update from SVN (please fix the const thing soon :slight_smile: ), and rebuild
fresh...

Helps if I post the errors, not that they will be of much help I would
bet, probably just need to rebuild after I clean it all...

4> Creating library
R:\SDKs\llvm\trunk_VC8nocrap_building\lib\Debug\tblgen.lib and object
R:\SDKs\llvm\trunk_VC8nocrap_building\lib\Debug\tblgen.exp
4>Record.obj : error LNK2001: unresolved external symbol "public: void
__thiscall std::basic_string<char,struct std::char_traits<char>,class
std::allocator<char> >::`copy constructor closure'(class
std::basic_string<char,struct std::char_traits<char>,class
std::allocator<char> > &)"
(??_O?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@QAEXAAV01@@Z)
4>RegisterInfoEmitter.obj : error LNK2019: unresolved external symbol
"public: void __thiscall std::basic_string<char,struct
std::char_traits<char>,class std::allocator<char> >::`copy constructor
closure'(class std::basic_string<char,struct
std::char_traits<char>,class std::allocator<char> > &)"
(??_O?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@QAEXAAV01@@Z)
referenced in function "public: virtual void __thiscall
llvm::RegisterInfoEmitter::run(class std::basic_ostream<char,struct
std::char_traits<char> > &)"
(?run@RegisterInfoEmitter@llvm@@UAEXAAV?$basic_ostream@DU?$char_traits@D@std@@@std@@@Z)
4>DAGISelEmitter.obj : error LNK2001: unresolved external symbol
"public: void __thiscall std::basic_string<char,struct
std::char_traits<char>,class std::allocator<char> >::`copy constructor
closure'(class std::basic_string<char,struct
std::char_traits<char>,class std::allocator<char> > &)"
(??_O?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@QAEXAAV01@@Z)
4>InstrInfoEmitter.obj : error LNK2001: unresolved external symbol
"public: void __thiscall std::basic_string<char,struct
std::char_traits<char>,class std::allocator<char> >::`copy constructor
closure'(class std::basic_string<char,struct
std::char_traits<char>,class std::allocator<char> > &)"
(??_O?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@QAEXAAV01@@Z)
4>IntrinsicEmitter.obj : error LNK2001: unresolved external symbol
"public: void __thiscall std::basic_string<char,struct
std::char_traits<char>,class std::allocator<char> >::`copy constructor
closure'(class std::basic_string<char,struct
std::char_traits<char>,class std::allocator<char> > &)"
(??_O?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@QAEXAAV01@@Z)
4>LLVMCConfigurationEmitter.obj : error LNK2001: unresolved external
symbol "public: void __thiscall std::basic_string<char,struct
std::char_traits<char>,class std::allocator<char> >::`copy constructor
closure'(class std::basic_string<char,struct
std::char_traits<char>,class std::allocator<char> > &)"
(??_O?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@QAEXAAV01@@Z)
4>AsmWriterEmitter.obj : error LNK2001: unresolved external symbol
"public: void __thiscall std::basic_string<char,struct
std::char_traits<char>,class std::allocator<char> >::`copy constructor
closure'(class std::basic_string<char,struct
std::char_traits<char>,class std::allocator<char> > &)"
(??_O?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@QAEXAAV01@@Z)
4>CodeGenDAGPatterns.obj : error LNK2001: unresolved external symbol
"public: void __thiscall std::basic_string<char,struct
std::char_traits<char>,class std::allocator<char> >::`copy constructor
closure'(class std::basic_string<char,struct
std::char_traits<char>,class std::allocator<char> > &)"
(??_O?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@QAEXAAV01@@Z)
4>CodeGenInstruction.obj : error LNK2001: unresolved external symbol
"public: void __thiscall std::basic_string<char,struct
std::char_traits<char>,class std::allocator<char> >::`copy constructor
closure'(class std::basic_string<char,struct
std::char_traits<char>,class std::allocator<char> > &)"
(??_O?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@QAEXAAV01@@Z)
4>CodeGenTarget.obj : error LNK2001: unresolved external symbol
"public: void __thiscall std::basic_string<char,struct
std::char_traits<char>,class std::allocator<char> >::`copy constructor
closure'(class std::basic_string<char,struct
std::char_traits<char>,class std::allocator<char> > &)"
(??_O?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@QAEXAAV01@@Z)
4>R:\SDKs\llvm\trunk_VC8nocrap_building\bin\Debug\tblgen.exe : fatal
error LNK1120: 1 unresolved externals
4>Build Time 0:29

Nope, even after deleting the thing, re-cmake'ing it, it still had
those errors only in debug mode...

OvermindDL1 a écrit :

As well as also getting tons of errors in LLVMCore, like this:

10>R:\SDKs\llvm\trunk\include\llvm/IntrinsicInst.h(211) : error C2039:
'memcpy' : is not a member of 'llvm::Intrinsic'
10>R:\SDKs\llvm\trunk\include\llvm/IntrinsicInst.h(211) : error C2051:
case expression not constant
10>R:\SDKs\llvm\trunk\include\llvm/IntrinsicInst.h(212) : error C2039:
'memmove' : is not a member of 'llvm::Intrinsic'
10>R:\SDKs\llvm\trunk\include\llvm/IntrinsicInst.h(212) : error C2051:
case expression not constant
10>R:\SDKs\llvm\trunk\include\llvm/IntrinsicInst.h(213) : error C2039:
'memset' : is not a member of 'llvm::Intrinsic'
10>R:\SDKs\llvm\trunk\include\llvm/IntrinsicInst.h(213) : error C2051:
case expression not constant
10>R:\SDKs\llvm\trunk\include\llvm/IntrinsicInst.h(216) : warning
C4065: switch statement contains 'default' but no 'case' labels
10>R:\SDKs\llvm\trunk\include\llvm/IntrinsicInst.h(246) : error C2039:
'memcpy' : is not a member of 'llvm::Intrinsic'
10>R:\SDKs\llvm\trunk\include\llvm/IntrinsicInst.h(246) : error C2679:
binary '==' : no operator found which takes a right-hand operand of
type 'overloaded-function' (or there is no acceptable conversion)
10> R:\SDKs\llvm\trunk\include\llvm/ADT/APInt.h(1380): could be
'bool llvm::operator ==(uint64_t,const llvm::APInt &)'
10> while trying to match the argument list
'(llvm::Intrinsic::ID, overloaded-function)'
10>R:\SDKs\llvm\trunk\include\llvm/IntrinsicInst.h(274) : error C2039:
'memmove' : is not a member of 'llvm::Intrinsic'
10>R:\SDKs\llvm\trunk\include\llvm/IntrinsicInst.h(274) : error C2679:
binary '==' : no operator found which takes a right-hand operand of
type 'overloaded-function' (or there is no acceptable conversion)
10> R:\SDKs\llvm\trunk\include\llvm/ADT/APInt.h(1380): could be
'bool llvm::operator ==(uint64_t,const llvm::APInt &)'
10> while trying to match the argument list
'(llvm::Intrinsic::ID, overloaded-function)'
10>R:\SDKs\llvm\trunk\include\llvm/IntrinsicInst.h(297) : error C2039:
'memset' : is not a member of 'llvm::Intrinsic'
10>R:\SDKs\llvm\trunk\include\llvm/IntrinsicInst.h(297) : error C2679:
binary '==' : no operator found which takes a right-hand operand of
type 'overloaded-function' (or there is no acceptable conversion)
10> R:\SDKs\llvm\trunk\include\llvm/ADT/APInt.h(1380): could be
'bool llvm::operator ==(uint64_t,const llvm::APInt &)'
10> while trying to match the argument list
'(llvm::Intrinsic::ID, overloaded-function)'
10>..\..\..\trunk\lib\VMCore\Verifier.cpp(1343) : error C2039:
'memcpy' : is not a member of 'llvm::Intrinsic'
10>..\..\..\trunk\lib\VMCore\Verifier.cpp(1343) : error C2051: case
expression not constant
10>..\..\..\trunk\lib\VMCore\Verifier.cpp(1344) : error C2039:
'memmove' : is not a member of 'llvm::Intrinsic'
10>..\..\..\trunk\lib\VMCore\Verifier.cpp(1344) : error C2051: case
expression not constant
10>..\..\..\trunk\lib\VMCore\Verifier.cpp(1345) : error C2039:
'memset' : is not a member of 'llvm::Intrinsic'
10>..\..\..\trunk\lib\VMCore\Verifier.cpp(1345) : error C2051: case
expression not constant
10>..\..\..\trunk\lib\VMCore\Verifier.cpp(1378) : error C2039:
'stackprotector' : is not a member of 'llvm::Intrinsic'
10>..\..\..\trunk\lib\VMCore\Verifier.cpp(1378) : error C2065:
'stackprotector' : undeclared identifier
10>..\..\..\trunk\lib\VMCore\Verifier.cpp(1378) : error C2051: case
expression not constant

I canceled that build and went ahead and tried to build release again,
no errors yet, but I did notice a rather odd looking warning:

6>R:\SDKs\llvm\trunk\include\llvm/Support/ManagedStatic.h(23) :
warning C4156: deletion of an array expression without using the array
form of 'delete'; array form substituted
6> R:\SDKs\llvm\trunk\include\llvm/Support/ManagedStatic.h(72)
: see reference to function template instantiation 'void
llvm::object_deleter<C>(void *)' being compiled
6> with
6> [
6> C=llvm::PseudoSourceValue [4]
6> ]
6> R:\SDKs\llvm\trunk\include\llvm/Support/ManagedStatic.h(71)
: while compiling class template member function 'void
llvm::ManagedStatic<C>::LazyInit(void) const'
6> with
6> [
6> C=llvm::PseudoSourceValue [4]
6> ]
6> ..\..\..\trunk\lib\CodeGen\PseudoSourceValue.cpp(23) : see
reference to class template instantiation 'llvm::ManagedStatic<C>'
being compiled
6> with
6> [
6> C=llvm::PseudoSourceValue [4]
6> ]

And this warning has possible issues too:

13>LoopRotation.cpp
13>..\..\..\..\trunk\lib\Transforms\Scalar\LoopRotation.cpp(561) :
warning C4288: nonstandard extension used : 'I' : loop control
variable declared in the for-loop is used outside the for-loop scope;
it conflicts with the declaration in the outer scope
13> ..\..\..\..\trunk\lib\Transforms\Scalar\LoopRotation.cpp(559)
: definition of 'I' used
13> ..\..\..\..\trunk\lib\Transforms\Scalar\LoopRotation.cpp(465)
: definition of 'I' ignored
13>..\..\..\..\trunk\lib\Transforms\Scalar\LoopRotation.cpp(561) :
warning C4288: nonstandard extension used : 'I' : loop control
variable declared in the for-loop is used outside the for-loop scope;
it conflicts with the declaration in the outer scope
13> ..\..\..\..\trunk\lib\Transforms\Scalar\LoopRotation.cpp(559)
: definition of 'I' used
13> ..\..\..\..\trunk\lib\Transforms\Scalar\LoopRotation.cpp(465)
: definition of 'I' ignored

And again at:

14>DeadArgumentElimination.cpp
14>..\..\..\..\trunk\lib\Transforms\IPO\DeadArgumentElimination.cpp(501)
: warning C4288: nonstandard extension used : 'i' : loop control
variable declared in the for-loop is used outside the for-loop scope;
it conflicts with the declaration in the outer scope
14> ..\..\..\..\trunk\lib\Transforms\IPO\DeadArgumentElimination.cpp(498)
: definition of 'i' used
14> ..\..\..\..\trunk\lib\Transforms\IPO\DeadArgumentElimination.cpp(492)
: definition of 'i' ignored
14>..\..\..\..\trunk\lib\Transforms\IPO\DeadArgumentElimination.cpp(506)
: warning C4288: nonstandard extension used : 'i' : loop control
variable declared in the for-loop is used outside the for-loop scope;
it conflicts with the declaration in the outer scope
14> ..\..\..\..\trunk\lib\Transforms\IPO\DeadArgumentElimination.cpp(498)
: definition of 'i' used
14> ..\..\..\..\trunk\lib\Transforms\IPO\DeadArgumentElimination.cpp(492)
: definition of 'i' ignored

But basically yes, release builds in fulle with no errors, debug does
not, I wonder if this is cmake related. Can take a look tomorrow at
the earliest...

Do not think so, updated it fresh a couple of times, but will not be
able to fully clean everything out well until I actually get to
sitting at the computer again, trying to clean it remotely would take
me hours (that I do not have).

I am quite confident about that functor needing const though; I have
experienced that error many times and that has always been the fix.

I updated the svn to 60607. It still needed that const change. Added
the const word on that member function. Tried building debug, debug
still fails horrible.

I am going to try to stop by that computer for an hour or so before my
next work shift tonight, will completely get rid of every trace of
LLVM and re-download the SVN, cmake it, and compile it all again if I
have time.

I did some looking up on that const thing. Apparently that const is
'supposed' to be there, but it is not strictly required. However
there is a bug in VS2k3 (VS7) through VS2k8 (VS9) (no clue if it has
been fixed yet) that requires it to be there when the functor is being
called through a const qualified interface, such as through stl
containers. They state that a bug report has been filed, but
regardless of if it is filled or not, in such functors you are
'supposed' to have a const there anyway. No clue what the standard
actually says on this, but what they said makes sense...

Okay, I got here and cleaned out every trace of LLVM. I then got the
latest from SVN (at the time: 60621). CMaked it, built it. Changed
nothing, no defaults, no anything and the build result is file
BuildLog_2008_12_05_22_19.txt (as a 7z file).

It has lots of errors, all still seem to relate to the const
qualification, but I still changed nothing.

I compiled again, just to get a build log that contained basically
nothing but the errors since everything else was built:
BuildLog_2008_12_05_22_19.txt (as a 7z file)

I then made that const change I mentioned earlier and built again, all
the errors disappeared except for the basic_string linking in debug
mode as before: BuildLog_2008_12_06_01_21.txt (as a 7z file)

I then compiled it as-is once more, just to get a build log of
basically nothing but the errors as is: BuildLog_2008_12_06_01_24.txt
(as a 7z file)

I then cleaned everything out again, made a new cmake and all. This
time I made the const change from the get-go, pretty much same as
excepted, everything worked except some of the debug linkings for
basic_string: BuildLog_2008_12_06_03_12.txt (as a 7z file)

I then just built it once more to get a build log of just the errors,
basically the same as before.

So it seems that the const qualifier *really* needs to be on here for
VS2k5, and as it is 'correct' anyway, it should work everywhere.

As for the basic_string linking errors, no clue, have not looked at it
yet, might be a cmake thing.

BuildLog_2008_12_05_22_19.7z (12.6 KB)

BuildLog_2008_12_05_22_25.7z (6.77 KB)

BuildLog_2008_12_06_01_21.7z (8.31 KB)

BuildLog_2008_12_06_01_24.7z (4.32 KB)

BuildLog_2008_12_06_03_12.7z (13.4 KB)

BuildLog_2008_12_06_03_28.7z (4.33 KB)

OvermindDL1 <overminddl1@gmail.com> writes:

[snip]

tblgen.exe builds fine on my vs2005 install with the Debug
configuration.

You are simultaneously building all the configurations (Relase, Debug,
RelWithDebInfo, etc). What happens if you do a "Clean Solution" and then
build just the Debug configuration?

We need to look at the actual commands VS is executing. Please show the
contents of

r:\SDKs\llvm\trunk_VC8nocrap_building\utils\TableGen\tblgen.dir\Debug\BuildLog.htm

I finally got some time to where I could delve into things. First,
let me say it had nothing to do with my includes, libraries, or
whatnot (those defines I require for everything I compile, they fix
some things Microsoft horribly broken). The "const" still needs to be
added to the function, that is correct and has to be done. However,
the string error in debug builds was a bug that was fixed in VS2k5SP1;
I, apparently, was running the SP1 beta. So when I add const to that
functor, everything builds nice and fine (well, besides the ton of
warnings), the example apps work, etc... and so forth. Thanks for the
help though.

But yes, let me say again, that functor still needs const added to it.
It is correct for the spec, and it is required for at least VC2k5 (I
tried building without it by removing my includes, libs, defines, and
about ten other things, it is needed in every case, spent about 8
hours on all this so I am extremely sure). Attached is the patch;
should I post it to the LLVM list as well?

Oh, and yes, instead of VC2k5 being the minimum requirement, it should
be VC2k5SP1 (although VC2k3 does not have that issue, if someone
managed to get around to fixing the friend errors that VC2k3 is bugged
with).

Actually, I am forwarding this to the list anyway, good record in case
anyone searches.

FunctorPatch.patch (418 Bytes)

OvermindDL1 <overminddl1@gmail.com> writes:

[snip]

But yes, let me say again, that functor still needs const added to it.
It is correct for the spec, and it is required for at least VC2k5 (I
tried building without it by removing my includes, libs, defines, and
about ten other things, it is needed in every case, spent about 8
hours on all this so I am extremely sure). Attached is the patch;
should I post it to the LLVM list as well?

Please send the patch to llvm-commits@cs.uiuc.edu

Oh, and yes, instead of VC2k5 being the minimum requirement, it should
be VC2k5SP1

[snip]

It would be great if you submit a patch for

http://www.llvm.org/docs/GettingStarted.html#requirements

and/or

http://www.llvm.org/docs/GettingStarted.html#brokengcc

BTW, that section should be renamed to "broken compilers and other
tools", since gcc is not the only compiler that builds LLVM.

[snip]