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/>

On Mon, 2003-11-03 at 15:10, Bruno Haible wrote:

Richard,

...

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.

The need to inline a function in some places and not in others came from three situations:

1) Some functions, like cl_SF_zerop or cl_FF_zerop, are just a single machine instruction when inlined, but I don't want to put the inline definition into the .h file because that would expose too many internals of the library in the .h file (leading to 1. violation of abstraction, 2. increased compilation times). Still I want to use the inline version of these functions in the library itself.

2) Some functions, like cl_{SF,FF,DF,LF}_idecode, are usually only invoked through a dispatcher cl_F_idecode that does nothing but dispatch the call to the right function. Here inlining is used, regardless of the size of the inlined functions, because it removes one function call from the chain of function calls. A compiler cannot know that this caller is the main caller for the 4 inlined functions.

3) Similarly, cl_I_from_NDS would be a bottleneck if not inlined: every creation of a new cl_I goes through this function. A compiler cannot know a priori the bottlenecks.

In each case, I read the assembler output in order to verify that g++ had really inlined the functions as I wished.

Bruno

Thanks for the analysis. It turns out that not all of these functions are being inlined now, although I trust you when you say that they were in the past. Instead, several cases are being emitted as weak symbols out-of-line and then being linked against the global copy. Since weak symbols are not supported on MinGW (probably a PE/COFF limitation), they are instead causing multiple definition errors. There is a way to prevent this from happening. If the functions in question are defined like this: // Declaration qualifiers ret-type foo( args) FORCE_INLINE; MAYBE_INLINE ret-type foo( args) { ... } The calling functions can #define FORCE_INLINE to be __attribute__((always_inline)) to force inlining. This define must be provided before #including the header for the function being inlined. I cannot read assembly code. However, I have used the output from nm to verify the behavior I have described. Would you accept a patch that implemented this change? Thanks, Jonathan Brandmeyer

On Tue, 2003-11-04 at 17:12, Richard B. Kreckel wrote:

Perhaps a naive question: If there is no support for weak symbols or something like this, then the compiler is forced to always inline whenever somebody says "inline", right? How then, does the compiler handle extreme cases where inlining cannot be done because of recursions, mutually inlined functions, and other such things???

After browsing the assembly code, it looks like "or something like this". If a function is marked inline and emitted out of line, it is placed into a section named ".text$[mangled name of the function]". The next line is ".linkonce discard" Normal functions are simply placed in the ".text" section. I am guessing that the linker can resolve all of the specially named sections to a single one, but cannot resolve that down to an identically named function in the ".text" section.

Only grudginly so. But if this turns out to work and there *really* is no other way on that platform, then possibly.

I'll ask on the binutils list to see if there is a workaround. Besides, if Mr. Haible needed those functions inline for performance, than isn't the fact that they are not being inlined, even on Linux, a bug in its own right? -Jonathan Brandmeyer