GCC 12.1 Release Candidate available from gcc.gnu.org

GCC 12.1 Release Candidate available from gcc.gnu.org

[Jakub Jelinek]

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.

Re: GCC 12.1 Release Candidate available from gcc.gnu.org

[Iain Sandoe]

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…

Re: GCC 12.1 Release Candidate available from gcc.gnu.org

[Jakub Jelinek]

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

Re: GCC 12.1 Release Candidate available from gcc.gnu.org

[Richard Biener]

> 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
> 

Re: GCC 12.1 Release Candidate available from gcc.gnu.org

[Jonathan Wakely]

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
> >
>

Re: GCC 12.1 Release Candidate available from gcc.gnu.org

[Boris Kolpackov]

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?

Re: GCC 12.1 Release Candidate available from gcc.gnu.org

[Marc Glisse]

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

Re: GCC 12.1 Release Candidate available from gcc.gnu.org

[Jonathan Wakely]

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).