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]
Other format: [Raw text]

Static variables in template functions


PR 18681 describes several V3 testsuite failures that occur on AIX
4.3.  These problems could almost certainly be reproduced on other
systems without weak symbol support.

One of the problems comes from the fact that V3 is using initialized
static variables in template functions.  In particular, in
mt_allocator.h, _S_get_pool does:

	const static size_t __align = (__alignof__(_Tp) >= sizeof(_Block_record)
				       ? __alignof__(_Tp)
				       : sizeof(_Block_record));

For a variable with a constant initializer, G++ wants to do the
initialization statically.  But, without weak symbols that means that
each instance of the variable has to have internal linkage, which is
why we get the warning:

warning: sorry: semantics of inline function static data 
'const size_t __align' are wrong (you'll wind up with multiple copies)
warning:   you can work around this by removing the initializer

In this case, the warning is somewhat lame, in that the variable is
(a) "const" and, (b) not addressed, so there's no problem.  (The only
way a conforming problem could detect the fact that there are multiple
copies are by either noticing that the copies have different
addresses, or by writing to one copy and seeing that the value of the
other is not updated.)

It would also be entirely valid for the compiler to perform the
initialization dynamically, which would eliminate the problem,
although it would pessimize the code.

I'm trying to figure out what we should do.  Here are some options:

0. Nothing.  Downside: inferior user experience on affected systems.

1. Adopt a coding standard for V3 that forbids static variables with
   constant initializers in template/inline functions.  Downside:
   painful for V3 developers.

2. Tweak the V3 testsuite not to cause test FAILs when this warning
   appears.  In other words, trust that the warning is not pertinent
   for V3 functions, which happens to be true in this case.  Downside:
   just cleans up the testsuite results, but does not eliminate the
   warning for users on affected systems.

3. Modify the compiler to initialize such variables dynamically,
   thereby eliminating the problem.  Downside: pessimizes code.

I think I like Option 3 best, despite the performance problems.  If
you're using G++ on such a system, it's likely because you want to
compile code that is built with G++ on some other system.  I think we
should faciliate that usage.  The fact that you don't have weak
symbols already means you'll be getting bloated executables, so
there's already performance degredation.  If you really care, you can
change your code so as not to use this construct.

Thoughts?

--
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com


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