g++ compiled executables failure in c++ object handling code; && bug

[John Garner]

We are having problems with our g++ setup and successfully running programs
created with it.

gcc compiles and runs programs fine.

g++ will compile programs correctly, but when they are run the programs fail
to exit properly and core dump. A standard no-option command line is used.

The example programs we have tried became more and more simple, the effect
still occurs with:

int main()
{
  return 0;
}


We have recently installed g++ version 2.95.2. Previous to this we had an
existing 2.8.1 setup which worked correctly. The 2.8.1 install was removed
using the pkgrm package remove command properly and this completed
successfully.

Any programs core dump on exit while tidying up, not while executing user
code whether they exit with exit() or return. Also attempting to do a simple
"cout << 123 << endl;" or hello-world equivalent with cout will core dump.
Using printf does work fine though.

Using "ddd" to trace it and various incredibly simple test source code
programs, it seems related to the standard libraries. The point at which
they crash appears to be inside the internal function "__do_global_dtors_aux
(). This information was gleaned from a "ddd" backtrace, the other functions
before it were exit(), _exithandle(), an unknown function (shown as "??")
and then _fini().

We have checked and it is using libstdc++.so.2.10.0 with the newer version
of the compiler although the libstdc++ was not explicitly removed before
installing the new version. We then uninstalled the new g++, uninstalled the
libstdc++ in case, and reinstalled the 2.95.2 g++ again. This did nothing to
change the problem so we have currently switched back to 2.8.1 again which
is working with the same stdc++ library.

The Operating System is Solaris 2.7, an edited uname -a gives:
SunOS <our hostname> 5.7 Generic_106541-08 sun4u sparc SUNW,Ultra-2

The $LD_LIBRARY_PATH is in the order /usr/lib:/usr/local/lib: .... etc

Removing the 2.95.2 version of the compiler and replacing with the 2.8.1
version causes it to work again.

Separately, there is another bug I have seen in the new g++ v2.95.2, the
compiler generated the following output:

-----------------------
bash-2.02$ g++ --version
2.95.2

g++ -I/opt/CommerceLink/GUPI -I/opt/CommerceLink/server/GlobalUtils -D__EXTE
NSIONS__ -Wall -DDEBUG -g -ggdb -c filter.cc
filter.cc: In method `filter::filter(const filter &)':
filter.cc:107: Internal compiler error in `find_function_data', at
function.c:542
Please submit a full bug report.
See <URL: http://www.gnu.org/software/gcc/faq.html#bugreport > for
instructions.

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

I can see a reason it might not like the source file: there is something of
the following form, I am afraid I cannot currently reproduce the error to
generate the preprocessed output to send, as we have reverted back to 2.8.1:

class foo
{
  public:
    foo()
    ~foo();

  private:
    static const unsigned int iSize;

    struct substr
    {
	char cMember[iSize];
      int iMember[iSize];
    }
};


My guess is the problem has to do with using the iSize in the class header
to declare the size of members in the struct, when it doesn't know the value
of iSize from just the header file. The .cc file obviously has a const
unsigned int foo::iSize=10; or whatever.

It was complaining at some seemingly random line in the source code.

We were using just const unsigned int iSize=10; before, in 2.8.1 and it
worked fine although giving the warnings and not being properly Ansi C
compliant.

John Garner, Developer at CommerceNTI.