public inbox for gdb-prs@sourceware.org
help / color / mirror / Atom feed
From: "cvs-commit at gcc dot gnu.org" <sourceware-bugzilla@sourceware.org>
To: gdb-prs@sourceware.org
Subject: [Bug build/31399] Build fails on macOS: error: cannot cast 'tui_win_info *' to 'tui_cmd_window *' via virtual base 'tui_win_info'
Date: Tue, 19 Mar 2024 14:57:35 +0000	[thread overview]
Message-ID: <bug-31399-4717-qW12rd4YdZ@http.sourceware.org/bugzilla/> (raw)
In-Reply-To: <bug-31399-4717@http.sourceware.org/bugzilla/>

https://sourceware.org/bugzilla/show_bug.cgi?id=31399

--- Comment #4 from Sourceware Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Andrew Burgess <aburgess@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=7d18eb9983b00455fd2f3100d4de2772c3f656ad

commit 7d18eb9983b00455fd2f3100d4de2772c3f656ad
Author: Andrew Burgess <aburgess@redhat.com>
Date:   Wed Mar 6 17:28:48 2024 +0000

    gdb: use static_cast in gdb::checked_static_cast

    This commit:

      commit 6fe4779ac4b1874c995345e3eabd89cb1a05fbdf
      Date:   Sat Feb 24 11:00:20 2024 +0100

          [gdb/build] Fix static cast of virtual base

    addressed an issue where GDB would not compile in production mode due
    to a use of gdb::checked_static_cast.  The problem was that we were
    asking GDB to cast from a virtual base class to a sub-class, this
    works fine when using dynamic_cast, but does not work with
    static_cast.

    The gdb::checked_static_cast actually uses dynamic_cast under the hood
    in development mode in order to ensure that the cast is valid, while
    in a production build we use static_cast as this is more efficient.

    What this meant however, was that when gdb::checked_static_cast was
    used to cast from a virtual base class, the dynamic_cast of a
    non-production build worked fine, while the production build's
    static_cast caused a build failure.

    However, the gdb::checked_static_cast function already contains some
    static_assert calls that are intended to catch any issues with invalid
    type casting, the goal of these asserts was to prevent issues like
    this: the build only failing in production mode.  Clearly the current
    asserts are not enough.

    I don't think there is a std::is_virtual_base type trait check, so
    what I propose instead is that in non-production mode we also make use
    of static_cast.  This will ensure that any errors that crop up in
    production mode should also be revealed in non-production mode, and
    should catch issues like this in the future.

    There should be no user visible changes after this commit.

    Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31399

    Co-Authored-By: Simon Marchi <simon.marchi@polymtl.ca>

-- 
You are receiving this mail because:
You are on the CC list for the bug.

      parent reply	other threads:[~2024-03-19 14:57 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-19  3:08 [Bug tui/31399] New: " spam_hole at shaw dot ca
2024-02-19 14:34 ` [Bug tui/31399] " ssbssa at sourceware dot org
2024-02-22 15:06 ` [Bug build/31399] " vries at gcc dot gnu.org
2024-02-22 16:19 ` vries at gcc dot gnu.org
2024-02-24 10:00 ` cvs-commit at gcc dot gnu.org
2024-02-24 10:01 ` vries at gcc dot gnu.org
2024-03-19 14:57 ` cvs-commit at gcc dot gnu.org [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=bug-31399-4717-qW12rd4YdZ@http.sourceware.org/bugzilla/ \
    --to=sourceware-bugzilla@sourceware.org \
    --cc=gdb-prs@sourceware.org \
    /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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).