Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Gary Benson <gbenson@redhat.com>
To: Tom Tromey <tom@tromey.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [OB PATCH] Build two gdb.cp testcases with -Wno-unused-comparison
Date: Tue, 16 Jun 2020 13:38:20 +0100	[thread overview]
Message-ID: <20200616123820.GA30305@blade.nx> (raw)
In-Reply-To: <87mu5qaa2b.fsf@tromey.com>

Tom Tromey wrote:
> >>>>> "Gary" == Gary Benson via Gdb-patches <gdb-patches@sourceware.org> writes:
> 
> Gary> +if { [prepare_for_testing "failed to prepare" ${testfile} ${srcfile} \
> Gary> +      {debug c++ additional_flags=-Wno-unused-comparison}] } {
> 
> Won't this cause build (and therefore test) failures if the compiler
> does not accept this option?
> 
> I wonder if there's a way to fix the warning in the C++ source file
> instead.

Yes, ideally, but by no means always.  I'm working my way through
these failures, and in many cases the "issue" the warning caught
was intended, some weird thing placed specifically to test some
functionality of GDB.  For example:

  Running /gdbtest/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.cp/ambiguous.exp ...
  gdb compile failed, /gdbtest/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.cp/ambiguous.cc:70:36:
  warning: direct base 'A1' is inaccessible due to ambiguity:
      class JVA1 -> class KV -> class A1
      class JVA1 -> class A1 [-Winaccessible-base]
  class JVA1 : public KV, public LV, public A1 {
                                     ^~~~~~~~~
  1 warning generated.

This one's obviously intentional, gdb.cp/abmigiuous.exp contains
"tests relating to ambiguous class members".  But a lot of these
cases aren't obvious, at least not to me.  Is something a mistake?
Some piece of K&R C from 1988 that was machine-converted in 1994?
Or some real thing put there to stop GCC optimizing something out?
I'm very much NOT someone to ask about code generation nuances!
If something's obvious or (ha!) documented I can fix the source;
places I've disabled warnings are where I couldn't tell what was
intended/expected.

Cheers,
Gary



      parent reply	other threads:[~2020-06-16 12:38 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-29 13:03 Gary Benson
2020-05-29 18:08 ` Tom Tromey
2020-05-29 18:31   ` Pedro Alves
2020-06-16 12:42     ` Gary Benson
2020-06-16 15:11       ` Pedro Alves
2020-06-17 17:29         ` Gary Benson
2020-06-17 19:53           ` [PATCH] W/ Clang, compile C/C++ testcases with -Wno-unknown-warning-option Pedro Alves
2020-06-18 16:18             ` Gary Benson
2020-06-24 22:26               ` Pedro Alves
2020-07-02 10:02                 ` Gary Benson
2020-06-16 12:38   ` Gary Benson [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200616123820.GA30305@blade.nx \
    --to=gbenson@redhat.com \
    --cc=gdb-patches@sourceware.org \
    --cc=tom@tromey.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox