[Bug target/113763] [14 Regression] build fails with clang++ host compiler because aarch64.cc uses C++14 constexpr.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113763 Andrew Pinski changed: What|Removed |Added CC||markmigm at gmail dot com --- Comment #19 from Andrew Pinski --- *** Bug 114091 has been marked as a duplicate of this bug. ***
[Bug target/113763] [14 Regression] build fails with clang++ host compiler because aarch64.cc uses C++14 constexpr.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113763 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #18 from Jakub Jelinek --- Hopefully fixed (don't have libc++ to try though).
[Bug target/113763] [14 Regression] build fails with clang++ host compiler because aarch64.cc uses C++14 constexpr.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113763 --- Comment #17 from GCC Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:df9f6b934886f51c0c07220d1ee38874b69646c7 commit r14-8828-gdf9f6b934886f51c0c07220d1ee38874b69646c7 Author: Jakub Jelinek Date: Tue Feb 6 15:56:50 2024 +0100 aarch64: Fix build against libc++ in c++11 mode [PR113763] std::pair ctor used in tiles constexpr variable is only constexpr in C++14 and later, it works with libstdc++ because it is marked constexpr there even in C++11 mode. The following patch fixes it by using an unnamed local class instead of std::pair, and additionally changes the first element from unsigned int to unsigned char because 0xff has to fit into unsigned char on all hosts. 2024-02-06 Jakub Jelinek PR target/113763 * config/aarch64/aarch64.cc (aarch64_output_sme_zero_za): Change tiles element from std::pair to an unnamed struct. Adjust uses of tile range variable.
[Bug target/113763] [14 Regression] build fails with clang++ host compiler because aarch64.cc uses C++14 constexpr.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113763 Jakub Jelinek changed: What|Removed |Added Attachment #57338|0 |1 is obsolete|| Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2024-02-06 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #16 from Jakub Jelinek --- Created attachment 57339 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57339=edit gcc14-pr113763.patch Updated patch I'll test then.
[Bug target/113763] [14 Regression] build fails with clang++ host compiler because aarch64.cc uses C++14 constexpr.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113763 --- Comment #15 from Jonathan Wakely --- Yup, no constructor needed, just make it an aggregate. I've created PR 113782 for the non-conforming constexpr in libstdc++.
[Bug target/113763] [14 Regression] build fails with clang++ host compiler because aarch64.cc uses C++14 constexpr.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113763 --- Comment #14 from Richard Sandiford --- AFAIK, the constructor shouldn't be necessary. (And without it, the whole thing would fit on one line.) LGTM (and preapproved) otherwise. Thanks for doing this.
[Bug target/113763] [14 Regression] build fails with clang++ host compiler because aarch64.cc uses C++14 constexpr.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113763 Jakub Jelinek changed: What|Removed |Added Attachment #57334|0 |1 is obsolete|| --- Comment #13 from Jakub Jelinek --- Created attachment 57338 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57338=edit gcc14-pr113763.patch This adds a local class for this instead.
[Bug target/113763] [14 Regression] build fails with clang++ host compiler because aarch64.cc uses C++14 constexpr.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113763 --- Comment #12 from Jakub Jelinek --- (In reply to Richard Sandiford from comment #11) > Currently away so can't try it myself, but how about just using an ad-hoc > structure instead? Yeah, I can do that too.
[Bug target/113763] [14 Regression] build fails with clang++ host compiler because aarch64.cc uses C++14 constexpr.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113763 --- Comment #11 from Richard Sandiford --- Currently away so can't try it myself, but how about just using an ad-hoc structure instead?
[Bug target/113763] [14 Regression] build fails with clang++ host compiler because aarch64.cc uses C++14 constexpr.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113763 --- Comment #10 from Jakub Jelinek --- Created attachment 57334 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57334=edit gcc14-pr113763.patch Can't we just get rid of std::pair here? I mean, 0xff certainly fits into host unsigned char, to make EBCDIC work on -fsigned-char hosts I've used char instead of unsigned char.
[Bug target/113763] [14 Regression] build fails with clang++ host compiler because aarch64.cc uses C++14 constexpr.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113763 --- Comment #9 from Jonathan Wakely --- No, _GLIBCXX14_CONSTEXPR only cares about 11 vs 14, not strict vs gnu.
[Bug target/113763] [14 Regression] build fails with clang++ host compiler because aarch64.cc uses C++14 constexpr.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113763 --- Comment #8 from Iain Sandoe --- (In reply to Jonathan Wakely from comment #7) > (In reply to Jakub Jelinek from comment #6) > > Jon, what about Iain's question whether it isn't a bug we use constexpr on > > the ctor even in C++11 mode? > > Do we treat such papers as DRs on the library side? > > No, but it looks like we did at some point in the past (see also the > constexpr stuff, PR 102916 et al). > > I'm not very motivated to replace those constexpr with _GLIBCXX14_CONSTEXPR > on pair, tuple and initializer_list, but for correctness we should do it. presumably, that still allows the constexpr with gnu++11? (so we'd not be losing that much, but we'd catch cases like this one earlier)
[Bug target/113763] [14 Regression] build fails with clang++ host compiler because aarch64.cc uses C++14 constexpr.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113763 --- Comment #7 from Jonathan Wakely --- (In reply to Jakub Jelinek from comment #6) > Jon, what about Iain's question whether it isn't a bug we use constexpr on > the ctor even in C++11 mode? > Do we treat such papers as DRs on the library side? No, but it looks like we did at some point in the past (see also the constexpr stuff, PR 102916 et al). I'm not very motivated to replace those constexpr with _GLIBCXX14_CONSTEXPR on pair, tuple and initializer_list, but for correctness we should do it.
[Bug target/113763] [14 Regression] build fails with clang++ host compiler because aarch64.cc uses C++14 constexpr.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113763 --- Comment #6 from Jakub Jelinek --- Jon, what about Iain's question whether it isn't a bug we use constexpr on the ctor even in C++11 mode? Do we treat such papers as DRs on the library side?
[Bug target/113763] [14 Regression] build fails with clang++ host compiler because aarch64.cc uses C++14 constexpr.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113763 --- Comment #5 from Jakub Jelinek --- I guess it surely helps if the array isn't dynamically initialized, but that is just an optimization, it will work even when it is. And the compiler should do that even if the array isn't constexpr if the ctor is constexpr.
[Bug target/113763] [14 Regression] build fails with clang++ host compiler because aarch64.cc uses C++14 constexpr.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113763 Richard Biener changed: What|Removed |Added Target Milestone|--- |14.0
[Bug target/113763] [14 Regression] build fails with clang++ host compiler because aarch64.cc uses C++14 constexpr.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113763 --- Comment #4 from Jonathan Wakely --- Or just const ... why bother using constexpr at all?
[Bug target/113763] [14 Regression] build fails with clang++ host compiler because aarch64.cc uses C++14 constexpr.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113763 --- Comment #3 from Jonathan Wakely --- (In reply to Jakub Jelinek from comment #2) > I think that ctor is constexpr since https://wg21.link/N3471 > Does that have some feature test macro? That was long before we started using feature test macros. > If not, should we use constexpr conditionally for C++14 and const otherwise? Yes.
[Bug target/113763] [14 Regression] build fails with clang++ host compiler because aarch64.cc uses C++14 constexpr.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113763 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||redi at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- I think that ctor is constexpr since https://wg21.link/N3471 Does that have some feature test macro? If not, should we use constexpr conditionally for C++14 and const otherwise?
[Bug target/113763] [14 Regression] build fails with clang++ host compiler because aarch64.cc uses C++14 constexpr.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113763 --- Comment #1 from Iain Sandoe --- I suppose the trivial fix is s/constexpr/const/ (but maybe there's something more elegant). If we agree that this is c++14 - only, then maybe we should have a separate bug that we accept this for c++11.
