never-used inlines becoming statics

Martin von Loewis martin@mira.isdn.cs.tu-berlin.de
Sun Sep 6 01:30:00 GMT 1998


> You're reproducing the problem, just that your linker can partially cope by
> the use of weak symbols.  However, not all linkers can remove common code
> this way - and this code SHOULD NOT BE GENERATED IF IT IS NOT USED.

Do you think shouting helps? I've tried to analyze why the code is
emitted, and here's what I've found:

- basic_string<char> is instantiated, it is used (in the C++ sense)
  all over the place
- In turn, clone is emitted; it is used, and not inline
- clone calls basic_string<char, string_char_traits<char>, __default_alloc_template<true, 0> >::Rep::create(unsigned int), which is inline (in clone)
- create has a local variable p
- initialization of p uses (in the C++ sense) basic_string<char, string_char_traits<char>, __default_alloc_template<true, 0> >::Rep::operator new(unsigned int, unsigned int), which is inline
- __default_alloc_template<true, 0>::allocate(unsigned int) is instantiated inline
- __malloc_alloc_template<0>::allocate(unsigned int) comes next
- this calls __malloc_alloc_template<0>::oom_malloc(unsigned int),
  which is not inline

I still can't see this as a bug; it's more a quality-of-implementation
issue. Of course, the 'implementation' extends beyond the compiler, to
assembler, linker, and operating system.

If you have patches that manage not to emit this code while not
breaking anything else, I'm sure they will be accepted. I'm not so
sure whether anybody else will do something about it.

Regards,
Martin



More information about the Gcc-bugs mailing list