Re: correction: prob with extern name for static local vbl of inline fn on alpha

[scott snyder <snyder at d0sgif dot fnal dot gov>]

hi -

I find that i'm able to build my code correctly (the bug report is appended
below) with the following patch to egcs (1.0.3-pre):

--- cp/decl.c-orig	Sun May 10 22:05:45 1998
+++ cp/decl.c	Wed May 13 00:13:27 1998
@@ -6692,9 +6692,9 @@
 	  && current_function_decl
 	  && DECL_CONTEXT (decl) == current_function_decl
 	  && DECL_THIS_INLINE (current_function_decl)
-	  && TREE_PUBLIC (current_function_decl))
+	  /*&& TREE_PUBLIC (current_function_decl) */)
 	{
-	  if (DECL_INTERFACE_KNOWN (current_function_decl))
+	  if (1 /*DECL_INTERFACE_KNOWN (current_function_decl)*/)
 	    {
 	      TREE_PUBLIC (decl) = 1;
 	      DECL_EXTERNAL (decl) = DECL_EXTERNAL (current_function_decl);

However, i'm not proposing that this go into egcs, as i don't
really think it's correct.  In particular, i don't really understand
the implications of the DECL_INTERFACE_KNOWN test.
(This change doesn't cause any test suite regressions, though.)

The first test is removed so that the `d0om_T2_type' static local 
of T2<int>::d0om_type_static() gets marked public, even though
the function itself isn't.

The second test is removed due to problems with __FUNCTION__
and __PRETTY_FUNCTION__.  When the decls for those get processed,
DECL_INTERFACE_KNOWN (current_function_decl) is true when t1 is
being compiled and false when t2 is being compiled.  Thus,
they get assigned static labelno's by build_overload_nested_name()
only when t1 is compiled.  By the time the d0om_T2_type decl
is processed, DECL_INTERFACE_KNOWN (current_function_decl) is true
in both cases.  Thus, with the test in place, d0om_T2_type
gets a different static labelno in the two different compilation
units.

sss


> To: egcs-bugs@cygnus.com
> Subject: correction: prob with extern name for static local vbl of inline fn on alpha
> Date: Tue, 12 May 1998 18:41:49 CDT
> From: scott snyder <snyder>
> 
> 
> hi -
> 
> The bug report i sent in a couple days ago had a problem in the test case
> (was including the wrong header).
> 
> This version corrects that problem.
> 
> thanks,
> sss
> 
> 
> hi -
> 
> I saw this problem with the egcs-1.0.3 prerelease on a Digital Unix
> 4.0b system (an alpha).  It was also present in a recent snapshot
> (19980425).
> 
> The problem is that sometimes, for an inline template function with a local
> static variable, gcc will generate a module-local assembler name for
> the static variable, preventing it from being shared properly between
> modules.
> 
> Here's an example:
> 
> -- t.hpp --------------------------------------------------------------------
> template <class T>
> class T2
> {
> public:
>   static void* d0om_type_static ()
>   {
>     static void* d0om_T2_type;
>     return d0om_T2_type;
>   };
> 
> };
> 
> template <class T>
> class d0_Ref
> {
> public:
>   void ptr1 () const;
> };
> 
> 
> template <class T>
> void d0_Ref<T>::ptr1() const
> {
>   T2<int>::d0om_type_static ();
> }
> 
> -- t1.cpp -------------------------------------------------------------------
> #include "t.hpp"
> 
> void bar (const d0_Ref<int>& r)
> {
>   r.ptr1 ();
> }
> -- t2.cpp -------------------------------------------------------------------
> #include "t.hpp"
> 
> static void d0om_type_setup ()
> {
>   T2<int>::d0om_type_static ();
> }
> -----------------------------------------------------------------------------
> 
> I then compile and look at the external name generated for `d0om_T2_type':
> 
> $ gcc -S -c t1.cpp
> $ gcc -S -c t2.cpp
> $ grep 'comm.*d0om_T2_type' t*.s
> t1.s:   .lcomm d0om_T2_type.6,8
> t2.s:   .comm _Q2t2T21Zi27d0om_type_static__t2T21Zi.0$d0om_T2_type,8
> 
> 
> For t1.cpp, it looks like the compiler used a module-local name for the
> variable; thus it won't be properly shared with the instance generated
> in t2.cpp.
> 
> So far, i've only seen this problem on the alpha; it does not appear
> to be present on i386/linux and mips/irix platforms.
> 
> thanks,
> sss