In article <[EMAIL PROTECTED]>,
Paul Pluzhnikov <[EMAIL PROTECTED]> wrote:
>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" ?
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
_______________________________________________
help-gplusplus mailing list
help-gplusplus@gnu.org
http://lists.gnu.org/mailman/listinfo/help-gplusplus
