Intel Compiler issue with aligned template class: declaration does not declare anything?

[erwincoumans]

When compiling Bullet 2.68 physics library, the following code doesn't compile with the Intel compiler , but fine with most others (gcc, MSVC etc). Error is:

1>....srcBulletCollisionBroadphaseCollisiontAxisSweep3.h(58): error: declaration does not declare anything

You can reproduce this by downloading the latest open source Bullet 2.68 physics library from google code, and convert the visual studio 2005 (8) projectfile to Intel.

Here are some details:

Intel compiler version Intel C++ 10.1.021 [IA-32], on Visual Studio 9, Vista 32bit.

#define ATTRIBUTE_ALIGNED16(a) __declspec(align(16)) a

template
class btAxisSweep3Internal : public btBroadphaseInterface
{
protected:

public:

public:
//Intel C++ compiler 10.1.021 doesn't compile when aligning this class
ATTRIBUTE_ALIGNED16(class) Handle : public btBroadphaseProxy// <--------- line 58 fails on Intel compiler
//class Handle : public btBroadphaseProxy // <----- this works fine
{
public:
BT_DECLARE_ALIGNED_ALLOCATOR();

// indexes into the edge arrays
BP_FP_INT_TYPE m_minEdges[3], m_maxEdges[3];// 6 * 2 = 12
//BP_FP_INT_TYPE m_uniqueId;
BP_FP_INT_TYPE m_pad;

//void* m_pOwner; this is now in btBroadphaseProxy.m_clientObject

SIMD_FORCE_INLINE void SetNextFree(BP_FP_INT_TYPE next) {m_minEdges[0] = next;}
SIMD_FORCE_INLINE BP_FP_INT_TYPE GetNextFree() const {return m_minEdges[0];}
};// 24 bytes + 24 for Edge structures = 44 bytes total per entry

Is this a bug?

Thanks,

Erwin

by the way, removing the alignment is a workaround, but would be nice to leave the class aligned. Dynamic allocated objects are already aligned anyway, and stack objects can be explicitly aligned.

[Dale_S_Intel]

Sorry for the delay in responding, but it does look like it might be a compiler bug. I'll see if I can confirm that and if I can come up with a workaround. If it does turn out to be a compiler bug, I'll post again here when it's fixed.

Thanks!

Dale

[Dale_S_Intel]

OK, third time's a charm :-)

I think I have a firm answer now, however subtle it may be.

The problematic line is in btAxisSweep3.h and looks something like this (the original inherits from btBroadphaseProxy but that's not important right now):

ATTRIBUTE_ALIGNED16(class) Handle

which expands to

__declspec(align(16)) class Handle

MS accepts this OK, but it can be ambiguous, e.g. if it were

__declspec(align(16)) class Handle {...} foo;

it would be unclear whether the alignment applied to the instance 'foo' or to the class 'Handle'. For that reason it is safer to declare it as follows:

class __declspec(align(16)) Handle

or using the original macro it could be written as

class ATTRIBUTE_ALIGNED16(Handle)

assuming that is consistent with the intentions of the author of the macro. This has two benefits, it avoids the ambiguity in the original, so that the alignment attribute clearly applies to all instances of class 'Handle', and it works with icl.

This is considered a bug and will be fixed in a future release, I'll try to remember to post here when that release is available. In the meantime, if you're game, try patching the source and see if it works for you. I also had to enable run-time type support ("C/C++"->Languages->"Enable Run-Time Type Info") but then the whole thing seemed to build ok for me.

Thanks!

Dale

[erwincoumans]

Thanks for the reply.

The reason for the macro is that on other compilers, such as gcc, we can use this one for alignment of the class:

#define ATTRIBUTE_ALIGNED16(a) a __attribute__ ((aligned (16)))

Is that still compatible with class ATTRIBUTE_ALIGNED16(Handle) ?

Thanks,

Erwin