C++ what can make type_info::hash_code differs for two (supposedly) same objects

Question

After trying to debug an unsuccessful dynamic downcasting, I eventually found that the reason probably is: type_info::hash_code for the type it is casted to is not the same depending where in the code it is called. type_info::name stays exactly the same though. Unfortunately I'm unable to reproduce the behavior in a minimal example since it appears in a quite entangled context. Therefore I'm essentially looking for clues of what can be the cause of such behavior, and consequently what direction I can take to solve this.

In short, if related, type looks like this (EDITED):

class A {...}

template < template <class> class>
class B : virtual public A {...}

template < template <class> class>
class C : virtual public A {...}

template < template <class> class>
class D : public B, public C {...}

template <class>
class E {...}

Issue looks like this:

D<E>* d = build_d();    
B<E>* b = d; 
A* a = d;     

dynamic_cast<D<E>*>(b);//returns correct pointer
dynamic_cast<D<E>*>(a);//returns 0, and really shouldn't !!

typeid(B<E>).hash_code();//differing depending where in the code this is called

Calls to type_info::hash_code are done inside different libraries (of my own). After digging, I found about compiler option -rdynamic with GCC (even if I'm using Clang). I'm not sure if it can be related to my problem in any way.

---

EDIT: I eventually found a good clue. No solution yet unfortunately. It appears the problem may be Qt related in the end.

Issue occurs in a slot function. When the slot is called by a signal, dynamic_cast downcasting fails. But if I manually call the slot instead (in main for instance), it succeeds. And if manually call the slot, then trigger it by the signal, it succeeds too. There's no argument for the signal, and content of the slot has been "neutralized" and doesn't depend of any parameter. 99,99% sure problem is not due to an algorithm error of allocation.

It looks like qt_static_metacall, when calling the slot, somehow lose the track of casting properties. Is the fact the associated moc being precompiled can have something to do with this ?