Re: Problems with dejagnu and c++ tests...

[mec dot gnu at mindspring dot com (Michael Elizabeth Chastain)]

ac> (aren't we trying to delete gcc_compiled? :-)

Yes.  When the last reference to gcc_compiled goes away,
then we can remove the code that initializes it.

ac> Something based on CPP would be more robust, and avoid assumptions such 
ac> as the target has output and can correctly compile / execute code. 
ac> Consider what happens when trying to bring up a new GDB+GCC+....

We're running the test suite.  If gdb_compile does not work,
or the resulting executables cannot be run, then the test script
cannot run its tests anyways.

Just look at the code in gdb.cp/ambiguous.exp or anywhere else that
calls get_compiler_info:

  if [get_compiler_info ${binfile} "c++"] {
      return -1;
  }
  ...
  if { [gdb_compile "${srcdir}/${subdir}/${srcfile}" "${binfile}" executable {debug c++}] != "" } {
    gdb_suppress_entire_file "Testcase compile failed, so all tests in this file will automatically fail."
  }
  ...
  gdb_exit
  gdb_start
  gdb_reinitialize_dir $srcdir/$subdir
  gdb_load ${binfile}

get_compiler_info is always followed by gdb_compile.
get_compiler_info should use the same compiler as gdb_compile.

Also, read the comments at the beginning of get_compiler_info.
'Something based on CPP' has a lot of problems with any implementation
that I can think of.

gdb 6.0 had four different implementations:

  most targets with c
  most targets with c++
  hpux|irix with c
  hpux|irix with c++

"most targets with c" and "most targets with c++" depended on
a non-standard gcc extension, which is why the hpux|irix targets
needed special cases.

hpux|irix with c++ *did not work*.  It used about 100 lines of special
code but did not even use the same compiler as gdb_compile, so it
invoked a different compiler and set the variables wrong.
That's what drove me to rewrite get_compiler_info in the first place.

Michael C