On Wed, 17 May 2023 at 10:38, Nathaniel Shead <nathanieloshead@gmail.com>
wrote:

> 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!
>

Yeah, we have a mix of tests using the old conventions (with copyright and
GPL headers) and new conventions (don't bother, they're not really
meaningful on tests).

We're unlikely to *remove* the copyright notices from the old tests,
because that would require all sorts of legal wrangling, and it's not clear
that the copyright holder (the FSF) would agree to it anyway.





> > 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.
>

I hope to have an updated patch by next week, so I'll let you know once
that's ready. Thanks for your patience and for pining the 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.
> > > >
> > >
> > >
>
>