This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: PR3042


	The AIX -G/-brtl linking option seems to provide the correct
semantics to allow proper functioning of static class members.  One gets
the same (accurate) duplicate symbol warning that occurs during static
linking, but the COMMON symbols are shared (because -brtl adds an
initializer that rewrites the TOC at runtime).  This allows the AIX linker
to provide semantics for weak symbols analogous to to SVR4 linkers with
GOTs.

	I need to think about how to implement this change, but I think it
needs the G++ driver to add -brtl to the link line when not -static.  Work
by the many AIX libtool developers means that libtool already recognizes
-brtl and builds the shared library with -G.


	The reason that I see this and the previous implicit template
instantiation COMDAT issues as different is that "static" is a
well-defined C and C++ keyword with well-defined semantics.  One expects
to get a COMMON definition if no STRONG definition exists and expects the
COMMON definitions to be merged.

	Implicit instantiation is an implementation issue, not a language
issue.  I make this claim because GNU C++ and other compilers specifically
provide options like -fno-implicit-templates and -frepo.  There is no
-fno-implicit-statics flag.

	The previous COMDAT change basically was a statement that the GNU
C++ implementation on AIX (and similar platforms, like Tru64?) does not
support -fimplicit-templates on that platform.  That is a quality of
implementation issue, not a correctness issue.

	Your proposed change to COMDAT modifying "static" is a correctness
issue, IMHO.  It may make things "consistent" (for some definition of
consitency), but it breaks the language implementation on that platform.

	I do not know the details of the ISO C++ Language specification.
All compiler implementation seem to have some leeway on template
instantiation, but do not seem to have any leeway on static class members.
Regardless whether your proposed change makes things "consistent", I do
not think that we have the latitude to break the semantic meaning of the
language on some targets.

David


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]