Re: [Ping][PATCH] libstdc++: Add missing functions to <cmath> [PR79700]

[Nathaniel Shead <nathanieloshead@gmail.com>]

On Wed, May 17, 2023 at 10:05:59AM +0100, Jonathan Wakely wrote:
> On Wed, 17 May 2023 at 09:37, Nathaniel Shead wrote:
> 
> > Now that GCC13.1 is released is it ok to merge? Thanks!
> >
> 
> Yes, I've been testing this locally, but I think it needs more work (sorry!)
> 
> Looking at it again, I'm not sure why I asked for the additional tests
> because if they fail, it's a problem in libc, and there's nothing we can
> actually do about it in libstdc++. We certainly do want std::expl(0.0L) to
> return the same thing as std::exp(0.0L), but if it doesn't, we'll just have
> a libstdc++ test failure caused by a bug in libc. But you wrote the test
> now, so let's keep it. If we get failures for the test it will allow us to
> inform the relevant libc maintainers that they have a bug.

Sounds good.

> Also, since you're contributing this under the DCO terms the new test
> should not have the FSF copyright header, unless it's a derived work of an
> existing test with that header (and in that case it should retain the dates
> from the copied test). I don't actually bother putting the copyright and
> license header on new tests these days. There's nothing in that test that
> is novel or interesting, and I think it's arguably not useful or meaningful
> to consider it copyrighted.

Makes sense, I was just copying from other tests in the directory. I'll
keep this in mind for the future, thanks!

> Finally, and most importantly, the new using-declarations in <cmath> are
> not guarded by any autoconf macro. That will break targets without full C99
> <math.h> support, e.g. djgpp declares acosf but not acosl, so the new
> "using acosl;" would be a hard error as soon as <cmath> is included (and
> might even prevent GCC building on that target). So I think we need a new
> autoconf check for the existence of those functions. I'm in the process of
> reworking the autoconf macros for <cmath> (due to PR 109818), which is why
> I didn't address it for this patch yet.

Ah, I see; yes, that would be a problem. I'm not very familiar with
autoconf, so thanks for working this out. Let me know when you've done
that if there's anything else I should do for this patch.

> >
> > On Tue, Apr 18, 2023 at 6:48 PM Jonathan Wakely <jwakely@redhat.com>
> > wrote:
> > >
> > > On Mon, 17 Apr 2023 at 09:11, Nathaniel Shead <nathanieloshead@gmail.com>
> > wrote:
> > > >
> > > > Hi, just checking whether there were any issues with this patch?
> > > > https://gcc.gnu.org/pipermail/gcc-patches/2023-February/612386.html
> > > >
> > > > Otherwise I assume it won't be in GCC13.
> > >
> > > That's right, it's too large and invasive a change to get into GCC 13
> > > when only submitted in February, sorry. I'll merge it to trunk once
> > > GCC 13.1 is released though.
> > >
> >
> >