On 11 April 2012 12:00, Bob McKay wrote:
> Dear gcc-ers,
> I need to compile fairly complex (automatically generated)
> expressions using gcc. An example is attached. To allow the code to
> run reasonably fast, I assumed it would be reasonable to macro-ise the
> functions where possible (most operators need to be protected against
> overflow, since I can't control the expressions that are generated),
> and inline the rest. Inlining works fine (the code compiles in a
> fraction of a second), but macro-ising doesn't. This version of the
> code ran up to 14GB of (real) memory and ~15 minutes compilation time
> before I killed it. While it doesn't matter much to me (the inlined
> version is still a huge speed-up on the interpreter I was using till
> now), it does seem a little surprising that compiling a relatively
> simple expression should generate such overheads. I could understand
> it, I guess, if I were using aggressive optimisations; but the same
> overheads appeared even under minimum optimisation. So back to the
> question: does this look like a bug to you? Should I be reporting it?
Impossible to know, as you haven't provided the most basic information
such as which version you're using. if you're using GCC 3.1 and it
works OK with a recent version, no, definitely don't report it.
In any case, running that through the preprocessor expands to 200MB so
it's not really surprising the compiler struggles with it.
> Even better, can anyone suggest a combination of switches that will
> allow it to compile in a reasonable time and memory?
Are you sure the version using inline functions isn't just better in every way?
[Linux C Programming]
[Linux Kernel]
[eCos]
[Fedora Development]
[Fedora Announce]
[Autoconf]
[The DWARVES Debugging Tools]
[Yosemite Campsites]
[Yosemite News]
[Linux GCC]