New bug, namespaces plus friend templates

New bug, namespaces plus friend templates

[Geoffrey Furnish]

valinux[35] cat x.cc
namespace N {

    template<class T> class C
    {
        template<class U> friend class C;
    };

}
valinux[36] c++ -v
Reading specs from /va1/furnish/local/lib/gcc-lib/i686-pc-linux-gnu/2.95/specs
gcc version 2.95 19990712 (prerelease)
valinux[37] c++ -c x.cc
x.cc:5: Internal compiler error.
x.cc:5: Please submit a full bug report to `egcs-bugs@egcs.cygnus.com'.
x.cc:5: See <URL: http://egcs.cygnus.com/faq.html#bugreport > for details.
valinux[38] 

The above clip is from a Linux system, but I have also seen this same
bug in the pre-2.95 snapshot for Cygwin, which corresponded to one of
the June egcs snapshots.

The code from which this boiled down example was culled, was compiling 
with egcs snapshots during the spring '99 timeframe.  I'm not really
sure which snapshot it was when this broke, since I skipped a bunch
between April and July.  

The internal compiler error goes away if you take the class C out of
the namespace N.

-- 
Geoffrey Furnish            Actel Corporation        furnish@actel.com
Senior Staff Engineer      955 East Arques Ave       voice: 408-522-7528
Placement & Routing     Sunnyvale, CA   94086-4533   fax:   408-328-2303

"... because only those who write the code truly control the project."
						      -- Jamie Zawinski
>From ghazi@caip.rutgers.edu Thu Jul 15 08:34:00 1999
From: "Kaveh R. Ghazi" <ghazi@caip.rutgers.edu>
To: law@cygnus.com, rth@cygnus.com
Cc: egcs-bugs@egcs.cygnus.com
Subject: gcc-2.95: new bootstrap failure on OSF4 stage1 building libgcc2.a
Date: Thu, 15 Jul 1999 08:34:00 -0000
Message-id: <199907151529.LAA07156@caip.rutgers.edu>
X-SW-Source: 1999-07/msg00570.html
Content-length: 1215

Snapshot:		gcc-2.95 19990714 (prerelease)
Platform:		alphaev5-dec-osf4.0b
Stage1 compiler:	cc
Assembler:		native
Linker:			native
BOOT_CFLAGS:		-g -O3 -funroll-all-loops


	I'm seeing a new bootstrap failure in stage1 when libgcc2.a is built:


 > if [ xlibgcc1.a != x ]; \
 > then (cd tmpcopy; ar x ../libgcc1.a); \
 > else true; \
 > fi
 > (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_


Here's the entry from "ar tv ../libgcc2.a"

 > % ar tv libgcc2.a
 > ---------    0/0      2994 Jul 15 10:27 1999   ________64ELEL_
 > rw-r--r--25820/0      8096 Jul 15 10:25 1999   _muldi3.o
 > [...]


I think the reason its complaining the ________64ELEL_ file already
exists is that another copy was already extracted from libgcc1.a:

 > % ar tv ../libgcc1.a
 > ---------    0/0      1366 Jul 14 17:38 1999   ________64ELEL_
 > rw-r--r--25820/0       712 Jul 14 17:38 1999   _mulsi3.o
 > [...]


		--Kaveh
--
Kaveh R. Ghazi			Engagement Manager / Project Services
ghazi@caip.rutgers.edu		Qwest Internet Solutions
>From casper@holland.sun.com Thu Jul 15 09:14:00 1999
From: Casper Dik <casper@holland.sun.com>
To: egcs-bugs@egcs.cygnus.com
Subject: SPARC libraries/runtime support should be build with -mno-app-regs
Date: Thu, 15 Jul 1999 09:14:00 -0000
Message-id: <199907151610.SAA16654@romulus>
X-SW-Source: 1999-07/msg00571.html
Content-length: 1004

The SPARC ABI has a few reserved global registers that can be used as scratch
registers by an application; but also as special reserved global registers
that cache an important global (or per-thread) value.

Because on applications can define these registers as they please,
libraries and other run-time support must not use them.

Building libraries w/ -mno-app-regs works partly, but the libgcc2.c
assembly (_muldi3 and others) as well as _bb (MACHINE_STATE_{SAVE,RESTORE})
still use %g2, even w/ -mno-app-regs.

For SPARCV9 this is easy to fix: the basic block code (if it is even tested)
can save condition code using rd %ccr, %g1 and wr %g1, %ccr and the
long long multiply code isn't even used as direct instructions are generated.

I'll have to double check the SPARCv8 ABI whether another scratch register
can be usedinstead of %g2; %g1 is save; %g4 and %g5 can also be used in
SPARCv9; IIRC %g5 is also reserved for the system together w/ %g6 and %g7
in the V8 ABI.

(Patches to follow)

Casper
>From pfeifer@dbai.tuwien.ac.at Thu Jul 15 09:59:00 1999
From: Gerald Pfeifer <pfeifer@dbai.tuwien.ac.at>
To: Alexandre Oliva <oliva@dcc.unicamp.br>
Cc: law@cygnus.com, Richard Henderson <rth@cygnus.com>, egcs-bugs@egcs.cygnus.com, egcs-patches@egcs.cygnus.com
Subject: Re: shared libstdc++ is broken on alphaev56-dec-osf4.0d
Date: Thu, 15 Jul 1999 09:59:00 -0000
Message-id: <Pine.GSO.4.10.9907151855560.21673-100000@markab.dbai.tuwien.ac.at>
References: <orr9mav362.fsf@cupuacu.lsd.dcc.unicamp.br>
X-SW-Source: 1999-07/msg00572.html
Content-length: 727

On 15 Jul 1999, Alexandre Oliva wrote:
> FYI, the last patch I posted was indeed incomplete: delete3.C still
> complained about some duplicate symbols in libgcc's new.o, _eh.o and
> exception.o.  If I come up with a solution, be it
> `-Wl,-all,-lgcc,-none' or
> `-Wl,-u,__some_symbol,-u,__some_other_symbol,...', may I mention it in
> the specific.html web page, along with the possible negative
> consequences of it?

Unless Jeff (or Richard) explicitly objects, feel free to check that in
without prior approval.

> It's very good to have someone as careful as you leading the project.
> Thanks, Jeff! :-)

<AOL>Thanks, Jeff!</AOL>

Gerald
-- 
Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/

Re: New bug, namespaces plus friend templates

[Martin v. Loewis]

> The internal compiler error goes away if you take the class C out of
> the namespace N.

Thanks for your bug report. This was fixed in the mainline with

1999-07-18  Mark Mitchell  <mark@codesourcery.com>

	* decl.c (lookup_nested_type): Remove.
	(pushtag): Don't call it.

The patch has not been moved to the release branch, yet.

Regards,
Martin