http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2316
--- Comment #38 from Marc Glisse <marc.glisse at normalesup dot org> 2012-01-02 10:39:35 UTC --- Thanks for the comments. (In reply to comment #36) > The library should overload qsort, then the libitm/clone.cc change wouldn't be > needed Indeed, that was the meaning of my comment "provide the true qsort prototype instead", I'll do that next time. (In reply to comment #37) > I think the change to tree.c should not be done as it is middle-end code. > That > should be in the C++ front-end specific code instead. That is the middle-end > should not care about the difference between extern "C" function types and > extern "C++" ones. That makes sense. I am surprised to see that I only use the new function once outside of the cp/ directory, and I don't even know whether that is really necessary. On the other hand, there may be other places I missed that need to preserve this information while building variants of the type. And keeping it in tree.c avoids duplicating this code. Maybe it would make sense to keep it in the middle-end, making the extra field an opaque "extra information" that the middle-end needs to preserve if it ever builds type variants? Although if it clones the function in some way, preserving the linkage may not make that much sense. (I don't have any experience so I may talk nonsense ;-) This information is supposed to be related to the calling convention (although the g++ ABI uses the same in all cases), which I guess is relevant to pass down to middle and back-end (then it isn't opaque anymore). The functions like __builtin_memcpy declared in tree.c should probably have "C" linkage. Which means it might be better if I switched to using a non-zero value for "C++" linkage (or at least make build_function_type build a C linkage type by default) so I don't interfere as much with the rest. So many choices... Well, that's for the next holidays unless someone else wants to work on it.
