C++ Issue on GCC 3.0 branch

C++ Issue on GCC 3.0 branch

[Jeffrey A Law]

A few of the remaining failures for PA32 using static libraries are
multiply defined symbols -- in each case one or more symbols defined by
the main program is a duplicate of a symbol in libstdc++.

For example, compiling g++.law/cvt2.C results in about a dozen duplicate
symbols (output has been massaged to be easier to read).

"std::istream::~istream()" in files cvt.o and libstdc++.a (misc-inst.o)

Similarly for the following symbols:

"std::basic_ios<char, std::char_traits<char> >::~basic_ios()"
"std::basic_ifstream<char, std::char_traits<char> >::~basic_ifstream()"
"std::basic_ios<char, std::char_traits<char> >::~basic_ios()"
"std::basic_ifstream<char, std::char_traits<char> >::basic_ifstream(char 
const*, std::_Ios_Openmode)"

[ ... ]

I'm not enough of a C++ guru to know where to start with this one, so any
help y'all could provide would be greatly appreciated.

jeff

Re: C++ Issue on GCC 3.0 branch

[John David Anglin]

> A few of the remaining failures for PA32 using static libraries are
> multiply defined symbols -- in each case one or more symbols defined by
> the main program is a duplicate of a symbol in libstdc++.

The duplicate symbol problem also prevents building a shared libstdc++.,
particularly if you use a low optimization level for debugging.

I have been trying to track this for a couple of days.  The enclosed
patch may resolve the problem of duplicate symbols.  It appears to prevent
the symbols from being exported.  However, I have no idea whether it is
technically correct.  It is possible the problem should be fixed when
the original clone decl is created.

The functions are all constructors being instantiated from templates.
It is my assumption that these don't really need to be accessible from
other files and the duplication won't be a problem (ie., static data
should be in common).  On systems with weak support, they are weak
symbols.

The patch is not a complete solution.  There are still import assembler
statements being generated for these functions.  I have being trying to
figure out how DECL_EXTERNAL gets set but so far I can't find where it
is set.  I tried setting breaks on every place that cc1plus sets it
directly but this didn't work.  I am now running a test using `watch'
but this is incredibly slow.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

2001-04-21  John David Anglin  <dave@hiauly1.hia.nrc.ca>

	* optimize.c (maybe_clone_body): Copy TREE_PUBLIC to clone.

--- optimize.c.orig	Wed Apr 11 15:05:20 2001
+++ optimize.c	Fri Apr 20 16:14:38 2001
@@ -1028,6 +1028,7 @@
       int parmno;
 
       /* Update CLONE's source position information to match FN's.  */
+      TREE_PUBLIC (clone) = TREE_PUBLIC (fn);
       DECL_SOURCE_FILE (clone) = DECL_SOURCE_FILE (fn);
       DECL_SOURCE_LINE (clone) = DECL_SOURCE_LINE (fn);
       DECL_INLINE (clone) = DECL_INLINE (fn);

Re: C++ Issue on GCC 3.0 branch

[David Edelsohn]

	As a confirmation, AIX linker reports many duplicate symbols when
building libstdc++ shared library and tests.  AIX does not consider it an
error by default and uses one instance.

David

Re: C++ Issue on GCC 3.0 branch

[Mark Mitchell]

Dave --

  Would you mind preparing a small testcase to demonstrate the
problem?  (Compile this file, compile that file, note that they both
generate definitions of the same constructor.)

  Then, mail them to me, with the PA traget-triplet and cc1plus
command-line options.  I should be able to track down what's going on,
although someone may have to remind me about how some of the PA
assembler directives work...

  Thanks to both you and Jeff for getting us this far.  I think this a
case where I can probably step in to get us past this hurdle.

  Thanks,

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: C++ Issue on GCC 3.0 branch

[John David Anglin]

>   Then, mail them to me, with the PA traget-triplet and cc1plus
> command-line options.  I should be able to track down what's going on,
> although someone may have to remind me about how some of the PA
> assembler directives work...

I think I am beginning to see the light.  In start_objects, there is
the code:

#if defined(ASM_OUTPUT_CONSTRUCTOR) && defined(ASM_OUTPUT_DESTRUCTOR)
  /* It can be a static function as long as collect2 does not have
     to scan the object file to find its ctor/dtor routine.  */
  TREE_PUBLIC (current_function_decl) = 0;
#endif

ASM_OUTPUT_CONSTRUCTOR and ASM_OUTPUT_DESTRUCTOR are not defined for
hpux 10.20.  The are some defines in pa-64.h for the 64-bit runtime
but they are disabled with #undef's following the defines.  As a result,
constructors are global.  For the SOM linker, I think we have the section
support needed to define these.  I don't know about the startup issues.
Hopefully, this would allow the constructors to be static.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: C++ Issue on GCC 3.0 branch

[Mark Mitchell]

>>>>> "John" == John David Anglin <dave@hiauly1.hia.nrc.ca> writes:

    >> Then, mail them to me, with the PA traget-triplet and cc1plus
    >> command-line options.  I should be able to track down what's
    >> going on, although someone may have to remind me about how some
    >> of the PA assembler directives work...

    John> I think I am beginning to see the light.  In start_objects,
    John> there is the code:

    John> #if defined(ASM_OUTPUT_CONSTRUCTOR) &&
    John> defined(ASM_OUTPUT_DESTRUCTOR) /* It can be a static
    John> function as long as collect2 does not have to scan the
    John> object file to find its ctor/dtor routine.  */ TREE_PUBLIC
    John> (current_function_decl) = 0; #endif

I'm sorry I haven't had more time to work on your problem this
weekend.  I've been working on a proposal that I need to get out.  I
will try to look at it more tonight, using your patch to cobble around
the cross-compilation abort.

I think this is a red herring though -- I think this code is talking
about "static constructors" which are the things that arrange for
global initialization and finalization, not constructors for
individual types, which is what the symbols you referenced were
talking about.

Yours,

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: C++ Issue on GCC 3.0 branch

[John David Anglin]

> I think this is a red herring though -- I think this code is talking
> about "static constructors" which are the things that arrange for
> global initialization and finalization, not constructors for
> individual types, which is what the symbols you referenced were
> talking about.

Can you point me to where the "model" for type constructors is set
up?

Regarding the constructors for global initialization, I think that
Jeff's patch truncating the length of section (subspace) names
needs to be reverted.  I am getting a bunch of unresolved symbol
references from the dynamic loader involving global constructor
names that have been truncated.

I believe the core dump by HP nm doesn't occur with the "-p" option
even when the section names are longer than 31 characters.  I will
know more soon if this is the case.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: C++ Issue on GCC 3.0 branch

[law]

  In message < 200104230018.UAA18822@hiauly1.hia.nrc.ca >you write:
  > > I think this is a red herring though -- I think this code is talking
  > > about "static constructors" which are the things that arrange for
  > > global initialization and finalization, not constructors for
  > > individual types, which is what the symbols you referenced were
  > > talking about.
  > 
  > Can you point me to where the "model" for type constructors is set
  > up?
  > 
  > Regarding the constructors for global initialization, I think that
  > Jeff's patch truncating the length of section (subspace) names
  > needs to be reverted.  I am getting a bunch of unresolved symbol
  > references from the dynamic loader involving global constructor
  > names that have been truncated.
This sounds like you haven't rebuilt collect2 after my change for NM_FLAGS.

The whole purpose of the change is to not get false hits when collect2
search for ctors/dtors which lead to undefined symbols.

I'd rather not remove "-p" just because hpux's nm core dumps with the option
unless having the option gives us no benefit.  I'm not likely revert the
truncation of section names, even if we remove -p.  Once bitten, twice shy.
jeff

Re: C++ Issue on GCC 3.0 branch

[John David Anglin]

>   > Regarding the constructors for global initialization, I think that
>   > Jeff's patch truncating the length of section (subspace) names
>   > needs to be reverted.  I am getting a bunch of unresolved symbol
>   > references from the dynamic loader involving global constructor
>   > names that have been truncated.
> This sounds like you haven't rebuilt collect2 after my change for NM_FLAGS.

No, collect was definitely rebuilt.

> The whole purpose of the change is to not get false hits when collect2
> search for ctors/dtors which lead to undefined symbols.
> 
> I'd rather not remove "-p" just because hpux's nm core dumps with the option
> unless having the option gives us no benefit.  I'm not likely revert the
> truncation of section names, even if we remove -p.  Once bitten, twice shy.

The patch was to remove " -n", not "-p" from NM_FLAGS.  HP nm doesn't dump
core on objects with long subspace names when "-p" is used.  This allows
using the long subspace names again, although I would have prefered not to
because of the bug in HP nm.  With "-p", the subspaces aren't output and
there are no false hits.

This is the change to the subspace output.  It fixes various missing
global names.  I don't fully understand the problem but I did see that
the missing constructors in the shared library had truncated names.
I use GNU nm rather than HP nm for my builds.  Thus, there is no possibilty
for false hits.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

2001-04-22  John David Anglin  <dave@hiauly1.hia.nrc.ca>

	* som.h: Don't truncate subspace names.

--- som.h.save	Sun Apr 22 15:18:51 2001
+++ som.h	Sun Apr 22 19:32:15 2001
@@ -135,7 +135,7 @@
       fputs ("\t.NSUBSPA $CODE$,QUAD=0,ALIGN=8,ACCESS=44,CODE_ONLY\n", FILE); \
     else if (TARGET_GAS)						\
       fprintf (FILE,							\
-	       "\t.SUBSPA .%.30s\n", name);				\
+	       "\t.SUBSPA .%s\n", name);				\
   }
     
 #define ASM_DECLARE_FUNCTION_NAME(FILE, NAME, DECL) \
@@ -280,10 +280,10 @@
       fputs ("\t.SPACE $TEXT$\n", FILE);			\
       if (TARGET_GAS)						\
 	fprintf (FILE,						\
-	       "\t.NSUBSPA %.31s,QUAD=0,ALIGN=8,ACCESS=44,CODE_ONLY,SORT=24\n", NAME);\
+	       "\t.NSUBSPA %s,QUAD=0,ALIGN=8,ACCESS=44,CODE_ONLY,SORT=24\n", NAME);\
       else							\
 	fprintf (FILE,						\
-	       "\t.NSUBSPA $%.29s$,QUAD=0,ALIGN=8,ACCESS=44,CODE_ONLY,SORT=24\n", NAME);\
+	       "\t.NSUBSPA $%s$,QUAD=0,ALIGN=8,ACCESS=44,CODE_ONLY,SORT=24\n", NAME);\
     }								\
   else if (!RELOC && DECL && DECL_READONLY_SECTION (DECL, RELOC))\
     {								\

Re: C++ Issue on GCC 3.0 branch

[law]

  In message <200104231528.LAA10001@hiauly1.hia.nrc.ca>you write:
  > > The whole purpose of the change is to not get false hits when collect2
  > > search for ctors/dtors which lead to undefined symbols.
  > > 
  > > I'd rather not remove "-p" just because hpux's nm core dumps with the opt
  > ion
  > > unless having the option gives us no benefit.  I'm not likely revert the
  > > truncation of section names, even if we remove -p.  Once bitten, twice sh
  > y.
  > 
  > The patch was to remove " -n", not "-p" from NM_FLAGS.  HP nm doesn't dump
  > core on objects with long subspace names when "-p" is used. 
I know that, but that's not a good reason to re-enable long subspace names.

  > This is the change to the subspace output.  It fixes various missing
  > global names.  I don't fully understand the problem but I did see that
  > the missing constructors in the shared library had truncated names.
  > I use GNU nm rather than HP nm for my builds.  Thus, there is no possibilty
  > for false hits.
I strongly think you're barking up the wrong tree in regards to the truncated 
names for ctors.    I'm not seeing this problem at all.


  > 2001-04-22  John David Anglin  <dave@hiauly1.hia.nrc.ca>
  > 
  > 	* som.h: Don't truncate subspace names.
This patch is not OK.  Please do not install it.
jeff

Re: C++ Issue on GCC 3.0 branch

[John David Anglin]

>   > This is the change to the subspace output.  It fixes various missing
>   > global names.  I don't fully understand the problem but I did see that
>   > the missing constructors in the shared library had truncated names.
>   > I use GNU nm rather than HP nm for my builds.  Thus, there is no possibilty
>   > for false hits.
> I strongly think you're barking up the wrong tree in regards to the truncated 
> names for ctors.    I'm not seeing this problem at all.

Have you tried using GNU nm?  I am presently using version 2.11 with my
builds.  I will do some more testing.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: C++ Issue on GCC 3.0 branch

[law]

  In message < 200104222154.RAA04022@hiauly1.hia.nrc.ca >you write:
  > >   Then, mail them to me, with the PA traget-triplet and cc1plus
  > > command-line options.  I should be able to track down what's going on,
  > > although someone may have to remind me about how some of the PA
  > > assembler directives work...
  > 
  > I think I am beginning to see the light.  In start_objects, there is
  > the code:
  > 
  > #if defined(ASM_OUTPUT_CONSTRUCTOR) && defined(ASM_OUTPUT_DESTRUCTOR)
  >   /* It can be a static function as long as collect2 does not have
  >      to scan the object file to find its ctor/dtor routine.  */
  >   TREE_PUBLIC (current_function_decl) = 0;
  > #endif
  > 
  > ASM_OUTPUT_CONSTRUCTOR and ASM_OUTPUT_DESTRUCTOR are not defined for
  > hpux 10.20.  The are some defines in pa-64.h for the 64-bit runtime
  > but they are disabled with #undef's following the defines.  As a result,
  > constructors are global.  For the SOM linker, I think we have the section
  > support needed to define these.  I don't know about the startup issues.
  > Hopefully, this would allow the constructors to be static.
There are probably ways that we could make ASM_OUTPUT_* work, then start
tackling startup/runtime for SOM.  However, that wouldn't help AIX (which
we know has similar problems) or other systems which might have this problem.

I'd like to see us look for a general solution for the set of targets which
do not have ASM_OUTPUT_{CONSTRUCTOR,DESTRUCTOR} defined rather than look for
a SOM specific solution.

Jeff

Re: C++ Issue on GCC 3.0 branch

[John David Anglin]

> I'd like to see us look for a general solution for the set of targets which
> do not have ASM_OUTPUT_{CONSTRUCTOR,DESTRUCTOR} defined rather than look for
> a SOM specific solution.

I reverted the subspace name truncation in pa.h and did a build last night.
This resolved the problem with missing symbols that I saw.  With this and
the constructor patch, the shared libstdc++ now builds.  However, most
applications linked to it generate a segmentation fault when they start.
It appears this happens when they try to run the constructors.  I will see if
I can figure out what's going wrong.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: C++ Issue on GCC 3.0 branch

[law]

  In message < 200104231508.LAA04771@hiauly1.hia.nrc.ca >you write:
  > > I'd like to see us look for a general solution for the set of targets whi
  > ch
  > > do not have ASM_OUTPUT_{CONSTRUCTOR,DESTRUCTOR} defined rather than look 
  > for
  > > a SOM specific solution.
  > 
  > I reverted the subspace name truncation in pa.h and did a build last night.
  > This resolved the problem with missing symbols that I saw.  With this and
  > the constructor patch, the shared libstdc++ now builds.  However, most
  > applications linked to it generate a segmentation fault when they start.
  > It appears this happens when they try to run the constructors.  I will see 
  > if
  > I can figure out what's going wrong.
Please stop.  You're going down the wrong direction into a rathole.

jeff

Re: C++ Issue on GCC 3.0 branch

[John David Anglin]

>   > This resolved the problem with missing symbols that I saw.  With this and
>   > the constructor patch, the shared libstdc++ now builds.  However, most
>   > applications linked to it generate a segmentation fault when they start.
>   > It appears this happens when they try to run the constructors.  I will see 
>   > if
>   > I can figure out what's going wrong.
> Please stop.  You're going down the wrong direction into a rathole.

Don't think so but your entitled to your opinions.  Note that the static
results for the libstdc++-v3 testsuite are still reasonable with my changes.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: C++ Issue on GCC 3.0 branch

[John David Anglin]

>   > I reverted the subspace name truncation in pa.h and did a build last night.
>   > This resolved the problem with missing symbols that I saw.  With this and
>   > the constructor patch, the shared libstdc++ now builds.  However, most
>   > applications linked to it generate a segmentation fault when they start.
>   > It appears this happens when they try to run the constructors.  I will see 
>   > if
>   > I can figure out what's going wrong.
> Please stop.  You're going down the wrong direction into a rathole.

Here is some more information about the above problem using:

# /usr/local/bin/hp735-hpux-gdb header_ciso646.sh-exe
GDB is free software and you are welcome to distribute copies of it
 under certain conditions; type "show copying" to see the conditions.
There is absolutely no warranty for GDB; type "show warranty" for details.
GDB 4.16 (hppa1.1-hp-hpux --target hp735-hpux),
Copyright 1996 Free Software Foundation, Inc...
(gdb) run
Starting program: /xxx/gnu/gcc-3.0/objdir/hppa1.1-hp-hpux10.20/libstdc++-v3/test
suite/header_ciso646.sh-exe
warning: Unable to find __d_pid symbol in object file.
warning: Suggest linking with /usr/lib/end.o.
warning: GDB will be unable to track shl_load/shl_unload calls
Current language:  auto; currently c
Program received signal SIGSEGV, Segmentation fault.
0x7adfdc08 in _ZNSt8ios_base4InitC1Ev (this=0x7ada5998)
    at ../../../../libstdc++-v3/src/ios.cc:138
138         if (++_S_ios_base_init == 1)
Current language:  auto; currently c++
(gdb) bt
#0  0x7adfdc08 in _ZNSt8ios_base4InitC1Ev (this=0x7ada5998)
    at ../../../../libstdc++-v3/src/ios.cc:138
#1  0x7adfae90 in _Z41__static_initialization_and_destruction_0ii (
    __initialize_p=1, __priority=65535)
    at ../../../../libstdc++-v3/include/bits/stl_algobase.h:57
#2  0x7adfb264 in _GLOBAL__I__ZNKSt12_Base_bitsetILj1EE16_M_do_find_firstEj ()
    at ../../../../libstdc++-v3/include/bits/stl_algobase.h:727
#3  0x7ade43dc in _GLOBAL__FI_libstdc___sl_3_0 ()
#4  0x28a0 in __do_global_ctors ()
#5  0x2950 in __main ()
#6  0x4f20 in main ()
    at /xxx/gnu/gcc-3.0/libstdc++-v3/testsuite/17_intro/header_ciso646.cc:122

The program binding has been changed to immediate.  I am using the above
old version of gdb because gdb 5.0 (my latest build) dumps core when the
program hits the SIGSEGV.

(gdb) disass
Dump of assembler code for function _ZNSt8ios_base4InitC1Ev:
0x7adfdb58 <_ZNSt8ios_base4InitC1Ev>:   stw rp,-14(sr0,sp)
0x7adfdb5c <_ZNSt8ios_base4InitC1Ev+4>: copy r3,r1
0x7adfdb60 <_ZNSt8ios_base4InitC1Ev+8>: copy sp,r3
0x7adfdb64 <_ZNSt8ios_base4InitC1Ev+12>:        stwm r1,1c0(sr0,sp)
0x7adfdb68 <_ZNSt8ios_base4InitC1Ev+16>:        stw r19,-20(sr0,sp)
0x7adfdb6c <_ZNSt8ios_base4InitC1Ev+20>:        stw r18,c8(sr0,r3)
0x7adfdb70 <_ZNSt8ios_base4InitC1Ev+24>:        stw r17,cc(sr0,r3)
0x7adfdb74 <_ZNSt8ios_base4InitC1Ev+28>:        stw r16,d0(sr0,r3)
0x7adfdb78 <_ZNSt8ios_base4InitC1Ev+32>:        stw r15,d4(sr0,r3)
0x7adfdb7c <_ZNSt8ios_base4InitC1Ev+36>:        stw r14,d8(sr0,r3)
0x7adfdb80 <_ZNSt8ios_base4InitC1Ev+40>:        stw r13,dc(sr0,r3)
0x7adfdb84 <_ZNSt8ios_base4InitC1Ev+44>:        stw r12,e0(sr0,r3)
0x7adfdb88 <_ZNSt8ios_base4InitC1Ev+48>:        stw r11,e4(sr0,r3)
0x7adfdb8c <_ZNSt8ios_base4InitC1Ev+52>:        stw r10,e8(sr0,r3)
0x7adfdb90 <_ZNSt8ios_base4InitC1Ev+56>:        stw r9,ec(sr0,r3)
0x7adfdb94 <_ZNSt8ios_base4InitC1Ev+60>:        stw r8,f0(sr0,r3)
0x7adfdb98 <_ZNSt8ios_base4InitC1Ev+64>:        stw r7,f4(sr0,r3)
0x7adfdb9c <_ZNSt8ios_base4InitC1Ev+68>:        stw r6,f8(sr0,r3)
0x7adfdba0 <_ZNSt8ios_base4InitC1Ev+72>:        stw r5,fc(sr0,r3)
0x7adfdba4 <_ZNSt8ios_base4InitC1Ev+76>:        stw r4,100(sr0,r3)
0x7adfdba8 <_ZNSt8ios_base4InitC1Ev+80>:        ldo 108(r3),r1
0x7adfdbac <_ZNSt8ios_base4InitC1Ev+84>:        fstds,ma fr21,8(sr0,r1)
0x7adfdbb0 <_ZNSt8ios_base4InitC1Ev+88>:        fstds,ma fr20,8(sr0,r1)
0x7adfdbb4 <_ZNSt8ios_base4InitC1Ev+92>:        fstds,ma fr19,8(sr0,r1)
0x7adfdbb8 <_ZNSt8ios_base4InitC1Ev+96>:        fstds,ma fr18,8(sr0,r1)
0x7adfdbbc <_ZNSt8ios_base4InitC1Ev+100>:       fstds,ma fr17,8(sr0,r1)
0x7adfdbc0 <_ZNSt8ios_base4InitC1Ev+104>:       fstds,ma fr16,8(sr0,r1)
0x7adfdbc4 <_ZNSt8ios_base4InitC1Ev+108>:       fstds,ma fr15,8(sr0,r1)
0x7adfdbc8 <_ZNSt8ios_base4InitC1Ev+112>:       fstds,ma fr14,8(sr0,r1)
0x7adfdbcc <_ZNSt8ios_base4InitC1Ev+116>:       fstds,ma fr13,8(sr0,r1)
0x7adfdbd0 <_ZNSt8ios_base4InitC1Ev+120>:       fstds,ma fr12,8(sr0,r1)
0x7adfdbd4 <_ZNSt8ios_base4InitC1Ev+124>:       stw r26,-24(sr0,r3)
0x7adfdbd8 <_ZNSt8ios_base4InitC1Ev+128>:
    bl 0x7adfdac8 <__get_eh_context>,rp
0x7adfdbdc <_ZNSt8ios_base4InitC1Ev+132>:       nop
0x7adfdbe0 <_ZNSt8ios_base4InitC1Ev+136>:       ldw 9c(sr0,r3),r19
0x7adfdbe4 <_ZNSt8ios_base4InitC1Ev+140>:       copy ret0,r20
0x7adfdbe8 <_ZNSt8ios_base4InitC1Ev+144>:       stws r20,-10(sr0,sp)
0x7adfdbec <_ZNSt8ios_base4InitC1Ev+148>:       fldws -10(sr0,sp),fr22
0x7adfdbf0 <_ZNSt8ios_base4InitC1Ev+152>:       fstws fr22,-10(sr0,sp)
0x7adfdbf4 <_ZNSt8ios_base4InitC1Ev+156>:       ldws -10(sr0,sp),r1
0x7adfdbf8 <_ZNSt8ios_base4InitC1Ev+160>:       stw r1,a4(sr0,r3)
0x7adfdbfc <_ZNSt8ios_base4InitC1Ev+164>:       stw r19,9c(sr0,r3)
0x7adfdc00 <_ZNSt8ios_base4InitC1Ev+168>:       addil -1000,r19
0x7adfdc04 <_ZNSt8ios_base4InitC1Ev+172>:       copy r1,r21
0x7adfdc08 <_ZNSt8ios_base4InitC1Ev+176>:       ldw 324(sr0,r21),r21

Register is wrong (it is 0 at 0x7adfdc00) causing the fault at the ldw.
Register r21 is 0xfffff000.  This looks like a code problem.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: C++ Issue on GCC 3.0 branch

[John David Anglin]

> Weird.  I actually get an abort on that code, compiling as you
> suggested.  (I'm using a cross-compiler from i686-pc-linux-gnu.)
> 
> What happens is that force_const_mem records constant-pool entries for
> labels here, from expand_builtin_setjmp_setup:
> 
>   emit_move_insn (validize_mem (mem),
> 		  force_reg (Pmode, gen_rtx_LABEL_REF (Pmode, receiver_label)));
> 
> Then, flow deletes the labels.  Then, when output_constant_pool goes
> to output the reference, this abort files:
> 
> 	case LABEL_REF:
> 	  tmp = XEXP (x, 0);
> 	  if (INSN_DELETED_P (tmp)
> 	      || (GET_CODE (tmp) == NOTE
> 		  && NOTE_LINE_NUMBER (tmp) == NOTE_INSN_DELETED))
> 	    {
> 	      abort ();
> 	      x = const0_rtx;
> 	    }
> 
> What's supposed to keep that from happenning?

How about this?

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

2001-04-21  John David Anglin  <dave@hiauly1.hia.nrc.ca>

	* builtins.c (expand_builtin_setjmp_setup): Set nonlocal flag in label.

--- builtins.c.orig	Tue Apr 17 14:26:59 2001
+++ builtins.c	Sat Apr 21 18:41:27 2001
@@ -468,6 +468,7 @@
   enum machine_mode sa_mode = STACK_SAVEAREA_MODE (SAVE_NONLOCAL);
   rtx stack_save;
   rtx mem;
+  rtx label_ref;
 
   if (setjmp_alias_set == -1)
     setjmp_alias_set = new_alias_set ();
@@ -495,8 +496,9 @@
   mem = gen_rtx_MEM (Pmode, plus_constant (buf_addr, GET_MODE_SIZE (Pmode))),
   MEM_ALIAS_SET (mem) = setjmp_alias_set;
 
-  emit_move_insn (validize_mem (mem),
-		  force_reg (Pmode, gen_rtx_LABEL_REF (Pmode, receiver_label)));
+  label_ref = gen_rtx_LABEL_REF (Pmode, receiver_label);
+  LABEL_REF_NONLOCAL_P (label_ref) = 1;
+  emit_move_insn (validize_mem (mem), force_reg (Pmode, label_ref));
 
   stack_save = gen_rtx_MEM (sa_mode,
 			    plus_constant (buf_addr,

Re: C++ Issue on GCC 3.0 branch

[John David Anglin]

> 2001-04-21  John David Anglin  <dave@hiauly1.hia.nrc.ca>
> 
> 	* builtins.c (expand_builtin_setjmp_setup): Set nonlocal flag in label.

Close but no cigar.  This one actually bootstraps with no regressions under
i686 linux.  However, I think it only addresses the symptom of the problem.
There must be a label uses problem somewhere.  In any event, the testcase
for duplicate symbols will compile with the patch installed.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

2001-04-21  John David Anglin  <dave@hiauly1.hia.nrc.ca>

	* builtins.c (expand_builtin_setjmp): Mark next_lab as used.

--- builtins.c.orig	Wed Feb  7 05:24:22 2001
+++ builtins.c	Sat Apr 21 20:18:59 2001
@@ -617,6 +617,7 @@
   buf_addr = expand_expr (TREE_VALUE (arglist), NULL_RTX, VOIDmode, 0);
 
   next_lab = gen_label_rtx ();
+  LABEL_PRESERVE_P (next_lab) = 1;
   cont_lab = gen_label_rtx ();
 
   expand_builtin_setjmp_setup (buf_addr, next_lab);

Re: C++ Issue on GCC 3.0 branch

[Bernd Schmidt]

On Sat, 21 Apr 2001, John David Anglin wrote:

> > 2001-04-21  John David Anglin  <dave@hiauly1.hia.nrc.ca>
> >
> > 	* builtins.c (expand_builtin_setjmp_setup): Set nonlocal flag in label.
>
> Close but no cigar.  This one actually bootstraps with no regressions under
> i686 linux.  However, I think it only addresses the symptom of the problem.
> There must be a label uses problem somewhere.  In any event, the testcase
> for duplicate symbols will compile with the patch installed.

You might want to look at the patches I installed on the 2.95 branch after
2.95.3.  This sounds like it's exactly the same problem.


Bernd

Re: C++ Issue on GCC 3.0 branch

[law]

  In message <Pine.LNX.4.33.0104231017340.7552-100000@host140.cambridge.redhat.
com>you write:
  > > There must be a label uses problem somewhere.  In any event, the testcase
  > > for duplicate symbols will compile with the patch installed.
  > 
  > You might want to look at the patches I installed on the 2.95 branch after
  > 2.95.3.  This sounds like it's exactly the same problem.
Are you referring to this patch?

2001-03-28  Bernd Schmidt  <bernds@redhat.com>

        * flow.c (propagate_block): When trying to delete a case vector, cope
        if its label has LABEL_PRESERVE_P set.
        * jump.c (jump_optimize_1): Move call to delete_barrier_successors to
        a point where JUMP_LABELS and LABEL_NUSES are set up properly.
        (delete_barrier_successors): If deleting a table jump, delete the case
        vector as well.
        * varasm.c (force_const_mem): If we have a label, set LABEL_PRESERVE_P
        so it won't get deleted.


Just want to be sure before I install it locally and fire off my tests.

jeff

Re: C++ Issue on GCC 3.0 branch

[Bernd Schmidt]

On Mon, 23 Apr 2001 law@redhat.com wrote:

>   In message <Pine.LNX.4.33.0104231017340.7552-100000@host140.cambridge.redhat.
> com>you write:
>   > > There must be a label uses problem somewhere.  In any event, the testcase
>   > > for duplicate symbols will compile with the patch installed.
>   >
>   > You might want to look at the patches I installed on the 2.95 branch after
>   > 2.95.3.  This sounds like it's exactly the same problem.
> Are you referring to this patch?
>
> 2001-03-28  Bernd Schmidt  <bernds@redhat.com>
>
>         * flow.c (propagate_block): When trying to delete a case vector, cope
>         if its label has LABEL_PRESERVE_P set.
>         * jump.c (jump_optimize_1): Move call to delete_barrier_successors to
>         a point where JUMP_LABELS and LABEL_NUSES are set up properly.
>         (delete_barrier_successors): If deleting a table jump, delete the case
>         vector as well.
>         * varasm.c (force_const_mem): If we have a label, set LABEL_PRESERVE_P
>         so it won't get deleted.

Yes.


Bernd

Re: C++ Issue on GCC 3.0 branch

[Bernd Schmidt]

On Mon, 23 Apr 2001 law@redhat.com wrote:

> 2001-03-28  Bernd Schmidt  <bernds@redhat.com>
>
>         * flow.c (propagate_block): When trying to delete a case vector, cope
>         if its label has LABEL_PRESERVE_P set.
>         * jump.c (jump_optimize_1): Move call to delete_barrier_successors to
>         a point where JUMP_LABELS and LABEL_NUSES are set up properly.
>         (delete_barrier_successors): If deleting a table jump, delete the case
>         vector as well.
>         * varasm.c (force_const_mem): If we have a label, set LABEL_PRESERVE_P
>         so it won't get deleted.

Just remembered; this also needs the followup

2001-03-30  Bernd Schmidt  <bernds@redhat.com>

        * jump.c (delete_barrier_successors): Fix error in last change.


Bernd

Re: C++ Issue on GCC 3.0 branch

[law]

  In message <Pine.LNX.4.33.0104231556040.7552-100000@host140.cambridge.redhat.
com>you write:
  > Just remembered; this also needs the followup
  > 
  > 2001-03-30  Bernd Schmidt  <bernds@redhat.com>
  > 
  >         * jump.c (delete_barrier_successors): Fix error in last change.
OK.  Thanks.  I'll give the set a whirl on my PAs :-)

jeff

Re: C++ Issue on GCC 3.0 branch

[Mark Mitchell]

  2001-04-21  John David Anglin  <dave@hiauly1.hia.nrc.ca>

	  * builtins.c (expand_builtin_setjmp): Mark next_lab as used.

  --- builtins.c.orig	Wed Feb  7 05:24:22 2001
  +++ builtins.c	Sat Apr 21 20:18:59 2001
  @@ -617,6 +617,7 @@
     buf_addr = expand_expr (TREE_VALUE (arglist), NULL_RTX, VOIDmode, 0);

     next_lab = gen_label_rtx ();
  +  LABEL_PRESERVE_P (next_lab) = 1;
     cont_lab = gen_label_rtx ();

     expand_builtin_setjmp_setup (buf_addr, next_lab);

Even with this workaround patch I still get a crash using a cross
compiler, so I guess I'll have to wait for Jeff's reworking of Bernd's
patch.

Thanks,

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: C++ Issue on GCC 3.0 branch

[John David Anglin]

>   2001-04-21  John David Anglin  <dave@hiauly1.hia.nrc.ca>
> 
> 	  * builtins.c (expand_builtin_setjmp): Mark next_lab as used.
> 
>   --- builtins.c.orig	Wed Feb  7 05:24:22 2001
>   +++ builtins.c	Sat Apr 21 20:18:59 2001
>   @@ -617,6 +617,7 @@
>      buf_addr = expand_expr (TREE_VALUE (arglist), NULL_RTX, VOIDmode, 0);
> 
>      next_lab = gen_label_rtx ();
>   +  LABEL_PRESERVE_P (next_lab) = 1;
>      cont_lab = gen_label_rtx ();
> 
>      expand_builtin_setjmp_setup (buf_addr, next_lab);
> 
> Even with this workaround patch I still get a crash using a cross
> compiler, so I guess I'll have to wait for Jeff's reworking of Bernd's
> patch.

Strange.  I just tried it again with the 3.0 source from a few hours
ago with no problems.  The above patch was the only source change.

I just configured with `--with-gnu-as --target=hppa1.1-hp-hpux10.20' and
did a make.  CFLAGS were the default `-g -O2'.  My build gcc was 3.0
20010421 (prerelease).

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: C++ Issue on GCC 3.0 branch

[Mark Mitchell]

After making Dave work hard sending me lots of information, it turns
out that his original patch is exactly the right thing.

I checked in the attached, on both the mainline and the branch;
hopefully it will remove the duplicate symbols on HPUX.

Tested on i686-pc-linux-gnu, and by looking at the .s output for
Dave's testcase.

Thanks,

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

2001-04-25  Mark Mitchell  <mark@codesourcery.com>

	* optimize.c (maybe_clone_body): Copy TREE_PUBLIC before emitting
	the clone.

Index: optimize.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/cp/optimize.c,v
retrieving revision 1.51.2.13
diff -c -p -r1.51.2.13 optimize.c
*** optimize.c	2001/04/25 00:12:47	1.51.2.13
--- optimize.c	2001/04/26 00:28:07
*************** maybe_clone_body (fn)
*** 1051,1056 ****
--- 1051,1057 ----
        DECL_EXTERNAL (clone) = DECL_EXTERNAL (fn);
        DECL_INTERFACE_KNOWN (clone) = DECL_INTERFACE_KNOWN (fn);
        DECL_NOT_REALLY_EXTERN (clone) = DECL_NOT_REALLY_EXTERN (fn);
+       TREE_PUBLIC (clone) = TREE_PUBLIC (fn);
  
        /* Start processing the function.  */
        push_to_top_level ();

Re: C++ Issue on GCC 3.0 branch

[John David Anglin]

Mark,

> After making Dave work hard sending me lots of information, it turns
> out that his original patch is exactly the right thing.
> 
> I checked in the attached, on both the mainline and the branch;
> hopefully it will remove the duplicate symbols on HPUX.

While I am certain that the patch eliminates the duplicate symbols, I
am still concerned that assemble_external is being called with TREE_PUBLIC
and DECL_EXTERNAL set for the type declarations.  This causes .IMPORT
statements to be generated for the symbols under hpux.  While this appears
harmless under HPUX, I am not sure it would be under all circumstances.
It seemed to me that when there is no weak support these declarations
should not be external.  I remember there was some discussion of this
under AIX back in January.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: C++ Issue on GCC 3.0 branch

[Mark Mitchell]

>>>>> "John" == John David Anglin <dave@hiauly1.hia.nrc.ca> writes:

    John> While I am certain that the patch eliminates the duplicate
    John> symbols, I am still concerned that assemble_external is
    John> being called with TREE_PUBLIC and DECL_EXTERNAL set for the
    John> type declarations.  This causes .IMPORT statements to be

Yes, that's why I asked about this.

There's a basic problem here; both the C and C++ front-ends call
assemble_external in a way that is inconsistent with the
assemble_external documentation.

In particular, ASM_OUTPUT_EXTERNAL is documented as used when
something is 

     A C statement (sans semicolon) to output to the stdio stream
     STREAM any text necessary for declaring the name of an external
     symbol named NAME which is referenced in this compilation but not
     defined.  The value of DECL is the tree node for the declaration.

You can't know this until the end of the translation unit.  But, we
compile a function-at-a-time, so if we see:

  extern void f(); 
  void g() { f(); }
  void f() {}

we call this macro for `f'.

It's even more extreme in C++ because we don't make up our minds about
the linkages of some functions until very late in the game.  (See the
tricks played with DECL_NOT_REALLY_EXTERN.)  That's all really pretty
grotesque, but it's not easy to fix, and it's been that way for a long
time, so I'm guessing most systems deal with it OK.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: C++ Issue on GCC 3.0 branch

[law]

  In message < 20010425173144F.mitchell@codesourcery.com >you write:
  > 
  > After making Dave work hard sending me lots of information, it turns
  > out that his original patch is exactly the right thing.
  > 
  > I checked in the attached, on both the mainline and the branch;
  > hopefully it will remove the duplicate symbols on HPUX.
  > 
  > Tested on i686-pc-linux-gnu, and by looking at the .s output for
  > Dave's testcase.
Noted.  I'm testing hpux PA32 with it now.

jeff

Re: C++ Issue on GCC 3.0 branch

[John David Anglin]

> 0x7adfdbd4 <_ZNSt8ios_base4InitC1Ev+124>:       stw r26,-24(sr0,r3)
> 0x7adfdbd8 <_ZNSt8ios_base4InitC1Ev+128>:
>     bl 0x7adfdac8 <__get_eh_context>,rp
> 0x7adfdbdc <_ZNSt8ios_base4InitC1Ev+132>:       nop
> 0x7adfdbe0 <_ZNSt8ios_base4InitC1Ev+136>:       ldw 9c(sr0,r3),r19
> 0x7adfdbe4 <_ZNSt8ios_base4InitC1Ev+140>:       copy ret0,r20
> 0x7adfdbe8 <_ZNSt8ios_base4InitC1Ev+144>:       stws r20,-10(sr0,sp)
> 0x7adfdbec <_ZNSt8ios_base4InitC1Ev+148>:       fldws -10(sr0,sp),fr22
> 0x7adfdbf0 <_ZNSt8ios_base4InitC1Ev+152>:       fstws fr22,-10(sr0,sp)
> 0x7adfdbf4 <_ZNSt8ios_base4InitC1Ev+156>:       ldws -10(sr0,sp),r1
> 0x7adfdbf8 <_ZNSt8ios_base4InitC1Ev+160>:       stw r1,a4(sr0,r3)
> 0x7adfdbfc <_ZNSt8ios_base4InitC1Ev+164>:       stw r19,9c(sr0,r3)

The problem was not my patch.  There is a real problem with pic C++ code.
The problem is that the "first" save for register r19 comes after the first
function call.  The initial save of r19 was to meet ABI requirements.  The
save at 0x7adfdbfc is the real save that was supposed to be used for
restoration of r19 after function calls.

You can see the problem in the rtl:

;; Function std::ios_base::Init::Init()

(note 1 0 6 ("../../../../libstdc++-v3/src/ios.cc") 137 0)

(insn 6 1 54 (set (reg/v/u/f:SI 94)
        (reg:SI 26 %r26)) -1 (nil)
    (expr_list:REG_EQUIV (mem/u/f:SI (plus:SI (reg/f:SI 89 virtual-incoming-args)
                (const_int -4 [0xfffffffc])) 0)
        (nil)))

(insn 54 6 43 (use:SI (reg:SI 105)) -1 (nil)
    (expr_list:REG_EH_CONTEXT (reg:SI 105)
        (nil)))

(insn 43 54 7 (set (reg:SI 103)
        (reg:SI 19 %r19)) -1 (nil)
    (nil))

(note 7 43 15 NOTE_INSN_FUNCTION_BEG 0)

(note 15 7 17 ("../../../../libstdc++-v3/src/ios.cc") 138 0)

As can be seen, the eh context stuff has been pushed to the beginning of
the function.   We need insn 43 to be at the beginning before the eh
context stuff.  We try to put the save at the start in hppa_init_pic_save:

void hppa_init_pic_save ()
{
  rtx insn, picreg;

  picreg = gen_rtx_REG (word_mode, PIC_OFFSET_TABLE_REGNUM);
  PIC_OFFSET_TABLE_SAVE_RTX = gen_reg_rtx (Pmode);
  insn = gen_rtx_SET (VOIDmode, PIC_OFFSET_TABLE_SAVE_RTX, picreg);

  /* Emit the insn at the beginning of the function after the prologue.  */
  push_topmost_sequence ();
  emit_insn_after (insn, last_parm_insn ? last_parm_insn : get_insns ());
  pop_topmost_sequence ();
}

This is called when the first call insn is encountered.  Any thoughts
on how to fix this?

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: C++ Issue on GCC 3.0 branch

[law]

  In message < 200104232221.SAA21738@hiauly1.hia.nrc.ca >you write:
  > As can be seen, the eh context stuff has been pushed to the beginning of
  > the function.   We need insn 43 to be at the beginning before the eh
  > context stuff.  We try to put the save at the start in hppa_init_pic_save:
Interesting.  I'm not sure if I'll have time to peek at this tonight/tomorrow.
So, if you've got time, you'd want to investigate precisely how the code to
call get_eh_context gets inserted before the code to save the PIC register.

jeff

Re: C++ Issue on GCC 3.0 branch

[John David Anglin]

>   In message < 200104232221.SAA21738@hiauly1.hia.nrc.ca >you write:
>   > As can be seen, the eh context stuff has been pushed to the beginning of
>   > the function.   We need insn 43 to be at the beginning before the eh
>   > context stuff.  We try to put the save at the start in hppa_init_pic_save:
> Interesting.  I'm not sure if I'll have time to peek at this tonight/tomorrow.
> So, if you've got time, you'd want to investigate precisely how the code to
> call get_eh_context gets inserted before the code to save the PIC register.

Yes!  I think that I have the fix.  See below.

The call to get_eh_context gets inserted before the code to save the PIC
register with the same technique that we use to save the PIC register:

rtx
get_eh_context ()
{
  if (current_function_ehc == 0)
    {
       rtx insn;

       current_function_ehc = gen_reg_rtx (Pmode);

       insn = gen_rtx_USE (GET_MODE (current_function_ehc),
			   current_function_ehc);
       insn = emit_insn_before (insn, get_first_nonparm_insn ());

       REG_NOTES (insn)
	 = gen_rtx_EXPR_LIST (REG_EH_CONTEXT, current_function_ehc,
			      REG_NOTES (insn));
    }
  return current_function_ehc;
}

Here are my latest test results for libstdc++-v3:

(chmod + ./mkcheck; \
  srcdir=`cd ../../../libstdc++-v3; pwd`; builddir=`pwd`; \
  test -d testsuite || (mkdir testsuite; chmod u+w testsuite); \
  cd testsuite; ${builddir}/mkcheck 0 ${builddir} ${srcdir})
running mkcheck
/xxx/gnu/gcc-3.0/objdir/hppa1.1-hp-hpux10.20/libstdc++-v3/mkcheck: testing the build directory
making utility ./printnow.exe

Detailed test results in ../20010424-mkcheck.txt
+: pass, -b: build failure, -r: run failure, x: disabled
------------------------------------------------------------------------
static	shared	test
------------------------------------------------------------------------
+	+	17_intro/header_ciso646.cc
+	+	17_intro/header_cstdio.cc
+	+	17_intro/header_cstdlib.cc
+	+	17_intro/header_cstring.cc
+	+	17_intro/header_ctime.cc
+	+	17_intro/header_cwchar.cc
+	+	17_intro/header_cwctype.cc
+	+	17_intro/header_fstream.cc
+	+	17_intro/header_iomanip.cc
+	+	17_intro/header_ios.cc
+	+	17_intro/header_iosfwd.cc
+	+	17_intro/header_iostream.cc
+	+	17_intro/header_istream.cc
+	+	17_intro/header_ostream.cc
+	+	17_intro/header_sstream.cc
+	+	17_intro/header_streambuf.cc
+	+	17_intro/headers.cc
+	+	17_intro/headers_c++.cc
+	+	17_intro/headers_c.cc
+	+	18_support/numeric_limits.cc
+	+	19_diagnostics/stdexceptions.cc
+	+	20_util/auto_ptr.cc
+	-r	21_strings/append.cc
-b	-b	21_strings/capacity.cc
+	+	21_strings/char_traits_requirements.cc
+	+	21_strings/char_traits_typedefs.cc
+	+	21_strings/compare.cc
-r	-r	21_strings/ctor_copy_dtor.cc
+	-r	21_strings/element_access.cc
+	+	21_strings/find.cc
+	-r	21_strings/insert.cc
+	+	21_strings/inserters_extractors.cc
+	+	21_strings/invariants.cc
+	+	21_strings/nonmember.cc
+	+	21_strings/operations.cc
+	+	21_strings/replace.cc
+	+	21_strings/rfind.cc
+	-r	21_strings/substr.cc
+	+	22_locale/codecvt_char_char.cc
+	+	22_locale/codecvt_unicode_char.cc
+	+	22_locale/codecvt_unicode_wchar_t.cc
+	+	22_locale/codecvt_wchar_t_char.cc
+	+	22_locale/ctor_copy_dtor.cc
+	+	22_locale/ctype.cc
-r	/xxx/gnu/gcc-3.0/objdir/hppa1.1-hp-hpux10.20/libstdc++-v3/mkcheck: printf: failed: invalid number
-r	/xxx/gnu/gcc-3.0/objdir/hppa1.1-hp-hpux10.20/libstdc++-v3/mkcheck: printf: failed: invalid number
22_locale/ctype_char_members.cc
+	+	22_locale/ctype_wchar_t_members.cc
+	+	22_locale/facet.cc
+	+	22_locale/global_templates.cc
+	+	22_locale/members.cc
-b	-b	22_locale/numpunct.cc
+	+	22_locale/numpunct_byname.cc
+	+	22_locale/numpunct_char_members.cc
+	+	22_locale/operators.cc
+	+	22_locale/static_members.cc
+	+	23_containers/bitset_ctor.cc
+	+	23_containers/bitset_shift.cc
-b	-b	23_containers/map_operators.cc
+	+	23_containers/multiset.cc
-b	-b	23_containers/set_operators.cc
+	+	23_containers/vector_capacity.cc
+	+	23_containers/vector_ctor.cc
+	-r	23_containers/vector_element_access.cc
+	+	23_containers/vector_modifiers.cc
+	+	24_iterators/istreambuf_iterator.cc
+	+	24_iterators/iterator.cc
+	+	25_algorithms/equal.cc
+	+	25_algorithms/lower_bound.cc
+	+	25_algorithms/min_max.cc
+	/xxx/gnu/gcc-3.0/objdir/hppa1.1-hp-hpux10.20/libstdc++-v3/mkcheck: printf: =: invalid number
+	/xxx/gnu/gcc-3.0/objdir/hppa1.1-hp-hpux10.20/libstdc++-v3/mkcheck: printf: =: invalid number
26_numerics/binary_closure.cc
+	+	26_numerics/buggy_complex.cc
+	+	26_numerics/c99_macros.cc
+	+	26_numerics/c_math.cc
+	+	26_numerics/complex_inserters_extractors.cc
+	+	26_numerics/complex_value.cc
+	+	26_numerics/valarray.cc
-b	-b	27_io/filebuf.cc
+	+	27_io/filebuf_members.cc
+	+	27_io/fpos.cc
+	+	27_io/ifstream_members.cc
+	+	27_io/ios_base_callbacks.cc
-r	/xxx/gnu/gcc-3.0/objdir/hppa1.1-hp-hpux10.20/libstdc++-v3/mkcheck: printf: 24689timemark: invalid number
-r	/xxx/gnu/gcc-3.0/objdir/hppa1.1-hp-hpux10.20/libstdc++-v3/mkcheck: printf: 24689timemark: invalid number
27_io/ios_base_members_static.cc
+	+	27_io/ios_base_storage.cc
+	+	27_io/ios_ctor.cc
+	+	27_io/ios_manip_basefield.cc
+	+	27_io/ios_manip_fmtflags.cc
+	-r	27_io/ios_members.cc
+	+	27_io/istream.cc
+	+	27_io/istream_extractor_arith.cc
-r	/xxx/gnu/gcc-3.0/objdir/hppa1.1-hp-hpux10.20/libstdc++-v3/mkcheck: printf: failed: invalid number
-r	/xxx/gnu/gcc-3.0/objdir/hppa1.1-hp-hpux10.20/libstdc++-v3/mkcheck: printf: failed: invalid number
27_io/istream_extractor_char.cc
+	+	27_io/istream_extractor_other.cc
+	+	27_io/istream_manip.cc
-b	-b	27_io/istream_seeks.cc
+	+	27_io/istream_sentry.cc
diff: ./istream_unformatted-2.txt: No such file or directory
+	diff: ./istream_unformatted-2.txt: No such file or directory
+	27_io/istream_unformatted.cc
+	+	27_io/istringstream_members.cc
+	/xxx/gnu/gcc-3.0/objdir/hppa1.1-hp-hpux10.20/libstdc++-v3/mkcheck: printf: cout: invalid number
+	/xxx/gnu/gcc-3.0/objdir/hppa1.1-hp-hpux10.20/libstdc++-v3/mkcheck: printf: cout: invalid number
27_io/narrow_stream_objects.cc
+	+	27_io/ofstream_members.cc
+	+	27_io/ostream.cc
+	+	27_io/ostream_inserter_arith.cc
+	+	27_io/ostream_inserter_char.cc
+	+	27_io/ostream_inserter_other.cc
+	+	27_io/ostream_manip.cc
+	+	27_io/ostream_seeks.cc
+	+	27_io/ostream_unformatted.cc
+	+	27_io/streambuf.cc
+	+	27_io/stringbuf.cc
+	+	27_io/stringstream.cc
+	+	27_io/wide_stream_objects.cc
+	+	ext/headers.cc
testrun == 9137 seconds

Most of the shared test now run sucessfully!  Yeah!

Here is the configuration:

1) Patch below to add the pic save to the parameter insns.

2) Hack to make type constructors static:
   < http://gcc.gnu.org/ml/gcc/2001-04/msg01011.html >.  Mark was going to
   provide a correct fix for this.

3) NM_FLAG fix:
   < http://gcc.gnu.org/ml/gcc-patches/2001-04/msg01058.html >.

4) Full length subspace names:
   < http://gcc.gnu.org/ml/gcc/2001-04/msg01067.html >.

5) GNU tools (as, nm, etc.) rather than HP.

I will try to look further into the section name problem tomorrow (I've just
driven 12 hours today).  I did notice that HP `nm -p' prints the subspace
names as `t' symbols and they still come out even with "-pg".  I will post
full testresults tomorrow.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

2001-01-04  John David Anglin  <dave@hiauly1.hia.nrc.ca>

	* pa.c (hppa_init_pic_save): Update last_parm_insn after emitting
	pic save insn.

--- pa.c.orig	Tue Apr 17 14:36:50 2001
+++ pa.c	Tue Apr 24 00:03:33 2001
@@ -3359,7 +3359,7 @@
 
   /* Emit the insn at the beginning of the function after the prologue.  */
   push_topmost_sequence ();
-  emit_insn_after (insn, last_parm_insn ? last_parm_insn : get_insns ());
+  last_parm_insn = emit_insn_before (insn, get_first_nonparm_insn ());
   pop_topmost_sequence ();
 }
 

Re: C++ Issue on GCC 3.0 branch

[law]

  In message < 200104250323.XAA05283@hiauly1.hia.nrc.ca >you write:
  > 2001-01-04  John David Anglin  <dave@hiauly1.hia.nrc.ca>
  > 
  > 	* pa.c (hppa_init_pic_save): Update last_parm_insn after emitting
  > 	pic save insn.
This is fine for the mainline sources as well as the branch.

Thanks for tracking this down!

If you want another challenge -- the rethrow1.C test from the g++ testsuite is
getting into an infinite loop.  A 2.95.x based compiler does the right thing.

I've started poking at this, but I don't have a real clear understanding of
the C++ language or its EH semantics.  About the only tidbit I've got that
might be helpful is that we might be missing a call to cp_pop_exception.

jeff

Re: C++ Issue on GCC 3.0 branch

[Mark Mitchell]

>>>>> "law" == law  <law@redhat.com> writes:

    law> I've started poking at this, but I don't have a real clear
    law> understanding of the C++ language or its EH semantics.  About
    law> the only tidbit I've got that might be helpful is that we
    law> might be missing a call to cp_pop_exception.

I'm delighted that we're making progress on HPUX.  That's exciting.

Of course, RTH is getting ready to stand EH on its head.  So, unless
this happens on the mainline, it's probaby not worth looking at; the
whole land of exceptions is going to turn upside down RSN.

Thanks,

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: C++ Issue on GCC 3.0 branch

[law]

  In message < 20010426170133Z.mitchell@codesourcery.com >you write:
  > >>>>> "law" == law  <law@redhat.com> writes:
  > 
  >     law> I've started poking at this, but I don't have a real clear
  >     law> understanding of the C++ language or its EH semantics.  About
  >     law> the only tidbit I've got that might be helpful is that we
  >     law> might be missing a call to cp_pop_exception.
  > 
  > I'm delighted that we're making progress on HPUX.  That's exciting.
  > 
  > Of course, RTH is getting ready to stand EH on its head.  So, unless
  > this happens on the mainline, it's probaby not worth looking at; the
  > whole land of exceptions is going to turn upside down RSN.
I'm really not looking at the mainline at all.  I'll put debugging EH stuff
on hold for now and look at other issues.
jeff

Re: C++ Issue on GCC 3.0 branch

[John David Anglin]

>   In message < 200104250323.XAA05283@hiauly1.hia.nrc.ca >you write:
>   > 2001-01-04  John David Anglin  <dave@hiauly1.hia.nrc.ca>
>   > 
>   > 	* pa.c (hppa_init_pic_save): Update last_parm_insn after emitting
>   > 	pic save insn.
> This is fine for the mainline sources as well as the branch.
> 
> Thanks for tracking this down!

Before I installed this, I checked to make sure there were no gcc regressions
in the testsuite with -fPIC.  I found that in fact there were some.  It looks
like there are problems with the placement of the save instruction when
the first non parameter insn is nil.  I think we need to place the save
after the first insn (the one returned by get_insns ()) in this case.

Some of the fails in the testsuite are due to an abort at integrate.c:430
due to first insn not being a note:

;; Function z

(note 2 0 26 NOTE_INSN_DELETED 0)

(insn 26 2 3 (set (reg:SI 98)
        (reg:SI 19 %r19)) -1 (nil)
    (nil))

(note 3 26 5 NOTE_INSN_FUNCTION_BEG 0)

I am going to go back to the original form and not use
get_first_nonparm_insn ().  I think this will fix the problem.
This suggests that there is also a bug in get_eh_context () for
the same reason.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: C++ Issue on GCC 3.0 branch

[John David Anglin]

> If you want another challenge -- the rethrow1.C test from the g++ testsuite is
> getting into an infinite loop.  A 2.95.x based compiler does the right thing.
> 
> I've started poking at this, but I don't have a real clear understanding of
> the C++ language or its EH semantics.  About the only tidbit I've got that
> might be helpful is that we might be missing a call to cp_pop_exception.

I think we need to define builtin_setjmp_receiver to restore r19.  The
default exception method I believe is exceptions via longjmp, so we need
this.  However, I have no idea whether or not this will fix the problem
with rethrow1.C.

I also noticed a while back that exception_receiver uses a stack offset
of -32 to restore the pic offset table register.  This won't work on
the 64-bit target.  I think we should restore from the
PIC_OFFSET_TABLE_SAVE_RTX.  However, we need to wait for it to be
initialized.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: C++ Issue on GCC 3.0 branch

[law]

  In message < 200104272214.SAA06753@hiauly1.hia.nrc.ca >you write:
  > I think we need to define builtin_setjmp_receiver to restore r19.  The
  > default exception method I believe is exceptions via longjmp, so we need
  > this.  However, I have no idea whether or not this will fix the problem
  > with rethrow1.C.
Yes, we probably need to restore %r19, but I'm 99.9 certain that's not the
problem with the rethrow test since they fail with static libraries.


  > I also noticed a while back that exception_receiver uses a stack offset
  > of -32 to restore the pic offset table register.  This won't work on
  > the 64-bit target.  I think we should restore from the
  > PIC_OFFSET_TABLE_SAVE_RTX.  However, we need to wait for it to be
  > initialized.
Right.
jeff

Re: C++ Issue on GCC 3.0 branch

[John David Anglin]

>   In message < 200104250323.XAA05283@hiauly1.hia.nrc.ca >you write:
>   > 2001-01-04  John David Anglin  <dave@hiauly1.hia.nrc.ca>
>   > 
>   > 	* pa.c (hppa_init_pic_save): Update last_parm_insn after emitting
>   > 	pic save insn.
> This is fine for the mainline sources as well as the branch.

I have installed it on the branch.  The code on the main is different.
Thus, I don't know if the same problem exists there or not.  The code
on the main looks strange to me.  One change that looks certainly
correct is to set RTX_UNCHANGING_P in PIC_OFFSET_TABLE_SAVE_RTX.

> Thanks for tracking this down!
> 
> If you want another challenge -- the rethrow1.C test from the g++ testsuite is
> getting into an infinite loop.  A 2.95.x based compiler does the right thing.
> 
> I've started poking at this, but I don't have a real clear understanding of
> the C++ language or its EH semantics.  About the only tidbit I've got that
> might be helpful is that we might be missing a call to cp_pop_exception.

I have been looking at some of the g++ failures.  I have some revisions
to the setjmp/longjmp stuff in pa.md.  However, I noticed last night
that some code generated by builtin_setjmp was missing.  It appears that
more than just labels were disappearing.  Essentially, builtin_setjmp
was dropping into the receiver code on the intial setup.

I have updated my test source so that it now includes your disappearing
label patch.  Hopefully, this will fix some of the problems.  I visually
looked at the assembler code in __sjthrow and it now looks ok.  Tests
are running..

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: C++ Issue on GCC 3.0 branch

[John David Anglin]

Forwarded message:
From dave Sat Apr 28 13:36:47 EDT 2001
Subject: Re: C++ Issue on GCC 3.0 branch
To: law@redhat.com
Date: Sat, 28 Apr 2001 13:36:47 -0400 (EDT)
From: "John David Anglin" <dave@hiauly1>
In-Reply-To: < 6087.988477036@slagheap.cygnus.com > from "law@redhat.com" at Apr 28, 2001 09:57:16 am
X-Mailer: ELM [version 2.4 PL25]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 3844      

>   In message < 200104272214.SAA06753@hiauly1.hia.nrc.ca >you write:
>   > I think we need to define builtin_setjmp_receiver to restore r19.  The
>   > default exception method I believe is exceptions via longjmp, so we need
>   > this.  However, I have no idea whether or not this will fix the problem
>   > with rethrow1.C.
> Yes, we probably need to restore %r19, but I'm 99.9 certain that's not the
> problem with the rethrow test since they fail with static libraries.
> 
> 
>   > I also noticed a while back that exception_receiver uses a stack offset
>   > of -32 to restore the pic offset table register.  This won't work on
>   > the 64-bit target.  I think we should restore from the
>   > PIC_OFFSET_TABLE_SAVE_RTX.  However, we need to wait for it to be
>   > initialized.

My test run with this revision is nearly complete.  The good news is
that the gcc results with and without "-fPIC" are now identical (39
FAILS under hppa1.1-hp-hpux10.20).

The bad news is that there have been a few g++ regressions (total of
19 FAILS in g++ testsuite with -fPIC).  I started looking at one of
them (cxa_vec.C) this morning.  I am afraid that there are still problems
with respect to r19.  In this particular case, I can see that the save
of r19 after various longjmp calls is being deleted in the jump pass.
The program has a segmentation call in the stub to call __start_cp_handler.
This is the calling code:

0x7ae94b20 <__cxa_vec_ctor+504>:        bl 0x7ae9489c <__sjthrow>,rp
0x7ae94b24 <__cxa_vec_ctor+508>:        stws r21,4(sr0,r20)
0x7ae94b28 <__cxa_vec_ctor+512>:        bl 0x7ae948d4 <__start_cp_handler>,rp
0x7ae94b2c <__cxa_vec_ctor+516>:        nop
0x7ae94b30 <__cxa_vec_ctor+520>:        ldw -f8(sr0,sp),r19

As you can see, r19 isn't being restored after the call to __sjthrow.
The program dies here:

(gdb) run
Program received signal SIGSEGV, Segmentation fault0x7ae948d8 in __start_cp_handler ()
    at ../../../../libstdc++-v3/libsupc++/vec.cc:130
(gdb) disass
0x7ae948d4 <__start_cp_handler>:        addil 9000,r19
0x7ae948d8 <__start_cp_handler+4>:      ldw -62c(sr0,r1),r21
(gdb) bt
#0  0x7ae948d8 in __start_cp_handler ()
    at ../../../../libstdc++-v3/libsupc++/vec.cc:130
#1  0x7ae94b30 in __cxa_vec_ctor (array_address=0x40004874, element_count=5,
    element_size=1, constructor=0x4000148a <DINFINITY+242>,
    destructor=0x40001482 <DINFINITY+234>)
    at ../../../../libstdc++-v3/libsupc++/vec.cc:149
nfo reg r1 r19
r1 4000a000
r19 40001000

Another slightly strange thing is that the longjmp calls are actual calls
to the library longjmp function.  On the otherhand, we are using the
builtin version for sjlj exceptions.  I wonder if it is a good idea to
be mixing the two.

I have looked at the placement of the pic offset table register save
in functions both with and without parameters.  This seems ok.  The above
problem seems to be a somewhat different problem although it still
involves the management of r19.  Should I install the current patch
or wait until there is a solution to the above issue?

2001-04-27  John David Anglin  <dave@hiauly1.hia.nrc.ca>

        * pa.c (hppa_init_pic_save): Update last_parm_insn after emitting
        pic save insn.

--- pa.c.orig	Tue Apr 17 14:36:50 2001
+++ pa.c	Fri Apr 27 14:11:02 2001
@@ -3359,7 +3359,8 @@
 
   /* Emit the insn at the beginning of the function after the prologue.  */
   push_topmost_sequence ();
-  emit_insn_after (insn, last_parm_insn ? last_parm_insn : get_insns ());
+  last_parm_insn =
+    emit_insn_after (insn, last_parm_insn ? last_parm_insn : get_insns ());
   pop_topmost_sequence ();
 }
 
It definitely is a major step forward even if it isn't the complete
solution.  

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)


-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)