This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug c/66682] Lots of macro expansion, very slow compilation
- From: "cr88192 at gmail dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Fri, 26 Jun 2015 15:32:04 +0000
- Subject: [Bug c/66682] Lots of macro expansion, very slow compilation
- Auto-submitted: auto-generated
- References: <bug-66682-4 at http dot gcc dot gnu dot org/bugzilla/>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66682
cr88192 at gmail dot com changed:
What |Removed |Added
----------------------------------------------------------------------------
Version|unknown |4.8.2
--- Comment #3 from cr88192 at gmail dot com ---
(In reply to Manuel LÃpez-IbÃÃez from comment #2)
> Note that this code is not really "stand-alone": See
> https://gcc.gnu.org/bugs/#need
Testing: -ftrack-macro-expansion=0
Linux (4.8.2): 6m41s
Windows (4.5.2 and 4.5.3):
cc1.exe: error: unrecognized command line option "-ftrack-macro-expansion=0"
As for standalone:
It compiles by itself (doesn't need external headers or other things).
Command-line:
time gcc -o natcall_lnx.elf natcall_sa.c
Compiler output:
no messages normally.
Temporaries files: generally too big to upload:
5MB for the .i file;
14MB for the .s file;
3MB for the .o file.
Noticed: both GCC and MSVC seem to generate approximately the same-sized output
files (so, it doesn't seem the amount of data is all that much different).
The generated output seems to work correctly, but it is just rather slow.
For contrast:
MSVC compiles the same code in about 2 seconds;
My own experimental compiler does it in 6 seconds
( It targets the VM the code is from )
It seems like there may be "something wrong" for it to be so slow.
More so, rebuilding something on Linux taking a long time (around an hour or
so) is a bit questionable, when MSVC on Windows does the same thing in a matter
of seconds.