This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: New GCC takes 19x as long to compile my program (compared to old GCC), plus void** patch suggestion

Hi Ian, hi Richard, hi Andi!

Many thanks for your comments.

>>> 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,
>> You could file a bug report with just a profile output of the compiler
>> (e.g. from oprofile or perf)
> But please use a pristine FSF compiler. You can also run the source through
> some obfuscation tool. Or get a first hint with using -ftime-report.
> In the end, without a testcase there is nothing to do for us ...

I downloaded the latest official GCC 4.7.1, but unfortunately configure stopped with "Building GCC requires GMP 4.2+, MPFR 2.3.1+ and MPC 0.8.0+.", and for my CentOS Linux, only older versions of this libs are available as RPMs. I saw many hours of manual fiddling ahead, so I suggest a more efficient solution:

I now sent the confidential source file by private message to Richard, please spend 5 minutes to run these two commands with it:

time gcc -m32 -g -O0 -fno-strict-aliasing -x c -Wall -Werror -c model.i
time gcc -m32 -g -O -fno-strict-aliasing -x c -Wall -Werror -c model.i

If you don't find an enormous slowdown with the second command (please post your timings) and conclude that this problem has been introduced by Google in their custom GCC, I'll pay you 100 USD for the 5 minutes wasted.

To Ian:

Not at all high.  See Type-Based Alias Analysis
for one reason.

Thanks, I read the article, but didn't really see how forbidding a function with argument void** to accept a pointer to any pointer helps with aliasing.

If it's perfectly normal that a function with argument void* accepts any
pointer, then a function with argument void** should accept a pointer to any
pointer by analogy, without having additional aliasing problems, no?

The C and C++ languages could work that way, yes. But they don't. GCC attempts to implement the standard language.

Yep, that's why I mentioned how GCC's smart extensions to the standard language saved the day many times in the past ;-)

Aliasing issues arise when a function has two pointers, and determine
whether an assignment to *p1 might change the value at *p2.  There are
no aliasing issues with a void* pointer, because if p1 is void* then
*p1 is invalid.  That is not true for a void** pointer, so aliasing
issues do arise.  If p1 is void** and p2 is int**, then GCC will
assume that an assignment to *p1 does not change the value at *p2, as
the language standard states.  It's easy to imagine that that could
break a program after inlining.

Many thanks for the clarification, and it also points to a simple solution:

GCC could simply permit to pass a pointer to any pointer to a function, if the function argument is of type 'void **restrict myptr'.

If adding a 'restrict' to a function declaration was the only thing required to get rid of countless nasty explicit type casts, the day would already be saved. There really seem to be lots of problem classes that cannot be solved with explicit type casts otherwise. The example for loading a binary file from disk and allocating the required memory to store the file contents being just one of them...

Best regards,

> Just one more complicated example: > > A function that loads a binary file from disk and allocates the required > memory to store the file contents, returning the number of bytes read. > dstadd is the address where the newly allocated pointer is stored: > > int dsc_loadfilealloc(void *dstadd,char *filename) > { int read,size; > FILE *fb; > > if ((fb=fopen(filename,"rb"))) > { size=dsc_filesize(filename); > *(void**)dstadd=mem_alloc(size); > read=dsc_readbytes(*(void**)dstadd,fb,size); > *(void**)dstadd=mem_realloc(*(void**)dstadd,read); > fclose(fb); > return(read); } > *(void**)dstadd=NULL; > return(0); } > > Again, nasty casts all over the place, which would all disappear if GCC > allowed me to write > > int dsc_loadfilealloc(void **dstadd,char *filename) > > which could then be used to load anything from text files to an array of > 'struct foo'. >

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]