CLN + GiNaC on MinGW

Richard B. Kreckel kreckel at thep.physik.uni-mainz.de
Wed Nov 5 23:23:50 CET 2003


Hi!

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

That effort would be highly appreciated.

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

Errr, yes, but...  Wait, that's a good piece of sophistic dialectics!

*If* he needed those functions inline for performance, *then* it would be
a bug.  But since you never actually *need* something for performance but
rather just *long* for it.

I would say that it would be a (less severe) optimization issue.

\end{nitpick}

What are those functions that aren't being inlined, even on Linux?  I just
checked the most obvious candidates by browsing the generated assembler
and they all appear inlined on my compilation using GCC-3.3.2 with "-O2
-fno-exceptions".

Let me also point out that the fact whether any function ends up being
inlined or not highly depends on how CXXFLAGS are set.  Namely the flags
-finline-limit=<n> --param max-inline-insns-single=<m1> --param
max-inline-insns-auto=<m2> --param max-inline-insns-rtl=<m3> do have a
significant effect, independent of the platform.

So, on your platform, the success of the whole compilation depends on such
tunable compiler parameters?  If that would be true it would be quite
unfortunate.

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


More information about the GiNaC-list mailing list