Re: PR3042

[David Edelsohn <dje at watson dot ibm dot com>]

>>>>> Mark Mitchell writes:

Mark> That's consistent with what I said above, for the uninitialized case.
Mark> For the initialized case, I think that you will find that there is no
Mark> storage allocated whatsoever.

	Okay, yes, now I understand what you are asking.  For an example
like:

  template <typename T>
  struct S {
    static int i;
  };

  template <typename T>
  int S<T>::i;

  int j = S<double>::i;

  template <typename Z>
  struct Y {
    static int m;
  };

  template <typename Z>
  int Y<Z>::m = 1;

  int n = Y<double>::m;


GCC 3.0 default behavior produces a COMMON symbol for S<double>::i and no
symbol for Y<double>::m .

xlC 3.6.6.0 default behavior produces a COMMON symbol for S<double>::i and
a STRONG symbol of initialized data for Y<double>::m .

	The current gcc-3.0 behavior is *IDENTICAL* to the gcc-2.95
behavior, for the example above.  I do not ever recall hearing a complaint
or seeing a bug report about GCC's semantics on AIX.  This simply may be a
case of the way that developers use static class members.  Or, possibly,
developers did not find it an inconvenience to fix the undefined symbol
warnings. 

	libstdc++-v2 worked with this behavior.  libstdc++-v3 works with
this behavior.  KDE and other open source and Free Software C++ packages
have been compiled for AIX with this behavior.

	Given AIX's limitations with respect to G++'s assumptions, we need
to find a balance between the C++ Language spec (as G++ wishes to
implement it) and the way that people program.  The first case we need to
satisfy is libstdc++.  We seem to have found a balance that libstdc++ can
deal with and that other packages have been able to deal with.  Given
those precedents, I believe that changing the G++ semantics at this time
would cause more problems, not less.  People do not seem to have been
confused by this "inconsistent" behavior.

	If for no other technical argument (which I obviously have not
been able to express correctly during this discussion), I would say: "If
it ain't broken, don't fix it."

David