* GCC 12.1 Release Candidate available from gcc.gnu.org @ 2022-04-29 14:34 Jakub Jelinek 2022-05-01 10:02 ` Iain Sandoe 2022-05-02 11:49 ` Boris Kolpackov 0 siblings, 2 replies; 8+ messages in thread From: Jakub Jelinek @ 2022-04-29 14:34 UTC (permalink / raw) To: gcc The first release candidate for GCC 12.1 is available from https://gcc.gnu.org/pub/gcc/snapshots/12.1.0-RC-20220429/ ftp://gcc.gnu.org/pub/gcc/snapshots/12.1.0-RC-20220429/ and shortly its mirrors. It has been generated from git commit r12-8321-g621650f64fb667. I have so far bootstrapped and tested the release candidate on x86_64-linux. Please test it and report any issues to bugzilla. If all goes well, I'd like to release 12.1 on Friday, May 6th. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: GCC 12.1 Release Candidate available from gcc.gnu.org 2022-04-29 14:34 GCC 12.1 Release Candidate available from gcc.gnu.org Jakub Jelinek @ 2022-05-01 10:02 ` Iain Sandoe 2022-05-01 11:41 ` Jakub Jelinek 2022-05-02 11:49 ` Boris Kolpackov 1 sibling, 1 reply; 8+ messages in thread From: Iain Sandoe @ 2022-05-01 10:02 UTC (permalink / raw) To: Jakub Jelinek; +Cc: GCC Development, David Malcolm Hi Jakub, thanks for doing the release. > On 29 Apr 2022, at 15:34, Jakub Jelinek via Gcc <gcc@gcc.gnu.org> wrote: > > The first release candidate for GCC 12.1 is available from > > https://gcc.gnu.org/pub/gcc/snapshots/12.1.0-RC-20220429/ > ftp://gcc.gnu.org/pub/gcc/snapshots/12.1.0-RC-20220429/ > > and shortly its mirrors. It has been generated from git commit > r12-8321-g621650f64fb667. > > I have so far bootstrapped and tested the release candidate on > x86_64-linux. Please test it and report any issues to bugzilla. I have some mixed results, unfortunately. OK: i686, powerpc-darwin9 (bootstrapped with gcc-5.3) all supported langs. x86_64-darwin{10..21} (bootstrapped with gcc-7.5) all supported langs. Where I have bootstrapped D, that was using 11.3 as the bootstrap GDC. results from: https://gcc.gnu.org/pipermail/gcc-testresults/2022-May/760678.html to: https://gcc.gnu.org/pipermail/gcc-testresults/2022-May/760692.html All of these show new fails (presumably because checking is off): XPASS: c-c++-common/goacc/kernels-decompose-pr100400-1-2.c -std=c++98 (internal compiler error) FAIL: c-c++-common/goacc/kernels-decompose-pr100400-1-2.c -std=c++98 (test for excess errors) XPASS: c-c++-common/goacc/kernels-decompose-pr100400-1-2.c -std=c++14 (internal compiler error) FAIL: c-c++-common/goacc/kernels-decompose-pr100400-1-2.c -std=c++14 (test for excess errors) XPASS: c-c++-common/goacc/kernels-decompose-pr100400-1-2.c -std=c++17 (internal compiler error) FAIL: c-c++-common/goacc/kernels-decompose-pr100400-1-2.c -std=c++17 (test for excess errors) XPASS: c-c++-common/goacc/kernels-decompose-pr100400-1-2.c -std=c++20 (internal compiler error) FAIL: c-c++-common/goacc/kernels-decompose-pr100400-1-2.c -std=c++20 (test for excess errors) earlier x86 darwin is particularly noisy test-wise because there seem to be a lot of newer AVX512 tests that do not check for support from the assembler etc. ==== We do not expect darwin9-11 to bootstrap with host tools, they do not have sufficient C++11 support. However from Darwin12+ (macOS 10.8) we expect to be able to bootstrap with the host clang, but: Not OK: x86_64-darwin{12..15} FAIL to bootstrap with host clang, this is a regression. the reason is that "gcc/analyzer/region-model.cc” uses initializer_lists, and it seems that <initializer_list> is not transitively included by any used headers for _LIBCPP_VERSION < 4000. I fixed that locally by adding initializer_list into system.h (and adding INCLUDE_INITIALIZER_LIST to the top of gcc/analyzer/region-model.cc) - with that change those versions do bootstrap and test OK*** OK: x86_64-darwin{16..21} bootstrap OK with the host clang, and the test results show no surprises c.f. the results with gcc-7.5 as the bootstrap. If there’s an rc2 (or it seems reasonable anyway) it would be nice to fix the bootstrap with host tools. thanks Iain *** I’ll do a patch for master/gcc-12 after the weekend (public holiday in the UK tomorrow), if no-one beats me to it… ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: GCC 12.1 Release Candidate available from gcc.gnu.org 2022-05-01 10:02 ` Iain Sandoe @ 2022-05-01 11:41 ` Jakub Jelinek 2022-05-01 15:38 ` Richard Biener 0 siblings, 1 reply; 8+ messages in thread From: Jakub Jelinek @ 2022-05-01 11:41 UTC (permalink / raw) To: Iain Sandoe; +Cc: GCC Development, David Malcolm On Sun, May 01, 2022 at 11:02:29AM +0100, Iain Sandoe wrote: > All of these show new fails (presumably because checking is off): > > XPASS: c-c++-common/goacc/kernels-decompose-pr100400-1-2.c -std=c++98 (internal compiler error) > FAIL: c-c++-common/goacc/kernels-decompose-pr100400-1-2.c -std=c++98 (test for excess errors) > XPASS: c-c++-common/goacc/kernels-decompose-pr100400-1-2.c -std=c++14 (internal compiler error) > FAIL: c-c++-common/goacc/kernels-decompose-pr100400-1-2.c -std=c++14 (test for excess errors) > XPASS: c-c++-common/goacc/kernels-decompose-pr100400-1-2.c -std=c++17 (internal compiler error) > FAIL: c-c++-common/goacc/kernels-decompose-pr100400-1-2.c -std=c++17 (test for excess errors) > XPASS: c-c++-common/goacc/kernels-decompose-pr100400-1-2.c -std=c++20 (internal compiler error) > FAIL: c-c++-common/goacc/kernels-decompose-pr100400-1-2.c -std=c++20 (test for excess errors) We can live with that for 12.1. > earlier x86 darwin is particularly noisy test-wise because there seem to be a lot of newer AVX512 tests > that do not check for support from the assembler etc. That would be nice to fix for 12.2, can you file a PR with a list? > However from Darwin12+ (macOS 10.8) we expect to be able to bootstrap with the host clang, but: > > Not OK: > x86_64-darwin{12..15} FAIL to bootstrap with host clang, this is a regression. > > the reason is that "gcc/analyzer/region-model.cc” uses initializer_lists, and it seems that <initializer_list> > is not transitively included by any used headers for _LIBCPP_VERSION < 4000. I fixed that locally by > adding initializer_list into system.h (and adding INCLUDE_INITIALIZER_LIST to the top of > gcc/analyzer/region-model.cc) > - with that change those versions do bootstrap and test OK*** From what I can see, with libstdc++ it works because <utility> which is included by system.h includes <initializer_list>. If I rename initializer_list in analyzer/region-model.ii to initializer_listx, I also get: ../../gcc/analyzer/region-model.cc: In function ‘void ana::selftest::test_binop_svalue_folding()’: ../../gcc/analyzer/region-model.cc:4966:48: error: deducing from brace-enclosed initializer list requires ‘#include <initializer_list>’ 4508 | +++ |+#include <initializer_list> 4509 | static void ...... 4966 | for (auto op : {BIT_IOR_EXPR, TRUTH_OR_EXPR}) | ^ ../../gcc/analyzer/region-model.cc:4978:49: error: deducing from brace-enclosed initializer list requires ‘#include <initializer_list>’ 4978 | for (auto op : {BIT_AND_EXPR, TRUTH_AND_EXPR}) | ^ I think we have 2 options, one is do what you wrote above, INCLUDE_INITIALIZER_LIST defined before system.h to get #include <initializer_list>. The other option is just to include that unconditionally, it is a very small header. For libstdc++ it will make no difference as it is included anyway and the header is really small there, libc++ includes <cstddef> which isn't normally included and system.h includes <stddef.h> instead. Jakub ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: GCC 12.1 Release Candidate available from gcc.gnu.org 2022-05-01 11:41 ` Jakub Jelinek @ 2022-05-01 15:38 ` Richard Biener 2022-05-01 18:06 ` Jonathan Wakely 0 siblings, 1 reply; 8+ messages in thread From: Richard Biener @ 2022-05-01 15:38 UTC (permalink / raw) To: Jakub Jelinek; +Cc: Iain Sandoe, GCC Development > Am 01.05.2022 um 13:42 schrieb Jakub Jelinek via Gcc <gcc@gcc.gnu.org>: > > On Sun, May 01, 2022 at 11:02:29AM +0100, Iain Sandoe wrote: >> All of these show new fails (presumably because checking is off): >> >> XPASS: c-c++-common/goacc/kernels-decompose-pr100400-1-2.c -std=c++98 (internal compiler error) >> FAIL: c-c++-common/goacc/kernels-decompose-pr100400-1-2.c -std=c++98 (test for excess errors) >> XPASS: c-c++-common/goacc/kernels-decompose-pr100400-1-2.c -std=c++14 (internal compiler error) >> FAIL: c-c++-common/goacc/kernels-decompose-pr100400-1-2.c -std=c++14 (test for excess errors) >> XPASS: c-c++-common/goacc/kernels-decompose-pr100400-1-2.c -std=c++17 (internal compiler error) >> FAIL: c-c++-common/goacc/kernels-decompose-pr100400-1-2.c -std=c++17 (test for excess errors) >> XPASS: c-c++-common/goacc/kernels-decompose-pr100400-1-2.c -std=c++20 (internal compiler error) >> FAIL: c-c++-common/goacc/kernels-decompose-pr100400-1-2.c -std=c++20 (test for excess errors) > > We can live with that for 12.1. > >> earlier x86 darwin is particularly noisy test-wise because there seem to be a lot of newer AVX512 tests >> that do not check for support from the assembler etc. > > That would be nice to fix for 12.2, can you file a PR with a list? > >> However from Darwin12+ (macOS 10.8) we expect to be able to bootstrap with the host clang, but: >> >> Not OK: >> x86_64-darwin{12..15} FAIL to bootstrap with host clang, this is a regression. >> >> the reason is that "gcc/analyzer/region-model.cc” uses initializer_lists, and it seems that <initializer_list> >> is not transitively included by any used headers for _LIBCPP_VERSION < 4000. I fixed that locally by >> adding initializer_list into system.h (and adding INCLUDE_INITIALIZER_LIST to the top of >> gcc/analyzer/region-model.cc) >> - with that change those versions do bootstrap and test OK*** > > From what I can see, with libstdc++ it works because <utility> which is > included by system.h includes <initializer_list>. > If I rename initializer_list in analyzer/region-model.ii to initializer_listx, I > also get: > ../../gcc/analyzer/region-model.cc: In function ‘void ana::selftest::test_binop_svalue_folding()’: > ../../gcc/analyzer/region-model.cc:4966:48: error: deducing from brace-enclosed initializer list requires ‘#include <initializer_list>’ > 4508 | > +++ |+#include <initializer_list> > 4509 | static void > ...... > 4966 | for (auto op : {BIT_IOR_EXPR, TRUTH_OR_EXPR}) > | ^ > ../../gcc/analyzer/region-model.cc:4978:49: error: deducing from brace-enclosed initializer list requires ‘#include <initializer_list>’ > 4978 | for (auto op : {BIT_AND_EXPR, TRUTH_AND_EXPR}) > | ^ > > I think we have 2 options, one is do what you wrote above, > INCLUDE_INITIALIZER_LIST defined before system.h to get #include <initializer_list>. > The other option is just to include that unconditionally, it is a very small > header. For libstdc++ it will make no difference as it is included anyway > and the header is really small there, libc++ includes <cstddef> which isn't > normally included and system.h includes <stddef.h> instead. I’d say unconditionally would be OK. I suppose the chance that any host C++ is good enough to build GCC as-is but fails to provide <initializer_list> is zero? I’d be OK to do this change without a new RC even. Richard. > > Jakub > ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: GCC 12.1 Release Candidate available from gcc.gnu.org 2022-05-01 15:38 ` Richard Biener @ 2022-05-01 18:06 ` Jonathan Wakely 0 siblings, 0 replies; 8+ messages in thread From: Jonathan Wakely @ 2022-05-01 18:06 UTC (permalink / raw) To: Richard Biener; +Cc: Jakub Jelinek, GCC Development, Iain Sandoe On Sun, 1 May 2022, 16:39 Richard Biener via Gcc, <gcc@gcc.gnu.org> wrote: > > > > Am 01.05.2022 um 13:42 schrieb Jakub Jelinek via Gcc <gcc@gcc.gnu.org>: > > > > On Sun, May 01, 2022 at 11:02:29AM +0100, Iain Sandoe wrote: > >> All of these show new fails (presumably because checking is off): > >> > >> XPASS: c-c++-common/goacc/kernels-decompose-pr100400-1-2.c -std=c++98 > (internal compiler error) > >> FAIL: c-c++-common/goacc/kernels-decompose-pr100400-1-2.c -std=c++98 > (test for excess errors) > >> XPASS: c-c++-common/goacc/kernels-decompose-pr100400-1-2.c -std=c++14 > (internal compiler error) > >> FAIL: c-c++-common/goacc/kernels-decompose-pr100400-1-2.c -std=c++14 > (test for excess errors) > >> XPASS: c-c++-common/goacc/kernels-decompose-pr100400-1-2.c -std=c++17 > (internal compiler error) > >> FAIL: c-c++-common/goacc/kernels-decompose-pr100400-1-2.c -std=c++17 > (test for excess errors) > >> XPASS: c-c++-common/goacc/kernels-decompose-pr100400-1-2.c -std=c++20 > (internal compiler error) > >> FAIL: c-c++-common/goacc/kernels-decompose-pr100400-1-2.c -std=c++20 > (test for excess errors) > > > > We can live with that for 12.1. > > > >> earlier x86 darwin is particularly noisy test-wise because there seem > to be a lot of newer AVX512 tests > >> that do not check for support from the assembler etc. > > > > That would be nice to fix for 12.2, can you file a PR with a list? > > > >> However from Darwin12+ (macOS 10.8) we expect to be able to bootstrap > with the host clang, but: > >> > >> Not OK: > >> x86_64-darwin{12..15} FAIL to bootstrap with host clang, this is a > regression. > >> > >> the reason is that "gcc/analyzer/region-model.cc” uses > initializer_lists, and it seems that <initializer_list> > >> is not transitively included by any used headers for _LIBCPP_VERSION < > 4000. I fixed that locally by > >> adding initializer_list into system.h (and adding > INCLUDE_INITIALIZER_LIST to the top of > >> gcc/analyzer/region-model.cc) > >> - with that change those versions do bootstrap and test OK*** > > > > From what I can see, with libstdc++ it works because <utility> which is > > included by system.h includes <initializer_list>. > > If I rename initializer_list in analyzer/region-model.ii to > initializer_listx, I > > also get: > > ../../gcc/analyzer/region-model.cc: In function ‘void > ana::selftest::test_binop_svalue_folding()’: > > ../../gcc/analyzer/region-model.cc:4966:48: error: deducing from > brace-enclosed initializer list requires ‘#include <initializer_list>’ > > 4508 | > > +++ |+#include <initializer_list> > > 4509 | static void > > ...... > > 4966 | for (auto op : {BIT_IOR_EXPR, TRUTH_OR_EXPR}) > > | ^ > > ../../gcc/analyzer/region-model.cc:4978:49: error: deducing from > brace-enclosed initializer list requires ‘#include <initializer_list>’ > > 4978 | for (auto op : {BIT_AND_EXPR, TRUTH_AND_EXPR}) > > | ^ > > > > I think we have 2 options, one is do what you wrote above, > > INCLUDE_INITIALIZER_LIST defined before system.h to get #include > <initializer_list>. > > The other option is just to include that unconditionally, it is a very > small > > header. For libstdc++ it will make no difference as it is included > anyway > > and the header is really small there, libc++ includes <cstddef> which > isn't > > normally included and system.h includes <stddef.h> instead. > > I’d say unconditionally would be OK. I suppose the chance that any host > C++ is good enough to build GCC as-is but fails to provide > <initializer_list> is zero? > Yes, definitely. > I’d be OK to do this change without a new RC even. > > Richard. > > > > > Jakub > > > ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: GCC 12.1 Release Candidate available from gcc.gnu.org 2022-04-29 14:34 GCC 12.1 Release Candidate available from gcc.gnu.org Jakub Jelinek 2022-05-01 10:02 ` Iain Sandoe @ 2022-05-02 11:49 ` Boris Kolpackov 2022-05-02 12:26 ` Marc Glisse 1 sibling, 1 reply; 8+ messages in thread From: Boris Kolpackov @ 2022-05-02 11:49 UTC (permalink / raw) To: Jakub Jelinek; +Cc: gcc Jakub Jelinek <jakub@redhat.com> writes: > The first release candidate for GCC 12.1 is available [...] There is an unfixed bogus warning that is a regression in 12 and that I think will have a pretty wide effect (any code that assigns/appends a 1-char string literal to std::string): https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105329 For example, in my relatively small codebase I had about 20 instances of this warning. Seeing that it's enabled as part of -Wall (not just -Wextra), I believe there will be a lot of grumpy users. There is a proposed work around in this (duplicate) bug that looks pretty simple: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104336 Perhaps it makes sense to consider it? ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: GCC 12.1 Release Candidate available from gcc.gnu.org 2022-05-02 11:49 ` Boris Kolpackov @ 2022-05-02 12:26 ` Marc Glisse 2022-05-02 15:42 ` Jonathan Wakely 0 siblings, 1 reply; 8+ messages in thread From: Marc Glisse @ 2022-05-02 12:26 UTC (permalink / raw) To: Boris Kolpackov; +Cc: gcc On Mon, 2 May 2022, Boris Kolpackov wrote: > Jakub Jelinek <jakub@redhat.com> writes: > >> The first release candidate for GCC 12.1 is available [...] > > There is an unfixed bogus warning that is a regression in 12 > and that I think will have a pretty wide effect (any code > that assigns/appends a 1-char string literal to std::string): > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105329 > > For example, in my relatively small codebase I had about 20 > instances of this warning. Seeing that it's enabled as part > of -Wall (not just -Wextra), I believe there will be a lot > of grumpy users. > > There is a proposed work around in this (duplicate) bug that > looks pretty simple: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104336 > > Perhaps it makes sense to consider it? Please no, that workaround looks like a fragile hack (basically writing a+b-a to obfuscate b) that may break if you look at it sideways and likely makes the generated code a bit worse. Besides, we should take it as a hint that user code is also likely to trigger the warning by accident. IMO there are several ways to make progress on this in parallel: * improve the optimizer (as investigated by Andrew) * tweak the warning so it becomes either cleverer or less eager (maybe even use the fact that this special case is in a system header? that should be a last resort though) * battle that has already been lost, no need to rehash it: --- a/gcc/c-family/c.opt +++ b/gcc/c-family/c.opt @@ -1450,3 +1450,3 @@ Warn when a declaration has duplicate const, volatile, restrict or _Atomic speci Wrestrict -C ObjC C++ ObjC++ Var(warn_restrict) Warning LangEnabledBy(C ObjC C++ ObjC++, Wall) +C ObjC C++ ObjC++ Var(warn_restrict) Warning LangEnabledBy(C ObjC C++ ObjC++, Wextra) Warn when an argument passed to a restrict-qualified parameter aliases with Or admit that --- a/gcc/doc/invoke.texi +++ b/gcc/doc/invoke.texi @@ -5729,4 +5729,3 @@ by this option and not enabled by the latter and vice versa. This enables all the warnings about constructions that some users -consider questionable, and that are easy to avoid (or modify to -prevent the warning), even in conjunction with macros. This also +consider questionable. This also enables some language-specific warnings described in @ref{C++ Dialect -- Marc Glisse ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: GCC 12.1 Release Candidate available from gcc.gnu.org 2022-05-02 12:26 ` Marc Glisse @ 2022-05-02 15:42 ` Jonathan Wakely 0 siblings, 0 replies; 8+ messages in thread From: Jonathan Wakely @ 2022-05-02 15:42 UTC (permalink / raw) To: gcc; +Cc: Boris Kolpackov, Marc Glisse On Mon, 2 May 2022, 13:26 Marc Glisse via Gcc, <gcc@gcc.gnu.org> wrote: > On Mon, 2 May 2022, Boris Kolpackov wrote: > > > Jakub Jelinek <jakub@redhat.com> writes: > > > >> The first release candidate for GCC 12.1 is available [...] > > > > There is an unfixed bogus warning that is a regression in 12 > > and that I think will have a pretty wide effect (any code > > that assigns/appends a 1-char string literal to std::string): > > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105329 > > > > For example, in my relatively small codebase I had about 20 > > instances of this warning. Seeing that it's enabled as part > > of -Wall (not just -Wextra), I believe there will be a lot > > of grumpy users. > > > > There is a proposed work around in this (duplicate) bug that > > looks pretty simple: > > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104336 > > > > Perhaps it makes sense to consider it? > > Please no, that workaround looks like a fragile hack (basically writing > a+b-a to obfuscate b) that may break if you look at it sideways and likely > makes the generated code a bit worse. Agreed. And it makes the variable names completely misleading (although that would be easy to fix). ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2022-05-02 15:42 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2022-04-29 14:34 GCC 12.1 Release Candidate available from gcc.gnu.org Jakub Jelinek 2022-05-01 10:02 ` Iain Sandoe 2022-05-01 11:41 ` Jakub Jelinek 2022-05-01 15:38 ` Richard Biener 2022-05-01 18:06 ` Jonathan Wakely 2022-05-02 11:49 ` Boris Kolpackov 2022-05-02 12:26 ` Marc Glisse 2022-05-02 15:42 ` Jonathan Wakely
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).