From: Jonathan Wakely <jwakely@redhat.com>
To: Jakub Jelinek <jakub@redhat.com>
Cc: gcc-patches@gcc.gnu.org, libstdc++@gcc.gnu.org
Subject: Re: [PATCH] libstdc++-v3: Implement {,b}float16_t nextafter and some fixes [PR106652]
Date: Wed, 19 Oct 2022 10:02:01 +0100 [thread overview]
Message-ID: <CACb0b4mFECk1zNKEfYnAEtML0PQsi5jRAToEoXaXWnpaBFXP0g@mail.gmail.com> (raw)
In-Reply-To: <Y0+z9IfvRybw/D2c@tucnak>
On Wed, 19 Oct 2022 at 09:23, Jakub Jelinek wrote:
>
> Hi!
>
> The following patch implements nextafter for std::{,b}float16_t,
> though right now only without constexpr support, and adds a testcase for it.
> The testcase unfortunately relevealed I've screwed up testing of my last
> patch. I've tested earlier version of the patch with
> --target_board=unix/-std=c++23
> but didn't test the final version with that RUNTESTFLAGS, so missed
> an invalid call to std::sph_neumann (too many arguments) in the test.
> And, I've made a typo in the guard for numeric_limits (the reason
> for the guard is I wanted to avoid defining a large macro that nothing
> will then use because the std::{,b}float*_t types are C++23 only) and
> so numeric_limits wasn't specialized for the types at all but
> testsuite/18_support/headers/limits/synopsis_cxx23.cc test didn't
> detect that.
> In the nextafter implementation I'm calling __builtin_nextafterf
> to get various required side-effects for nextafter from 0/-0, or from max
> to inf or from min to largest subnormal to avoid needing to set errno
> inline, or use inline asm specific for each processor to force math
> evaluation barriers. Dunno if
> #ifdef __INT16_TYPE__
> using __float16_int_type = __INT16_TYPE__;
> #else
> using __float16_int_type = short int;
> #endif
> isn't too ugly, perhaps we could just blindly use short int and hope
> or even assert it has the same size as _Float16 or __gnu_cxx::__bfloat16_t?
I'm happy with the preprocessor conditions above, but using short int
and a static assert would be OK too.
> Only aarch64, arm, csky, gcn, x86, nvptx and riscv support these types
> and all of them have 16-bit short (I think the only target with some
> other short size is avr with certain command line switches where both
> short and int are 8-bit, but such mode isn't compatible with C and C++
> requirements).
It's not, but we do try to support avr, especially for something like
<limits> which requires no OS support and has always been required for
freestanding. But will it have float16 anyway? I suppose it might do,
so maybe the preprocessor dance for __INT16_TYPE__ is better. It's
only needed in two places, so isn't too bad.
> --- libstdc++-v3/testsuite/26_numerics/headers/cmath/nextafter_c++23.cc.jj 2022-10-18 17:18:32.237061706 +0200
> +++ libstdc++-v3/testsuite/26_numerics/headers/cmath/nextafter_c++23.cc 2022-10-18 18:51:21.465258133 +0200
> @@ -0,0 +1,124 @@
> +// Copyright (C) 2022 Free Software Foundation, Inc.
> +//
> +// This file is part of the GNU ISO C++ Library. This library is free
> +// software; you can redistribute it and/or modify it under the
> +// terms of the GNU General Public License as published by the
> +// Free Software Foundation; either version 3, or (at your option)
> +// any later version.
> +
> +// This library is distributed in the hope that it will be useful,
> +// but WITHOUT ANY WARRANTY; without even the implied warranty of
> +// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> +// GNU General Public License for more details.
> +
> +// You should have received a copy of the GNU General Public License along
> +// with this library; see the file COPYING3. If not see
> +// <http://www.gnu.org/licenses/>.
> +
> +// { dg-do run { target c++23 } }
This should have { dg-options "-std=gnu++2b" } before the dg-do.
OK with that change.
prev parent reply other threads:[~2022-10-19 9:02 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-19 8:23 Jakub Jelinek
2022-10-19 9:02 ` 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=CACb0b4mFECk1zNKEfYnAEtML0PQsi5jRAToEoXaXWnpaBFXP0g@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).