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 <jwak...@redhat.com> > > wrote: > > > > > > On Mon, 17 Apr 2023 at 09:11, Nathaniel Shead <nathanielosh...@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. > > > > > > >
