I've finally convinced myself that this patch is OK, because we provide stub versions of all the functions being declared here. So if a target is missing them, we provide them anyway. That happens to be broken for the avr target, but that defaults to --disable-libstdcxx anyway.
I've pushed the patch to trunk - thanks for the work on it! On Wed, 17 May 2023 at 11:07, Jonathan Wakely <jwak...@redhat.com> wrote: > > > > On Wed, 17 May 2023 at 10:38, Nathaniel Shead <nathanielosh...@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 <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. >> > > > >> > > >> > > >>
