From: Jonathan Wakely <jwakely@redhat.com>
To: Alexandre Oliva <oliva@adacore.com>
Cc: "François Dumont" <frs.dumont@gmail.com>,
"Jonathan Wakely" <jwakely.gcc@gmail.com>,
libstdc++ <libstdc++@gcc.gnu.org>
Subject: Re: [PATCH] libstdc++: bvector: undef always_inline macro
Date: Thu, 9 Nov 2023 20:18:22 +0000 [thread overview]
Message-ID: <CACb0b4=zgQ0GEwkjMNnP34w6snLgCRLj29e1s9m6mwdpUHo3FQ@mail.gmail.com> (raw)
In-Reply-To: <orr0kypuzy.fsf_-_@lxoliva.fsfla.org>
On Thu, 9 Nov 2023 at 19:49, Alexandre Oliva <oliva@adacore.com> wrote:
>
> On Nov 9, 2023, Jonathan Wakely <jwakely@redhat.com> wrote:
>
> > But I've just realised we probably want to #undef the macro at the end
> > of bits/stl_bvector.h too.
>
> I'm not sure why (what if another libstdc++ header were to define the
> macro, includes stl_bvector.h, and then use the macro expecting it to
> still be there?), but I suppose this is what you mean.
It's consistent with all the other definitions of the macro in our
headers. We always define it locally and then undef it again at the
end of the header. You're right that that makes it rather hard to use
reliably.
> Regstrapped on
> x86_64-linux-gnu just to be sure. Ok to install?
OK thanks.
>
>
> From: Alexandre Oliva <oliva@adacore.com>
>
> It's customary to undefine temporary internal macros at the end of the
> header that defines them, even such widely-usable ones as
> _GLIBCXX_ALWAYS_INLINE, so do so in the header where the define was
> recently introduced.
>
>
> for libstdc++-v3/ChangeLog
>
> * include/bits/stl_bvector.h (_GLIBCXX_ALWAYS_INLINE): Undef.
> ---
> libstdc++-v3/include/bits/stl_bvector.h | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/libstdc++-v3/include/bits/stl_bvector.h b/libstdc++-v3/include/bits/stl_bvector.h
> index 2b91af2005f2d..1b7648535c523 100644
> --- a/libstdc++-v3/include/bits/stl_bvector.h
> +++ b/libstdc++-v3/include/bits/stl_bvector.h
> @@ -1628,4 +1628,6 @@ _GLIBCXX_END_NAMESPACE_CONTAINER
> _GLIBCXX_END_NAMESPACE_VERSION
> } // namespace std
>
> +#undef _GLIBCXX_ALWAYS_INLINE
> +
> #endif
>
> --
> Alexandre Oliva, happy hacker https://FSFLA.org/blogs/lxo/
> Free Software Activist GNU Toolchain Engineer
> More tolerance and less prejudice are key for inclusion and diversity
> Excluding neuro-others for not behaving ""normal"" is *not* inclusive
>
next prev parent reply other threads:[~2023-11-09 20:18 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-08 16:10 [PATCH] libstdc++: optimize bit iterators assuming normalization [PR110807] Alexandre Oliva
2023-11-08 19:32 ` Jonathan Wakely
2023-11-09 1:17 ` [PATCH v2] " Alexandre Oliva
2023-11-09 1:22 ` Jonathan Wakely
2023-11-09 3:36 ` [PATCH v3] " Alexandre Oliva
2023-11-09 5:57 ` François Dumont
2023-11-09 8:16 ` Jonathan Wakely
2023-11-09 19:49 ` [PATCH] libstdc++: bvector: undef always_inline macro Alexandre Oliva
2023-11-09 20:18 ` Jonathan Wakely [this message]
2023-11-15 2:20 ` Patrick Palka
2023-11-15 5:53 ` Alexandre Oliva
2023-11-15 2:44 ` Alexandre Oliva
2023-11-15 5:08 ` Alexandre Oliva
2023-11-15 8:22 ` Jonathan Wakely
2023-11-16 4:40 ` Alexandre Oliva
2024-02-07 16:25 ` [PATCH v2] libstdc++: optimize bit iterators assuming normalization [PR110807] Torbjorn SVENSSON
2024-02-07 16:36 ` Jonathan Wakely
2024-02-09 8:49 ` Torbjorn SVENSSON
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=zgQ0GEwkjMNnP34w6snLgCRLj29e1s9m6mwdpUHo3FQ@mail.gmail.com' \
--to=jwakely@redhat.com \
--cc=frs.dumont@gmail.com \
--cc=jwakely.gcc@gmail.com \
--cc=libstdc++@gcc.gnu.org \
--cc=oliva@adacore.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).