Mike Harrold <[EMAIL PROTECTED]> writes:
> I have a class that looks like this:
>
> class X
> {
> public:
>
> static void foo() {
> do_something();
> }
> };
...
> Since moving to gcc-4.1 (from gcc.3.4) I notice that gcc is no
> longer emitting the code for foo() inside this unit.
What is "this unit" ?
Does "this unit" call foo() ?
If it doesn't, why do you care whether code for foo() is emitted
or not?
> The only way
> that I have (so far) discovered to force this is to use the
> __attribute__ ((used)) functionality.
Ok, so this unit does not call foo(), yet you want it to be defined
in this unit. What for?
Presumably so some other unit can call it. But whichever unit does,
should have the same definition of foo(), or your program is
ill-formed.
> Is there a command line switch that changes this behaviour? (And
> not -fkeep-inline as it keeps all inline functions in the module,
> which in many cases is several hundred per unit because of all the
> included header files!)
You want a switch, that will prevent discarding unused foo(),
but will not prevent discarding similarly unused bar()?
How could compiler possibly know that foo() is different from bar() ?
Besides, you didn't say what platform you are on, but on ELF inline
functions are put into LINK_ONCE_DISCARD sections, so it doesn't
really matter how many such functions you have in each compilation
unit (disk space is cheap) -- you end up with only one copy in the
final executable.
Finally, when I compile your test on Linux with gcc-3.3.3,
I do not get a definition of X::foo(), and I bet your gcc-3.4
doesn't emit it eiter (for that test case). IOW, you are not telling
the whole story, and omitting some very relevant parts.
Cheers,
--
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.
_______________________________________________
help-gplusplus mailing list
help-gplusplus@gnu.org
http://lists.gnu.org/mailman/listinfo/help-gplusplus
