[LLVMdev] C++ -> C translation problems

Reid Spencer rspencer at reidspencer.com
Sun Apr 8 10:07:18 PDT 2007


Hi Mauro,

On Sun, 2007-04-08 at 18:16 +0200, Mauro Condarelli wrote:
> Hi All,
> I am trying to use llvm compiler to translate a non-trivial piece of code from C++ to C.
> I need this because I need to use part of the code as lib for another project that is strictly C.
> I am working under MSWin and I have choice to use either BCC or MSVC.
> 
> After a good deal of tries I found out I had to somewhat massage llc
> -march=c output to make it *almost* compilable.

The target for the CBE output is gcc so its not surprising a number of
changes needed to be made to get it to compile with another compiler.
Eventually we'd like to be able to specify different compiler variants.
For example, vector support (if we ever support it) would need to be
done with extensions. GCC has a set of builtins and attributes to deal
with vectors. We could use these but then it isn't "plain C" any more.  

Anyway, as you can imagine, there are numerous issues with making this
portable to multiple compilers.

> 
> I have one residual problem I'm unable to overcome :(
> 
> I reduced the test program to real minimal version:
> ===================================================
> class File {
> public:
>    File() {}
>    virtual ~File() {}
> };
> 
> class showError : public File {
> public:
>    showError(void);
>    ~showError(void);
> };
> 
> showError::showError(void) {
>    //
> }
> 
> showError::~showError(void) {
>    //
> }
> ===================================================
> The acid is the "virtual" specifier in "virtual ~File() {}". If I
> remove it then BCC32 compiles the resulting program, else it bombs
> with "Error E2063 terr.c 153: Illegal initialization".

Okay. 

> 
> For the whole compilation I use the following .bat file:
> ===================================================
> rm err.bc
> .\..\..\LLVM\bin\llvm-g++ -I../LLVM/include -Wno-deprecated -I../unrar -emit-llvm -c err.cpp -o err.bc
> rm err.cbe.c
> .\..\..\LLVM\src\llvm-1.9\Release\bin\llc -march=c err.bc
> 
> sed "s/!defined(_MSC_VER)/!defined(_MSC_VER) \&\& !defined(__BORLANDC__)/" err.cbe.c >t1
> 
> sed "s,__stdcall ,/*__stdcall*/ ,g" t1 >t2
> sed "s/_$_/_S_/g" t2 >t3
> sed "s/_2$_/_2S_/g" t3 >terr.c
> rm t1 t2 t3
> "C:\Program Files\Borland\BDS\4.0\bin\bcc32" -I"C:/Program Files/Borland/BDS/4.0/include" -I../unrar -p- -c terr.c
> ===================================================
> 
> I won't send the (rather long) terr.c, but it is (obviously) available on request.
> 
> The offending line is:
> ===================================================
> ..
> /* Global Variable Definitions and Initialization */
> vvvvvv this is the culprit vvvvvv
> struct l_struct_2E___si_class_type_info_pseudo _ZTI9showError
> __ATTRIBUTE_WEAK__ = { { ((signed char
> *)(((unsigned )(&_ZTVN10__cxxabiv120__si_class_type_infoE)) + 8u)),
> (&(_ZTS9showError[0])) }, ((struct opaque_0 *)(&_ZTI4File)) };
> ^^^^^^ this is the culprit ^^^^^^

There's a number of things here. First, it could be __ATTRIBUTE_WEAK__.
Can you provide the pre-processed version of this lines?

Another possibility is that the BCC compiler just can't handle this
aggregate initialization. I don't see anything wrong with it. Its simply
a structure with three fields being initialized with the address of
three symbols. Two are casted. I don't know why this confuses the BCC
compiler.

GCC compiles it just fine.


> signed char _ZTS9showError[11] __ATTRIBUTE_WEAK__ = "9showError";
> ..
> ===================================================
> 
> I'm using latest stable version (I downloadad it last week).
> 
> Also cl doesn't work; first problem is it doesn't like "long long"...
> 
> Please HHHEEEEEELLLLLPPPPPPP!! :)

I think perhaps you should be talking to Borland about this.

> 
> Best Regards
> Mauro
> 
> 
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev




More information about the llvm-dev mailing list