CLN + GiNaC on MinGW

[Richard B. Kreckel]

On Mon, 3 Nov 2003, Jonathan Brandmeyer wrote:
[...]
> 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.

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

I can't believe this is the ultimate answer.

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

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

Cheers
   -richy.
-- 
Richard B. Kreckel
<Richard.Kreckel at GiNaC.DE>
<http://www.ginac.de/~kreckel/>