problem with explicit template instantiation and -frepo

problem with explicit template instantiation and -frepo

[scott snyder]

hi -

This is concerning egcs 19990606, on a mips-sgi-irix6.5 platform.

When -frepo is used, the following source gives an error the _second_
time it is compiled:

-- bug41.cc ------------------------------------------
template <class T>
void fill_n (T x)
{
}


template <class T>
class d0_Vector_1
{
public:
  void allocate_and_fill () {
    fill_n (0);
  }

  virtual void d0_vector_1 () {}
};

template class d0_Vector_1<void const*>;
------------------------------------------------------

% gcc -c -frepo bug41.cc
% gcc -c -frepo bug41.cc
bug41.cc:18: duplicate explicit instantiation of `class d0_Vector_1<const void *>'


BTW, the other -frepo bug i reported a couple months ago (along with
a patch)

< http://egcs.cygnus.com/ml/egcs-patches/1999-04/msg00915.html >

is still in  egcs 19990606.

thanks,
sss

Re: problem with explicit template instantiation and -frepo

[Loren James Rittle]

; rm -f t.rpo
; cat t.C
template<class A>
class B
{
 public:
  B (void);
  virtual ~B (void);
};

template class B<int>;



; g++ -V2.95 -frepo -c t.C
; g++ -V2.95 -frepo -c t.C
t.C:9: duplicate explicit instantiation of `class B<int>'

The following patch allows my huge base of software (ACE/TAO) to
compile and then recompile without first removing all .rpo files.

Sorry it isn't pretty...

; ccvs diff -u pt.c 
Index: pt.c
===================================================================
RCS file: /cvs/egcs/egcs/gcc/cp/pt.c,v
retrieving revision 1.307
diff -u -r1.307 pt.c
--- pt.c        1999/06/14 15:56:12     1.307
+++ pt.c        1999/07/15 23:35:21
@@ -9094,8 +9094,10 @@
          If CLASSTYPE_INTERFACE_ONLY, then the first explicit
         instantiation was `extern', and if EXTERN_P then the second
         is.  Both cases are OK.  */
+#if 0
       if (!CLASSTYPE_INTERFACE_ONLY (t) && !extern_p)
        cp_error ("duplicate explicit instantiation of `%#T'", t);
+#endif
       
       /* If we've already instantiated the template, just return now.  */
       if (!CLASSTYPE_INTERFACE_ONLY (t))
>From fvali@biotrack.com Thu Jul 15 16:46:00 1999
From: Fais <fvali@biotrack.com>
To: egcs-bugs@egcs.cygnus.com
Subject: 1.1.2 BUG: ill-formed code being compiled - re: Class Member Access 
Date: Thu, 15 Jul 1999 16:46:00 -0000
Message-id: <37B4AE2F.AFA9CE3A@biotrack.com>
X-SW-Source: 1999-07/msg00591.html
Content-length: 1314

Using khan's win32 port of egcs 1.1.2.

According to Section 3.4.5 paragraph 1 of the C++ standard I believe the
following code is ill-formed.

template< typename TY_>
struct ID { };

struct B
{
   template< typename TY_ >
     void ID() { }
};

int main()
{
  B b;
  b. template /* template should not be required, another bug! */
       ID<int>();

}  

The way I figured it was this:
'ID' is looked up in the scope of the object expression b, and found to
be a template.
'ID' is then looked in the context of the entire postfix expression,
which would be in the block of main before its use, or in the global
namespace before its use.
Since ID is found to be a *class template* and does not refer to the
same entity as the one found in the class of the object expression, the
code should be ill-formed, according ot bullet 3 of that paragraph.
Yet egcs 1.1.2 compiles it fine.


Since I do not check this bugs group much, I would really appreciate it
if some one emailed me back confirming whether this is a bug or not :-)
-thanks
-fais



-- 
Faisal Vali		fvali@biotrack.com
Software Engineer	Identix Biometric Security
WWW: http://www.identix.com
-------------------------------------------------------
Nothing can cure the soul but the senses, just as nothing can cure the
senses but the soul. (Oscar Wilde)
>From law@cygnus.com Thu Jul 15 17:41:00 1999
From: Jeffrey A Law <law@cygnus.com>
To: "Kaveh R. Ghazi" <ghazi@caip.rutgers.edu>
Cc: rth@cygnus.com, egcs-bugs@egcs.cygnus.com
Subject: Re: gcc-2.95: new bootstrap failure on OSF4 stage1 building libgcc2.a 
Date: Thu, 15 Jul 1999 17:41:00 -0000
Message-id: <21232.932085378@upchuck.cygnus.com>
References: <199907151529.LAA07156@caip.rutgers.edu>
X-SW-Source: 1999-07/msg00592.html
Content-length: 779

  In message < 199907151529.LAA07156@caip.rutgers.edu >you write:
  >  > (cd tmpcopy; ar x ../libgcc2.a)
  >  > ar: Error: ________64ELEL_ cannot create
  >  > make[3]: *** [stmp-multilib-sub] Error 1
  > 
  > 
  > 	The file ________64ELEL_ already exists with no perms:
  > 
  >  >  2 ----------   1 ghazi    system       1366 Jul 15 10:27 ________64ELEL
  > _
Where did that weird file come from to begin with?  It almost looks like
an internal file, in which case I wouldn't expect our tools to have access
to it at all.

I don't see any way the -mieee multilib stuff could have caused this, but I
could be wrong.  Can you please debug it?    I certainly can't given the
speed our our osf1 box.  It wouldn't finish building until Sat or Sun if
I started a build now.

jeff