public inbox for libstdc++@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jonathan Wakely <jwakely@redhat.com>
To: Jakub Jelinek <jakub@redhat.com>
Cc: gcc Patches <gcc-patches@gcc.gnu.org>,
	"libstdc++" <libstdc++@gcc.gnu.org>
Subject: Re: [PATCH] libstdc++: Work around clang misdesign in time_get<>::get [PR104990]
Date: Mon, 21 Mar 2022 10:00:12 +0000	[thread overview]
Message-ID: <CACb0b4=juX+5UcEUvd=dNfhv5xB77wEGnxVj83i50XHEGTGxEA@mail.gmail.com> (raw)
In-Reply-To: <YjgebfpclpVUaQqG@tucnak>

On Mon, 21 Mar 2022 at 06:42, Jakub Jelinek wrote:
>
> Hi!
>
> Apparently clang has a -fgnuc-version= option which allows it to pretend
> it is any GCC version the user likes.  It is already bad that it claims to
> be GCC 4.2 compatible by default when it is not (various unimplemented
> extensions at least), but this option is a horrible idea.
>
> Anyway, this patch adds a hack for it.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

OK for trunk.

In stage 1 we might want to consider removing the __GNUC__ check
entirely. We don't support using old versions of genuine GCC. Intel
icc claims to be the latest GCC. And now Clang can be told to cosplay
as any version of GCC, so we can't trust __GNUC__ at all. So this
check would be just !defined(__clang__).


>
> 2022-03-21  Jakub Jelinek  <jakub@redhat.com>
>
>         PR libstdc++/104990
>         * include/bits/locale_facets_nonio.tcc (get): Don't check if do_get
>         isn't overloaded if __clang__ is defined.
>
> --- libstdc++-v3/include/bits/locale_facets_nonio.tcc   2022-03-18 10:37:41.176593188 +0100
> +++ libstdc++-v3/include/bits/locale_facets_nonio.tcc   2022-03-20 20:28:07.203815325 +0100
> @@ -1465,7 +1465,7 @@ _GLIBCXX_END_NAMESPACE_LDBL_OR_CXX11
>        ctype<_CharT> const& __ctype = use_facet<ctype<_CharT> >(__loc);
>        __err = ios_base::goodbit;
>        bool __use_state = false;
> -#if __GNUC__ >= 5
> +#if __GNUC__ >= 5 && !defined(__clang__)
>  #pragma GCC diagnostic push
>  #pragma GCC diagnostic ignored "-Wpmf-conversions"
>        // Nasty hack.  The C++ standard mandates that get invokes the do_get
>
>         Jakub
>


      reply	other threads:[~2022-03-21 10:00 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-21  6:42 Jakub Jelinek
2022-03-21 10:00 ` Jonathan Wakely [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='CACb0b4=juX+5UcEUvd=dNfhv5xB77wEGnxVj83i50XHEGTGxEA@mail.gmail.com' \
    --to=jwakely@redhat.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jakub@redhat.com \
    --cc=libstdc++@gcc.gnu.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).