Hi! On Sat, 1 Nov 2003, Jonathan Brandmeyer wrote:
Wait! -finline-functions is something which is switched on with -O3 normally. Now, I do know that there used to be such unresolved symbols with -O3. Since not much else is switched on with -O3 (only register renaming), maybe that would be the culprit? Could you please try without -finline-functions and see how it goes?!
Sorry it took so long to get back to you on this. The first time I did this I recieved several multiple definition errors.
Sorry, I do not understand. The first time you did *what*? Switch *off* -finline-functions??
After a lot of digging I worked around the problem my not using MAYBE_INLINE in all of the places I recieved errors. In each case the code being declared MAYBE_INLINE was fairly large, certainly larger than I would consider for an inline function.
Well, this is why it is only *selectably* inlined, I guess. :-) Seriously, pointing a disassembler at the generated .o files I see that the stuff declared MAYBE_INLINE is generally quite small. There are a few exceptions, however. These exceptions are the functions defined in cl_RA_sqrt.cc, cl_I_from_NDS.cc and in all the cl_*_idecode.cc. I slightly wonder why they got marked MAYBE_INLINE, but frankly, I don't care too much.
I finally got a libcln-2.dll and both 'exam' and 'test' passed.
I have a couple of additional questions. 1) Why does CLN use MAYBE_INLINE at all? Defining a function inline in one compilation unit and not inline in another sounds like a bad idea to me.
Why? If it ends up not being inlined in not more than one compilation unit everything is fine! This technique makes inlining manually selectable, something which is otherwise not possible with plain C++ where you either declare your functions inline or you don't. Isn't it smoewhat strange that Standard C++ puts this decision *only* into the hands of the programmer of the callee? It does not furnish the programmer of the caller with any authority on the matter of inlining! There does seem to be some degree of consensus among the maintainers of GCC that the matter is indeed not entirely asymmetric, as it appears on first sight. This became clear during the course of the recent (heated) discussion about the meaning of the keyword "inline". There, it was asserted by some that the builtin case-by-case heuristics is usually better than the programmer's intuition. [Gaby: please don't shoot me now! The question boils down to whether the heuristics are better than a good C++ programmer's reasoning or a bad programmer's "intuition". Anyway, this is going too far.] But in the end, I haven't done the analysis which led to the decisions what to MAYBE_INLINE in CLN and what not. Bruno Haible did it back in the days of GCC 2.7, I guess. And I suppose that he did this as he usually does: by carefully reading the assembler output and basing these decisions on deeper insights than by looking at the sources. Bruno?
2) What does CLN do that interferes with GCC's function inlining logic such that all of those undefined references pop up?
Nothing. I think now you're confused. You were complaining about undefined references to functions like _GLOBAL__I_cl_module__foo_bar and similar in your first email, and these are entirely unrelated to the functions declared MAYBE_INLINE. I believe these issues are a compiler bug triggered by the PROVIDE/REQUIRE scheme in include/cln/modules.h when -finline-functions is turned on. Current GCC mainline does seem to be doing a better job, so I don't think anything should be "fixed" in CLN. Regards -richy. -- Richard B. Kreckel <Richard.Kreckel@GiNaC.DE> <http://www.ginac.de/~kreckel/>