CLN + GiNaC on MinGW

[Richard B. Kreckel]

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 at GiNaC.DE>
<http://www.ginac.de/~kreckel/>