(In reply to Andrey Vihrov from comment #0)
> -fwhole-program is that it can be used with one source file that includes
> standard library headers and links with the standard library. If this is
> wrong, then I'm sorry for filing a bogus bug report.

I don't know if it's supposed to work (I would expect not), but using -fwhole-program with _GLIBCXX_DEBUG seems silly to me. The Debug Mode macro can slow things down by an order of magnitude, so the advantages of -fwhole-program will be minimal anyway.

Is there a reason you can't use -flto instead?

Thanks for a fast reply!

My use case for these two (amongst several others) options together is competitive programming, in which a contestant is required a write a one-source-file solution, test it locally and submit it to a grading server. Debug Mode helps detect mistakes, and -fwhole-program helps find variables or functions that I defined and intended to use, but forgot to. For example, for this source:

int unused;

int main()
{

}

"g++ -Wall -fwhole-program x.cpp" gives

x.cpp:1:5: warning: 'unused' defined but not used [-Wunused-variable]

, and there is no warning without -fwhole-program. Of course, I can get the same effect by making everything "static", but this depends on me remembering to do it, so this option is better in this regard. -flto doesn't have the same effect.

If -fwhole-program isn't supported in this case, then it's fair enough. But then it would be great if the documentation on -fwhole-program was updated to clarify when the option can be used and when not.

I compiled the example program without and with -fwhole-program to assembly code, and here are the differences: http://pastie.org/9859649

As I understand, normally the ".weak" directive ensures that there is only one definition of std::string::_Rep::_S_empty_rep_storage per whole program. But with -fwhole-program the .weak directive disappears, and instead another local definition is created.

Looking at libstdc++ source code, I see

// The following storage is init'd to 0 by the linker, resulting
// (carefully) in an empty string with one reference.
static size_type _S_empty_rep_storage[];

. . .

// Linker sets _S_empty_rep_storage to all 0s (one reference, empty string)
// at static init time (before static ctors are run).
template<typename _CharT, typename _Traits, typename _Alloc>
typename basic_string<_CharT, _Traits, _Alloc>::size_type
basic_string<_CharT, _Traits, _Alloc>::_Rep::_S_empty_rep_storage[
(sizeof(_Rep_base) + sizeof(_CharT) + sizeof(size_type) - 1) /
sizeof(size_type)];

I can get kind of the same difference in assembly by compiling this code:

template<typename T = void>
struct S
{
    static char arr[];
};

template<typename T>
char S<T>::arr[3];

int main()
{
    return S<>::arr[1];
}

Without -fwhole-program ".weak" and stuff is emitted, with the option the array probably becomes static and so the program is compiled to "return 0".

So it looks like the problem here is that with -fwhole-program GCC does not consider the possible existence of the same template instantiation in other translation units.

Looks like _S_empty_rep_storage is tested like

  if (ptr != &_S_empty_rep_storage)

in libstdc++ and thus having multiple _S_empty_rep_storage instantiations is
going to break.

Honza - how was -fwhole-program (and LTO?!) designed to deal with C++ ODR
rules?  With -fno-linker-plugin, that is?


To others:

-fwhole-program basically assumes that all defined symbols can be brought
local to the unit (apart from main()).  Seems like this includes instantiated
templates which means that we assume there is only a single TU and thus ODR
violations never arise from that.

(In reply to Andrey Vihrov from comment #2)
> , and there is no warning without -fwhole-program. Of course, I can get the
> same effect by making everything "static", but this depends on me
> remembering to do it, so this option is better in this regard. -flto doesn't
> have the same effect.

This is not what -fwhole-program is for, you're just using it for a side-effect that happens as a result of making everything static.

So my suggestion would be "don't do that".

If you have a single file how hard can it be to remember to make your globals static? How many of them do you have?! Just enclosing them in an anonymous namespace would work, and then all you have to remember to do is add new globals inside that scope, not elsewhere in the file.

Thanks for your reply. You have a point: using -fwhole-program introduces more effects than needed, as evidenced by this bug report, so an anonymous namespace is safer and cleaner.

In any case, in this bug report we have a program that produces unexpected results with GCC. If this usage is supported, then it is a bug. If this usage is unsupported, then it would be nice to explicitly document cases when -fwhole-program can be used in GCC. For example, GCC documentation might say something like

   Note: -fwhole-program can be specified for programs that link only to the standard C/C++ library (or link to nothing at all), and do not use any template class or function from the standard C++ library.

I agree the docs should be clear on what's supported.