[Digital UNIX V4.0B] C++ ICE in egcs 1.1.2 and current CVS version

[Digital UNIX V4.0B] C++ ICE in egcs 1.1.2 and current CVS version

[Rainer Orth]

Both egcs 1.1.2 and a recent CVS version (egcs-2.93.20 19990430) get an ICE
on the following input file (stripped down from James Clark's jade 1.2.1
jade/SgmlFOTBuilder.cxx) on Digital UNIX V4.0B (alpha-dec-osf4.0b):

class   OutputCharStream {
public:
  OutputCharStream &operator<<(char);
};

inline
void hex2(OutputCharStream &os, unsigned char c)
{
  static const char hexDigits[] = "0123456789ABCDEF";
  os << hexDigits[c >> 4] << hexDigits[c & 0xF];
}

test.ii: In function `void hex2(class OutputCharStream &, unsigned char)':
test.ii:9: warning: sorry: semantics of inline function static data `const char const hexDigits[17]' are wrong (you'll wind up with multiple copies)
test.ii:9: Internal compiler error.

The same file compiles fine on Solaris 2.6 and IRIX 6.2 with egcs 1.1.2.

	Rainer
>From craig@jcb-sc.com Wed May 05 13:31:00 1999
From: craig@jcb-sc.com
To: Prince_Tim_C@solarturbines.com
Cc: craig@jcb-sc.com
Subject: Re: status of some hppa/g77 bugs
Date: Wed, 05 May 1999 13:31:00 -0000
Message-id: <19990505202836.17782.qmail@deer>
References: <37308989.6E8C.0223.000*/c=US/admd=> </prmd=Cat/o=GWise/s=Prince/g=Tim/i=C/"@MHS> <37308989.6E8C.0223.000*/c=US/admd=/prmd=Cat/o=GWise/s=Prince/g=Tim/i=C/"@MHS>
X-SW-Source: 1999-05/msg00114.html
Content-length: 675

>The problem with over-lapping automatic arrays in the popular
>TEST_FPU benchmark, which still existed in egcs-1.1.2, has
>disappeared.  Thanks to whomever made this happen!  I don't
>have access to a PPC machine able to run egcs; the Mac port of
>g77 used to have a similar problem with the same code.

That's good news!  I'll remove the pertinent item from bugs.texi,
and add a note to news.texi.  Sorry I never got around to rigorously
debugging this -- not having an HPPA machine handy posed a problem --
but it *was* still on my list of things to deal with, and getting
pretty near the top, especially as we passed the 1.2 feature freeze
date.

        tq vm, (burley)
>From dave@hiauly1.hia.nrc.ca Wed May 05 14:02:00 1999
From: "John David Anglin" <dave@hiauly1.hia.nrc.ca>
To: egcs-bugs@egcs.cygnus.com
Subject: Wrong type for 2nd arg of getgroups under vax-dec-ultrix4.3 in fixed unistd.h
Date: Wed, 05 May 1999 14:02:00 -0000
Message-id: <199905052102.RAA24647@hiauly1.hia.nrc.ca>
X-SW-Source: 1999-05/msg00115.html
Content-length: 435

According to the man page for getgroups, the type of the second argument
should be "int *".  The type in the fixed version of unistd.h is "short *".
I think this happens because the type of gid_t is short under
vax-dec-ultrix4.3.  This happens both with egcs-2.91.57 and gcc-2.8.1.

-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)
>From lavoie@yoho.genie.uottawa.ca Wed May 05 14:04:00 1999
From: Lavoie Philippe <lavoie@yoho.genie.uottawa.ca>
To: egcs-bugs@egcs.cygnus.com
Subject: Going nuts with templates and libstdc++
Date: Wed, 05 May 1999 14:04:00 -0000
Message-id: <199905052059.QAA23823@yoho.genie.uottawa.ca>
X-SW-Source: 1999-05/msg00116.html
Content-length: 1821

At one point templates where the answer, no they are more and more of
a nightmare.

My program compiles fine under Solaris. It fails because I'm
initializing a pointer to 0 under Linux and on DEC Alpha, removing a
few template lines solves all linking problems.

The only thing common is that we all are using egcs1.1.2

You can download my program (NURBS++)
http://yukon.genie.uottawa.ca/~lavoie/software/nurbs/download.shtml

I should never have tried using deque in my program...

Anyway, under Linux the latest problem is

c++ -shared  f_nurbs.lo f_nurbsS.lo f_curve.lo f_surface.lo f_hnurbsS.lo matrixRT.lo f_nurbs_sp.lo f_nurbsS_sp.lo f_hnurbsS_sp.lo nurbsGL.lo f_nurbsArray.lo f_nurbsSub.lo f_tri_spline.lo  -lc  -Wl,-soname -Wl,libnurbsf.so.0 -o .libs/libnurbsf.so.0.1.0
/usr/local/lib/libstdc++.a(stlinst.o): In function `__malloc_alloc_template<0>::oom_malloc(unsigned int)':
/home/lavoie/app/egcs-1.1.2/i686-pc-linux-gnu/libstdc++/stl/stl_alloc.h:186: multiple definition of `__default_alloc_template<true, 0>::start_free'
f_nurbsSub.lo:/home/lavoie/project/nurbs++-3.0.4/nurbs/nurbsSub.cc:59: first defined here
/usr/local/lib/libstdc++.a(stlinst.o): In function `__malloc_alloc_template<0>::oom_malloc(unsigned int)':
/home/lavoie/app/egcs-1.1.2/i686-pc-linux-gnu/libstdc++/stl/stl_alloc.h:186: multiple definition of `__default_alloc_template<true, 0>::end_free'
f_nurbsSub.lo:/home/lavoie/project/nurbs++-3.0.4/nurbs/nurbsSub.cc:59: first defined here
....

the line in question is

surf = 0 ;

where surf is defined as 

NurbSurface<T> *surf ;  

and NurbSurface is 

template <class T> class NurbSurface ;


How am I suppose to fix this problem ? Removing the line is not an
option. The strangest thing is that the same line worked with 1.1.2
just 2 weeks ago. I'll post an update if I can fix it.

Phil
>From grahamg@cst.ca Wed May 05 14:36:00 1999
From: Graham Gilmore <grahamg@cst.ca>
To: egcs-bugs@egcs.cygnus.com
Subject: Internal compiler error with egcs
Date: Wed, 05 May 1999 14:36:00 -0000
Message-id: <l03130304b35661e84953@[193.77.49.62]>
X-SW-Source: 1999-05/msg00117.html
Content-length: 2376

	Hello; I'm using egcs 1.1.2 on sparc-sun-solaris2.5.1 .
	While compiling some source code the compiler reported an internal
compiler error.  I saw that the code in question had an obvious syntax
error, so I managed to isolate the offending code & create a sample that
generates the error.  Following is the preprocessed output of the example,
and the output of gcc -v --save-temps -o error.out error.cpp
	Notice that the declaration of struct Bozo is missing a terminating
semi-colon.  Placing the semi-colon where it belongs eliminates the
internal compiler error.

------------------------------
# 1 "error.cpp"
namespace baz
{
template <class FOO> class Bar
{
public:
    Bar() {};
    ~Bar() {};
};
};

struct Bozo
{
    int operator () (int in_Int1, int in_Int2) const;
}






typedef baz::Bar<long> LongBar;

int main(void)
{
    LongBar theLongBar;
    int i = 2;
    int l = 4 + i;

    return(l-6);
};

-------------------------------

Reading specs from
/usr/local/pkgs/egcs-1.1.2/lib/gcc-lib/sparc-sun-solaris2.5.1/egcs-2.91.66/specs
gcc version egcs-2.91.66 19990314 (egcs-1.1.2 release)
 /usr/local/pkgs/egcs-1.1.2/lib/gcc-lib/sparc-sun-solaris2.5.1/egcs-2.91.66/cpp
-lang-c++ -v -undef -D__GNUC__=2 -D__GNUG__=2 -D__cplusplus
-D__GNUC_MINOR__=91 -Dsparc -Dsun -Dunix -D__svr4__ -D__SVR4 -D__sparc__
-D__sun__ -D__unix__ -D__svr4__ -D__SVR4 -D__sparc -D__sun -D__unix
-Asystem(unix) -Asystem(svr4) -D__EXCEPTIONS -D__GCC_NEW_VARARGS__
-Acpu(sparc) -Amachine(sparc) error.cpp error.ii
GNU CPP version egcs-2.91.66 19990314 (egcs-1.1.2 release) (sparc)
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/pkgs/egcs-1.1.2/include/g++
 /usr/local/include
 /usr/local/pkgs/egcs-1.1.2/sparc-sun-solaris2.5.1/include
 /usr/local/pkgs/egcs-1.1.2/lib/gcc-lib/sparc-sun-solaris2.5.1/egcs-2.91.66/incl
ude
 /usr/include
End of search list.
 /usr/local/pkgs/egcs-1.1.2/lib/gcc-lib/sparc-sun-solaris2.5.1/egcs-2.91.66/cc1p
lus error.ii -quiet -dumpbase error.cc -version -o error.s
GNU C++ version egcs-2.91.66 19990314 (egcs-1.1.2 release)
(sparc-sun-solaris2.5.1) compiled by GNU C version egcs-2.91.66 19990314
(egcs-1.1.2 release).
error.cpp:21: Internal compiler error 980711.
error.cpp:21: Please submit a full bug report to `egcs-bugs@egcs.cygnus.com'.
error.cpp:21: See <URL: http://egcs.cygnus.com/faq.html#bugreport > for details.

Re: [Digital UNIX V4.0B] C++ ICE in egcs 1.1.2 and current CVS version

[Rainer Orth]

The ICE reported in

	http://egcs.cygnus.com/ml/egcs-bugs/1999-05/msg00113.html

still exists with the current CVS version gcc-2.95 19990623 (prerelease).

	Rainer
>From Joel.Peterson@dowjones.com Thu Jun 24 09:54:00 1999
From: "Peterson, Joel" <Joel.Peterson@dowjones.com>
To: "'egcs-bugs@egcs.cygnus.com'" <egcs-bugs@egcs.cygnus.com>
Subject: relocation error on Solaris 2.6
Date: Thu, 24 Jun 1999 09:54:00 -0000
Message-id: <9DE45C904D93D211B20D0008C75DA88226DC6B@sbkmxsmb06>
X-SW-Source: 1999-06/msg00793.html
Content-length: 694

I get the following error when trying to link some template-heavy code
generated by egcs-1.1.2 on Sparc-sun-solaris2.6:

ld: warning: relocation error: R_SPARC_32: file testAssociation.o:
  symbol findCandidate__H1:
  external symbolic relocation against non-allocatable section .stab;
  cannot be processed at runtime: relocation ignored
[...]

The link then fails with findCandidate__H1 being undefined.

I noticed a similar problem in the egcs-bugs archive reported for Solaris 7,
but didn't see it for Solaris 2.6.

BTW.  This doesn't happen with all template code, only some of it.

Is this a known problem with a known solution?  Would you like more
information?

Regards,

Joel Peterson
>From brachman@dss.bc.ca Thu Jun 24 11:49:00 1999
From: Barry Brachman <brachman@dss.bc.ca>
To: egcs-bugs@egcs.cygnus.com
Subject: egcs-2.91.66 internal bug
Date: Thu, 24 Jun 1999 11:49:00 -0000
Message-id: <199906241849.LAA12908@dss.bc.ca>
X-SW-Source: 1999-06/msg00794.html
Content-length: 1831

Synopsis:
 egcs-2.91.66 19990314 (egcs-1.1.2 release) may not be maintaining
 current_function_name properly when compiling C++ code.  The variable may
 sometimes point to (apparently) random junk.

Environment:
 egcs-2.91.66 was compiled by GCC 2.8.1 on a Linux/Pentium II platform and
 it was configured for that target platform.

Description:
 I'm assuming that current_function_name should always point to something
 reasonable.  When compiling the attached C++ file, however, it appears that
 the memory that the variable is pointing to is freed and/or reallocated
 prematurely.
 
How-To-Repeat:
 I'm using gdb 4.17.
 Set some breakpoints in cc1plus and observe that current_function_name is
 sometimes not pointing to a printable ASCII string.  It seems to me that it
 should be pointing to a valid function name at these points.  I suggest a
 breakpoint in any of:
    config/i386/i386.c:ix86_prologue()
    config/i386/i386.c:function_epilogue()
    function.c:pop_function_context_from() after
        current_function_name = p->name;
 You may add a condition to the breakpoint: !isprint(current_function_name[0])
 Then:
    run -quiet < vpcc2.ii > /dev/null
 At a breakpoint, print the value of current_function_name.

Fix:
 I suspect the problem is in the maintenance of the print_ring cache in
 cp/tree.c:lang_printable_name(), but I'm not certain.  If you insert the
 following as the first line of that function, the bug disappears:
     return(xstrdup (lang_decl_name (decl, v)));
 Also, if you increase PRINT_RING_SIZE sufficiently from 4 (why 4??), the
 bug disappears.  I found a PRINT_RING_SIZE of 12 to be the minimum size needed
 to make the problem go away for this input file.

The input file that demonstrates the problem, vpcc2.ii, is attached in gzip
form.

Barry Brachman
Distributed Systems Software 

Re: [patch] Alpha C++ ICE in egcs 1.1.2 and current CVS version

[Rainer Orth]

Richard Henderson writes:
> On Thu, Jun 24, 1999 at 06:15:23PM +0200, Rainer Orth wrote:
> > The ICE reported in
> > 
> > 	http://egcs.cygnus.com/ml/egcs-bugs/1999-05/msg00113.html
> > 
> > still exists with the current CVS version gcc-2.95 19990623 (prerelease).
> 
> Curiously, I don't even get the warning on alpha-linux.

Works fine, thanks.  Looking at the surrounding code in cp/decl.c, I now
realize why the same code works fine on Solaris 2 and IRIX 6: both
platforms support weak symbols, while the Digital UNIX port currently does
not.  I'll submit patches for this once I've had some time to clean them up.

	Rainer

[patch] Alpha C++ ICE in egcs 1.1.2 and current CVS version

[Richard Henderson]

On Thu, Jun 24, 1999 at 06:15:23PM +0200, Rainer Orth wrote:
> The ICE reported in
> 
> 	http://egcs.cygnus.com/ml/egcs-bugs/1999-05/msg00113.html
> 
> still exists with the current CVS version gcc-2.95 19990623 (prerelease).

Curiously, I don't even get the warning on alpha-linux.


r~


1999-06-26  Richard Henderson  <rth@cygnus.com>

	* decl.c (cp_finish_decl): Fix typo in cp_warning_at call.

Index: decl.c
===================================================================
RCS file: /egcs/carton/cvsfiles/egcs/gcc/cp/decl.c,v
retrieving revision 1.358.4.4
diff -c -p -d -u -r1.358.4.4 decl.c
--- decl.c	1999/06/19 11:17:52	1.358.4.4
+++ decl.c	1999/06/27 05:54:13
@@ -8130,7 +8130,7 @@ cp_finish_decl (decl, init, asmspec_tree
 	      else if (! DECL_ARTIFICIAL (decl))
 		{
 		  cp_warning_at ("sorry: semantics of inline function static data `%#D' are wrong (you'll wind up with multiple copies)", decl);
-		  cp_warning_at ("  you can work around this by removing the initializer"), decl;
+		  cp_warning_at ("  you can work around this by removing the initializer", decl);
 		}
 	    }
 	}