On Wed, Aug 8, 2012 at 4:01 PM, Elmar Krieger <el...@cmbi.ru.nl> wrote:
> Dear all,
>
> while I fully understand that GCC's steadily advancing optimization
> capabilities can't be 'for free', the latest versions have become almost
> unusably slow for me:
>
> With simple optimization -O, compiling a certain C source file (~60000
> lines) now takes 4.5 minutes, while older GCCs did it in 14 seconds (that's
> 19x as long, requiring a cup of coffee after each code change). (Core i7
> CPU).
>
> For completeness, these are the GCC versions:
>
> Slow with 264 seconds:
>
> i686-linux-android-gcc (GCC) 4.6.x-google 20120106 (prerelease)
> Copyright (C) 2011 Free Software Foundation, Inc.
>
> Fast with 14 seconds:
>
> i386-mingw32msvc-gcc (GCC) 3.2.3 (mingw special 20030504-1)
> Copyright (C) 2002 Free Software Foundation, Inc.
>
> The slowdown is not the same with other files, so I'm essentially sure that
> this specific source file has some 'feature' that catches GCC at the wrong
> leg. This raises my hopes that one of the GCC experts wants to take a look
> at it. The code is confidential, but if you agree on one expert to have a
> look, I'll provide it privately (please contact elmar _at_ cmbi.ru.nl).
> Could be related to the fact that this particular source file contains the
> application's main loop, a single large function with 28000 lines.
Neither version is a pristine FSF released GCC (not to mention the
huge timespan this regression spans). As the slowdown is for a specific
file it could be due to patches the vendors put in.
I suggest to narrow down the slowdown to a single file, produce preprocessed
source (that happens to compile with both compiler versions) and file a bug
so people can investigate.
Richard.
> One other thing I just thought of: GCC has a history of very smart
> extensions to C that allow to write faster and more elegant code. If I look
> at my code, there are mostly two sources of 'dirty hacks' left. One that
> could be fixed easily is the 'void** pointer problem', that clutters my code
> with nasty explicit type casts:
>
> A simple example is the function freesetnull, that frees a pointer and sets
> it NULL (ptradd is a pointer address):
>
> void freesetnull(void **ptradd)
> { free(*ptradd);
> *ptradd=NULL; }
>
> Unfortunately, this function cannot be used in practice, because calling it
> yields an error:
>
> error: passing argument 1 of ‘freesetnull’ from incompatible pointer type
> note: expected ‘void **’ but argument is of type ‘char **’
> [or whatever pointer you want to free]
>
>
> If I understand correctly from a Usenet discussion, the reason for this
> error is that the C standard allows pointers to have different sizes (so
> sizeof(void*) might be larger than sizeof(int*) or so).
>
> To get rid of this error, I need to sacrifice type safety and clutter my
> code with explicit casts, e.g.
>
> void freesetnull(void *ptradd)
> { free(*(void**)ptradd);
> *(void**)ptradd=NULL; }
>
> But since I've never seen such an exotic architecture with different pointer
> sizes and am 100% certain that my application will never run on such an
> architecture, I feel the strong need to sit down and contribute a GCC patch
> that turns this error into a warning that can be disabled (on mainstream
> architectures where all pointers have the same size).
>
> To me, that just looks like a remnant from the ancient past that hinders the
> future. On the other hand, my feeling tells me that this patch would not be
> accepted, that's why I'm asking for my chances in advance ;-)
>
> Best regards and many thanks,
> Elmar
