Play with the C++ compiler - compile nightmare

xiangfan — Mon, 15 Sep 2008 17:49:00 GMT

Playing with the compiler is interesting. One challenge for the compiler writer is compilation performance. There're many kinds of C++ code which are the nightmare for the compiler. Now let's go!

1. Preprocess

a. Self Inclusion (GCC only)
Normally, the compiler will limit the nest level of inclusion. In order to challenge the compiler, you have to stop the inclusion at appropriate stage. GCC provides a useful macro __INCLUDE_LEVEL__ to do the work.
(We can write similar code for other compiler, although less elegant)

#if __INCLUDE_LEVEL__<199
#include __FILE__
#include __FILE__
#endif

b. Macro Expansion Explosion
By using macro, the code after the preprocess may reach O(2ⁿ). For example:

#define F1(x) x,x
#define F2(x) F1(x),F1(x)
#define F3(x) F2(x),F2(x)
#define F4(x) F3(x),F3(x)
#define F5(x) F4(x),F4(x)
#define F6(x) F5(x),F5(x)
#define F7(x) F6(x),F6(x)
#define F8(x) F7(x),F7(x)
#define F9(x) F8(x),F8(x)
#define G1(x) F9(x),F9(x)
#define G2(x) G1(x),G1(x)
#define G3(x) G2(x),G2(x)
#define G4(x) G3(x),G3(x)
#define G5(x) G4(x),G4(x)
#define G6(x) G5(x),G5(x)
#define G7(x) G6(x),G6(x)
#define G8(x) G7(x),G7(x)
#define G9(x) G8(x),G8(x)

int main()
{
G9(1);
}

Of course, different compilers handle this kind of overflow differently. GCC will fail directly (when all of the resource are eaten up), and VC will give ICE (Internal Compiler Error).

2. Template

a. Nesting
Similarly, there're nest level limit for template, but we can easily deceive the compiler.
Some version of GCC will enter infinite loop when compiles the following code:

#include <cstddef>
template <class T>
struct Test {
static const size_t Value=Test<Test<T> >::Value;
};

VC is wise enough to stop when the nest level limit is exceeded in the above code. But we can use one of VC's bug (you can also treat it as an extension) to write template which requires O(n^a) compilation time:

#include <cstddef>

#define INNER(A3,N3,A2,N2) \
template<size_t N3>\
struct A3\
{\
    enum {N=A3<N3-1>::N+1};\
};\
template<>\
struct A3<0>\
{\
    enum {N=A2<N2-1>::N};\
};

#define OUTER(A2,N2,A1,N1,A3,CONTENT) \
template<size_t N2>\
struct A2\
{\
    CONTENT\
    \
    enum {N=A3<N2>::N};\
};\
template<>\
struct A2<0>\
{\
    enum {N=A1<N1-1>::N};\
};

#define LEVEL2(a,b,c) INNER(A##b,N##b,A##a,N##a)
#define LEVEL3(a,b,c) OUTER(A##b,N##b,A##a,N##a,A##c,LEVEL2(a##1,b##1,c##1))
#define LEVEL4(a,b,c) OUTER(A##b,N##b,A##a,N##a,A##c,LEVEL3(a##1,b##1,c##1))
#define LEVEL5(a,b,c) OUTER(A##b,N##b,A##a,N##a,A##c,LEVEL4(a##1,b##1,c##1))

template<size_t N1>
struct A1
{
    LEVEL5(1,11,111)
    enum {N=A11<N1>::N};
};
template<>
struct A1<0>
{
    enum {N=0};
};

int main()
{
    return A1<20>::N;
}

The interesting thing is that, the standard doesn't allow this kind of specialization in template class. Is this a bug or extension of VC?
A member or a member template may be nested within many enclosing class templates. In an explicit specialization for such a member, the member declaration shall be preceded by a template<> for each enclosing class template that is explicitly specialized.

Based on similar idea, we can write portable version for both GCC and VC.

#define INNER(A3,N3) \
template<class N3>\
struct A3\
{\
    static void f() {}\
};

#define OUTER(A2,N2,A1,CONTENT) \
template<class N2>\
struct A2\
{\
    CONTENT\
    \
    static void f() {\
        A1<char>::f();\
        A1<short>::f();\
        A1<int>::f();\
        A1<long>::f();\
        A1<unsigned char>::f();\
        A1<unsigned short>::f();\
        A1<unsigned int>::f();\
        A1<unsigned long>::f();\
    }\
};

#define LEVEL2(a,b) INNER(A##a,T##a)
#define LEVEL3(a,b) OUTER(A##a,T##a,A##b,LEVEL2(a##1,b##1))
#define LEVEL4(a,b) OUTER(A##a,T##a,A##b,LEVEL3(a##1,b##1))
#define LEVEL5(a,b) OUTER(A##a,T##a,A##b,LEVEL4(a##1,b##1))
#define LEVEL6(a,b) OUTER(A##a,T##a,A##b,LEVEL5(a##1,b##1))
#define LEVEL7(a,b) OUTER(A##a,T##a,A##b,LEVEL6(a##1,b##1))
#define LEVEL8(a,b) OUTER(A##a,T##a,A##b,LEVEL7(a##1,b##1))

LEVEL8(1,11)

int main()
{
    A1<int>::f();
}

b. Multiple inheritance
C++ allows multiple inheritance, it can be used to hang the compiler. Try the following "Fibonacci" inheritance:

template<size_t N>
class Evil:virtual public Evil<N-1>,virtual public Evil<N-2>
{
public:
virtual ~Evil() {}
};

template<>
class Evil<1>
{
};
template<>
class Evil<0>
{
};

int main()
{
Evil<100> evil;
}

c. OLE (Output limit exceeded)
Normally, the compile time for template is O(n), but in contrast, the amount of error message will be O(n²). Taking advantage of this, you can make the error message "Output Limit Exceeded". For example:

#define ClassName A

template <int N>
class ClassName
{
enum {Value=ClassName<N-1>::Value};
};

int main()
{
int n=ClassName<0>::Value;
}

If I change "ClassName" to a very long name (which is widely supported by modern compilers), the error message will be easily OLE.
PS: The above code will cause ICE in VC8. This is the bug of VC8, and VC9 is happy with the code.

Magic behind ValueType.Equals

xiangfan — Mon, 01 Sep 2008 18:35:00 GMT

In "Effective C#", Bill Wagner says "Always create an override of ValueType.Equals() whenever you create a value type". His main consideration is the performance, because reflection is needed to compare two value types memberwisely.

In fact, the framework provides optimization for "simple" value type. Let's find out the magic.

Here is the code disassembled by Reflector:

bool Equals(object obj)
{
    //Compare type

    object a = this;
    if (CanCompareBits(this))
    {
        return FastEqualsCheck(a, obj);
    }

    //Compare using reflection
}

The magic is the two functions "CanCompareBits" and "FastEqualsCheck". They both have attribute "[MethodImpl(MethodImplOptions.InternalCall)]", which indicates that their implementations are in native dlls.

Walkthrough the source of rotor, you can find that these functions are in "clr\src\vm\comutilnative.cpp"

The comment of CanCompareBits says "Return true if the valuetype does not contain pointer and is tightly packed". And FastEqualsCheck use "memcmp" to speed up the comparison.

Then you may think you can safely rely on this optimization and stick to the default ValueType.Equals implementation. But wait a minute. Do you find anything wrong in CanCompareBits?

The problem is that the condition in the comment doesn't ensure the bitwise comparison to work.

Imagine you have a structure which only contains a float. What will occur if one contains +0.0, and the other contains -0.0? They should be the same, but the underlying binary representation are different.
If you nest other structure which override the Equals method, that optimization will also fail.

This should be a bug. But it also provide another reason for why you should always implement your own instance Equals for ValueType.

Van's House : Bug

Play with the C++ compiler - compile nightmare

Magic behind ValueType.Equals