gcc name bug?
-- System Information -------------------------------------------
Debian Release: stable on Pentium III
Kernel Version: Linux 2.2.18pre21/2.2.19
gcc version: 2.95.2
-----------------------------------------------------------------
Hi,
While trying to optimize some C code for speed, we have
encountered what we think is a very strange bug with gcc: the
execution time depends on the name of the executable (!). As an
example, here is a bares bones C code snippet which reproduces
the problem:
/* strange.c ==================================================*/
#define N 1000000000
double content()
{
return 0;
}
int main()
{
int i;
double bucket=0;
for (i=0; i<N; i++)
bucket += content();
return 0;
}
/*=============================================================*/
When we compile this program (gcc strange.c) and time its
execution (time a.out) we obtain:
real 0m23.247s
user 0m23.240s
sys 0m0.000s
where "user" is the time we are interested in. Upon renaming the
executable we find two widely different execution times:
trial name of executable user time (s)
---------------------------------------------------------
1 a 23.24
2 aa 23.25
3 aaa 23.24
4 aaaa 23.24
5 aaaaa 49.92
6 aaaaaa 49.91
7 aaaaaaa 49.92
8 aaaaaaaa 49.92
9 aaaaaaaaa 49.91
10 aaaaaaaaaa 49.90
11 aaaaaaaaaaa 49.90
12 aaaaaaaaaaaa 49.94
13 aaaaaaaaaaaaa 23.24
14 aaaaaaaaaaaaaa 23.21
15 aaaaaaaaaaaaaaa 23.39
16 aaaaaaaaaaaaaaaa 23.62
17 aaaaaaaaaaaaaaaaa 23.79
18 aaaaaaaaaaaaaaaaaa 23.82
19 aaaaaaaaaaaaaaaaaaa 23.57
20 aaaaaaaaaaaaaaaaaaaa 22.83
21 aaaaaaaaaaaaaaaaaaaaa 48.06
22 aaaaaaaaaaaaaaaaaaaaaa 49.02
23 aaaaaaaaaaaaaaaaaaaaaaa 49.93
24 aaaaaaaaaaaaaaaaaaaaaaaa 49.91
etc.
---------------------------------------------------------
We are not familiar with the intricate workings of the compiler,
but this must have to do with an alignment problem when the
executable is launched, as the changes typically occur when the
name length is increased by 8 bytes. This is a serious bug since
in our simple example it more than doubles the execution time
when we choose a "bad" name!
We have reproduced the problem on Pentium III machine with gcc
2.95, with a variety of kernels, and with C and C++ codes of
varying complexity. The "time" function is not the culprit, since
we can confirm our results with a wall clock.
We would like to know:
1) Does this behavior occur on other systems?
2) Is this a known issue?
3) Can the cause of the problem be identified?
4) Is there any workaround (e.g. compiler option)?
Thanks a bunch,
Fred.
Reply to: