On Tue, 15 Apr 2014, DJ Delorie wrote:
I wasn't sure what to do with that array, since it was static and couldn't have "empty" slots in them like the arrays in tree.h. Also, do we need to have *every* type in that list? What's the rule for whether a type gets installed there or not? The comment says "guaranteed to be in the runtime support" but does that mean "for this particular build" (wrt multilibs) as not all intN types are guaranteed (even the int128 types were not guaranteed to be supported before my patch). In other parts of the patch, just taking out the special case for __int128 was sufficient to "do the right thing" for all __intN types.
You need someone who understands this better than me (ask Jason). To be able to throw/catch a type, you need some typeinfo symbols. The front-end generates that for classes when they are defined. For fundamental types, it assumes libsupc++ will provide it, and the function you are modifying is the one generating libsupc++ (I am surprised your patch didn't cause any failure on x64_64, at least in abi_check). We need to generate the typeinfo for __intN, either in libsupc++, or in each TU, and since both cases will require code, I assume libsupc++ is preferable.
I can certainly put the intN types in there, but note that it would mean regenerating the fundamentals[] array at runtime to include those types which are supported at the time.
After the patch I linked, it should just mean calling the helper function on your new types, no need to touch the array.
Do the entries in the array need to be in a particular order?
No, any random order would do. -- Marc Glisse
