This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

typeinfo problem (bug?)

Hi everyone,

I've run into a problem with std::type_info.

It appears that hidden visibility can cause multiple instances of a type_info object for one type, hence RTTI information is not being merged across SSO and DSO boundaries.  :-(

Is there an appropriate flag to specify to the compiler that will cause __GXX_MERGED_TYPEINFO_NAMES to be defined as 1?

I supposed I can just -D__GXX_MERGED_TYPEINFO_NAMES ... but I was under the impression that the __GXX_WHATEVER preprocessor defines shouldn't be twiddled by hand.

Perhaps I'm mistaken about refraining from specifying -D__GXX_WHATEVER on the g++ command line?

- - - - - - - - - - - - - - - - - - - - -

Also (incidentally & unrelated to the above), it is very weird that __GXX_MERGED_TYPEINFO_NAMES has two different semantics.  Specifying __GXX_MERGED_TYPEINFO_NAMES has two unrelated orthogonal effects:
1. are the before() and operator==() routines inline or function calls
2. are the before() and operator==() routines lightweight pointer compares or slightly more costly string compares

I'd like to have inline routines using __builtin_strcmp.  But I can imagine some situations where __builtin_strcmp is desired, but only as function calls and not inline.

__GXX_MERGED_TYPEINFO_NAMES == 0 means "strcmp & function calls".
__GXX_MERGED_TYPEINFO_NAMES == 1 means "pointer compares & inline".

There's no "strcmp & inline" (what I want), nor is there "pointer compares & function calls".  Hmmmm.

I'm using GCC 4.0.1, so perhaps this has been fixed by now.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]