[PATCH v2 0/9] Cleanup gdb.cp tests when running with clang

[PATCH v2 0/9] Cleanup gdb.cp tests when running with clang

[Bruno Larsen]

Following my previous series, where I tried to reduce the amount of
failures when running gdb.base tests using clang, I moved to reducing
errors in gdb.cp.

Actual GDB issues are being addressed in separate patches, and this
series is confined to just changing tests to either work or
XFAIL/disable them, to make it simpler to keep track of issues.

Changelog for v2:
* Pushed 2 patches that were approved by Andrew
* Added language test for all test_compiler calls
* Added some logic to new compilation flags
* Addressed all patch-specific comments from Andrew

Bruno Larsen (9):
  gdb/testsuite: ignore Non-C-typedefs for gdb.cp/class2.exp
  gdb/testsuite: enable running gdb.cp/classes.exp with clang
  gdb/testsuite: account for clang's nested destructor calls on
    gdb.cp/mb-ctor.exp
  gdb/testsuite: add XFAIL to gdb.cp/derivation.exp when using Clang
  gdb/testsuite: allow for Clang style destructors on
    gdb.cp/m-static.exp
  gdb/testsuite: skip gdb.cp/anon-struct.exp when using Clang
  gdb/testsuite: disable some tests of gdb.cp/typeid.exp when using
    Clang
  gdb/testsuite: remove XFAIL on gdb.cp/temargs.exp
  gdb/testsuite: disable gdb.cp/call-method-register.exp when not using
    gcc

 gdb/testsuite/gdb.cp/anon-struct.exp          | 10 ++++++
 gdb/testsuite/gdb.cp/call-method-register.exp |  5 +++
 gdb/testsuite/gdb.cp/class2.exp               |  9 ++++-
 gdb/testsuite/gdb.cp/classes.exp              | 36 ++++++++++++++++++-
 gdb/testsuite/gdb.cp/derivation.exp           |  4 +++
 gdb/testsuite/gdb.cp/m-static.exp             | 11 +++---
 gdb/testsuite/gdb.cp/mb-ctor.exp              | 18 ++++++++++
 gdb/testsuite/gdb.cp/temargs.exp              |  6 ++--
 gdb/testsuite/gdb.cp/typeid.exp               | 10 +++++-
 9 files changed, 99 insertions(+), 10 deletions(-)

-- 
2.37.3

[PATCH v2 1/9] gdb/testsuite: ignore Non-C-typedefs for gdb.cp/class2.exp

[Bruno Larsen]

When attempting to test gdb.cp/class2.exp using Clang, it fails to
prepare with the following error:

Executing on host: clang++    -fdiagnostics-color=never -Wno-unknown-warning-option  -c -g -o /home/blarsen/Documents/fsf_build/gdb/testsuite/outputs/gdb.cp/class2/class20.o /home/blarsen/Documents/fsf_build/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.cp/class2.cc    (timeout = 300)
builtin_spawn -ignore SIGHUP clang++ -fdiagnostics-color=never -Wno-unknown-warning-option -c -g -o /home/blarsen/Documents/fsf_build/gdb/testsuite/outputs/gdb.cp/class2/class20.o /home/blarsen/Documents/fsf_build/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.cp/class2.cc
/home/blarsen/Documents/fsf_build/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.cp/class2.cc:53:14: warning: anonymous non-C-compatible type given name for linkage purposes by typedef declaration; add a tag name here [-Wnon-c-typedef-for-linkage]
typedef class {
             ^
              Dbase
/home/blarsen/Documents/fsf_build/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.cp/class2.cc:54:2: note: type is not C-compatible due to this member declaration
 public:
 ^~~~~~~
/home/blarsen/Documents/fsf_build/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.cp/class2.cc:58:3: note: type is given name 'Dbase' for linkage purposes by this typedef declaration
} Dbase;
  ^
1 warning generated.
gdb compile failed, /home/blarsen/Documents/fsf_build/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.cp/class2.cc:53:14: warning: anonymous non-C-compatible type given name for linkage purposes by typedef declaration; add a tag name here [-Wnon-c-typedef-for-linkage]
typedef class {
             ^
              Dbase
/home/blarsen/Documents/fsf_build/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.cp/class2.cc:54:2: note: type is not C-compatible due to this member declaration
 public:
 ^~~~~~~
/home/blarsen/Documents/fsf_build/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.cp/class2.cc:58:3: note: type is given name 'Dbase' for linkage purposes by this typedef declaration
} Dbase;
  ^
1 warning generated.
UNTESTED: gdb.cp/class2.exp: failed to prepare

This can be silenced by adding -Wno-non-c-typedef-for-linkage for Clang
11 or later.  The test shows no failures with this change.
---
 gdb/testsuite/gdb.cp/class2.exp | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/gdb/testsuite/gdb.cp/class2.exp b/gdb/testsuite/gdb.cp/class2.exp
index 32f9dfc18a5..cc192b6de64 100644
--- a/gdb/testsuite/gdb.cp/class2.exp
+++ b/gdb/testsuite/gdb.cp/class2.exp
@@ -18,7 +18,14 @@ if { [skip_cplus_tests] } { return }
 
 standard_testfile .cc
 
-if {[prepare_for_testing "failed to prepare" $testfile $srcfile {debug c++}]} {
+set flags [list debug c++]
+# When using recent Clangs, this test fails to compile without this warning
+# being disabled.  However, older Clangs fail to recognize the flag.
+if { [gcc_major_version "clang-*" "c++"] > 10 } {
+    lappend flags additional_flags=-Wno-non-c-typedef-for-linkage
+}
+
+if {[prepare_for_testing "failed to prepare" $testfile $srcfile $flags]} {
     return -1
 }
 
-- 
2.37.3

[PATCH v2 2/9] gdb/testsuite: enable running gdb.cp/classes.exp with clang

[Bruno Larsen]

When attempting to run the gdb.cp/classes.exp test using Clang++, the
test fails to prepare with -Wnon-c-typedef-for-linkage like the
previously fixed gdb.cp/class2.exp. Upon fixing this, the test shows 5
unexpected failures. One such failures is:

ptype/r class class_with_public_typedef
type = class class_with_public_typedef {
  private:
    int a;
  public:
    class_with_public_typedef::INT b;

  private:
    typedef int INT;
}
(gdb) FAIL: gdb.cp/classes.exp: ptype class class_with_public_typedef // wrong access specifier for typedef: private

While g++ provided the following output:

ptype/r class class_with_public_typedef
type = class class_with_public_typedef {
  private:
    int a;
  public:
    class_with_public_typedef::INT b;

    typedef int INT;
}
(gdb) PASS: gdb.cp/classes.exp: ptype class class_with_public_typedef

This error happens because Clang does not add DW_AT_accessibility to
typedefs inside classes, and without this information GDB defaults to
assuming the typedef is private.  Since there is nothing that GDB can do
about this, these tests have been set as xfails, and Clang bug 57608 has
been filed.

Bug: https://github.com/llvm/llvm-project/issues/57608
---
 gdb/testsuite/gdb.cp/classes.exp | 36 +++++++++++++++++++++++++++++++-
 1 file changed, 35 insertions(+), 1 deletion(-)

diff --git a/gdb/testsuite/gdb.cp/classes.exp b/gdb/testsuite/gdb.cp/classes.exp
index 7b8b315ac1f..9a947754bb6 100644
--- a/gdb/testsuite/gdb.cp/classes.exp
+++ b/gdb/testsuite/gdb.cp/classes.exp
@@ -24,7 +24,16 @@ load_lib "cp-support.exp"
 
 standard_testfile .cc
 
-if {[prepare_for_testing "failed to prepare" $testfile $srcfile {debug c++}]} {
+set flags [list debug c++]
+set clang_used false
+if { [test_compiler_info "clang-*" "c++"] } {
+    set clang_used true
+    if { [gcc_major_version "clang-*" "c++"] >= 11} {
+	lappend flags additional_flags=-Wno-non-c-typedef-for-linkage
+    }
+}
+
+if {[prepare_for_testing "failed to prepare" $testfile $srcfile $flags]} {
     return -1
 }
 
@@ -319,6 +328,12 @@ proc test_ptype_class_objects {} {
 
     # Classes with typedefs of different access.
 
+    # Clang does not add access information for typedefs in classes.
+    # More information on: https://github.com/llvm/llvm-project/issues/57608
+    if {$::clang_used} {
+	setup_xfail "clang 57608" *-*-*
+    }
+
     cp_test_ptype_class \
 	"class class_with_typedefs" "" "class" "class_with_typedefs" \
 	{
@@ -339,6 +354,10 @@ proc test_ptype_class_objects {} {
 	    { typedef private "typedef int private_int;" }
 	}
 
+    if {$::clang_used} {
+	setup_xfail "clang 57608" *-*-*
+    }
+
     cp_test_ptype_class \
 	"class class_with_public_typedef" "" "class" \
 	"class_with_public_typedef" {
@@ -346,6 +365,11 @@ proc test_ptype_class_objects {} {
 	    { field public "class_with_public_typedef::INT b;" }
 	    { typedef public "typedef int INT;" }
 	}
+
+    if {$::clang_used} {
+	setup_xfail "clang 57608" *-*-*
+    }
+
     cp_test_ptype_class \
 	"class class_with_protected_typedef" "" "class" \
 	"class_with_protected_typedef" {
@@ -353,6 +377,11 @@ proc test_ptype_class_objects {} {
 	    { field protected "class_with_protected_typedef::INT b;" }
 	    { typedef protected "typedef int INT;" }
 	}
+
+    if {$::clang_used} {
+	setup_xfail "clang 57608" *-*-*
+    }
+
     cp_test_ptype_class \
 	"struct struct_with_protected_typedef" "" "struct" \
 	"struct_with_protected_typedef" {
@@ -360,6 +389,11 @@ proc test_ptype_class_objects {} {
 	    { field protected "struct_with_protected_typedef::INT b;" }
 	    { typedef protected "typedef int INT;" }
 	}
+
+    if {$::clang_used} {
+	setup_xfail "clang 57608" *-*-*
+    }
+
     cp_test_ptype_class \
 	"struct struct_with_private_typedef" "" "struct" \
 	"struct_with_private_typedef" {
-- 
2.37.3

[PATCH v2 3/9] gdb/testsuite: account for clang's nested destructor calls on gdb.cp/mb-ctor.exp

[Bruno Larsen]

When compiling virtual classes's destructors, two versions are compiled,
one with a single parameter (this) and the other with 2 parameters (this
and vtt).

GCC's compilation makes it so either the version with 1
parameter or the one with 2 parameters is called, depending on whether
the destructor is being called by the class itself or by an inherited
class. On the test gdb.cp/mb-ctor.exp, this means that the breakpoint
set at the destructor will be hit 4 times.

Clang, on the other hand, makes the single-parameter version call the 2
parameter version, probably in an attempt to reduce the size of the
resulting executable. This means that the gdb.cp/mb-ctor.exp will hit 6
breakpoints before finishing, and is the reason why this test was
failing. To make this test stop failing, a compiler check is added and
another "continue" instruction is issued to account for this difference.
---
 gdb/testsuite/gdb.cp/mb-ctor.exp | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)

diff --git a/gdb/testsuite/gdb.cp/mb-ctor.exp b/gdb/testsuite/gdb.cp/mb-ctor.exp
index 5a3c0a4a90f..05dbf507e90 100644
--- a/gdb/testsuite/gdb.cp/mb-ctor.exp
+++ b/gdb/testsuite/gdb.cp/mb-ctor.exp
@@ -25,6 +25,12 @@ if {[prepare_for_testing "failed to prepare" $testfile $srcfile {debug c++}]} {
     return -1
 }
 
+if {[test_compiler_info {clang-*-*} c++]} {
+    set using_clang true
+} else {
+    set using_clang false
+}
+
 if ![runto_main] then {
     perror "couldn't run to breakpoint"
     return
@@ -71,6 +77,13 @@ gdb_continue_to_breakpoint "set breakpoint here, second dynamic time"\
 
 gdb_test "continue" ".*Breakpoint.*~Derived.*" "Run to dynamic destructor v1"
 
+# Clang makes Derived::~Derived(this) call Derived::~Derives(this, vtt)
+# whereas gcc puts all the logic necessary on both functions.
+if {$using_clang} {
+    gdb_test "continue" ".*Breakpoint.*~Derived.*"\
+	"clang's nested dynamic destructor call"
+}
+
 gdb_test "continue" ".*Breakpoint.*~Derived.*" "Run to dynamic destructor v2"
 
 gdb_test "continue" \
@@ -81,6 +94,11 @@ gdb_test "continue" \
     ".*Breakpoint.*~Derived.*" \
     "run to breakpoint 3 v2"
 
+if {$using_clang} {
+    gdb_test "continue" ".*Breakpoint.*~Derived.*"\
+	"clang's nested destructor call"
+}
+
 gdb_test "continue" \
     ".*exited normally.*" \
     "run to exit"
-- 
2.37.3

[PATCH v2 4/9] gdb/testsuite: add XFAIL to gdb.cp/derivation.exp when using Clang

[Bruno Larsen]

When running gdb.cp/derivation.exp using Clang, we get an unexpected
failure when printing the type of a class with an internal typedef. This
happens because Clang doesn't add accessibility information for typedefs
inside classes (see https://github.com/llvm/llvm-project/issues/57608
for more info). To help with Clang testing, an XFAIL was added to this
test.
---
 gdb/testsuite/gdb.cp/derivation.exp | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/gdb/testsuite/gdb.cp/derivation.exp b/gdb/testsuite/gdb.cp/derivation.exp
index c95fef004b5..f49ab208ac9 100644
--- a/gdb/testsuite/gdb.cp/derivation.exp
+++ b/gdb/testsuite/gdb.cp/derivation.exp
@@ -77,6 +77,10 @@ gdb_test "up" ".*main.*" "up from marker1"
 
 gdb_test "print a_instance" "\\$\[0-9\]+ = \{a = 1, aa = 2\}" "print value of a_instance"
 
+# Clang does not add accessibility information for typedefs inside classes.
+if {[test_compiler_info {clang*} c++]} {
+    setup_xfail "clang 57608" *-*-*
+}
 cp_test_ptype_class \
     "a_instance" "" "class" "A" \
     {
-- 
2.37.3

[PATCH v2 5/9] gdb/testsuite: allow for Clang style destructors on gdb.cp/m-static.exp

[Bruno Larsen]

when running gdb.cp/m-static.exp using Clang, we get the following
failures:

    print test1.~gnu_obj_1^M
    $6 = {void (gnu_obj_1 * const)} 0x555555555470 <gnu_obj_1::~gnu_obj_1()>^M
    (gdb) FAIL: gdb.cp/m-static.exp: simple object instance, print destructor
    ptype test1.~gnu_obj_1^M
    type = void (gnu_obj_1 * const)^M
    (gdb) FAIL: gdb.cp/m-static.exp: simple object instance, ptype destructor
    print test1.'~gnu_obj_1'^M
    $7 = {void (gnu_obj_1 * const)} 0x555555555470 <gnu_obj_1::~gnu_obj_1()>^M
    (gdb) FAIL: gdb.cp/m-static.exp: simple object instance, print quoted destructor

This is because the test is expecting an extra integer parameter on the
destructor. Looking at the debuginfo, it seems that there is nothing
actually wrong with this output, so these tests were changed to test
multiple possible regexps.
---
 gdb/testsuite/gdb.cp/m-static.exp | 11 ++++++-----
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/gdb/testsuite/gdb.cp/m-static.exp b/gdb/testsuite/gdb.cp/m-static.exp
index 979de23a44f..1239dbc0f1d 100644
--- a/gdb/testsuite/gdb.cp/m-static.exp
+++ b/gdb/testsuite/gdb.cp/m-static.exp
@@ -102,15 +102,16 @@ if { [is_aarch32_target] } {
 	{type = void \(single_constructor \* const\)} \
 	"simple object class, ptype constructor"
 
-    gdb_test "print test1.~gnu_obj_1" \
-	{ = {void \(gnu_obj_1 \* const, int\)} 0x[0-9a-f]+ <gnu_obj_1::~gnu_obj_1\(\)>} \
+    gdb_test "print test1.~gnu_obj_1"\
+	{ = {void \(gnu_obj_1 \* const(?:, int)?\)} 0x[0-9a-f]+ <gnu_obj_1::~gnu_obj_1\(\)>}\
 	"simple object instance, print destructor"
-    gdb_test "ptype test1.~gnu_obj_1" \
-	{type = void \(gnu_obj_1 \* const, int\)} \
+
+    gdb_test "ptype test1.~gnu_obj_1"\
+	{type = void \(gnu_obj_1 \* const(?:, int)?\)}\
 	"simple object instance, ptype destructor"
 
     gdb_test "print test1.'~gnu_obj_1'" \
-	{ = {void \(gnu_obj_1 \*( const)?, int\)} 0x[0-9a-f]+ <gnu_obj_1::~gnu_obj_1\(\)>} \
+	{ = {void \(gnu_obj_1 \*( const)?(?:, int)?\)} 0x[0-9a-f]+ <gnu_obj_1::~gnu_obj_1\(\)>} \
 	"simple object instance, print quoted destructor"
 
     gdb_test "ptype gnu_obj_1::'~gnu_obj_1'" \
-- 
2.37.3

[PATCH v2 6/9] gdb/testsuite: skip gdb.cp/anon-struct.exp when using Clang

[Bruno Larsen]

When Clang compiles anonymous structures, it does not add linkage names in
their dwarf representations. This is compounded by Clang not adding linkage
names to subprograms of those anonymous structs (for instance, the
constructor). With these 2 things together, GDB is unable to refer to
any of them, so there is no way to pass any of the tests of
gdb.cp/anon-struct.exp

Since this isn't a bug on Clang or GDB according to the DWARF
specifications as DW_AT_name is optional for all DIEs, the test was marked
as untested.

Since I was already touching the file, I also added a comment at the top
of the file explaining what it is testing for.
---
 gdb/testsuite/gdb.cp/anon-struct.exp | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/gdb/testsuite/gdb.cp/anon-struct.exp b/gdb/testsuite/gdb.cp/anon-struct.exp
index 2c709ab9ecc..2113957fed0 100644
--- a/gdb/testsuite/gdb.cp/anon-struct.exp
+++ b/gdb/testsuite/gdb.cp/anon-struct.exp
@@ -14,12 +14,22 @@
 # You should have received a copy of the GNU General Public License
 # along with this program.  If not, see <http://www.gnu.org/licenses/>.
 
+# This test is used to verify GDB's ability to refer to linkage names
+# for types and functions within anonymous structures.
+
 standard_testfile .cc
 
 if { [prepare_for_testing "failed to prepare" ${testfile} ${srcfile} {debug c++}] } {
      return -1
 }
 
+# Clang doesn't add any names for functions within anonymous structures,
+# so there is no way to try and refer to them inside GDB.
+if {[test_compiler_info clang-*-* c++]} {
+    untested "clang does not use linkage name in this case"
+    return
+}
+
 if { [is_aarch32_target] } {
     gdb_test "ptype t::t" "type = struct t {\r\n    C m;\r\n} \\*\\(t \\* const\\)" \
 	"print type of t::t"
-- 
2.37.3

[PATCH v2 7/9] gdb/testsuite: disable some tests of gdb.cp/typeid.exp when using Clang

[Bruno Larsen]

Since Clang chooses to not add any debug information for base types,
expecting it to be included with libraries' informations, gdb.cp/typeid.exp
will always fail if the program hasn't started.  This commit fixes that by
making it so when using Clang, the base type variables aren't tested.
---
 gdb/testsuite/gdb.cp/typeid.exp | 10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/gdb/testsuite/gdb.cp/typeid.exp b/gdb/testsuite/gdb.cp/typeid.exp
index 6411217191a..fd8e96276c5 100644
--- a/gdb/testsuite/gdb.cp/typeid.exp
+++ b/gdb/testsuite/gdb.cp/typeid.exp
@@ -29,8 +29,16 @@ proc do_typeid_tests {started} {
     # We might see the standard type or gdb's internal type.
     set type_re "(std::type_info|gdb_gnu_v3_type_info)"
 
+    set var {ca b}
+    if {$started || ![test_compiler_info clang-*-* c++]} {
+	# Clang doesn't place type information for the base types in
+	# the executable, and relies on this being linked in from the
+	# standard library.  As a result, type information for these
+	# variables is only available once the inferior is started.
+	lappend var i cp ccp
+    }
 
-    foreach simple_var {i cp ccp ca b} {
+    foreach simple_var $var {
 	gdb_test "print &typeid($simple_var)" \
 	    " = \\($type_re \\*\\) $hex.*"
 
-- 
2.37.3

[PATCH v2 8/9] gdb/testsuite: remove XFAIL on gdb.cp/temargs.exp

[Bruno Larsen]

gdb.cp/temargs.exp last 2 tests always setup an XFAILs, despite checking
for old gcc versions.  However, Clang does not fail in this test,
turning into XPASSes and slighty annoying when comparing between
compilers.  To change this, make the xfails only happen if we using gcc.
---
 gdb/testsuite/gdb.cp/temargs.exp | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/gdb/testsuite/gdb.cp/temargs.exp b/gdb/testsuite/gdb.cp/temargs.exp
index 05fd902bb83..2a927d8651b 100644
--- a/gdb/testsuite/gdb.cp/temargs.exp
+++ b/gdb/testsuite/gdb.cp/temargs.exp
@@ -46,6 +46,8 @@ if {[test_compiler_info {gcc-[0-3]-*}]
     set have_pr_45024_fixed 0
 }
 
+set using_gcc [test_compiler_info gcc-*-*]
+
 set line [gdb_get_line_number "Breakpoint 1" $srcfile]
 gdb_test "break $srcfile:$line" "Breakpoint 2.*" \
     "set first breakpoint for temargs"
@@ -190,10 +192,10 @@ gdb_test "print F" "&S::somefunc" "test value of F in k2_m"
 gdb_continue_to_breakpoint "continue to sixth breakpoint for temargs"
 
 if $have_older_template_gcc { setup_xfail "*-*-*"
-} else { setup_xfail gcc/49546 "*-*-*" }
+} elseif $using_gcc { setup_xfail gcc/49546 "*-*-*" }
 gdb_test "ptype F" {type = void \(\*\)\(int\)} "test type of F in k3_m"
 
 if $have_older_template_gcc { setup_xfail "*-*-*"
-} else { setup_xfail gcc/49546 "*-*-*" }
+} elseif $using_gcc { setup_xfail gcc/49546 "*-*-*" }
 gdb_test "print F" { = \(void \(\*\)\(int\)\) 0x[0-9a-f]+ <S3::m\(int\)>} \
 	 "test value of F in k3_m"
-- 
2.37.3

Re: [PATCH v2 8/9] gdb/testsuite: remove XFAIL on gdb.cp/temargs.exp

[Tom Tromey]

>>>>> "Bruno" == Bruno Larsen via Gdb-patches <gdb-patches@sourceware.org> writes:

Bruno> gdb.cp/temargs.exp last 2 tests always setup an XFAILs, despite checking
Bruno> for old gcc versions.  However, Clang does not fail in this test,
Bruno> turning into XPASSes and slighty annoying when comparing between
Bruno> compilers.  To change this, make the xfails only happen if we using gcc.

Bruno>  if $have_older_template_gcc { setup_xfail "*-*-*"
Bruno> -} else { setup_xfail gcc/49546 "*-*-*" }
Bruno> +} elseif $using_gcc { setup_xfail gcc/49546 "*-*-*" }
...
Bruno> +} elseif $using_gcc { setup_xfail gcc/49546 "*-*-*" }

IMO it's better Tcl style to brace the condition, like "elseif {$using_gcc}"

This is ok with this tweak.

Tom

[PATCH v2 9/9] gdb/testsuite: disable gdb.cp/call-method-register.exp when not using gcc

[Bruno Larsen]

The test gdb.cp/call-method-register.exp assumes that the class will be
placed on a register. However, this keyword has been deprecated since
C++11, and Clang, for instance, does not feel the need to follow it.
Since this test is not usable without this working, this commit marks
this test as untested.
---
 gdb/testsuite/gdb.cp/call-method-register.exp | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/gdb/testsuite/gdb.cp/call-method-register.exp b/gdb/testsuite/gdb.cp/call-method-register.exp
index a1e6498d66c..a98b11e4c11 100644
--- a/gdb/testsuite/gdb.cp/call-method-register.exp
+++ b/gdb/testsuite/gdb.cp/call-method-register.exp
@@ -26,6 +26,11 @@ if {[prepare_for_testing "failed to prepare" $testfile $srcfile {debug c++}]} {
     return -1
 }
 
+if {![test_compiler_info gcc-*-* c++]} {
+    untested "test relies on a gcc extension"
+    return
+}
+
 proc test_call_register_class {} {
     global gdb_prompt
 
-- 
2.37.3

Re: [PATCH v2 0/9] Cleanup gdb.cp tests when running with clang

[Tom Tromey]

>>>>> "Bruno" == Bruno Larsen via Gdb-patches <gdb-patches@sourceware.org> writes:

Bruno> Following my previous series, where I tried to reduce the amount of
Bruno> failures when running gdb.base tests using clang, I moved to reducing
Bruno> errors in gdb.cp.

Bruno> Actual GDB issues are being addressed in separate patches, and this
Bruno> series is confined to just changing tests to either work or
Bruno> XFAIL/disable them, to make it simpler to keep track of issues.

Thank you.  I read through this and had one minor comment.
The rest looks good to me.

Some of the xfail'd tests seem like "bad" tests in a way -- they are
testing the compiler as much as gdb.  Ideally I guess we would have used
the DWARF assembler for these, but it probably didn't exist back then
(and is more of a pain anyhow).

Also, call-method-register.exp in particular seems fragile at best.

thanks,
Tom

Re: [PATCH v2 0/9] Cleanup gdb.cp tests when running with clang

[Bruno Larsen]

On 10/11/2022 19:24, Tom Tromey wrote:
>>>>>> "Bruno" == Bruno Larsen via Gdb-patches <gdb-patches@sourceware.org> writes:
> Bruno> Following my previous series, where I tried to reduce the amount of
> Bruno> failures when running gdb.base tests using clang, I moved to reducing
> Bruno> errors in gdb.cp.
>
> Bruno> Actual GDB issues are being addressed in separate patches, and this
> Bruno> series is confined to just changing tests to either work or
> Bruno> XFAIL/disable them, to make it simpler to keep track of issues.
>
> Thank you.  I read through this and had one minor comment.
> The rest looks good to me.
Thank you! I'll apply your suggestion and push the whole series
>
> Some of the xfail'd tests seem like "bad" tests in a way -- they are
> testing the compiler as much as gdb.  Ideally I guess we would have used
> the DWARF assembler for these, but it probably didn't exist back then
> (and is more of a pain anyhow).
I agree, but since my plan was fixing stuff with clang and dwarf 
assembler requires gcc, it didn't feel like the best use of my time.
>
> Also, call-method-register.exp in particular seems fragile at best.
Yeah, me and Andrew thought the same thing, and andrew even submitted a 
port of it as a reply to my previous series. I encouraged him to submit 
as a standalone patch, but I don't think he did. Here's his original 
submission: 
https://sourceware.org/pipermail/gdb-patches/2022-October/193208.html

-- 
Cheers,
Bruno

>
> thanks,
> Tom
>