Building LLVM and Clang with EKOPath 4

Hi all,

I've managed to build LLVM and Clang with EKOPath 4.0.12.1 compiler. Here are patches I had to introcduce
to make it compiling.

Patch for clang moves some classes from anonymous namespaces which otherwise caused linker
errors. Probably it's a bug in compiler producing symbols with incorrect visibility.

llvm_ekopath.patch (2.04 KB)

clang_ekopath.patch (4.21 KB)

I must admit it seems weird to be tweaking the code just to get it to compile with an exotic compiler.

Adding includes occurs regularly because the standard does not define which standard includes include which others, so you often miss one or two.

On the other hand, it seems strange that you had to add the “std::” qualifiers, remove the anonymous namespace in some places (all ?) and change *–S.end() into S[S.size()-1].

I think it would be more productive to file bugs against EKOPath so they improve their compiler instead. Don’t you ?

– Matthieu

--S.end() isn't portable if S is a std::string (or a std::vector, come
to that) -- if the iterator type is a pointer type then decrementing
an rvalue is ill-formed. This is where's C++11's std::prev is handy,
but of course we can't use it here, and we can't use C++11's
string::back() either, so the C++98 options are either S[S.size() - 1]
or *S.rbegin().

-- James

Hi all,

I’ve managed to build LLVM and Clang with EKOPath 4.0.12.1 compiler. Here are patches I had to introcduce
to make it compiling.

Patch for clang moves some classes from anonymous namespaces which otherwise caused linker
errors. Probably it’s a bug in compiler producing symbols with incorrect visibility.


Regards,
Konstantin


cfe-dev mailing list
cfe-dev@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev

I must admit it seems weird to be tweaking the code just to get it to compile with an exotic compiler.

Adding includes occurs regularly because the standard does not define which standard includes include which others, so you often miss one or two.

On the other hand, it seems strange that you had to add the “std::” qualifiers,

This one’s not actually that surprising - if a std::vector’s iterators are implemented as raw pointers, rather than as a type in the std namespace, then unqualified find(vec.begin(), vec.end(), …) won’t compile, since ‘find’ won’t be found via ADL.

remove the anonymous namespace in some places (all ?)

This I can’t explain - what errors are given that motivate this change?

and change *–S.end() into S[S.size()-1].

Again, if the iterators are truly raw pointers, – doesn’t work on them, only on user defined types with an op-- overload. The simpler form is “S.back()”.

  • David

Hi all,

I’ve managed to build LLVM and Clang with EKOPath 4.0.12.1 compiler. Here are patches I had to introcduce
to make it compiling.

Patch for clang moves some classes from anonymous namespaces which otherwise caused linker
errors. Probably it’s a bug in compiler producing symbols with incorrect visibility.


Regards,
Konstantin


cfe-dev mailing list
cfe-dev@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev

I must admit it seems weird to be tweaking the code just to get it to compile with an exotic compiler.

Adding includes occurs regularly because the standard does not define which standard includes include which others, so you often miss one or two.

On the other hand, it seems strange that you had to add the “std::” qualifiers,

This one’s not actually that surprising - if a std::vector’s iterators are implemented as raw pointers, rather than as a type in the std namespace, then unqualified find(vec.begin(), vec.end(), …) won’t compile, since ‘find’ won’t be found via ADL.

Right, I had thought they would be wrapped in “proper” classes and not just typedef.

remove the anonymous namespace in some places (all ?)

This I can’t explain - what errors are given that motivate this change?

and change *–S.end() into S[S.size()-1].

Again, if the iterators are truly raw pointers, – doesn’t work on them, only on user defined types with an op-- overload. The simpler form is “S.back()”.

Unfortunately as James pointed out .back is not available on strings, I would still prefer *S.rbegin() but that is bike-shedding here.

  • David

So the only outstanding point is the anonymous namespaces, this could warrant a bug report to EKOPath.

– Matthieu

This explanation exactly matches error message I've got from EKOPath.

Hi all,

I've managed to build LLVM and Clang with EKOPath 4.0.12.1 compiler. Here are patches I had to introcduce
to make it compiling.

Patch for clang moves some classes from anonymous namespaces which otherwise caused linker
errors. Probably it's a bug in compiler producing symbols with incorrect visibility.

--
Regards,
Konstantin

_______________________________________________
cfe-dev mailing list
cfe-dev@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev

I must admit it seems weird to be tweaking the code just to get it to compile with an exotic compiler.

Adding includes occurs regularly because the standard does not define which standard includes include which others, so you often miss one or two.

On the other hand, it seems strange that you had to add the "std::" qualifiers,

This one's not actually that surprising - if a std::vector's iterators are implemented as raw pointers, rather than as a type in the std namespace, then unqualified find(vec.begin(), vec.end(), ...) won't compile, since 'find' won't be found via ADL.

EKOPath uses Apache stdcxx library as its STL implementation so it's probably the case.

remove the anonymous namespace in some places (all ?)

This I can't explain - what errors are given that motivate this change?

There were several unresolved symbols coming from classes declared in these namespaces. Probably it's a bug in compiler which erroneously uses internal linking for symbols declared in anonymous namespace. For the record, this bug affects only derivatives of RecursiveASTVisitor template.

Does the link succeed if you move the out-of-line definitions of the class members into the anonymous namespace?

These classes don't have members with out-of-line definitions.

So could anybody commit llvm_ekopath.patch?