gdb tests, gcc HEAD versus gcc tree-ssa

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

How about some gcc tree-ssa testing with gdb?

Here are the gdb test suite regressions from gcc HEAD to gcc tree-ssa.
The dates are:

  gcc HEAD 2004-02-01 15:37:18 UTC
  gcc tree-ssa-20020619-branch 2004-02-05 12:45:13 UTC

I tested on native i686-pc-linux-gnu, red hat linux 8.0.
I used several versions of gdb and the gdb test suite.
The most useful results are gdb HEAD, gdb test suite HEAD.
I configured gcc with --disable-shared.
I have binutils 2.14, glibc 2.2.93-5-rh.
I have $LANG=en_US.UTF-8.
I tested with "-gdwarf-2 -g2" and "-gstabs+ -g2".

These regressions fall into two categories:

  bugs in gcc             2
  bugs in gdb test suite  3

Michael C

. GCC BUGS

  http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14048
  [tree-ssa regression] bad debug line numbers near "return" statement, c++
    gdb.cp/class2.exp: print alpha at marker return 0
    gdb.cp/class2.exp: print beta at marker return 0
    gdb.cp/class2.exp: print * aap at marker return 0
    gdb.cp/class2.exp: print * bbp at marker return 0
    gdb.cp/class2.exp: print * abp at marker return 0, s-p-o off
    gdb.cp/class2.exp: print * (B *) abp at marker return 0
      # dwarf-2 stabs+

  http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14049
  [tree-ssa regression] bad debug block info, dwarf-2, c++
    gdb.cp/local.exp: ptype Local
    gdb.cp/local.exp: ptype l
    gdb.mi/mi-var-block.exp: create local variable foo {2}
    gdb.mi/mi-var-block.exp: update all vars: cb foo changed
    gdb.mi/mi-var-block.exp: update foo: did not change
    gdb.mi/mi-var-block.exp: delete var foo {2}
    gdb.mi/mi1-var-block.exp: create local variable foo {2}
    gdb.mi/mi1-var-block.exp: update all vars: cb foo changed
    gdb.mi/mi1-var-block.exp: update foo: did not change
    gdb.mi/mi1-var-block.exp: delete var foo {2}
    gdb.mi/mi2-var-block.exp: create local variable foo {2}
    gdb.mi/mi2-var-block.exp: update all vars: cb foo changed
    gdb.mi/mi2-var-block.exp: update foo: did not change
    gdb.mi/mi2-var-block.exp: delete var foo {2}
      # dwarf-2

. GDB TEST SUITE BUGS

  . gdb.base/fileio.exp: Renaming a directory to a subdir of itself returns EINVAL
    gdb.base/fileio.exp: Renaming a nonexistant file returns ENOENT
    gdb.base/fileio.exp: Unlink a file
    gdb.base/fileio.exp: Unlinking a file in a directory w/o write access returns EACCES
    gdb.base/fileio.exp: Unlinking a nonexistant file returns ENOENT
      # stabs+

      This happened with gdb drow-cplus-branch suite drow-cplus-branch.
      fileio.exp had a bug with a lack of anchors to $gdb_prompt.  The
      bug has been fixed in suite HEAD; the bug fix needs to be imported
      to suite drow-cplus-branch.

  . gdb.base/structs.exp: value foo<n> returned; return 1 structs-tc
    gdb.base/structs.exp: value foo<n> returned; return 2 structs-tc
    gdb.base/structs.exp: value foo<n> returned; return 3 structs-tc
    gdb.base/structs.exp: value foo<n> returned; return 4 structs-tc
    gdb.base/structs.exp: value foo<n> returned; return 5 structs-tc
    gdb.base/structs.exp: value foo<n> returned; return 6 structs-tc
    gdb.base/structs.exp: value foo<n> returned; return 7 structs-tc
    gdb.base/structs.exp: value foo<n> returned; return 8 structs-tc
    gdb.base/structs.exp: value foo<n> returned; return 1 structs-ts
    gdb.base/structs.exp: value foo<n> returned; return 2 structs-ts
    gdb.base/structs.exp: value foo<n> returned; return 3 structs-ts
    gdb.base/structs.exp: value foo<n> returned; return 4 structs-ts
    gdb.base/structs.exp: value foo<n> returned; return 1 structs-ti
    gdb.base/structs.exp: value foo<n> returned; return 2 structs-ti
    gdb.base/structs.exp: value foo<n> returned; return 1 structs-tl
    gdb.base/structs.exp: value foo<n> returned; return 2 structs-tl
    gdb.base/structs.exp: value foo<n> returned; return 1 structs-tll
    gdb.base/structs.exp: value foo<n> returned; return 1 structs-tf
    gdb.base/structs.exp: value foo<n> returned; return 2 structs-tf
    gdb.base/structs.exp: value foo<n> returned; return 1 structs-td
    gdb.base/structs.exp: value foo<n> returned; return 2 structs-ts-tc
    gdb.base/structs.exp: value foo<n> returned; return 2 structs-ti-tc
    gdb.base/structs.exp: value foo<n> returned; return 2 structs-tl-tc
    gdb.base/structs.exp: value foo<n> returned; return 2 structs-tf-tc
    gdb.base/structs.exp: value foo<n> returned; return 2 structs-tc-ts
    gdb.base/structs.exp: value foo<n> returned; return 2 structs-tc-ti
    gdb.base/structs.exp: value foo<n> returned; return 2 structs-tc-tl
    gdb.base/structs.exp: value foo<n> returned; return 2 structs-td-tf
    gdb.base/structs.exp: value foo<n> returned; return 2 structs-tf-td
      # dwarf-2 stabs+

      The test program looks like this:

	struct struct1 fun1() { return foo1; }
	main () { ... L1 = fun1(); ... }

      The test script sets a breakpoint on fun1, runs to the breakpoint,
      and executes 'return foo1'.

      gdb says:

	The location at which to store the function's return value is unknown.
	If you continue, the return value that you specified will be ignored.
	Make fun1 return now? (y or n)

      The test script says 'y'.  fun1 returns.  The test script executes
      'next' to get to the next line.  The test script prints L1.

      With gcc HEAD, L1 has the same value that it did before the call to
      fun1, and the result is PASS.  With gcc tree-ssa, L1 has a random
      value, and the result is FAIL.

      Here is why.  fun1 returns a structure, so it has a hidden first
      parameter which is the address of the structure in memory.
      (This is native i686-pc-linux-gnu).  With gcc HEAD, the generated
      code for main looks like this:

	fun1(&L1);

      With gcc tree-ssa, the generated code for main looks like this:

	auto struct struct1 temp_1;
	fun1(&temp_1);
	L1 = temp1;

      So with gcc HEAD, when gdb does not store into the return value of
      fun1, the old value of L1 is left alone.  With gcc tree-ssa, when
      gdb does not store into the return value of fun1, temp_1 is left
      with an uninitialized value which is then copied into L1.

      I think that it's a bug in the test script to rely on the old
      behavior, but I'm not sure about that.

  . gdb.mi/mi-until.exp: until after while loop
    gdb.mi/mi1-until.exp: until after while loop
    gdb.mi/mi2-until.exp: until after while loop
      # dwarf-2 stabs+

      The test program contains:

	7  i = 0;
	8
	9  while (i < 2)
       10    i++;
       11
       12  x = i;

      The test script runs to line 10 and then executes 'until' with no
      argument.

      With gcc HEAD, this proceeds to line 12.  With gcc tree-ssa, this
      proceeds to line 9.

      This gdb behavior is documented under the 'until' command:

	`until' may produce somewhat counterintuitive results if the order
	of machine code does not match the order of the source lines.
	...
	This happened because, for execution efficiency, the compiler had
	generated code for the loop closure test at the end, rather than
	the start, of the loop--even though the test in a C `for'-loop is
	written before the body of the loop.

      That is what happens with gcc tree-ssa.  The test script needs
      a trivial enhancement.