Bug

[Gcc <gcc at sunburst dot rose dot hp dot com>]

This is an intersting bug it occurs on HPUX, not sure if this happens on
other platforms.  If u try to make any type of struct inside a template
function it will generate :

bash-2.01$ gcc --save-temps -v test4.C  
Reading specs from
/usr/local/lib/gcc-lib/hppa1.1-hp-hpux10.20/egcs-2.91.03/specs
gcc version egcs-2.91.03 971215 (gcc-2.8.0)
 /usr/local/lib/gcc-lib/hppa1.1-hp-hpux10.20/egcs-2.91.03/cpp -lang-c++ -v
-undef -D__GNUC__=2 -D__GNUG__=2 -D_
_cplusplus -D__GNUC_MINOR__=91 -Dhppa -Dhp9000s800 -D__hp9000s800 -Dhp9k8
-DPWB -Dhpux -Dunix -D__hppa__ -D__hp
9000s800__ -D__hp9000s800 -D__hp9k8__ -D__PWB__ -D__hpux__ -D__unix__
-D__hppa -D__hp9000s800 -D__hp9k8 -D__PWB
 -D__hpux -D__unix -Asystem(unix) -Asystem(hpux) -Acpu(hppa)
-Amachine(hppa) -D__EXCEPTIONS -D__hp9000s700 -D_P
A_RISC1_1 -D_HPUX_SOURCE -D_HIUX_SOURCE test4.C test4.ii
GNU CPP version egcs-2.91.03 971215 (gcc-2.8.0) (hppa)
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/include/g++
 /usr/local/include
 /usr/local/hppa1.1-hp-hpux10.20/include
 /usr/local/lib/gcc-lib/hppa1.1-hp-hpux10.20/egcs-2.91.03/include
 /usr/include
End of search list.
 /usr/local/lib/gcc-lib/hppa1.1-hp-hpux10.20/egcs-2.91.03/cc1plus test4.ii
-quiet -dumpbase test4.cc -version -
o test4.s
GNU C++ version egcs-2.91.03 971215 (gcc-2.8.0) (hppa1.1-hp-hpux10.20)
compiled by GNU C version egcs-2.91.03 9
71215 (gcc-2.8.0).
test4.C: In function `void sort(T *, int)':
test4.C:8: Internal compiler error.
test4.C:8: Please submit a full bug report to `egcs-bugs@cygnus.com'.

This type of code can be seen in packages such as doc++.

int main() {
   return (0);
}
 
template< class T > void sort( T* t, int n )
{
   struct asd
   {
      int a;
   } c ;
}

cat test4.ii
        .LEVEL 1.1
        .SPACE $PRIVATE$
        .SUBSPA $DATA$,QUAD=1,ALIGN=8,ACCESS=31
        .SUBSPA $BSS$,QUAD=1,ALIGN=8,ACCESS=31,ZERO,SORT=82
        .SPACE $TEXT$
        .SUBSPA $LIT$,QUAD=0,ALIGN=8,ACCESS=44
        .SUBSPA $CODE$,QUAD=0,ALIGN=8,ACCESS=44,CODE_ONLY
        .IMPORT $global$,DATA
        .IMPORT $$dyncall,MILLICODE
; gcc_compiled.:
        .IMPORT __main,CODE
        .SPACE $TEXT$
        .SUBSPA $CODE$

        .align 4
        .NSUBSPA $CODE$,QUAD=0,ALIGN=8,ACCESS=44,CODE_ONLY
        .EXPORT main,ENTRY,PRIV_LEV=3,RTNVAL=GR
main
        .PROC
        .CALLINFO FRAME=64,CALLS,SAVE_RP,SAVE_SP,ENTRY_GR=3
        .ENTRY
        stw %r2,-20(0,%r30)
        copy %r3,%r1
        copy %r30,%r3
        stwm %r1,64(0,%r30)
        .CALL 
        bl __main,%r2
        nop
        ldi 0,%r28
        bl,n L$0001,0
        ldi 0,%r28
        bl,n L$0001,0
L$0001
        ldw -20(0,%r3),%r2
        ldo 64(%r3),%r30
        ldwm -64(0,%r30),%r3
        bv,n 0(%r2)
        .EXIT
        .PROCEND

One other note, how is one suppose to correctly generate a shared library
on HPUX with egcs generated o files.  I tried
bash-2.01$ g++ -shared -o libtest.sl *.o
/usr/ccs/bin/ld: DP relative code in file /var/tmp/cca12255.o - shared
library must be position
    independent.  Use +z or +Z to recompile.
collect2: ld returned 1 exit status
Yes, the .o files were created with -fPIC, -fpic doesn't make any
difference.  The reason I don't use /usr/bin/ld -b -n -o libtest.sl *.o.
Is because whenever u use static template members inside a shared library
it will crash whenever u try to access it.  When the shared library is
loaded the constructors for static template members aren't called.  This
can be proven by building an archive library and the core dump goes away.

Thanks