Now lets take a simple built. gcc -c test1.c gcc -c test2.c gcc test1.o test2.o -o final
--test1.c-- /* of course in real world this would be some complex but solveable function */ int test (int a) { a=a+1; } --test2.c-- #include <stdio.h> int test(int a); /* normally in a header somewhere not bothering to put it there */ int main() { printf("hi value %i\n",test(20)); } -- back to point out problem here -- Since test is in a different object file it gets completely skiped from optimising even that it should be optimised out. Now if you build it gcc test1.c test2.c -o final it does get optimised out of existance. Common argument linker should do this. Sorry that means binutils has to have a complete duplication of the optimisation system in gcc. Now I will run threw the information that is useful that number one could pickup if something like this has happened number two allow something to be done about it. First thing is keeping two lists one of solvable functions ie functions if passed constant values will return a constant and another functions passed constant values that are extern. Comparing these lists before the objects go to linker will tell if this event has happened. Programmer can be informed and code altered avoiding events like this. Of course this is not perfect. This can go even more down the track. Producing two files. .o and .solve solve contains all solvable functions. solve can be appendable for the project. Since test1.c was built first and its solvable was put in the solve file when test2.o is processed it is solved. Now this makes it simpler for the linker it now only has to strip unused functions also avoids taking a performance hit going threw not needed code paths. Ie gcc -c test1.c -solve project.solve; gcc -c test2.c -solve project.solve. This allows location of solvable functions spread across many .o files. Of course this is not perfect programmer would either have to build everything at least twice or load them into the solve file in the correct order. Its not a magic bullet. Of course printing warning about using functions that could have been solved would be a good thing. If the gcc supports import only .solve files these could be used with libraries to reduce code as much as possible. This could be like crypt in glibc and other functions like it that when passed constant values give constant returns. Even in C++ it could have major size and speed advantages. The optimiser is missing finding functions that should be optimised out of existence due to a minor design oversite. Peter Dolding