Re: Forcing instantiation of static class functions

[Mike Harrold]

In article <m31whuc29r.fsf@somewhere.in.california.localhost>,
Paul Pluzhnikov  <ppluzhnikov-nsp@charter.net> wrote:
>Mike Harrold <mike@nospam.com> 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" ?

A file contain a class.

>Does "this unit" call foo() ?

No.

>
>If it doesn't, why do you care whether code for foo() is emitted
>or not?

Because other units do.

>> 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?

It needs to be defined somewhere otherwise the program doesn't link.

>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.

It does. The header file is generated from the .cc file.
I should have added that everything is compiled with the
 -fno-default-inline switch to prevent functions being
inlined.

>> 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()?

No. I want a switch that forces the emission of code for all static
functions in a class. (I've subsequently found that this isn't limited
to static functions. The compiler isn't emitting member functions
either.) What I really want is to know what changed with regard to
code emission. I have looked through the docs, and can't find anything.

>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.

True, but unnecessary in this instance. I just want the class files.

>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.

Not at all; my program compiles _and links_ fine on gcc-3.2 and
gcc-3.4. It will not link with gcc-4.1 with several thousand
"undefined reference" errors...

Regards,

/Mike