[Bug libstdc++/100982] wrong constraint in std::optional::operator=

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100982

--- Comment #2 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Jonathan Wakely
:

https://gcc.gnu.org/g:e198d93d49f89a3b69f9b4e4c305f9f8b511027a

commit r11-8560-ge198d93d49f89a3b69f9b4e4c305f9f8b511027a
Author: Jonathan Wakely 
Date:   Wed Jun 9 11:03:15 2021 +0100

libstdc++: Fix constraint on std::optional assignment [PR 100982]

libstdc++-v3/ChangeLog:

PR libstdc++/100982
* include/std/optional (optional::operator=(const optional&)):
Fix value category used in is_assignable check.
* testsuite/20_util/optional/assignment/100982.cc: New test.

(cherry picked from commit b3fce1bd45f72cc9e55fb7431762e92e30fefcf1)

[Bug libstdc++/98842] optional's spaceship operations generates wrong code when operator== is not present

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98842

--- Comment #4 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Jonathan Wakely
:

https://gcc.gnu.org/g:4f11586945fffd0ff808c16f2f341f9e85d83749

commit r11-8559-g4f11586945fffd0ff808c16f2f341f9e85d83749
Author: Jonathan Wakely 
Date:   Mon Jun 7 13:02:15 2021 +0100

libstdc++: Constrain three-way comparison for std::optional [PR 98842]

The operator<=>(const optional&, const U&) operator is supposed to be
constrained with three_way_comparable_with so that it can only be
used when T and U are weakly-equality-comparable and also three-way
comparable.

Adding that constrain completely breaks std::optional comparisons,
because it causes constraint recursion. To avoid that, an additional
check that U is not a specialization of std::optional is needed. That
appears to be a defect in the standard and should be reported to LWG.

Signed-off-by: Jonathan Wakely 

libstdc++-v3/ChangeLog:

PR libstdc++/98842
* include/std/optional (operator<=>(const optional& const U&)):
Add missing constraint and add workaround for template
recursion.
* testsuite/20_util/optional/relops/three_way.cc: Check that
type without equality comparison cannot be compared when wrapped
in std::optional.

(cherry picked from commit adec14811714e22a6c1f7f0199adc05370f0d8b0)

[Bug libstdc++/100824] ranges::size should treat the subexpression as an lvalue

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100824

--- Comment #12 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Jonathan Wakely
:

https://gcc.gnu.org/g:2ba1680d3e9f3bb99783519a08eed6435f131045

commit r11-8558-g2ba1680d3e9f3bb99783519a08eed6435f131045
Author: Jonathan Wakely 
Date:   Sat Jun 5 11:42:01 2021 +0100

libstdc++: Fix return type of ranges::ssize for 128-bit integer [PR 100824]

Signed-off-by: Jonathan Wakely 

libstdc++-v3/ChangeLog:

PR libstdc++/100824
* include/bits/ranges_base.h (_SSize): Return signed type.
* testsuite/std/ranges/access/ssize.cc: Check with __int128.

(cherry picked from commit 96963713f6a648a0ed890450e02ebdd8ff583b14)

[Bug libstdc++/100824] ranges::size should treat the subexpression as an lvalue

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100824

--- Comment #11 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Jonathan Wakely
:

https://gcc.gnu.org/g:950535915868cd0b7f3dbad4321de913f01bddfc

commit r11-8556-g950535915868cd0b7f3dbad4321de913f01bddfc
Author: Jonathan Wakely 
Date:   Fri Jun 4 20:25:39 2021 +0100

libstdc++: Fix helper concept for ranges::data [PR 100824]

We need to decay the result of t.data() before checking if it's a
pointer.

Signed-off-by: Jonathan Wakely 

libstdc++-v3/ChangeLog:

PR libstdc++/100824
* include/bits/ranges_base.h (__member_data): Use __decay_copy.
* testsuite/std/ranges/access/data.cc: Add testcase from PR.

(cherry picked from commit 3e5f2425f80aedd00f28235022a2755eb46f310d)

[Bug libstdc++/100824] ranges::size should treat the subexpression as an lvalue

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100824

--- Comment #10 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Jonathan Wakely
:

https://gcc.gnu.org/g:a842cb9c255f66f38ddd36b10c60920ed5f189de

commit r11-8555-ga842cb9c255f66f38ddd36b10c60920ed5f189de
Author: Jonathan Wakely 
Date:   Fri Jun 4 15:59:38 2021 +0100

libstdc++: Fix value categories used by ranges access CPOs [PR 100824]

The implementation of P2091R0 was incomplete, so that some range access
CPOs used perfect forwarding where they should not. This fixes it by
consistently operating on lvalues.

Some additional changes that are not necessary to fix the bug:

Modify the __as_const helper to simplify its usage. Instead of deducing
the value category from its argument, and requiring callers to forward
the argument as the correct category, add a non-deduced template
parameter which is used for the value category and accept the argument
as an lvalue. This means callers say __as_const(t) instead of
__as_const(std::forward(t)).

Always use an lvalue reference type as the template argument for the
_S_noexcept helpers, so that we only instantiate one specialization for
lvalues and rvalues of the same type.

Move some helper concepts and functions from namespace std::__detail
to ranges::__cust_access, to be consistent with the ranges::begin CPO.
This ensures that the __adl_begin concept and the _Begin::operator()
function are in the same namespace, so unqualified lookup is consistent
and the poison pills for begin are visible to both.

Simplified static assertions for arrays, because the expression a+0 is
already ill-formed for an array of incomplete type.

Signed-off-by: Jonathan Wakely 

libstdc++-v3/ChangeLog:

PR libstdc++/100824
* include/bits/iterator_concepts.h (__detail::__decay_copy)
(__detail::__member_begin, __detail::__adl_begin): Move to
namespace ranges::__cust_access.
(__detail::__ranges_begin): Likewise, and rename to __begin.
Remove redundant static assertion.
* include/bits/ranges_base.h (_Begin, _End, _RBegin, _REnd):
Use lvalue in noexcept specifier.
(__as_const): Add non-deduced parameter for value category.
(_CBegin, _CEnd, _CRBegin, _CREnd, _CData): Adjust uses of
__as_const.
(__member_size, __adl_size, __member_empty, __size0_empty):
(__eq_iter_empty, __adl_data): Use lvalue objects in
requirements.
(__sentinel_size): Likewise. Add check for conversion to
unsigned-like.
(__member_data): Allow non-lvalue types to satisfy the concept,
but use lvalue object in requirements.
(_Size, _SSize): Remove forwarding to always use an lvalue.
(_Data): Likewise. Add static assertion for arrays.
* testsuite/std/ranges/access/cdata.cc: Adjust expected
behaviour for rvalues. Add negative tests for ill-formed
expressions.
* testsuite/std/ranges/access/data.cc: Likewise.
* testsuite/std/ranges/access/empty.cc: Adjust expected
behaviour for rvalues.
* testsuite/std/ranges/access/size.cc: Likewise.

(cherry picked from commit ee9548b36a7f17e8a63585b58f340c93dcba95d8)

[Bug middle-end/100944] missing -Warray-bounds accessing a flexible array member of a nested struct

[segher at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100944

Segher Boessenkool  changed:

   What|Removed |Added

 CC||segher at gcc dot gnu.org

--- Comment #1 from Segher Boessenkool  ---
Even with -std=c11 and similar, although it should complain earlier then:
structures with a flexible array member are not allowed as members of
structures
or as elements of arrays in standard C (6.7.2.1/3).  Or do I read that wrong?

[Bug c++/101029] [10/11/12 regression] unexpected error: non-constant condition for static assertion in gcc 10/11, but not 9 (clang also fine)

[jason at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101029

Jason Merrill  changed:

   What|Removed |Added

   Priority|P3  |P2
Summary|unexpected error:   |[10/11/12 regression]
   |non-constant condition for  |unexpected error:
   |static assertion in gcc |non-constant condition for
   |10/11, but not 9 (clang |static assertion in gcc
   |also fine)  |10/11, but not 9 (clang
   ||also fine)

[Bug d/100999] d: foreach over a tuple doesn't work on 16-bit targets

[ibuclaw at gdcproject dot org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100999

Iain Buclaw  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from Iain Buclaw  ---
Fix committed

[Bug d/100999] d: foreach over a tuple doesn't work on 16-bit targets

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100999

--- Comment #3 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Iain Buclaw
:

https://gcc.gnu.org/g:ecbe8af2c38e22d3db99a57e21531fd523700492

commit r10-9910-gecbe8af2c38e22d3db99a57e21531fd523700492
Author: Iain Buclaw 
Date:   Fri Jun 11 19:33:07 2021 +0200

d: foreach over a tuple doesn't work on 16-bit targets (PR100999)

Improves semantic passes in the front-end around the `foreach' and
`static foreach' statements to be more resilient to compiling in a
minimal D runtime environment.  Checking of the index type has been
improved as well so now there won't be needless compiler errors when
using 8 or 16-bit integers as index types when the size fits the
expected loop range.

gcc/d/ChangeLog:

PR d/100999
* dmd/cond.c (lowerArrayAggregate): Run CTFE interpret on foreach
input range.
(createTupleType): Don't generate typeinfo when disabled.
(lowerNonArrayAggregate): Suppress errors when running type
semantic.
(staticForeachPrepare): Don't run CTFE interpret from here.
* dmd/dinterpret.c (ctfeInterpret): Add more shortcut cases.
* dmd/expression.c (resolvePropertiesX): Remove early error.
(Expression::checkPostblit): Don't generate typeinfo when type is
missing from library.
* dmd/expressionsem.c (ExpressionSemanticVisitor): Set type of
DotTemplateExp as void.
* dmd/statementsem.c (StatementSemanticVisitor::declareVariable):
Don't override index type.
(StatementSemanticVisitor::makeTupleForeachBody): Check index type
is
integral and index range fits type size.
(StatementSemanticVisitor::visit (ForeachStatement*)): Adjust index
range before testing.

libphobos/ChangeLog:

PR d/100999
* src/std/typecons.d (template Proxy): Check for field or property
functions as the else branch.

gcc/testsuite/ChangeLog:

PR d/100999
* gdc.test/compilable/staticforeach.d: Add new tests.
* gdc.test/fail_compilation/diag16976.d: Likewise.
* gdc.test/fail_compilation/fail117.d: Likewise.
* gdc.test/fail_compilation/fail238_m32.d: Likewise.
* gdc.test/fail_compilation/fail238_m64.d: Likewise.
* gdc.test/fail_compilation/fail7424b.d: Likewise.
* gdc.test/fail_compilation/fail7424c.d: Likewise.
* gdc.test/fail_compilation/fail7424d.d: Likewise.
* gdc.test/fail_compilation/fail7424e.d: Likewise.
* gdc.test/fail_compilation/fail7424f.d: Likewise.
* gdc.test/fail_compilation/fail7424g.d: Likewise.
* gdc.test/fail_compilation/fail7424h.d: Likewise.
* gdc.test/fail_compilation/fail7424i.d: Likewise.
* gdc.test/fail_compilation/fail9766.d: Likewise.
* gdc.test/fail_compilation/ice9406.d: Likewise.
* gdc.test/compilable/extra-files/minimal/object.d: New file.
* gdc.test/compilable/interpret5.d: New test.
* gdc.test/compilable/minimal3.d: New test.
* gdc.test/compilable/test21742.d: New test.
* gdc.test/compilable/test22006.d: New test.
* gdc.test/fail_compilation/b12504.d: New test.
* gdc.test/fail_compilation/fail22006.d: New test.
* gdc.test/fail_compilation/test21927.d: New test.
* gdc.test/fail_compilation/test21939.d: New test.

(cherry picked from commit 68f46862d33707450bdf70cfddd91ae2a12527a8)

[Bug c++/101038] ice in vect_optimize_slp

[dcb314 at hotmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101038

--- Comment #1 from David Binderman  ---
Reduced C++ code is:

typedef char quint8;
typedef struct {
  quint8 green, blue;
} CharPixel;
CharPixel *equalize_equalize_map;
int equalize_i;
void equalize() {
  unsigned low_0, high_0, low_1, high_1;
  for (; equalize_i; ++equalize_i) {
equalize_equalize_map[equalize_i].green =
255 * (equalize_equalize_map[equalize_i].green - low_1) /
(high_1 - low_1);
equalize_equalize_map[equalize_i].blue =
255 * (equalize_equalize_map[equalize_i].blue - low_0) /
(high_0 - low_0);
  }
}

-march=bdver2 not needed, but -O3 is.

[Bug testsuite/101002] Some powerpc tests fail with -mlong-double-64

[segher at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101002

--- Comment #3 from Segher Boessenkool  ---
(In reply to Segher Boessenkool from comment #2)
> The first test is for _Float128.  What goes wrong there?
> 
> For all these tests yo

..u have to figure out what is going wrong.  After that it will
likely be simple for each of them :-)

[Bug testsuite/101002] Some powerpc tests fail with -mlong-double-64

[segher at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101002

--- Comment #2 from Segher Boessenkool  ---
The first test is for _Float128.  What goes wrong there?

For all these tests yo

[Bug target/101023] [11/12 Regression] wrong code with -mstackrealign

[hjl.tools at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101023

H.J. Lu  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #7 from H.J. Lu  ---
A patch is posted at

https://gcc.gnu.org/pipermail/gcc-patches/2021-June/572596.html

[Bug c++/101029] unexpected error: non-constant condition for static assertion in gcc 10/11, but not 9 (clang also fine)

[jason at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101029

Jason Merrill  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |jason at gcc dot gnu.org
 Status|NEW |ASSIGNED

[Bug c++/101038] New: ice in vect_optimize_slp

[dcb314 at hotmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101038

Bug ID: 101038
   Summary: ice in vect_optimize_slp
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

Created attachment 50988
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50988=edit
gzipped C++ source code

The attached C++ code, when compiled by -march=bdver2 and -O3, 
does this:

during GIMPLE pass: vect
/home/dcb34/rpmbuild/BUILD/kolourpaint-21.04.1/imagelib/effects/blitz.cpp: In
fu
nction ‘bool _Z8equalizeR6QImage.part.0(QImage&)’:
/home/dcb34/rpmbuild/BUILD/kolourpaint-21.04.1/imagelib/effects/blitz.cpp:125:6:
 internal compiler error: Segmentation fault
  125 | bool equalize(QImage )
  |  ^~~~
0xfcd5f9 crash_signal(int)
../../trunk.git/gcc/toplev.c:327
0x12a4968 vect_optimize_slp(vec_info*)
../../trunk.git/gcc/tree-vect-slp.c:3626

This code was fine at git hash 91349e57bbfd0101, but had gone wrong by
f8b067056ba5dd53, a few days later.

[Bug target/100085] Bad code for union transfer from __float128 to vector types

[segher at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100085

--- Comment #14 from Segher Boessenkool  ---
We *have* TImode already, but most 128-bit scalars currently use V1TImode.
This often leads to reduced performance because that is not a scalar mode,
does not get all optimisations we have generically for all other integer
scalars.  We have to do a lot of it manually, which is a lot of (combine)
patterns, and we still miss almost all cases.

I am not saying we should remove V1TImode.  I am saying we want to use
plain TImode for scalars, on newer cpus.  On p8 we had V1TImode so that
we could reduce the traffic between the vector register files and the
GPR register file, because that was very costly on p8 (mtvsr* and mfvsr*
were 5 cycles, and mtvsrdd and mfvsrld didn't even exist yet).

Using V1TImode for scalars on p8 was a pretty big win.  It should be a win
again to use TImode on later cpus though.

> And I have grave reservations about the vague plans of small/fringe minority 
> to 
> subset the PowerISA for their convenience.

I don't have reservations about that.  Instead, I battle that with all I can.

[Bug c++/94404] [meta-bug] C++ core issues

[ppalka at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94404
Bug 94404 depends on bug 96560, which changed state.

Bug 96560 Summary: Substitution triggers compile-time error when it shouldn't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96560

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

[Bug c++/96560] Substitution triggers compile-time error when it shouldn't

[ppalka at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96560

Patrick Palka  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED
   Target Milestone|--- |12.0

--- Comment #3 from Patrick Palka  ---
Fixed.

[Bug c++/96560] Substitution triggers compile-time error when it shouldn't

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96560

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Patrick Palka :

https://gcc.gnu.org/g:b0d73a66ae3962fa83309527d85613d72a6aa43d

commit r12-1398-gb0d73a66ae3962fa83309527d85613d72a6aa43d
Author: Patrick Palka 
Date:   Fri Jun 11 16:00:52 2021 -0400

c++: Substitute into function parms in lexical order [PR96560]

This makes tsubst_arg_types substitute into a function's parameter types
in left-to-right instead of right-to-left order, in accordance with DR
1227.

DR 1227
PR c++/96560

gcc/cp/ChangeLog:

* pt.c (tsubst_arg_types): Rearrange so that we substitute into
TYPE_ARG_TYPES in forward order while short circuiting
appropriately.  Adjust formatting.

gcc/testsuite/ChangeLog:

* g++.dg/template/sfinae-dr1227.C: New test.

[Bug target/92469] ICE: output_operand: invalid use of register 'frame' in 7/8/9/10

[hjl.tools at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92469

--- Comment #15 from H.J. Lu  ---
This isn't completely fixed:

[hjl@gnu-clx-1 gcc]$ ./xgcc -B./
/export/gnu/import/git/sources/gcc/gcc/testsuite/gcc.target/i386/pr97032.c -m32
-fdiagnostics-plain-output -O2 -mincoming-stack-boundary=2
-fstack-protector-all -ffat-lto-objects -fno-ident -S -o pr97032.s -mtune=k8
/export/gnu/import/git/sources/gcc/gcc/testsuite/gcc.target/i386/pr97032.c: In
function ??sys_socketcall??:
/export/gnu/import/git/sources/gcc/gcc/testsuite/gcc.target/i386/pr97032.c:14:3:
warning: listing the stack pointer register ??esp?? in a clobber list is
deprecated [-Wdeprecated]
/export/gnu/import/git/sources/gcc/gcc/testsuite/gcc.target/i386/pr97032.c:14:3:
note: the value of the stack pointer after an ??asm?? statement must be the
same as it was before the statement
during RTL pass: final
/export/gnu/import/git/sources/gcc/gcc/testsuite/gcc.target/i386/pr97032.c:21:1:
internal compiler error: output_operand: invalid use of register 'frame'
0xad9216 output_operand_lossage(char const*, ...)
/export/gnu/import/git/sources/gcc/gcc/final.c:3235
0x11b16c4 ix86_print_operand_address_as
/export/gnu/import/git/sources/gcc/gcc/config/i386/i386.c:13698
0xad9531 output_operand(rtx_def*, int)
/export/gnu/import/git/sources/gcc/gcc/final.c:3677
0xada075 output_asm_insn(char const*, rtx_def**)
/export/gnu/import/git/sources/gcc/gcc/final.c:3589
0x170edad output_1175
/export/gnu/import/git/sources/gcc/gcc/config/i386/i386.md:20907
0xadd898 final_scan_insn_1
/export/gnu/import/git/sources/gcc/gcc/final.c:2827
0xaddd6b final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*)
/export/gnu/import/git/sources/gcc/gcc/final.c:2940
0xadde47 final_1
/export/gnu/import/git/sources/gcc/gcc/final.c:1997
0xade9e4 rest_of_handle_final
/export/gnu/import/git/sources/gcc/gcc/final.c:4285
0xade9e4 execute
/export/gnu/import/git/sources/gcc/gcc/final.c:4363
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
[hjl@gnu-clx-1 gcc]$

[Bug libstdc++/101037] std::atomic_flag deadlock on Windows

[bjornsundin02 at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101037

--- Comment #2 from Björn Sundin  ---
Created attachment 50987
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50987=edit
A short ping-pong example program.

The preprocessed file was too large so I attached the original C++ source
instead.

[Bug libstdc++/101037] std::atomic_flag deadlock on Windows

[bjornsundin02 at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101037

--- Comment #1 from Björn Sundin  ---
The preprocessed file was too big. Should I attach the original C++ source or a
compressed version of the preprocessed file instead?

[Bug fortran/100950] ICE in output_constructor_regular_field, at varasm.c:5514

[anlauf at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100950

--- Comment #11 from anlauf at gcc dot gnu.org ---
The variant with typespec and non-constant length is incorrectly rejected:

program p
  integer :: n = 2
  print *, [character(n) :: 'a', 'b']
end

All versions since at least gcc-7 give:

pr100950-z3.f90:3:0:

   print *, [character(n) :: 'a', 'b']

Error: size of variable 'A.1' is too large

Maybe the issue here is somewhere in trans-array.c(gfc_walk_array_constructor),
but that is unrelated to the issue with constant substring length.

[Bug libstdc++/101037] New: std::atomic_flag deadlock on Windows

[bjornsundin02 at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101037

Bug ID: 101037
   Summary: std::atomic_flag deadlock on Windows
   Product: gcc
   Version: 11.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bjornsundin02 at gmail dot com
  Target Milestone: ---

The attached preprocessed file is a "ping-pong" example where two threads take
turns to wait for the other thread using a C++20 std::atomic_flag. I am fairly
certain that the code is correct and should not hang. I tested the program on
Linux (Ubuntu 21.04), where it works as expected every time. On Windows, with a
build from https://winlibs.com/, it more often than not hangs. The program on
Windows is compiled in exactly the same way as on Linux.

The expected behavior is: the program exits within less than a second.
The observed behavior is: sometimes the program exits within less than a
second, but often it hangs without ever returning.

Below is the complete compiler command and output:
> g++ -v -save-temps -std=c++20 -pthread deadlock_debugging.cpp 
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=c:/mingw64/bin/../libexec/gcc/x86_64-w64-mingw32/11.1.1/lto-wrapper.exe
OFFLOAD_TARGET_NAMES=nvptx-none
Target: x86_64-w64-mingw32
Configured with: ../configure
--prefix=/R/winlibs64_stage/inst_gcc-11-20210605/share/gcc
--build=x86_64-w64-mingw32 --host=x86_64-w64-mingw32
--enable-offload-targets=nvptx-none --with-pkgversion='MinGW-W64
x86_64-posix-seh, built by Brecht Sanders' --with-tune=generic
--enable-checking=release --enable-threads=posix --disable-sjlj-exceptions
--disable-libunwind-exceptions 
--disable-serial-configure --disable-bootstrap --enable-host-shared
--enable-plugin --disable-default-ssp --disable-rpath --enable-libstdcxx-pch
--enable-libstdcxx-time=yes --disable-libstdcxx-debug
--disable-version-specific-runtime-libs --with-stabs --disable-symvers
--enable-languages=c,c++,fortran,lto,objc,obj-c++ --disable-gold --disable-nls
--disable-stage1-checking --disable-win32-registry --disable-multilib
--enable-ld --enable-libquadmath --enable-libada --enable-libssp
--enable-libstdcxx --enable-lto --enable-fully-dynamic-string --enable-libgomp
--enable-graphite --enable-mingw-wildcard
--with-mpc=/d/Prog/winlibs64_stage/custombuilt
--with-mpfr=/d/Prog/winlibs64_stage/custombuilt
--with-gmp=/d/Prog/winlibs64_stage/custombuilt
--with-isl=/d/Prog/winlibs64_stage/custombuilt --enable-install-libiberty
--enable-__cxa_atexit --without-included-gettext --with-diagnostics-color=auto
--enable-clocale=generic --with-libiconv --with-system-zlib
--with-build-sysroot=/R/winlibs64_stage/gcc-11-20210605/build_mingw/mingw-w64
CFLAGS=-I/d/Prog/winlibs64_stage/custombuilt/include/libdl-win32
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.1.1 20210605 (MinGW-W64 x86_64-posix-seh, built by Brecht
Sanders) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++20' '-pthread' '-shared-libgcc'
'-mtune=generic' '-march=x86-64' '-dumpdir' 'a-'
 c:/mingw64/bin/../libexec/gcc/x86_64-w64-mingw32/11.1.1/cc1plus.exe -E -quiet
-v -iprefix c:\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/11.1.1/ -D_REENTRANT
-U_REENTRANT deadlock_debugging.cpp -mtune=generic -march=x86-64 -std=c++20
-fpch-preprocess -o a-deadlock_debugging.ii
ignoring duplicate directory
"c:/mingw64/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/11.1.1/../../../../include/c++/11.1.1"
ignoring duplicate directory
"c:/mingw64/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/11.1.1/../../../../include/c++/11.1.1/x86_64-w64-mingw32"
ignoring duplicate directory
"c:/mingw64/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/11.1.1/../../../../include/c++/11.1.1/backward"
ignoring duplicate directory
"c:/mingw64/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/11.1.1/include"
ignoring nonexistent directory
"R:/winlibs64_stage/inst_gcc-11-20210605/share/gcc/include"
ignoring nonexistent directory
"/R/winlibs64_stage/inst_gcc-11-20210605/share/gcc/include"
ignoring duplicate directory
"c:/mingw64/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/11.1.1/include-fixed"
ignoring duplicate directory
"c:/mingw64/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/11.1.1/../../../../x86_64-w64-mingw32/include"
ignoring nonexistent directory "/mingw/include"
#include "..." search starts here:
#include <...> search starts here:

c:\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/11.1.1/../../../../include/c++/11.1.1

c:\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/11.1.1/../../../../include/c++/11.1.1/x86_64-w64-mingw32

c:\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/11.1.1/../../../../include/c++/11.1.1/backward
 c:\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/11.1.1/include
 c:\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/11.1.1/../../../../include
 c:\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/11.1.1/include-fixed

[Bug d/100999] d: foreach over a tuple doesn't work on 16-bit targets

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100999

--- Comment #2 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Iain Buclaw
:

https://gcc.gnu.org/g:a30552af7073aba16af6798a1e6cd0a345b06586

commit r11-8553-ga30552af7073aba16af6798a1e6cd0a345b06586
Author: Iain Buclaw 
Date:   Fri Jun 11 19:33:07 2021 +0200

d: foreach over a tuple doesn't work on 16-bit targets (PR100999)

Improves semantic passes in the front-end around the `foreach' and
`static foreach' statements to be more resilient to compiling in a
minimal D runtime environment.  Checking of the index type has been
improved as well so now there won't be needless compiler errors when
using 8 or 16-bit integers as index types when the size fits the
expected loop range.

gcc/d/ChangeLog:

PR d/100999
* dmd/cond.c (lowerArrayAggregate): Run CTFE interpret on foreach
input range.
(createTupleType): Don't generate typeinfo when disabled.
(lowerNonArrayAggregate): Suppress errors when running type
semantic.
(staticForeachPrepare): Don't run CTFE interpret from here.
* dmd/dinterpret.c (ctfeInterpret): Add more shortcut cases.
* dmd/expression.c (Expression::checkPostblit): Don't generate
typeinfo when type is missing from library.
* dmd/expressionsem.c (resolvePropertiesX): Remove early error.
* dmd/statementsem.c (StatementSemanticVisitor::declareVariable):
Don't override index type.
(StatementSemanticVisitor::makeTupleForeachBody): Check index type
is
integral and index range fits type size.
(StatementSemanticVisitor::visit (ForeachStatement*)): Adjust index
range before testing.

libphobos/ChangeLog:

PR d/100999
* src/std/typecons.d (template Proxy): Check for field or property
functions as the else branch.

gcc/testsuite/ChangeLog:

PR d/100999
* gdc.test/compilable/staticforeach.d: Add new tests.
* gdc.test/fail_compilation/diag16976.d: Likewise.
* gdc.test/fail_compilation/fail117.d: Likewise.
* gdc.test/fail_compilation/fail238_m32.d: Likewise.
* gdc.test/fail_compilation/fail238_m64.d: Likewise.
* gdc.test/fail_compilation/fail7424b.d: Likewise.
* gdc.test/fail_compilation/fail7424c.d: Likewise.
* gdc.test/fail_compilation/fail7424d.d: Likewise.
* gdc.test/fail_compilation/fail7424e.d: Likewise.
* gdc.test/fail_compilation/fail7424f.d: Likewise.
* gdc.test/fail_compilation/fail7424g.d: Likewise.
* gdc.test/fail_compilation/fail7424h.d: Likewise.
* gdc.test/fail_compilation/fail7424i.d: Likewise.
* gdc.test/fail_compilation/fail9766.d: Likewise.
* gdc.test/fail_compilation/ice9406.d: Likewise.
* gdc.test/compilable/extra-files/minimal/object.d: New file.
* gdc.test/compilable/interpret5.d: New test.
* gdc.test/compilable/minimal3.d: New test.
* gdc.test/compilable/test21742.d: New test.
* gdc.test/compilable/test22006.d: New test.
* gdc.test/fail_compilation/b12504.d: New test.
* gdc.test/fail_compilation/fail22006.d: New test.
* gdc.test/fail_compilation/test21927.d: New test.
* gdc.test/fail_compilation/test21939.d: New test.

(cherry picked from commit 68f46862d33707450bdf70cfddd91ae2a12527a8)

[Bug c/101036] New: ICE: in fold_convert_loc, at fold-const.c:2430

[cnsun at uwaterloo dot ca via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101036

Bug ID: 101036
   Summary: ICE: in fold_convert_loc, at fold-const.c:2430
   Product: gcc
   Version: tree-ssa
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: cnsun at uwaterloo dot ca
  Target Milestone: ---

$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/scratch/software/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/12.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /tmp/tmp.GWysxNSsSH-gcc-builder/gcc/configure
--enable-languages=c,c++,lto --enable-checking-yes --enable-multiarch
--prefix=/scratch/software/gcc-trunk --disable-bootstrap
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.0.0 20210610 (experimental) [master revision
:697cc07ce:edec2660ff4890ecf8cc191f7c92cf527de51fe2] (GCC)

$ cat mutant.c
z1_called;
z1() { z1_called++; }
int z1_called[] = z3;

$ gcc-trunk  mutant.c
mutant.c:1:1: warning: data definition has no type or storage class
1 | z1_called;
  | ^
mutant.c:1:1: warning: type defaults to ‘int’ in declaration of ‘z1_called’
[-Wimplicit-int]
mutant.c:2:1: warning: return type defaults to ‘int’ [-Wimplicit-int]
2 | z1() { z1_called++; }
  | ^~
mutant.c:3:5: error: conflicting types for ‘z1_called’; have ‘int[]’
3 | int z1_called[] = z3;
  | ^
mutant.c:1:1: note: previous declaration of ‘z1_called’ with type ‘int’
1 | z1_called;
  | ^
mutant.c:3:19: error: ‘z3’ undeclared here (not in a function); did you mean
‘z1’?
3 | int z1_called[] = z3;
  |   ^~
  |   z1
mutant.c: In function ‘z1’:
mutant.c:2:17: internal compiler error: in fold_convert_loc, at
fold-const.c:2430
2 | z1() { z1_called++; }
  |~^~
0x6c27da fold_convert_loc(unsigned int, tree_node*, tree_node*)
/tmp/tmp.GWysxNSsSH-gcc-builder/gcc/gcc/fold-const.c:2430
0xc3a3fe gimplify_self_mod_expr(tree_node**, gimple**, gimple**, bool,
tree_node*)
/tmp/tmp.GWysxNSsSH-gcc-builder/gcc/gcc/gimplify.c:3202
0xc33e0f gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/tmp/tmp.GWysxNSsSH-gcc-builder/gcc/gcc/gimplify.c:14009
0xc37aea gimplify_stmt(tree_node**, gimple**)
/tmp/tmp.GWysxNSsSH-gcc-builder/gcc/gcc/gimplify.c:6863
0xc3831e gimplify_bind_expr
/tmp/tmp.GWysxNSsSH-gcc-builder/gcc/gcc/gimplify.c:1424
0xc34553 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/tmp/tmp.GWysxNSsSH-gcc-builder/gcc/gcc/gimplify.c:14280
0xc37aea gimplify_stmt(tree_node**, gimple**)
/tmp/tmp.GWysxNSsSH-gcc-builder/gcc/gcc/gimplify.c:6863
0xc390e3 gimplify_body(tree_node*, bool)
/tmp/tmp.GWysxNSsSH-gcc-builder/gcc/gcc/gimplify.c:15324
0xc39531 gimplify_function_tree(tree_node*)
/tmp/tmp.GWysxNSsSH-gcc-builder/gcc/gcc/gimplify.c:15478
0xa8b027 cgraph_node::analyze()
/tmp/tmp.GWysxNSsSH-gcc-builder/gcc/gcc/cgraphunit.c:670
0xa8df51 analyze_functions
/tmp/tmp.GWysxNSsSH-gcc-builder/gcc/gcc/cgraphunit.c:1234
0xa8ea21 symbol_table::finalize_compilation_unit()
/tmp/tmp.GWysxNSsSH-gcc-builder/gcc/gcc/cgraphunit.c:2508
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug d/100999] d: foreach over a tuple doesn't work on 16-bit targets

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100999

--- Comment #1 from CVS Commits  ---
The master branch has been updated by Iain Buclaw :

https://gcc.gnu.org/g:68f46862d33707450bdf70cfddd91ae2a12527a8

commit r12-1396-g68f46862d33707450bdf70cfddd91ae2a12527a8
Author: Iain Buclaw 
Date:   Fri Jun 11 19:33:07 2021 +0200

d: foreach over a tuple doesn't work on 16-bit targets (PR100999)

Improves semantic passes in the front-end around the `foreach' and
`static foreach' statements to be more resilient to compiling in a
minimal D runtime environment.  Checking of the index type has been
improved as well so now there won't be needless compiler errors when
using 8 or 16-bit integers as index types when the size fits the
expected loop range.

gcc/d/ChangeLog:

PR d/100999
* dmd/MERGE: Merge upstream dmd 7a3808254.

libphobos/ChangeLog:

PR d/100999
* src/MERGE: Merge upstream phobos 55bb17543.

[Bug c/101035] New: ICE: in wide_int_to_tree_1, at tree.c:1751

[cnsun at uwaterloo dot ca via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101035

Bug ID: 101035
   Summary: ICE: in wide_int_to_tree_1, at tree.c:1751
   Product: gcc
   Version: tree-ssa
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: cnsun at uwaterloo dot ca
  Target Milestone: ---

$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/scratch/software/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/12.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /tmp/tmp.GWysxNSsSH-gcc-builder/gcc/configure
--enable-languages=c,c++,lto --enable-checking-yes --enable-multiarch
--prefix=/scratch/software/gcc-trunk --disable-bootstrap
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.0.0 20210610 (experimental) [master revision
:697cc07ce:edec2660ff4890ecf8cc191f7c92cf527de51fe2] (GCC)

$ cat mutant.c
__GIMPLE
foo() { t1_1 = __builtin_abs->next; }

$ gcc-trunk -fgimple mutant.c
mutant.c:2:1: warning: return type defaults to ‘int’ [-Wimplicit-int]
2 | foo() { t1_1 = __builtin_abs->next; }
  | ^~~
mutant.c: In function ‘foo’:
mutant.c:2:14: error: base variable or SSA name undeclared before ‘=’ token
2 | foo() { t1_1 = __builtin_abs->next; }
  |  ^
mutant.c:2:14: internal compiler error: in wide_int_to_tree_1, at tree.c:1751
0x7ce2c8 wide_int_to_tree_1
/tmp/tmp.GWysxNSsSH-gcc-builder/gcc/gcc/tree.c:1751
0x1217cd0 wide_int_to_tree(tree_node*, poly_int<1u,
generic_wide_int > > const&)
/tmp/tmp.GWysxNSsSH-gcc-builder/gcc/gcc/tree.c:1863
0x1217cd0 build_int_cst(tree_node*, poly_int<1u, long>)
/tmp/tmp.GWysxNSsSH-gcc-builder/gcc/gcc/tree.c:1503
0x1219918 build_simple_mem_ref_loc(unsigned int, tree_node*)
/tmp/tmp.GWysxNSsSH-gcc-builder/gcc/gcc/tree.c:5174
0x95a5db c_parser_gimple_postfix_expression_after_primary
/tmp/tmp.GWysxNSsSH-gcc-builder/gcc/gcc/c/gimple-parser.c:1834
0x95a5db c_parser_gimple_postfix_expression
/tmp/tmp.GWysxNSsSH-gcc-builder/gcc/gcc/c/gimple-parser.c:1712
0x95b374 c_parser_gimple_binary_expression
/tmp/tmp.GWysxNSsSH-gcc-builder/gcc/gcc/c/gimple-parser.c:922
0x95c66f c_parser_gimple_statement
/tmp/tmp.GWysxNSsSH-gcc-builder/gcc/gcc/c/gimple-parser.c:859
0x95c66f c_parser_gimple_compound_statement
/tmp/tmp.GWysxNSsSH-gcc-builder/gcc/gcc/c/gimple-parser.c:650
0x95c66f c_parser_gimple_compound_statement
/tmp/tmp.GWysxNSsSH-gcc-builder/gcc/gcc/c/gimple-parser.c:381
0x95ea87 c_parser_parse_gimple_body(c_parser*, char*, c_declspec_il,
profile_count)
/tmp/tmp.GWysxNSsSH-gcc-builder/gcc/gcc/c/gimple-parser.c:253
0x94db47 c_parser_declaration_or_fndef
/tmp/tmp.GWysxNSsSH-gcc-builder/gcc/gcc/c/c-parser.c:2533
0x955423 c_parser_external_declaration
/tmp/tmp.GWysxNSsSH-gcc-builder/gcc/gcc/c/c-parser.c:1777
0x955e89 c_parser_translation_unit
/tmp/tmp.GWysxNSsSH-gcc-builder/gcc/gcc/c/c-parser.c:1650
0x955e89 c_parse_file()
/tmp/tmp.GWysxNSsSH-gcc-builder/gcc/gcc/c/c-parser.c:22104
0x9b7245 c_common_parse_file()
/tmp/tmp.GWysxNSsSH-gcc-builder/gcc/gcc/c-family/c-opts.c:1219
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug target/101016] Arm: vld1q polymorphic variants failing with undefined reference to `__ARM_undef` error.

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101016

--- Comment #1 from CVS Commits  ---
The master branch has been updated by SRINATH PARVATHANENI
:

https://gcc.gnu.org/g:b13f297f01c943aa167f7c6eb94bed40dce0d553

commit r12-1395-gb13f297f01c943aa167f7c6eb94bed40dce0d553
Author: Srinath Parvathaneni 
Date:   Fri Jun 11 18:11:58 2021 +0100

arm: Fix polymorphic variants failing with undefined reference to
`__ARM_undef` error.

This patch fixes the issue mentioned in PR101016, which is mve polymorphic
variants
failing at linking with undefined reference to "__ARM_undef" error.

gcc/ChangeLog:

2021-06-11  Srinath Parvathaneni  

PR target/101016
* config/arm/arm_mve.h (__arm_vld1q): Change __ARM_mve_coerce(p0,
int8_t const *) to __ARM_mve_coerce1(p0, int8_t *) in the argument
for
the polymorphic variants matching code.
(__arm_vld1q_z): Likewise.
(__arm_vld2q): Likewise.
(__arm_vld4q): Likewise.
(__arm_vldrbq_gather_offset): Likewise.
(__arm_vldrbq_gather_offset_z): Likewise.

gcc/testsuite/ChangeLog:

2021-06-11  Srinath Parvathaneni  

PR target/101016
* gcc.target/arm/mve/intrinsics/pr101016.c: New test.

[Bug c++/101033] Error message for spelling error in copy assignment operator could be improved

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101033

Jonathan Wakely  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug c++/101033] Error message for spelling error in copy assignment operator could be improved

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101033

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||diagnostic
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2021-06-11

[Bug c++/97202] GCC reports an error: expected unqualified-id before ‘short’

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97202

--- Comment #6 from Jonathan Wakely  ---
If the invalid special member is defined out of the class body, you get another
error:

template
struct F
{
  F();
};

template
inline F::F() { }


101032.C:4:8: error: expected unqualified-id before ‘)’ token
4 |   F();
  |^
101032.C:8:8: error: no declaration matches ‘F::F()’
8 | inline F::F() { }
  |^~~~
101032.C:8:8: note: no functions named ‘F::F()’
101032.C:2:8: note: ‘struct F’ defined here
2 | struct F
  |^

As well as improving the first error (which is the subject of this bug) maybe
the constructor could be parsed as though it had been written correctly, so
that the "no declaration matches" error doesn't happen. Compilation is already
going to fail, we don't need to also complain about the valid function
definition not matching anything.

[Bug c++/97202] GCC reports an error: expected unqualified-id before ‘short’

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97202

Jonathan Wakely  changed:

   What|Removed |Added

 CC||kevin.c.eady at gmail dot com

--- Comment #5 from Jonathan Wakely  ---
*** Bug 101032 has been marked as a duplicate of this bug. ***

[Bug c++/101032] Regression on parser with g++11 using experimental c++20 (compiles under c++17)

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101032

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #2 from Jonathan Wakely  ---
Yes, the constructors are declared like this in the class body:

TypedThreadSafeFunction();
TypedThreadSafeFunction(
napi_threadsafe_function tsFunctionValue);

This is not valid in C++20.

You shouold simply write them like this, which is valid in all versions of C++
and easier to read anyway:

TypedThreadSafeFunction();
TypedThreadSafeFunction(napi_threadsafe_function tsFunctionValue);

*** This bug has been marked as a duplicate of bug 97202 ***

[Bug libstdc++/101034] wrong constraint in std::any's constructor

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101034

Jonathan Wakely  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2021-06-11
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
 Status|UNCONFIRMED |ASSIGNED

[Bug tree-optimization/96392] Optimize x+0.0 if x is an integer

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96392

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Roger Sayle :

https://gcc.gnu.org/g:a761829ae06a754f72ff957cbedb21f4d98fab70

commit r12-1394-ga761829ae06a754f72ff957cbedb21f4d98fab70
Author: Roger Sayle 
Date:   Fri Jun 11 17:42:14 2021 +0100

[PATCH] PR tree-optimization/96392 Optimize x+0.0 if x is an integer

Doh! Wrong patch version.  Sorry for the inconvenience.

2020-06-11  Roger Sayle  

gcc/ChangeLog
PR tree-optimization/96392
* fold-const.h (tree_expr_maybe_real_minus_zero_p): Fix prototype.

[Bug libstdc++/101034] wrong constraint in std::any's constructor

[hewillk at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101034

--- Comment #1 from 康桓瑋  ---
any#L272 has the same typo:

template 
  __emplace_t, initializer_list<_Up>, _Args&&...>
  emplace(initializer_list<_Up> __il, _Args&&... __args)

[Bug tree-optimization/101025] [11 Regression] wrong code at -O3 on x86_64-linux-gnu

[qrzhang at gatech dot edu via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101025

--- Comment #8 from Qirun Zhang  ---
(In reply to Richard Biener from comment #7)
> Fixed on trunk sofar.  Keep more testcases coming ;)  (I have a hunch this
> code has more issues...)

Thanks, Richard. Will do.

[Bug target/100530] [9/10/11/12 Regression] ICE with -g: in add_dwarf_attr with __seg_gs (Alternative address-space) global variable since r8-4385-ga297ccb52e0c894e

[dcb314 at hotmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100530

David Binderman  changed:

   What|Removed |Added

 CC||dcb314 at hotmail dot com

--- Comment #4 from David Binderman  ---
I see this also with the source code for ./gcc.target/i386/pr100936.c
and flag -g:

$ /home/dcb/gcc/results.20210611.asan.ubsan/bin/gcc -c -g
./gcc.target/i386/pr100936.c
./gcc.target/i386/pr100936.c:5:1: internal compiler error: in add_dwarf_attr,
at
 dwarf2out.c:4493
5 | __seg_gs int var;
  | ^~~~
0x88a057 add_dwarf_attr(die_struct*, dw_attr_struct*)
../../trunk.git/gcc/dwarf2out.c:4493

[Bug libstdc++/101034] New: wrong constraint in std::any's constructor

[hewillk at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101034

Bug ID: 101034
   Summary: wrong constraint in std::any's constructor
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hewillk at gmail dot com
  Target Milestone: ---

In any#L208:

template , typename _Mgr = _Manager<_VTp>,
  __any_constructible_t<_VTp, initializer_list<_Up>,
  _Args&&...> = false>
explicit
any(in_place_type_t<_Tp>, initializer_list<_Up> __il, _Args&&... __args)


It should be __any_constructible_t<_VTp, initializer_list<_Up>&, _Args&&...> =
false>.

https://godbolt.org/z/afhTbM3b1

#include 

struct S {
  S(std::initializer_list&, int) {}
};

int main() {
  std::any a(std::in_place_type, {0}, 0);
}

[Bug tree-optimization/96392] Optimize x+0.0 if x is an integer

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96392

--- Comment #1 from CVS Commits  ---
The master branch has been updated by Roger Sayle :

https://gcc.gnu.org/g:5b02ed4b87685c0f7c5da9b46cde3ce56fcfd457

commit r12-1393-g5b02ed4b87685c0f7c5da9b46cde3ce56fcfd457
Author: Roger Sayle 
Date:   Fri Jun 11 17:15:38 2021 +0100

[PATCH] PR tree-optimization/96392 Optimize x+0.0 if x is an integer

The patch implements a missed optimization enhancement.  Under usual
IEEE rules, x+0.0 can't be simplified to x when x might potentially
be an IEEE minus zero (-0.0).  The current logic in the middle-end
checks whether the type of x should honor signed zeros, but with this
patch we introduce tree_expr_maybe_real_minus_zero_p that allows us
to confirm that the value can't possibly be -0.0, for example, the result
of a conversion from an integer type, or the result of fabs (or has a
type that doesn't honor signed zero).

Whilst modifying match.pd, I also converted some additional folding
transformations from "testing the type" to "testing the value".

2020-06-10  Roger Sayle  

gcc/ChangeLog
PR tree-optimization/96392
* fold-const.c (fold_real_zero_addition_p): Take both arguments
of the addition or subtraction, not just the zero.  Use this
other argument in tests for signaling NaNs and signed zeros.
(tree_expr_maybe_real_minus_zero_p): New predicate.
* fold-const.h (fold_real_zero_addition_p): Update prototype.
(tree_expr_maybe_real_minus_zero_p): New function prototype.
* match.pd: Update calls to fold_real_zero_addition_p.
Replace HONOR_NANS with tree_expr_maybe_nan_p.
Replace HONOR_SIGNED_ZEROS with tree_expr_maybe_real_minus_zero_p.
Replace HONOR_SNANS with tree_expr_maybe_signaling_nan_p.
* tree-ssa-reassoc.c (eliminate_using_constants): Update
call to fold_real_zero_addition_p.

gcc/testsuite/ChangeLog
PR tree-optimization/96392
* gcc.dg/pr96392.c: New test.

[Bug tree-optimization/101025] [11 Regression] wrong code at -O3 on x86_64-linux-gnu

[rguenth at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101025

Richard Biener  changed:

   What|Removed |Added

  Known to work||12.0
Summary|[11/12 Regression] wrong|[11 Regression] wrong code
   |code at -O3 on  |at -O3 on x86_64-linux-gnu
   |x86_64-linux-gnu|
  Known to fail|12.0|

--- Comment #7 from Richard Biener  ---
Fixed on trunk sofar.  Keep more testcases coming ;)  (I have a hunch this code
has more issues...)

[Bug tree-optimization/101025] [11/12 Regression] wrong code at -O3 on x86_64-linux-gnu

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101025

--- Comment #6 from CVS Commits  ---
The master branch has been updated by Richard Biener :

https://gcc.gnu.org/g:b8b80b8aa3d9a7abbcb59b651ea5e84c2ea12d0b

commit r12-1392-gb8b80b8aa3d9a7abbcb59b651ea5e84c2ea12d0b
Author: Richard Biener 
Date:   Fri Jun 11 12:06:08 2021 +0200

tree-optimization/101025 - fix store-motion dependence checking

This plugs a hole in store-motion where it fails to perform dependence
checking on conditionally executed but not store-motioned refs.

2021-06-11  Richard Biener  

PR tree-optimization/101025
* tree-ssa-loop-im.c (sm_seq_valid_bb): Make sure to process
all refs that require dependence checking.

* gcc.dg/torture/pr101025.c: New testcase.

[Bug c++/101032] Regression on parser with g++11 using experimental c++20 (compiles under c++17)

[mpolacek at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101032

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #1 from Marek Polacek  ---
Please check if this is a dup of 97202.  If TypedThreadSafeFunction is a
constructor, then remove  to make it work.

[Bug c++/101033] New: Error message for spelling error in copy assignment operator could be improved

[hewillk at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101033

Bug ID: 101033
   Summary: Error message for spelling error in copy assignment
operator could be improved
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hewillk at gmail dot com
  Target Milestone: ---

Consider the following:

https://godbolt.org/z/vfdTq9j3x

class S {
  S& operator=(cont S&);
};

There is a spelling error here, gcc-9 rejects with:

:2:16: error: declaration of 'operator=' as non-function
2 |   S& operator=(cont S&);
  |^~~~

The cursor is accurately positioned on the spelling error, but the error
message of gcc-trunk is:

:2:6: error: declaration of 'operator=' as non-function
2 |   S& operator=(cont S&);
  |  ^~~~

which seems to be a bit distracting, and may increase the cost of debugging.

[Bug c++/101032] New: Regression on parser with g++11 using experimental c++20 (compiles under c++17)

[kevin.c.eady at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101032

Bug ID: 101032
   Summary: Regression on parser with g++11 using experimental
c++20 (compiles under c++17)
   Product: gcc
   Version: 11.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kevin.c.eady at gmail dot com
  Target Milestone: ---

the exact version of GCC: g++ (GCC) 11.1.0

the system type / the options given when GCC was configured/built: this is the
official gcc:11.1.0 docker image

the complete command line that triggers the bug: g++ -Wall -Wextra
-Wno-deprecated -fsyntax-only -save-temps -std=c++20 napi-full.h

the compiler output (error messages, warnings, etc.):
napi-full.h:3305:60: error: expected unqualified-id before ')' token
 3305 | TypedThreadSafeFunction();
  |^
napi-full.h:3307:33: error: expected ')' before 'tsFunctionValue'
 3307 | napi_threadsafe_function tsFunctionValue);
  | ^~~~
  | )
napi-full.h:3306:59: note: to match this '('
 3306 | TypedThreadSafeFunction(
  |   ^
napi-full.h:8276:8: error: no declaration matches
'Napi::TypedThreadSafeFunction::TypedThreadSafeFunction()'
 8276 | inline TypedThreadSafeFunction::
  |^~
napi-full.h:8276:8: note: no functions named
'Napi::TypedThreadSafeFunction::TypedThreadSafeFunction()'
napi-full.h:3175:9: note: 'class Napi::TypedThreadSafeFunction' defined here
 3175 |   class TypedThreadSafeFunction {
  | ^~~
napi-full.h:8283:8: error: no declaration matches
'Napi::TypedThreadSafeFunction::TypedThreadSafeFunction(napi_threadsafe_function)'
 8283 | inline TypedThreadSafeFunction::
  |^~
napi-full.h:8283:8: note: no functions named
'Napi::TypedThreadSafeFunction::TypedThreadSafeFunction(napi_threadsafe_function)'
napi-full.h:3175:9: note: 'class Napi::TypedThreadSafeFunction' defined here
 3175 |   class TypedThreadSafeFunction {
  | ^~~

the preprocessed file (*.i*) that triggers the bug: it is over the 1000 K size
limit, please see
https://drive.google.com/file/d/1oMEjMEuKG7806DlXbfJaHxAzVF3sUTFs/view?usp=sharing
 


note: when using c++17, the file passes the syntax check

[Bug c++/101015] Poor diagnostic for deprecated alias-declaration

[mpolacek at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101015

--- Comment #2 from Marek Polacek  ---
This is because dump_decl does the decoration for TYPE_DECL_ALIAS_P:

1228   if (TYPE_DECL_ALIAS_P (t)
1229   && (flags & TFF_DECL_SPECIFIERS
1230   || flags & TFF_CLASS_KEY_OR_ENUM))
1231 {
1232   pp_cxx_ws_string (pp, "using");
1233   dump_decl (pp, DECL_NAME (t), flags);
1234   pp_cxx_whitespace (pp);
1235   pp_cxx_ws_string (pp, "=");
1236   pp_cxx_whitespace (pp);
1237   dump_type (pp, (DECL_ORIGINAL_TYPE (t)
1238   ? DECL_ORIGINAL_TYPE (t) : TREE_TYPE (t)),
1239  flags);

A way around it would be to disable TYPE_DECL_ALIAS_P temporarily for the
warning:

--- a/gcc/cp/decl2.c
+++ b/gcc/cp/decl2.c
@@ -5519,7 +5519,16 @@ cp_warn_deprecated_use (tree decl, tsubst_flags_t
complain)
}
 }
   else
-warned = warn_deprecated_use (decl, NULL_TREE);
+{
+  // XXX alias_type_or_template_p?
+  const bool using_p = (TREE_CODE (decl) == TYPE_DECL
+   && TYPE_DECL_ALIAS_P (decl));
+  if (using_p)
+   TYPE_DECL_ALIAS_P (decl) = false;
+  warned = warn_deprecated_use (decl, NULL_TREE);
+  if (using_p)
+   TYPE_DECL_ALIAS_P (decl) = true;
+}

   return warned;
 }

and then we get:

101015.C:7:8: warning: ‘A::bad’ is deprecated [-Wdeprecated-declarations]
7 | A::bad j = 0;
  |^
101015.C:3:9: note: declared here
3 |   using bad [[deprecated]] = int;
  | ^~~

But maybe that's too ugly a hack.

[Bug fortran/100948] [12 Regression] ICE in gfc_conv_expr_val, at fortran/trans-expr.c:9069

[jrfsousa at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100948

--- Comment #4 from José Rui Faustino de Sousa  ---
I am looking into this.

I think I already have a patch for the ICE, but there are further problems
which I am trying to solve.

Best regards,
José Rui

[Bug target/99939] CMSE: -march=armv8.1-m.main+mve does not support CMSE correctly.

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99939

--- Comment #1 from CVS Commits  ---
The master branch has been updated by SRINATH PARVATHANENI
:

https://gcc.gnu.org/g:c5ed0148347beea1bd34795de146a2454c36

commit r12-1391-gc5ed0148347beea1bd34795de146a2454c36
Author: Srinath Parvathaneni 
Date:   Fri Jun 11 15:56:37 2021 +0100

arm: Fix the mve multilib for the broken cmse support (pr99939).

The current CMSE support in the multilib build for
"-march=armv8.1-m.main+mve -mfloat-abi=hard -mfpu=auto" is broken
as specified in PR99939 and this patch fixes the issue.

gcc/testsuite/ChangeLog:

2021-06-11  Srinath Parvathaneni  

PR target/99939
* gcc.target/arm/cmse/cmse-18.c: Add separate scan-assembler
directives check for target is v8.1-m.main+mve or not before
comparing the assembly output.
* gcc.target/arm/cmse/cmse-20.c: New test.

libgcc/ChangeLog:

2021-06-11  Srinath Parvathaneni  

PR target/99939
* config/arm/cmse_nonsecure_call.S: Add __ARM_FEATURE_MVE
macro.
* config/arm/t-arm: To link cmse.o and cmse_nonsecure_call.o
on passing -mcmse option.

[Bug target/101023] [11/12 Regression] wrong code with -mstackrealign

[hjl.tools at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101023

H.J. Lu  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |hjl.tools at gmail dot 
com

--- Comment #6 from H.J. Lu  ---
Created attachment 50986
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50986=edit
A patch

[Bug target/101022] rs6000: __builtin_altivec_vcmpequt expands to wrong pattern

[wschmidt at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101022

--- Comment #4 from Bill Schmidt  ---
Hi Carl -- while you're in there, can you please remove these?

+BU_P10_OVERLOAD_2 (VRLQ, "vrlq")   
+BU_P10_OVERLOAD_2 (VSLQ, "vslq")   
+BU_P10_OVERLOAD_2 (VSRQ, "vsrq")   
+BU_P10_OVERLOAD_2 (VSRAQ, "vsraq") 

They aren't used in the overload table, because we already have vec_rl, vec_sl,
vec_sr, and vec_sra that you rightly use.  So these macros don't provide any
other utility.

Sorry I didn't see this sooner.

Thanks!
Bill

[Bug c++/98940] Implement C++23 language features

[jakub at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98940
Bug 98940 depends on bug 100974, which changed state.

Bug 100974 Summary: [C++23] Implement if consteval
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100974

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

[Bug c++/100974] [C++23] Implement if consteval

[jakub at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100974

Jakub Jelinek  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #4 from Jakub Jelinek  ---
Implemented for GCC 12.

[Bug c++/100974] [C++23] Implement if consteval

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100974

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Jakub Jelinek :

https://gcc.gnu.org/g:117c64266405e244da4dae3ae7b60905af63b955

commit r12-1390-g117c64266405e244da4dae3ae7b60905af63b955
Author: Jakub Jelinek 
Date:   Fri Jun 11 15:50:34 2021 +0200

c++: Add C++23 consteval if support - P1938R3 [PR100974]

The following patch implements consteval if support.
There is a new IF_STMT_CONSTEVAL_P flag on IF_STMT and IF_COND is
boolean_false_node to match the non-manifestly constant evaluation
behavior, while constexpr evaluation special-cases it.  Perhaps cleaner
would be to set the condition to __builtin_is_constant_evaluated () call
but we need the IF_STMT_CONSTEVAL_P flag anyway and the IL would be larger.

And I'm not changing the libstdc++ side, where perhaps we could change
std::is_constant_evaluated definition for
 #ifdef __cpp_if_consteval
case to if consteval { return true; } else { return false; }
but we need to keep it defined to __builtin_is_constant_evaluated ()
for C++20 or older.

2021-06-11  Jakub Jelinek  

PR c++/100974
gcc/c-family/
* c-cppbuiltin.c (c_cpp_builtins): Predefine __cpp_if_consteval for
-std=c++2b for P1938R3 consteval if support.
gcc/cp/
* cp-tree.h (struct saved_scope): Add consteval_if_p
member.  Formatting fix for the discarded_stmt comment.
(in_consteval_if_p, IF_STMT_CONSTEVAL_P): Define.
* parser.c (cp_parser_lambda_expression): Temporarily disable
in_consteval_if_p when parsing lambda body.
(cp_parser_selection_statement): Parse consteval if.
* decl.c (struct named_label_entry): Add in_consteval_if member.
(level_for_consteval_if): New function.
(poplevel_named_label_1, check_previous_goto_1, check_goto): Handle
consteval if.
* constexpr.c (cxx_eval_builtin_function_call): Clarify in comment
why CP_BUILT_IN_IS_CONSTANT_EVALUATED needs to *non_constant_p
for !ctx->manifestly_const_eval.
(cxx_eval_conditional_expression): For IF_STMT_CONSTEVAL_P evaluate
condition as if it was __builtin_is_constant_evaluated call.
(potential_constant_expression_1): For IF_STMT_CONSTEVAL_P always
recurse on both branches.
* cp-gimplify.c (genericize_if_stmt): Genericize
IF_STMT_CONSTEVAL_P
as the else branch.
* pt.c (tsubst_expr) : Copy IF_STMT_CONSTEVAL_P.
Temporarily set in_consteval_if_p when recursing on
IF_STMT_CONSTEVAL_P then branch.
(tsubst_lambda_expr): Temporarily disable
in_consteval_if_p when instantiating lambda body.
* call.c (immediate_invocation_p): Return false when
in_consteval_if_p.
gcc/testsuite/
* g++.dg/cpp23/consteval-if1.C: New test.
* g++.dg/cpp23/consteval-if2.C: New test.
* g++.dg/cpp23/consteval-if3.C: New test.
* g++.dg/cpp23/consteval-if4.C: New test.
* g++.dg/cpp23/consteval-if5.C: New test.
* g++.dg/cpp23/consteval-if6.C: New test.
* g++.dg/cpp23/consteval-if7.C: New test.
* g++.dg/cpp23/consteval-if8.C: New test.
* g++.dg/cpp23/consteval-if9.C: New test.
* g++.dg/cpp23/consteval-if10.C: New test.
* g++.dg/cpp23/feat-cxx2b.C: Add __cpp_if_consteval tests.

[Bug tree-optimization/101031] [12 Regression] wrong code at -O2 on x86_64-linux-gnu

[rguenth at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101031

--- Comment #3 from Richard Biener  ---
Simpler IL:

int a;
char b, e;
static char *c = 
static long d;
void f(void);
void __attribute__((noipa)) h() {
  int g = 0;
  for (; g < 2; ++g) {
d = *c;
*c = 1;
b = 0;
  }
  f();
}
void __attribute__((noipa)) f() {
  if (d++)
c = 
  for (; a;)
;
}
int main() {
  h();
  if (b != 0)
__builtin_abort ();
  return 0;
}

we end up with

void h ()
{
  char * c.0_14;
  char _24;
  long int _25;

   [local count: 357878152]:
  c.0_14 = c;
  *c.0_14 = 1;
  b = 0;
  _24 = *c.0_14;
  _25 = (long int) _24;
  d = _25;
  *c.0_14 = 1;
  f (); [tail call]
  return;

[Bug tree-optimization/101031] [12 Regression] wrong code at -O2 on x86_64-linux-gnu

[rguenth at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101031

Richard Biener  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org

--- Comment #2 from Richard Biener  ---
Confirmed, mine.  Not a dup of PR101009.

[Bug target/100217] [11/12 Regression] ICE when building valgrind testsuite with -march=z14 since r11-7552

[jakub at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100217

Jakub Jelinek  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #16 from Jakub Jelinek  ---
Fixed.

[Bug c++/101029] unexpected error: non-constant condition for static assertion in gcc 10/11, but not 9 (clang also fine)

[marxin at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101029

Martin Liška  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #5 from Martin Liška  ---
@Jason: Can you please take a look?

[Bug c++/101029] unexpected error: non-constant condition for static assertion in gcc 10/11, but not 9 (clang also fine)

[marxin at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101029

--- Comment #4 from Martin Liška  ---
Created attachment 50985
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50985=edit
test-case

I see the following issue when not using an optimization level:

$ g++ gcc_issue.cc -c
gcc_issue.cc: In instantiation of ‘struct is_default_constructible’:
gcc_issue.cc:10:8:   required from ‘struct
__and_, int, int>’
gcc_issue.cc:29:57:   required by substitution of ‘template, _U2,
int>::valuebool>::type  > pair::pair() [with _U1 = int; _U2 = int;
typename enable_if<__and_, _U2,
int>::valuebool>::type  = ]’
:126:31:   required from here
gcc_issue.cc:18:43: error: non-constant condition for static assertion
   18 |   static_assert(__is_complete_or_unbounded(_Tp{}));
  | ~~^~~
gcc_issue.cc:18:43:   in ‘constexpr’ expansion of
‘__is_complete_or_unbounded(0).integral_constant<1>::operator
integral_constant<1>::value_type()’
gcc_issue.cc:18:43: internal compiler error: in cxx_eval_call_expression, at
cp/constexpr.c:2701
0x65e879 cxx_eval_call_expression
/home/marxin/Programming/gcc/gcc/cp/constexpr.c:2701
0x9a0489 cxx_eval_constant_expression
/home/marxin/Programming/gcc/gcc/cp/constexpr.c:6232
0x9acc6d cxx_eval_binary_expression
/home/marxin/Programming/gcc/gcc/cp/constexpr.c:3187
0x99f86a cxx_eval_constant_expression
/home/marxin/Programming/gcc/gcc/cp/constexpr.c:6590
0x9a3f47 cxx_eval_outermost_constant_expr
/home/marxin/Programming/gcc/gcc/cp/constexpr.c:7264
0xb955e9 finish_static_assert(tree_node*, tree_node*, unsigned int, bool, bool)
/home/marxin/Programming/gcc/gcc/cp/semantics.c:10306
0xb55ec3 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/marxin/Programming/gcc/gcc/cp/pt.c:18644
0xb55ec3 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/marxin/Programming/gcc/gcc/cp/pt.c:18096
0xb710e9 instantiate_class_template_1
/home/marxin/Programming/gcc/gcc/cp/pt.c:12009
0xb710e9 instantiate_class_template(tree_node*)
/home/marxin/Programming/gcc/gcc/cp/pt.c:12268
0xbbfe17 complete_type(tree_node*)
/home/marxin/Programming/gcc/gcc/cp/typeck.c:143
0xbbfe17 complete_type(tree_node*)
/home/marxin/Programming/gcc/gcc/cp/typeck.c:111
0xb7d116 lookup_member(tree_node*, tree_node*, int, bool, int,
access_failure_info*)
/home/marxin/Programming/gcc/gcc/cp/search.c:1148
0xabbe97 lookup_qualified_name(tree_node*, tree_node*, LOOK_want, bool)
/home/marxin/Programming/gcc/gcc/cp/name-lookup.c:7113
0xb366f9 tsubst_qualified_id
/home/marxin/Programming/gcc/gcc/cp/pt.c:16364
0xb3889b tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
/home/marxin/Programming/gcc/gcc/cp/pt.c:19839
0xb54186 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/marxin/Programming/gcc/gcc/cp/pt.c:19082
0xb54186 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/marxin/Programming/gcc/gcc/cp/pt.c:18096
0xb5bf55 tsubst_template_arg(tree_node*, tree_node*, int, tree_node*)
/home/marxin/Programming/gcc/gcc/cp/pt.c:12286
0xb5bf55 tsubst_template_arg(tree_node*, tree_node*, int, tree_node*)
/home/marxin/Programming/gcc/gcc/cp/pt.c:12274
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.


while -O is fine:

$ g++ gcc_issue.cc -c -O

[Bug tree-optimization/101031] [12 Regression] wrong code at -O2 on x86_64-linux-gnu

[jakub at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101031

Jakub Jelinek  changed:

   What|Removed |Added

 Ever confirmed|0   |1
Summary|wrong code at -O2 on|[12 Regression] wrong code
   |x86_64-linux-gnu|at -O2 on x86_64-linux-gnu
Version|unknown |12.0
   Priority|P3  |P1
   Last reconfirmed||2021-06-11
 CC||jakub at gcc dot gnu.org
   Target Milestone|--- |12.0
 Status|UNCONFIRMED |NEW

[Bug tree-optimization/101031] wrong code at -O2 on x86_64-linux-gnu

[qrzhang at gatech dot edu via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101031

Qirun Zhang  changed:

   What|Removed |Added

 CC||rguenther at suse dot de

--- Comment #1 from Qirun Zhang  ---
My bisection points to g:d1d01a66012a93cc8cb7dafbe1b5ec453e

[Bug tree-optimization/101031] New: wrong code at -O2 on x86_64-linux-gnu

[qrzhang at gatech dot edu via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101031

Bug ID: 101031
   Summary: wrong code at -O2 on x86_64-linux-gnu
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: qrzhang at gatech dot edu
  Target Milestone: ---

It appears to be a recent regression.


$ gcc-trunk -v
Supported LTO compression algorithms: zlib
gcc version 12.0.0 20210611 (experimental) [master revision
336c41dbcb2:00da4bcb67d:36943c6bdd3d3b535b24872bbd802d91ef0c6299] (GCC)


$ gcc-trunk abc.c ; ./a.out
0

$ gcc-trunk -O2 abc.c ; ./a.out
1


$ cat abc.c
int a;
char b, e;
static char *c = 
static long d;
void f(void);
void h() {
  int g = 0;
  for (; g < 2; ++g) {
d = *c;
*c = 1;
b = 0;
  }
  f();
}
void f() {
  if (d++)
c = 
  for (; a;)
;
}
int main() {
  h();
  printf("%d\n", b);
}

[Bug testsuite/101020] [12 regression] Several test case failures after r12-1316

[dje at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101020

David Edelsohn  changed:

   What|Removed |Added

   Last reconfirmed||2021-06-11
 CC||dje at gcc dot gnu.org
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #2 from David Edelsohn  ---
I already have a patch for the first part of this.  This should test dg-require
target int128 and float128, not lp64.

[Bug target/101023] [11/12 Regression] wrong code with -mstackrealign

[zsojka at seznam dot cz via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101023

--- Comment #5 from Zdenek Sojka  ---
(In reply to Jakub Jelinek from comment #3)
> Here it is:
> 

Thank you, I probably wouldn't be able to get back to this until next week.

[Bug target/101023] [11/12 Regression] wrong code with -mstackrealign

[jakub at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101023

--- Comment #4 from Jakub Jelinek  ---
// { dg-do run { target lp64 } }
(or ! ia32 if you want).

[Bug target/101023] [11/12 Regression] wrong code with -mstackrealign

[jakub at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101023

Jakub Jelinek  changed:

   What|Removed |Added

 Status|WAITING |NEW
 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
Here it is:

// PR target/101023
// { dg-do run }
// { dg-options "-O2 -mtune=opteron -mstackrealign
--param=hot-bb-frequency-fraction=1" }

struct S {
  __attribute__((noipa)) int m1 ();
  __attribute__((noipa)) void m2 ();
};
struct T {
  __attribute__((noipa)) virtual S m3 ();
};
struct U : T {
  int u;
  __attribute__((noipa)) U (int);
};
int *a;
S *b;
int c;

int
S::m1 ()
{
  return 0;
}

void
S::m2 ()
{
}

S
T::m3 ()
{
  return S ();
}

U::U (int) : u (4)
{
}

__attribute__((noipa)) int
foo ()
{
  if (a)
return 0;
  U d(c);
  S *e = b;
  e->m2 ();
  return e->m1();
}

int
main ()
{
  register int r12 __asm ("r12") = 1;
  register int rax __asm ("rax") = 2;
  asm volatile ("" : "+r" (r12), "+r" (rax));
  foo ();
  asm volatile ("" : "+r" (r12));
  if (r12 != 1)
__builtin_abort ();
}

[Bug fortran/100948] [12 Regression] ICE in gfc_conv_expr_val, at fortran/trans-expr.c:9069

[marxin at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100948

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org,
   ||pault at gcc dot gnu.org

--- Comment #3 from Martin Liška  ---
Likely started with r8-3365-gb89a63b916340ef2.

[Bug tree-optimization/101026] [12 Regression] ICE Segmentation fault since r12-1329-gce670e4faafb296d

[rguenth at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101026

Richard Biener  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #3 from Richard Biener  ---
Fixed.

[Bug fortran/100949] [9/10/11/12 Regression] ICE in gfc_conv_expr_present, at fortran/trans-expr.c:1975

[marxin at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100949

Martin Liška  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2021-06-11
 CC||marxin at gcc dot gnu.org,
   ||vehre at gcc dot gnu.org
 Status|UNCONFIRMED |NEW

--- Comment #1 from Martin Liška  ---
Started with r7-4021-g574284e9c49687d8.

[Bug middle-end/26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)

[rguenth at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
Bug 26163 depends on bug 101028, which changed state.

Bug 101028 Summary: [12 Regression] SLP compile-time hog since 
r12-1329-gce670e4faafb296d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101028

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

[Bug tree-optimization/101028] [12 Regression] SLP compile-time hog since r12-1329-gce670e4faafb296d

[rguenth at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101028

Richard Biener  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from Richard Biener  ---
Fixed.

[Bug tree-optimization/101028] [12 Regression] SLP compile-time hog since r12-1329-gce670e4faafb296d

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101028

--- Comment #1 from CVS Commits  ---
The master branch has been updated by Richard Biener :

https://gcc.gnu.org/g:b9ec5ebb605936684e95b8dcc12e43ba7d8f2cb4

commit r12-1388-gb9ec5ebb605936684e95b8dcc12e43ba7d8f2cb4
Author: Richard Biener 
Date:   Fri Jun 11 13:36:26 2021 +0200

tree-optimization/101028 - fix endless SLP reassoc discovery

This fixes a missing clearing of mismatched lanes from the
fatal fail path in SLP reassoc discovery in the most conservative
way.

2021-06-11  Richard Biener  

PR tree-optimization/101028
* tree-vect-slp.c (vect_build_slp_tree_2): When SLP
reassoc discovery fails fatally, mark appropriate lanes
in matches[] so.

* gcc.dg/pr101028.c: New testcase.

[Bug target/101023] [11/12 Regression] wrong code with -mstackrealign

[hjl.tools at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101023

H.J. Lu  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2021-06-11
 Status|UNCONFIRMED |WAITING

--- Comment #2 from H.J. Lu  ---
(In reply to Zdenek Sojka from comment #0)
> Created attachment 50981 [details]
> auto-reduced testcase (from OpenTTD sources)
> 
> Compiler output:
> $ x86_64-pc-linux-gnu-g++ -O2 -mtune=opteron -mstackrealign
> --param=hot-bb-frequency-fraction=1 testcase.C -S
> 
> The offending code is:
> .L8:
>   pushq   %rbp
>   .cfi_def_cfa_offset 16
>   .cfi_offset 6, -16
>   movq%rsp, %rbp
>   .cfi_def_cfa_register 6
>   movq%r12, -8(%rbp)
>   pushq   %rax
> 
> the "push" overwrites r12 stored just one instruction above; when returning:
>   movq-8(%rbp), %r12
>   xorl%eax, %eax
>   leave
>   .cfi_def_cfa 7, 8
>   ret
> 
> the wrong data is restored to r12
> 
> I wasn't able yet to generate an executable testcase, but I can try to if
> needed. (it shouldn't be that hard, just r12 needs to be used by the caller
> during the call)

Please create a run-time testcase.

[Bug c++/101030] New: gcc internal error with Wconversion

[chrishair85 at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101030

Bug ID: 101030
   Summary: gcc internal error with Wconversion
   Product: gcc
   Version: 11.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chrishair85 at gmail dot com
  Target Milestone: ---

template 
struct jj {
int ii[N ?: 1];
};

int main() {
jj<2> kk;
}

g++ -Wconversion dies with
version 8 to 11

changing template to template makes it work

Regards

:4:18: internal compiler error: Segmentation fault
4 | int ii[N ?: 1];
  |  ^
0x1780bf9 internal_error(char const*, ...)
???:0
0x6d96a9 cp_convert_and_check(tree_node*, tree_node*, int)
???:0
0x6f2dc8 grokdeclarator(cp_declarator const*, cp_decl_specifier_seq*,
decl_context, int, tree_node**)
???:0
0x707dd4 grokfield(cp_declarator const*, cp_decl_specifier_seq*, tree_node*,
bool, tree_node*, tree_node*)
???:0
0x7c0cab c_parse_file()
???:0
0x892aa2 c_common_parse_file()
???:0
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
Compiler returned: 1

Rgds

[Bug c++/101029] unexpected error: non-constant condition for static assertion in gcc 10/11, but not 9 (clang also fine)

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101029

--- Comment #3 from Jonathan Wakely  ---
(In reply to Jim Walker from comment #0)
> /opt/gcc-10.2.0/include/c++/10.2.0/type_traits:918:52: error: non-constant
> condition for static assertion
>   918 |  
> static_assert(std::__is_complete_or_unbounded(__type_identity<_Tp>{}),

This assertion was added for gcc 10, which is why you don't see it with gcc 9.

[Bug c++/101029] unexpected error: non-constant condition for static assertion in gcc 10/11, but not 9 (clang also fine)

[marxin at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101029

Martin Liška  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
 CC||marxin at gcc dot gnu.org
   Last reconfirmed||2021-06-11

--- Comment #2 from Martin Liška  ---
Confirmed, reducing that right now..

[Bug rtl-optimization/101008] ICE: in native_encode_rtx, at simplify-rtx.c:6594 with -O -g

[jakub at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101008

Jakub Jelinek  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #5 from Jakub Jelinek  ---
Fixed, again except for the testcase might be desirable to backport.

[Bug target/101007] [12 Regression] ICE: in extract_insn, at recog.c:2770 (unrecognizable insn) with -mno-sse2

[jakub at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101007

Jakub Jelinek  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #6 from Jakub Jelinek  ---
Fixed, although perhaps desirable to backport (except for the testcase).

[Bug c++/101029] unexpected error: non-constant condition for static assertion in gcc 10/11, but not 9 (clang also fine)

[jim.w.walker at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101029

--- Comment #1 from Jim Walker  ---
Adding version output:

/opt/gcc-10.2.0/bin/g++ --version
g++ (GCC) 10.2.0
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Thanks

[Bug c++/101029] New: unexpected error: non-constant condition for static assertion in gcc 10/11, but not 9 (clang also fine)

[jim.w.walker at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101029

Bug ID: 101029
   Summary: unexpected error: non-constant condition for static
assertion in gcc 10/11, but not 9 (clang also fine)
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jim.w.walker at gmail dot com
  Target Milestone: ---

Created attachment 50984
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50984=edit
Output from -save-temps

A recent change to use unity builds in a product
(https://github.com/couchbase/kv_engine) I work on produced a build failure
which only occurred on our gcc 10.2 builder, it was fine on clang based builds. 

Further debugging of the issue revealed it appears to build fine on gcc 9. This
investigation also revealed I could make an unrelated code change preceding the
use of a templated type, and the code would then compile (details of this are
below). So far my conclusion is that this is an issue in gcc.

When compiled on gcc 10.2 the following error is seen.

/opt/gcc-10.2.0/include/c++/10.2.0/type_traits: In instantiation of ‘struct
std::is_default_constructible’:
/opt/gcc-10.2.0/include/c++/10.2.0/type_traits:143:12:   required from ‘struct
std::__and_,
std::is_default_constructible,
std::__not_,
std::__is_implicitly_default_constructible > > >’
/opt/gcc-10.2.0/include/c++/10.2.0/bits/stl_pair.h:244:59:   required by
substitution of ‘template,
std::is_default_constructible<_U2>,
std::__not_,
std::__is_implicitly_default_constructible<_U2> > > >::value, bool>::type
 > constexpr std::pair::pair() [with _U1 = const
char; _U2 = char; typename
std::enable_if,
std::is_default_constructible<_U2>,
std::__not_,
std::__is_implicitly_default_constructible<_U2> > > >::value, bool>::type
 = ]’
tlm/deps/folly.exploded/include/folly/AtomicHashArray-inl.h:63:19:   required
from here
/opt/gcc-10.2.0/include/c++/10.2.0/type_traits:918:52: error: non-constant
condition for static assertion
  918 |  
static_assert(std::__is_complete_or_unbounded(__type_identity<_Tp>{}),
  |
~~~^~~~

The complete gcc command used (this generated the attached file):

/opt/gcc-10.2.0/bin/g++
-DDESTINATION_ROOT=\"/mnt/Code/couchbase/docker/install\" -DEP_USE_ROCKSDB=1
-DFMT_LOCALE -DGLOG_NO_ABBREVIATED_SEVERITIES -DGOOGLE_GLOG_DLL_DECL=""
-DHAVE_BREAKPAD -DHAVE_JEMALLOC -DHAVE_JEMALLOC_SDALLOCX
-DLIBCOUCHSTORE_NO_VISIBILITY
-DMEMCACHED_VERSION=\"5c9636b6d00bf1f53f1302b7d76eee3ba9c0cd0d\"
-DOBJECT_ROOT=\"/home/couchbase/couchbase/kv_engine\"
-DPRODUCT_VERSION=\"0.0.0-\"
-DSOURCE_ROOT=\"/mnt/Code/couchbase/docker/kv_engine\" -DSPDLOG_COMPILED_LIB
-DSPDLOG_FMT_EXTERNAL -DSPDLOG_LEVEL_NAMES="{\"TRACE\", \"DEBUG\", \"INFO\",
\"WARNING\", \"ERROR\", \"CRITICAL\", \"OFF\"}" -D_FILE_OFFSET_BITS=64
-D_GNU_SOURCE=1 -D_POSIX_PTHREAD_SEMANTICS -D__EXTENSIONS__=1
-D__STDC_FORMAT_MACROS -Dgsl_CONFIG_CONTRACT_VIOLATION_THROWS
-Itlm/deps/prometheus-cpp.exploded/include -Ikv_engine/engines/ep
-Icouchstore/include -I/mnt/Code/couchbase/docker/couchstore/include
-I/mnt/Code/couchbase/docker/kv_engine/include
-I/mnt/Code/couchbase/docker/kv_engine/tracing
-I/mnt/Code/couchbase/docker/kv_engine/utilities
-I/mnt/Code/couchbase/docker/kv_engine
-I/mnt/Code/couchbase/docker/platform/external
-I/mnt/Code/couchbase/docker/platform/include
-Itlm/deps/flatbuffers.exploded/include -Itlm/deps/snappy.exploded/include
-Ikv_engine/engines/ep/src
-I/mnt/Code/couchbase/docker/kv_engine/engines/ep/src
-I/mnt/Code/couchbase/docker/kv_engine/engines/ep
-I/mnt/Code/couchbase/docker/install/include -Ikv_engine/include
-Iplatform/include
-I/mnt/Code/couchbase/docker/kv_engine/engines/ep/tools/couchfile_upgrade
-I/mnt/Code/couchbase/docker/third_party/spdlog/include -isystem
/mnt/Code/couchbase/docker/third_party/HdrHistogram_c/src -isystem
/mnt/Code/couchbase/docker/phosphor/include -isystem
tlm/deps/boost.exploded/include -isystem tlm/deps/json.exploded/include
-isystem /mnt/Code/couchbase/docker/third_party/gsl-lite/include -isystem
tlm/deps/libevent.exploded/include -isystem tlm/deps/openssl.exploded/include
-isystem tlm/deps/jemalloc.exploded/include -isystem
tlm/deps/rocksdb.exploded/include -isystem
/mnt/Code/couchbase/docker/third_party/googletest/googletest/include -isystem
/mnt/Code/couchbase/docker/third_party/googletest/googlemock/include -isystem
tlm/deps/folly.exploded/include -isystem
tlm/deps/double-conversion.exploded/include -isystem
tlm/deps/glog.exploded/include -isystem tlm/deps/fmt.exploded/include -isystem
tlm/deps/zlib.exploded/include -isystem
/home/couchbase/couchbase/tlm/deps/breakpad.exploded/include/breakpad
-fvisibility=hidden -pthread -pedantic -Wall -Wredundant-decls
-Werror=missing-braces -fno-strict-aliasing -Werror=switch -g -fPIC
-ftls-model=initial-exec 

[Bug tree-optimization/101024] Missed min expression at phiopt1

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101024

--- Comment #2 from Andrew Pinski  ---
I have a start but there are a few patterns that need to be moved.
An example is from gcc.dg/tree-ssa/pr66726-4.c:
#define SAT(x) (x < 0 ? 0 : (x > 255 ? 255 : x))

void
foo (unsigned char *p, int i)
{
  *p = SAT (i);
}

[Bug target/101017] ICE: Segmentation fault, convert_memory_address_addr_space_1 with vector_size(32) and target_clone arch=core-avx2/default

[marxin at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101017

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2021-06-11
 CC||marxin at gcc dot gnu.org

--- Comment #1 from Martin Liška  ---
Confirmed.

[Bug tree-optimization/101026] [12 Regression] ICE Segmentation fault since r12-1329-gce670e4faafb296d

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101026

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Richard Biener :

https://gcc.gnu.org/g:fbd8a8041292f2ec2c22be43c8d3e74b37b2bc88

commit r12-1387-gfbd8a8041292f2ec2c22be43c8d3e74b37b2bc88
Author: Richard Biener 
Date:   Fri Jun 11 13:33:17 2021 +0200

tree-optimization/101026 - fix SLP re-association

Since we cannot yet encode the operation in the SLP node itself
but need a representative stmt require an existing one for now
to avoid the need to build a fake GIMPLE stmt.

2021-06-11  Richard Biener  

PR tree-optimization/101026
* tree-vect-slp.c (vect_build_slp_tree_2): Make sure we
have a representative for the associated chain nodes.

* gfortran.dg/pr101026.f: New testcase.

[Bug c++/100897] Symmetric transfer does not prevent stack-overflow for C++20 coroutines

[iains at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100897

--- Comment #3 from Iain Sandoe  ---
(In reply to Leonard von Merzljak from comment #2)
> (In reply to Iain Sandoe from comment #1)

> Thank you for your comment. I tried it out and can confirm that I don't get
> a stack-overflow anymore if I omit -fsanitize=address and use an
> optimization level > 1.

So that's a workaround (on platforms that support indirect tail calls at all).

> If the issues with coroutines and sanitizers are
> already known, then this bug report can be marked as resolved.

For the present, I will leave this open - until (at least) there's a chance to
confirm the hypothesis and determine if the problems are the same ones as
mentioned in other PRs.

> Of course, it would be nice if the stack-overflow would not occur even when
> using an optimization level <= 1, but this probably does not qualify as a
> bug.

Note that the inability to support indirect tail calls is not usually a failing
in GCC - but that some platform ABIs cannot support it (e.g. because they
require initialisation of some per DSO data).

For platforms that support indirect tail calls, it is actually feasible to
support the symmetric transfer at O0 (at least as per my local testing) - the
front end can demand a tailcall "for correctness".  The issue is that
coroutines are not a target-specific implementation, and therefore demanding
the tailcall will cause compile fails on targets that cannot support it.

Of course, one can argue that the code will *probably* fail on those targets if
there is arbitrary recursion needed - but it was decided to not to make this
demand until a solution is found to supporting continuations on all target.

JFTR, my outline sketch for this would be to allocate some area in the
coroutine frame that is reserved for target-specific continuation support, and
then to use a builtin to implement the continuation rather than relying on the
indirect tailcall mechanism.

[Bug rtl-optimization/101008] ICE: in native_encode_rtx, at simplify-rtx.c:6594 with -O -g

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101008

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Jakub Jelinek :

https://gcc.gnu.org/g:4bdcdd8fa8d7659e5a19a930cf2f0332127f8a46

commit r12-1386-g4bdcdd8fa8d7659e5a19a930cf2f0332127f8a46
Author: Jakub Jelinek 
Date:   Fri Jun 11 12:59:43 2021 +0200

simplify-rtx: Fix up simplify_logical_relational_operation for vector IOR
[PR101008]

simplify_relational_operation callees typically return just const0_rtx
or const_true_rtx and then simplify_relational_operation attempts to fix
that up if the comparison result has vector mode, or floating mode,
or punt if it has scalar mode and vector mode operands (it doesn't know how
exactly to deal with the scalar masks).
But, simplify_logical_relational_operation has a special case, where
it attempts to fold (x < y) | (x >= y) etc. and if it determines it is
always true, it just returns const_true_rtx, without doing the dances that
simplify_relational_operation does.
That results in an ICE on the following testcase, where such folding
happens
during expansion (of debug stmts into DEBUG_INSNs) and we ICE because
all of sudden a VOIDmode rtx appears where it expects a vector (V4SImode)
rtx.

The following patch fixes that by moving the adjustement into a separate
helper routine and using it from both simplify_relational_operation and
simplify_logical_relational_operation.

2021-06-11  Jakub Jelinek  

PR rtl-optimization/101008
* simplify-rtx.c (relational_result): New function.
(simplify_logical_relational_operation,
simplify_relational_operation): Use it.

* gcc.dg/pr101008.c: New test.

[Bug target/101007] [12 Regression] ICE: in extract_insn, at recog.c:2770 (unrecognizable insn) with -mno-sse2

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101007

--- Comment #5 from CVS Commits  ---
The master branch has been updated by Jakub Jelinek :

https://gcc.gnu.org/g:a984da88a35b42f444d1f9eeba77aa520b950d35

commit r12-1385-ga984da88a35b42f444d1f9eeba77aa520b950d35
Author: Jakub Jelinek 
Date:   Fri Jun 11 12:58:22 2021 +0200

i386: Fix up *vec_concat_0_1 [PR101007]

On Fri, Apr 23, 2021 at 12:53:58PM +0800, Hongtao Liu via Gcc-patches
wrote:
> -(define_insn "*vec_concatv4si_0"
> -  [(set (match_operand:V4SI 0 "register_operand"   "=v,x")
> - (vec_concat:V4SI
> -   (match_operand:V2SI 1 "nonimmediate_operand" "vm,?!*y")
> -   (match_operand:V2SI 2 "const0_operand"   " C,C")))]
> +(define_insn "*vec_concat_0"
> +  [(set (match_operand:VI124_128 0 "register_operand"   "=v,x")
> + (vec_concat:VI124_128
> +   (match_operand: 1 "nonimmediate_operand"
"vm,?!*y")
> +   (match_operand: 2 "const0_operand"   "
C,C")))]
>"TARGET_SSE2"
>"@
> %vmovq\t{%1, %0|%0, %1}
> @@ -22154,6 +22157,24 @@ (define_insn "avx_vec_concat"
> (set_attr "prefix" "maybe_evex")
> (set_attr "mode" "")])
>
> +(define_insn_and_split "*vec_concat_0"
> +  [(set (match_operand:V 0 "register_operand")
> + (vec_select:V
> +   (vec_concat:
> + (match_operand:V 1 "nonimmediate_operand")
> + (match_operand:V 2 "const0_operand"))
> +   (match_parallel 3 "movq_parallel"
> + [(match_operand 4 "const_int_operand")])))]
> +  "ix86_pre_reload_split ()"
> +  "#"
> +  "&& 1"
> +  [(set (match_dup 0)
> + (vec_concat:V (match_dup 1) (match_dup 5)))]
> +{
> +  operands[1] = gen_lowpart (mode, operands[1]);
> +  operands[5] = CONST0_RTX (mode);
> +})

This regressed the following testcase with -msse -mno-sse2.
The define_insn_and_split splits the permutation into *vec_concat_0
or *vec_concatv2di_0 insns which both have TARGET_SSE2 in their
conditions (for the former you can see it above), but the
define_insn_and_split matches always when the V mode's condition do,
which for V16QI/V8HI/V4SI/V2DI/V4SF modes is always (well, when those
modes are valid, which is TARGET_SSE).

2021-06-11  Jakub Jelinek  

PR target/101007
* config/i386/sse.md (*vec_concat_0_1): Require TARGET_SSE2.

* gcc.target/i386/sse-pr101007.c: New test.

[Bug tree-optimization/101028] [12 Regression] SLP compile-time hog since r12-1329-gce670e4faafb296d

[marxin at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101028

Martin Liška  changed:

   What|Removed |Added

   Target Milestone|--- |12.0
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2021-06-11
   Priority|P3  |P1
 Blocks||26163


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
[Bug 26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)

[Bug tree-optimization/101028] New: [12 Regression] SLP compile-time hog since r12-1329-gce670e4faafb296d

[marxin at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101028

Bug ID: 101028
   Summary: [12 Regression] SLP compile-time hog since
r12-1329-gce670e4faafb296d
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: compile-time-hog
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: rguenth at gcc dot gnu.org
  Target Milestone: ---

The following is causing hog (reduced from imagick SPEC benchmark):

$ cat 1.i
void ConvertImageCommand();
void MagickCommandGenesis();
void MogrifyImages();
void TracePath();

typedef struct {
  double x, y;
} PointInfo;

typedef struct {
  PointInfo point;
} PrimitiveInfo;

int TraceBezier_alpha, TraceBezier_i;
double TraceBezier_weight;
PointInfo *TraceBezier_points;
PrimitiveInfo *TraceBezier_primitive_info;
void DrawImage() { TracePath(); }

void TracePath() {
  double *coefficients;
  PointInfo point;
  long j;
  for (; TraceBezier_i; TraceBezier_i++) {
point.x = point.y = TraceBezier_alpha = 1.0;
j = 0;
for (; j < 4; j++) {
  point.x += TraceBezier_alpha * coefficients[j] *
 TraceBezier_primitive_info->point.x;
  point.y += TraceBezier_alpha * TraceBezier_primitive_info->point.y;
  TraceBezier_alpha *= TraceBezier_weight;
  TraceBezier_primitive_info++;
}
TraceBezier_points[TraceBezier_i] = point;
TraceBezier_weight += 1.0;
  }
}

void ConvertMain() { MagickCommandGenesis(ConvertImageCommand); }
void ConvertImageCommand() { MogrifyImages(); }
void MogrifyImages() { DrawImage(); }

int main() { return ConvertMain; }

$ gcc 1.i -flto=auto -Ofast  -shared -fPIC
...

likely never finishes :)

[Bug target/101021] PSHUFB is emitted instead of PSHUFD, PSHUFLW and PSHUFHW with -msse4

[ubizjak at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101021

Uroš Bizjak  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED
   Target Milestone|--- |12.0

--- Comment #3 from Uroš Bizjak  ---
Fixed.

[Bug c++/100897] Symmetric transfer does not prevent stack-overflow for C++20 coroutines

[l.v.merzljak at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100897

--- Comment #2 from Leonard von Merzljak  ---
(In reply to Iain Sandoe from comment #1)
> for symmetric transfer to work without stack overflow, it relies on an
> indirect tailcall.
> 
> For some GCC targets indirect tail-calls are not available without some
> additional support (see PR94794).
> 
> I tried to reproduce this (with a test case I use regularly for this) on a
> target that normally completes symmetric transfers successfully when the
> optimisation level is > 1. (x86_64, darwin).
> 
> The fail also occurs with my regular test case with -fsanitize=address - so,
> it seems that the inclusion of the address sanitiser is preventing or
> interfering with the tailcall.  Note that there are also other known issues
> with coroutines and the sanitizers (PR95137).

Thank you for your comment. I tried it out and can confirm that I don't get a
stack-overflow anymore if I omit -fsanitize=address and use an optimization
level > 1. If the issues with coroutines and sanitizers are already known, then
this bug report can be marked as resolved.
Of course, it would be nice if the stack-overflow would not occur even when
using an optimization level <= 1, but this probably does not qualify as a bug.

[Bug target/101021] PSHUFB is emitted instead of PSHUFD, PSHUFLW and PSHUFHW with -msse4

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101021

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Uros Bizjak :

https://gcc.gnu.org/g:1fa991d1d74cb1ce96c48ede70ae0be7a9683ce3

commit r12-1384-g1fa991d1d74cb1ce96c48ede70ae0be7a9683ce3
Author: Uros Bizjak 
Date:   Fri Jun 11 12:31:42 2021 +0200

i386: Try to avoid variable permutation instruction [PR101021]

Some permutations can be implemented without costly PSHUFB instruction,
e.g.:

{ 8,9,10,11,12,13,14,15, 0,1,2,3,4,5,6,7 } with PALIGNR,

{ 0,1,2,3, 4,5,6,7, 4,5,6,7, 12,13,14,15 } with PSHUFD,

{ 0,1, 2,3, 2,3, 6,7, 8,9,10,11,12,13,14,15 } with PSHUFLW and

{ 0,1,2,3,4,5,6,7, 8,9, 10,11, 10,11, 14,15 } with PSHUFHW.

All these instructions have constant shuffle control mask and do not
need to load shuffle mask from a memory to a temporary XMM register.

2021-06-11  Uroš Bizjak  

gcc/
PR target/101021
* config/i386/i386-expand.c (expand_vec_perm_pshufb): Return
false if the permutation can be implemented with constant
permutation instruction in wider mode.
(canonicalize_vector_int_perm): Move above expand_vec_perm_pshufb.
Handle V8QImode and V4HImode.

gcc/testsuite/

PR target/101021
* gcc.target/i386/pr101021-1.c: New test.
* gcc.target/i386/pr101021-2.c: Ditto.

[Bug tree-optimization/101026] [12 Regression] ICE Segmentation fault since r12-1329-gce670e4faafb296d

[rguenth at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101026

Richard Biener  changed:

   What|Removed |Added

   Last reconfirmed||2021-06-11
   Target Milestone|--- |12.0
 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Mine.

[Bug tree-optimization/79201] missed optimization: sinking doesn't handle calls, swap PRE and sinking

[drraph at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79201

--- Comment #5 from Raphael C  ---
I can confirm you now get

f:
mov eax, 1
ret

with gcc 8 onwards.

[Bug target/79185] [8 Regression] register allocation in the addition of two 128/9 bit ints

[drraph at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79185

--- Comment #17 from Raphael C  ---
Tested in gcc 11.1 with -O2

ai(__int128, __int128):
mov r9, rdi
mov rax, rdx
mov r8, rsi
mov rdx, rcx
add rax, r9
adc rdx, r8
ret


This looks like two more mov's than needed but I may be wrong.

By contrast clang gives

ai(__int128, __int128):  
mov rax, rdi
add rax, rdx
adc rsi, rcx
mov rdx, rsi
ret

[Bug gcov-profile/100788] Internal compiler error related to #line macros(?)

[marxin at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100788

Martin Liška  changed:

   What|Removed |Added

  Known to work||12.0

--- Comment #14 from Martin Liška  ---
Fixed on master so far.

[Bug gcov-profile/100788] Internal compiler error related to #line macros(?)

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100788

--- Comment #13 from CVS Commits  ---
The master branch has been updated by Martin Liska :

https://gcc.gnu.org/g:8bf728aecc4fea46b4490e950b9ae229f90597b0

commit r12-1383-g8bf728aecc4fea46b4490e950b9ae229f90597b0
Author: Martin Liska 
Date:   Tue Jun 1 15:13:18 2021 +0200

Introduce -Wcoverage-invalid-line-number

PR gcov-profile/100788

gcc/ChangeLog:

* common.opt: Add new option.
* coverage.c (coverage_begin_function): Emit warning instead on
the internal compiler error.
* doc/invoke.texi: Document the option.
* toplev.c (process_options): Enable it by default.

gcc/testsuite/ChangeLog:

* gcc.dg/pr100788.c: New test.

[Bug tree-optimization/100934] [9/10/11/12 Regression] wrong code at -O3 during unrolling since r9-6299

[rguenth at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100934

Richard Biener  changed:

   What|Removed |Added

   Assignee|rguenth at gcc dot gnu.org |unassigned at gcc dot 
gnu.org
   Priority|P3  |P2
 CC||rguenth at gcc dot gnu.org
 Status|ASSIGNED|NEW

--- Comment #6 from Richard Biener  ---
Not working on this at the moment.

[Bug tree-optimization/101009] [10/11 Regression] wrong code with "-O3 -fno-tree-sra"

[rguenth at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101009

Richard Biener  changed:

   What|Removed |Added

  Known to work||12.0
Summary|[10/11/12 Regression] wrong |[10/11 Regression] wrong
   |code with "-O3  |code with "-O3
   |-fno-tree-sra"  |-fno-tree-sra"

--- Comment #12 from Richard Biener  ---
Fixed on trunk sofar - the underlying issue is latent everywhere and not really
a regression.

[Bug tree-optimization/101009] [10/11/12 Regression] wrong code with "-O3 -fno-tree-sra"

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101009

--- Comment #11 from CVS Commits  ---
The master branch has been updated by Richard Biener :

https://gcc.gnu.org/g:336c41dbcb21740f8964021e157bc69ca547059b

commit r12-1381-g336c41dbcb21740f8964021e157bc69ca547059b
Author: Richard Biener 
Date:   Fri Jun 11 09:33:58 2021 +0200

middle-end/101009 - fix distance vector recording

This fixes recording of distance vectors in case the DDR has just
constant equal indexes.  In that case we expect distance vectors
with zero distances to be recorded which is what was done when
any distance was computed for affine indexes.

2021-06-11  Richard Biener  

PR middle-end/101009
* tree-data-ref.c (build_classic_dist_vector_1): Make sure
to set *init_b to true when we encounter a constant equal
index pair.
(compute_affine_dependence): Also dump the actual DR_REF.

* gcc.dg/torture/pr101009.c: New testcase.

[Bug tree-optimization/101009] [10/11/12 Regression] wrong code with "-O3 -fno-tree-sra"

[jakub at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101009

--- Comment #10 from Jakub Jelinek  ---
(In reply to Richard Biener from comment #8)
> With -O2 -fno-tree-sra -fno-tree-pre -ftree-loop-distribution even GCC 10
> miscompiles the code.  For dg-torture:

That started with r10-141-g051ef623d6e332a6199bbf4e6c66e53925cac825