* isl 0.26 C++17 issues when bootstrapping with GCC @ 2023-08-29 14:29 Ben Boeckel 2023-08-29 16:57 ` Richard Biener 0 siblings, 1 reply; 8+ messages in thread From: Ben Boeckel @ 2023-08-29 14:29 UTC (permalink / raw) To: gcc Hi, I tried adding isl 0.26 to a 13.2 GCC build using Iain's macOS aarch64 patches: https://github.com/iains/gcc-13-branch It seems that the bootstrap's `CXX='g++ -std=c++11'` confuses isl's build where C++17 is expected to work by disabling C++17 behind its back. Should GCC not add this flag for its dependencies but only its own build perhaps? isl bug report thread (with isl configure logs and the like): https://groups.google.com/g/isl-development/c/ShnQcW_35ZQ Thanks, --Ben ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: isl 0.26 C++17 issues when bootstrapping with GCC 2023-08-29 14:29 isl 0.26 C++17 issues when bootstrapping with GCC Ben Boeckel @ 2023-08-29 16:57 ` Richard Biener 2023-08-29 23:32 ` Ben Boeckel 0 siblings, 1 reply; 8+ messages in thread From: Richard Biener @ 2023-08-29 16:57 UTC (permalink / raw) To: Ben Boeckel; +Cc: gcc > Am 29.08.2023 um 16:30 schrieb Ben Boeckel via Gcc <gcc@gcc.gnu.org>: > > Hi, > > I tried adding isl 0.26 to a 13.2 GCC build using Iain's macOS aarch64 > patches: > > https://github.com/iains/gcc-13-branch > > It seems that the bootstrap's `CXX='g++ -std=c++11'` confuses isl's > build where C++17 is expected to work by disabling C++17 behind its > back. Should GCC not add this flag for its dependencies but only its own > build perhaps? I suppose for bootstrapping we could disable ISL during stage1 since it enables an optional feature only. Other than that GCC only requires a C++11 compiler for building, so ISL breaks that constraint with requiring C++17. Richard > isl bug report thread (with isl configure logs and the like): > > https://groups.google.com/g/isl-development/c/ShnQcW_35ZQ > > Thanks, > > --Ben ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: isl 0.26 C++17 issues when bootstrapping with GCC 2023-08-29 16:57 ` Richard Biener @ 2023-08-29 23:32 ` Ben Boeckel 2024-05-13 15:05 ` Iain Sandoe 0 siblings, 1 reply; 8+ messages in thread From: Ben Boeckel @ 2023-08-29 23:32 UTC (permalink / raw) To: Richard Biener; +Cc: gcc On Tue, Aug 29, 2023 at 18:57:37 +0200, Richard Biener wrote: > I suppose for bootstrapping we could disable ISL during stage1 since > it enables an optional feature only. Other than that GCC only > requires a C++11 compiler for building, so ISL breaks that constraint > with requiring C++17. Note that it doesn't *require* it per sé; the tests that try it are compiled if C++17 support was detected at all. The headers seem to just have optional header-only `std::any`-using APIs if C++17 is around. `isl` supporting a flag to disable the tests would also work, but that doesn't fix 0.26. It also doesn't mean it won't start requiring C++17 at some point in the future. In light of that, I feel that skipping it for bootstrap is probably the right solution here. Alas, my skill with autotools is closer to the caveman-with-club level rather than that of a surgeon. --Ben ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: isl 0.26 C++17 issues when bootstrapping with GCC 2023-08-29 23:32 ` Ben Boeckel @ 2024-05-13 15:05 ` Iain Sandoe 2024-05-13 16:00 ` Iain Sandoe 0 siblings, 1 reply; 8+ messages in thread From: Iain Sandoe @ 2024-05-13 15:05 UTC (permalink / raw) To: GCC Development; +Cc: Ben Boeckel, Richard Biener This > On 30 Aug 2023, at 00:32, Ben Boeckel via Gcc <gcc@gcc.gnu.org> wrote: > > On Tue, Aug 29, 2023 at 18:57:37 +0200, Richard Biener wrote: >> I suppose for bootstrapping we could disable ISL during stage1 since >> it enables an optional feature only. Other than that GCC only >> requires a C++11 compiler for building, so ISL breaks that constraint >> with requiring C++17. > > Note that it doesn't *require* it per sé; the tests that try it are > compiled if C++17 support was detected at all. The headers seem to just > have optional header-only `std::any`-using APIs if C++17 is around. > `isl` supporting a flag to disable the tests would also work, but that > doesn't fix 0.26. It also doesn't mean it won't start requiring C++17 at > some point in the future. Perhaps, in the short-term (i.e. before it requires C++ > 11) we can solve this by ensuring that we pass -std=c++11 to the configure stages as well as to the build. ISTM that configure is finding C++17-capability (because we do not, I think, force C++11 for the configure) and then the build takes it away by forcing -std=c++11. [ will try this out ] > In light of that, I feel that skipping it for bootstrap is probably the > right solution here. Alas, my skill with autotools is closer to the > caveman-with-club level rather than that of a surgeon. I am not sure we have an easy way to exclude a host module from stage1 only (but ICBW). Iain > > --Ben ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: isl 0.26 C++17 issues when bootstrapping with GCC 2024-05-13 15:05 ` Iain Sandoe @ 2024-05-13 16:00 ` Iain Sandoe 2024-05-13 17:46 ` Richard Biener 0 siblings, 1 reply; 8+ messages in thread From: Iain Sandoe @ 2024-05-13 16:00 UTC (permalink / raw) To: GCC Development; +Cc: Ben Boeckel, Richard Biener > On 13 May 2024, at 16:05, Iain Sandoe via Gcc <gcc@gcc.gnu.org> wrote: >> On 30 Aug 2023, at 00:32, Ben Boeckel via Gcc <gcc@gcc.gnu.org> wrote: >> >> On Tue, Aug 29, 2023 at 18:57:37 +0200, Richard Biener wrote: >>> I suppose for bootstrapping we could disable ISL during stage1 since >>> it enables an optional feature only. Other than that GCC only >>> requires a C++11 compiler for building, so ISL breaks that constraint >>> with requiring C++17. >> >> Note that it doesn't *require* it per sé; the tests that try it are >> compiled if C++17 support was detected at all. The headers seem to just >> have optional header-only `std::any`-using APIs if C++17 is around. >> `isl` supporting a flag to disable the tests would also work, but that >> doesn't fix 0.26. It also doesn't mean it won't start requiring C++17 at >> some point in the future. > > Perhaps, in the short-term (i.e. before it requires C++ > 11) we can > solve this by ensuring that we pass -std=c++11 to the configure stages > as well as to the build. ISTM that configure is finding C++17-capability > (because we do not, I think, force C++11 for the configure) and then > the build takes it away by forcing -std=c++11. That was not right. We add std=c++11 to the compiler command. However,as noted (earlier in this thread) the isl configure has the idiom - does the compiler do c++17 with no options? - does the compiler do c++17 if we add -std=c++17? where the second one overrides our setting of std=c++11 in the compiler comand. (I think that this is a reasonably often used idiom in configures) However the isl configure _does_ still append CXXFLAGS, and so that if we add -std=c++11 to those, it re-asserts our intent. Maybe we should just add the -std=c++11 to CXXFLAGS instead of the compiler command? Iain >> In light of that, I feel that skipping it for bootstrap is probably the >> right solution here. Alas, my skill with autotools is closer to the >> caveman-with-club level rather than that of a surgeon. > > I am not sure we have an easy way to exclude a host module from > stage1 only (but ICBW). > > Iain > >> >> --Ben ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: isl 0.26 C++17 issues when bootstrapping with GCC 2024-05-13 16:00 ` Iain Sandoe @ 2024-05-13 17:46 ` Richard Biener 2024-05-13 18:43 ` Iain Sandoe 0 siblings, 1 reply; 8+ messages in thread From: Richard Biener @ 2024-05-13 17:46 UTC (permalink / raw) To: Iain Sandoe; +Cc: GCC Development, Ben Boeckel On Mon, May 13, 2024 at 6:00 PM Iain Sandoe <iain@sandoe.co.uk> wrote: > > > > > On 13 May 2024, at 16:05, Iain Sandoe via Gcc <gcc@gcc.gnu.org> wrote: > >> On 30 Aug 2023, at 00:32, Ben Boeckel via Gcc <gcc@gcc.gnu.org> wrote: > >> > >> On Tue, Aug 29, 2023 at 18:57:37 +0200, Richard Biener wrote: > >>> I suppose for bootstrapping we could disable ISL during stage1 since > >>> it enables an optional feature only. Other than that GCC only > >>> requires a C++11 compiler for building, so ISL breaks that constraint > >>> with requiring C++17. > >> > >> Note that it doesn't *require* it per sé; the tests that try it are > >> compiled if C++17 support was detected at all. The headers seem to just > >> have optional header-only `std::any`-using APIs if C++17 is around. > >> `isl` supporting a flag to disable the tests would also work, but that > >> doesn't fix 0.26. It also doesn't mean it won't start requiring C++17 at > >> some point in the future. > > > > Perhaps, in the short-term (i.e. before it requires C++ > 11) we can > > solve this by ensuring that we pass -std=c++11 to the configure stages > > as well as to the build. ISTM that configure is finding C++17-capability > > (because we do not, I think, force C++11 for the configure) and then > > the build takes it away by forcing -std=c++11. > > That was not right. > We add std=c++11 to the compiler command. > > However,as noted (earlier in this thread) the isl configure has the idiom > - does the compiler do c++17 with no options? > - does the compiler do c++17 if we add -std=c++17? > > where the second one overrides our setting of std=c++11 in the compiler > comand. > > (I think that this is a reasonably often used idiom in configures) > > However the isl configure _does_ still append CXXFLAGS, and so that if > we add -std=c++11 to those, it re-asserts our intent. > > Maybe we should just add the -std=c++11 to CXXFLAGS instead of the > compiler command? I don't understand. If we set CXX to g++ -std=c++11 and ISL checks for -std=c++17 why does it then fail to add that to CXXFLAGS? > Iain > > >> In light of that, I feel that skipping it for bootstrap is probably the > >> right solution here. Alas, my skill with autotools is closer to the > >> caveman-with-club level rather than that of a surgeon. > > > > I am not sure we have an easy way to exclude a host module from > > stage1 only (but ICBW). > > > > Iain > > > >> > >> --Ben > ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: isl 0.26 C++17 issues when bootstrapping with GCC 2024-05-13 17:46 ` Richard Biener @ 2024-05-13 18:43 ` Iain Sandoe 2024-05-13 19:37 ` Iain Sandoe 0 siblings, 1 reply; 8+ messages in thread From: Iain Sandoe @ 2024-05-13 18:43 UTC (permalink / raw) To: Richard Biener; +Cc: GCC Development, Ben Boeckel > On 13 May 2024, at 18:46, Richard Biener <richard.guenther@gmail.com> wrote: > > On Mon, May 13, 2024 at 6:00 PM Iain Sandoe <iain@sandoe.co.uk> wrote: >> >> >> >>> On 13 May 2024, at 16:05, Iain Sandoe via Gcc <gcc@gcc.gnu.org> wrote: >>>> On 30 Aug 2023, at 00:32, Ben Boeckel via Gcc <gcc@gcc.gnu.org> wrote: >>>> >>>> On Tue, Aug 29, 2023 at 18:57:37 +0200, Richard Biener wrote: >>>>> I suppose for bootstrapping we could disable ISL during stage1 since >>>>> it enables an optional feature only. Other than that GCC only >>>>> requires a C++11 compiler for building, so ISL breaks that constraint >>>>> with requiring C++17. >>>> >>>> Note that it doesn't *require* it per sé; the tests that try it are >>>> compiled if C++17 support was detected at all. The headers seem to just >>>> have optional header-only `std::any`-using APIs if C++17 is around. >>>> `isl` supporting a flag to disable the tests would also work, but that >>>> doesn't fix 0.26. It also doesn't mean it won't start requiring C++17 at >>>> some point in the future. >>> >>> Perhaps, in the short-term (i.e. before it requires C++ > 11) we can >>> solve this by ensuring that we pass -std=c++11 to the configure stages >>> as well as to the build. ISTM that configure is finding C++17-capability >>> (because we do not, I think, force C++11 for the configure) and then >>> the build takes it away by forcing -std=c++11. >> >> That was not right. >> We add std=c++11 to the compiler command. >> >> However,as noted (earlier in this thread) the isl configure has the idiom >> - does the compiler do c++17 with no options? >> - does the compiler do c++17 if we add -std=c++17? >> >> where the second one overrides our setting of std=c++11 in the compiler >> comand. >> >> (I think that this is a reasonably often used idiom in configures) >> >> However the isl configure _does_ still append CXXFLAGS, and so that if >> we add -std=c++11 to those, it re-asserts our intent. >> >> Maybe we should just add the -std=c++11 to CXXFLAGS instead of the >> compiler command? > > I don't understand. If we set CXX to g++ -std=c++11 and ISL checks > for -std=c++17 why does it then fail to add that to CXXFLAGS? This appears to be the underlying bug. — isl configure.ac does: AX_CXX_COMPILE_STDCXX_17([], [optional]) …. AM_CONDITIONAL(HAVE_CXX17, test "x$HAVE_CXX17" = "x1”) — and then Makefile.am adds the c++17-requirements: if HAVE_CXX17 noinst_PROGRAMS += isl_test_cpp17 isl_test_cpp17-checked TESTS += isl_test_cpp17 isl_test_cpp17-checked endif .. this mechanism does not seem to preserve the fact that an additional -std=c++17 was needed to get the CXX17 (and there is no mention of CXXFLAGS in Makefile.am) Not sure if it’s a bug in isl’s config - or a limitation of AX_CXX_COMPILE_STDCXX_17 itself. — assuming we file a bug and it gets agreed and fixed, we’ll still need either to skip broken versions or work around it (I have no specific preference - although I do build isl in-tree, so far 0.24 has been OK). Iain > >> Iain >> >>>> In light of that, I feel that skipping it for bootstrap is probably the >>>> right solution here. Alas, my skill with autotools is closer to the >>>> caveman-with-club level rather than that of a surgeon. >>> >>> I am not sure we have an easy way to exclude a host module from >>> stage1 only (but ICBW). >>> >>> Iain >>> >>>> >>>> --Ben ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: isl 0.26 C++17 issues when bootstrapping with GCC 2024-05-13 18:43 ` Iain Sandoe @ 2024-05-13 19:37 ` Iain Sandoe 0 siblings, 0 replies; 8+ messages in thread From: Iain Sandoe @ 2024-05-13 19:37 UTC (permalink / raw) To: Richard Biener; +Cc: GCC Development, Ben Boeckel > On 13 May 2024, at 19:43, Iain Sandoe <iain@sandoe.co.uk> wrote: > > > >> On 13 May 2024, at 18:46, Richard Biener <richard.guenther@gmail.com> wrote: >> >> On Mon, May 13, 2024 at 6:00 PM Iain Sandoe <iain@sandoe.co.uk> wrote: >>> >>> >>> >>>> On 13 May 2024, at 16:05, Iain Sandoe via Gcc <gcc@gcc.gnu.org> wrote: >>>>> On 30 Aug 2023, at 00:32, Ben Boeckel via Gcc <gcc@gcc.gnu.org> wrote: >>>>> >>>>> On Tue, Aug 29, 2023 at 18:57:37 +0200, Richard Biener wrote: >>>>>> I suppose for bootstrapping we could disable ISL during stage1 since >>>>>> it enables an optional feature only. Other than that GCC only >>>>>> requires a C++11 compiler for building, so ISL breaks that constraint >>>>>> with requiring C++17. >>>>> >>>>> Note that it doesn't *require* it per sé; the tests that try it are >>>>> compiled if C++17 support was detected at all. The headers seem to just >>>>> have optional header-only `std::any`-using APIs if C++17 is around. >>>>> `isl` supporting a flag to disable the tests would also work, but that >>>>> doesn't fix 0.26. It also doesn't mean it won't start requiring C++17 at >>>>> some point in the future. >>>> >>>> Perhaps, in the short-term (i.e. before it requires C++ > 11) we can >>>> solve this by ensuring that we pass -std=c++11 to the configure stages >>>> as well as to the build. ISTM that configure is finding C++17-capability >>>> (because we do not, I think, force C++11 for the configure) and then >>>> the build takes it away by forcing -std=c++11. >>> >>> That was not right. >>> We add std=c++11 to the compiler command. >>> >>> However,as noted (earlier in this thread) the isl configure has the idiom >>> - does the compiler do c++17 with no options? >>> - does the compiler do c++17 if we add -std=c++17? >>> >>> where the second one overrides our setting of std=c++11 in the compiler >>> comand. >>> >>> (I think that this is a reasonably often used idiom in configures) >>> >>> However the isl configure _does_ still append CXXFLAGS, and so that if >>> we add -std=c++11 to those, it re-asserts our intent. >>> >>> Maybe we should just add the -std=c++11 to CXXFLAGS instead of the >>> compiler command? >> >> I don't understand. If we set CXX to g++ -std=c++11 and ISL checks >> for -std=c++17 why does it then fail to add that to CXXFLAGS? > > This appears to be the underlying bug. > > — isl configure.ac does: > > AX_CXX_COMPILE_STDCXX_17([], [optional]) > > …. > > AM_CONDITIONAL(HAVE_CXX17, test "x$HAVE_CXX17" = "x1”) > > — and then Makefile.am adds the c++17-requirements: > > if HAVE_CXX17 > noinst_PROGRAMS += isl_test_cpp17 isl_test_cpp17-checked > TESTS += isl_test_cpp17 isl_test_cpp17-checked > endif > > .. this mechanism does not seem to preserve the fact that an additional > -std=c++17 was needed to get the CXX17 (and there is no mention of > CXXFLAGS in Makefile.am) > > Not sure if it’s a bug in isl’s config - or a limitation of > AX_CXX_COMPILE_STDCXX_17 itself. > > — assuming we file a bug and it gets agreed and fixed, we’ll still need > either to skip broken versions or work around it (I have no specific > preference - although I do build isl in-tree, so far 0.24 has been OK) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115077 ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2024-05-13 19:37 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2023-08-29 14:29 isl 0.26 C++17 issues when bootstrapping with GCC Ben Boeckel 2023-08-29 16:57 ` Richard Biener 2023-08-29 23:32 ` Ben Boeckel 2024-05-13 15:05 ` Iain Sandoe 2024-05-13 16:00 ` Iain Sandoe 2024-05-13 17:46 ` Richard Biener 2024-05-13 18:43 ` Iain Sandoe 2024-05-13 19:37 ` Iain Sandoe
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).