[Bug tree-optimization/101025] New: 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

Bug ID: 101025
   Summary: wrong code at -O3 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.

Bisection points to g:128f43cf679e51564202b41f23fae4146347f93d



$ gcc-trunk -v
Supported LTO compression algorithms: zlib
gcc version 12.0.0 20210610 (experimental) [master revision
5ad76ad7f5b:c64ab1c4fe0:cce1697e6fe0134616ebc8f7040d99e66c12241a] (GCC)


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

$ gcc-trunk -O3 abc.c ; ./a.out
4

$ cat abc.c
int a[10];
int b, d, g;
volatile char c;
short e;
volatile int f;
int main() {
  for (; d <= 9; d++) {
b = e = 0;
for (; e < 10; e++)
  a[e] = 4;
for (; b <= 9; b++)
  if (g)
f = 0;
  else
a[b] = c;
  }
  printf("%d\n", a[1]);
}

[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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Mine.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25290
[Bug 25290] PHI-OPT could be rewritten so that is uses match

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

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

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

Bug ID: 101024
   Summary: Missed min expression at phiopt1
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: enhancement
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---

Take:
unsigned f(int nunits)
{
  int units_per = 32 / (8);


  unsigned int chunk_nunits = ((nunits) < (units_per) ? (nunits) :
(units_per));
  return chunk_nunits;
}
 CUT --
Compile with the C++ front-end and -O2 (note C++ is needed as fold won't
convert ?: into min/max expression due to lvalue requirements).
You will notice this is not caught by phiopt1 even though it should be while it
is caught now (on the trunk) by phiopt2 (match-and-simplify).  That is the
minmax_replacement does not handle the above case but match does.

Note this shows up in read code (GCC) in assemble_real (varasm.c). There are
two cases of this in assemble_real but only one of the two is caught in phiopt2
though because there looks like some jump threading that had happened before
that causes other issues.

I am filing this as a bug only so I can keep track of moving minmax_replacement
to match-and-simplify.

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

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

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

luoxhu at gcc dot gnu.org changed:

   What|Removed |Added

 CC||segher at gcc dot gnu.org,
   ||segher at kernel dot 
crashing.org

--- Comment #1 from luoxhu at gcc dot gnu.org ---
Confirmed. The BE-m32 test is a nightmare to me... :(

For float128-call.c, need check target BE or LE.
And for pr100085.c, vector __int128 is not supported with {-m32}, just skip it.
Ok to trunk?


[PATCH] rs6000: Fix test case failures by PR100085 [PR101020]

gcc/testsuite/ChangeLog:

PR target/101020
* gcc.target/powerpc/float128-call.c: Adjust.
* gcc.target/powerpc/pr100085.c: Likewise.
---
 gcc/testsuite/gcc.target/powerpc/float128-call.c | 6 --
 gcc/testsuite/gcc.target/powerpc/pr100085.c  | 2 +-
 2 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/gcc/testsuite/gcc.target/powerpc/float128-call.c
b/gcc/testsuite/gcc.target/powerpc/float128-call.c
index a1f09df..b64ffc6 100644
--- a/gcc/testsuite/gcc.target/powerpc/float128-call.c
+++ b/gcc/testsuite/gcc.target/powerpc/float128-call.c
@@ -21,5 +21,7 @@
 TYPE one (void) { return ONE; }
 void store (TYPE a, TYPE *p) { *p = a; }

-/* { dg-final { scan-assembler "lvx 2"  } } */
-/* { dg-final { scan-assembler "stvx 2" } } */
+/* { dg-final { scan-assembler {\mlxvd2x 34\M} {target be} } } */
+/* { dg-final { scan-assembler {\mstxvd2x 34\M} {target be} } } */
+/* { dg-final { scan-assembler {\mlvx 2\M} {target le} } }  */
+/* { dg-final { scan-assembler {\mstvx 2\M} {target le} } } */
diff --git a/gcc/testsuite/gcc.target/powerpc/pr100085.c
b/gcc/testsuite/gcc.target/powerpc/pr100085.c
index 7d8b147..b6738ea 100644
--- a/gcc/testsuite/gcc.target/powerpc/pr100085.c
+++ b/gcc/testsuite/gcc.target/powerpc/pr100085.c
@@ -1,4 +1,4 @@
-/* { dg-do compile } */
+/* { dg-do compile {target lp64} } */
 /* { dg-options "-O2 -mdejagnu-cpu=power8" } */

[Bug c++/100995] Extend std::is_constant_evaluated in if warning

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

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #3 from Marek Polacek  ---
Done.

[Bug c++/100995] Extend std::is_constant_evaluated in if warning

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

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Marek Polacek :

https://gcc.gnu.org/g:26dbe85a3781af913639b17bc966f4a0b8209f3b

commit r12-1375-g26dbe85a3781af913639b17bc966f4a0b8209f3b
Author: Marek Polacek 
Date:   Wed Jun 9 15:18:39 2021 -0400

c++: Extend std::is_constant_evaluated in if warning [PR100995]

Jakub pointed me at
   

which shows that our existing warning could be extended to handle more
cases.  This patch implements that.

A minor annoyance was handling macros, in libstdc++ we have

  reference operator[](size_type __pos) {
  __glibcxx_assert(__pos <= size());
  ...
  }

wherein __glibcxx_assert expands to

  if (__builtin_is_constant_evaluated() && !bool(__pos <= size())
...

but I'm of a mind to not warn on that.

Once consteval if makes it in, we should tweak this warning one more
time.

PR c++/100995

gcc/cp/ChangeLog:

* constexpr.c (maybe_constexpr_fn): New.
* cp-tree.h (maybe_constexpr_fn): Declare.
* semantics.c (find_std_constant_evaluated_r): New.
(maybe_warn_for_constant_evaluated): New.
(finish_if_stmt_cond): Call it.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/is-constant-evaluated9.C: Add dg-warning.
* g++.dg/cpp2a/is-constant-evaluated12.C: New test.

[Bug middle-end/98871] Cannot silence -Wmaybe-uninitialized at declaration site

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

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

--- Comment #5 from Martin Sebor  ---
Latest patch posted for review:
https://gcc.gnu.org/pipermail/gcc-patches/2021-June/572515.html

[Bug tree-optimization/98512] [11/12 Regression] “#pragma GCC diagnostic ignored” ineffective in conjunction with alias attribute

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

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

--- Comment #10 from Martin Sebor  ---
Latest patch: https://gcc.gnu.org/pipermail/gcc-patches/2021-June/572515.html

[Bug c++/100946] [11/12 Regression] [concepts] nonsensical results of compound requirements in requires expressions

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

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

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #4 from Patrick Palka  ---
Fixed for GCC 11.2 and 12.  Thanks for the bug report!

[Bug c++/100946] [11/12 Regression] [concepts] nonsensical results of compound requirements in requires expressions

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

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

--- Comment #3 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Patrick Palka
:

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

commit r11-8549-gae96e217ef82502312bed7e195a30ca5c67ca7ef
Author: Patrick Palka 
Date:   Thu Jun 10 18:31:18 2021 -0400

c++: normalization of non-templated return-type-req [PR100946]

Here the satisfaction cache is conflating the satisfaction value of the
two return-type-requirements because the corresponding constrained
'auto's have level 2, but they capture an empty current_template_parms.
This ultimately causes the satisfaction cache to think the type
constraint doesn't depend on the deduced type of the expression.

When normalizing the constraints on an 'auto', the assumption made by
normalize_placeholder_type_constraints is that the level of the 'auto'
is one greater than the depth of the captured current_template_parms, an
assumption which is not holding here.  So this patch just makes n_p_t_c
adjust the normalization context appropriately in this situation.

PR c++/100946

gcc/cp/ChangeLog:

* constraint.cc (normalize_placeholder_type_constraints): When
normalizing a non-templated return-type-requirement, add a dummy
level to initial_parms.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/concepts-return-req3.C: New test.

(cherry picked from commit 206db06ee380f490db0293af4ea7a4d590abd78c)

[Bug c++/67829] Bogus "ambiguous template instantiation" error with partial specializations involving a template template parameter

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

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

Patrick Palka  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |12.0
   Keywords||rejects-valid

--- Comment #2 from Patrick Palka  ---
Fixed for GCC 12

[Bug c++/67829] Bogus "ambiguous template instantiation" error with partial specializations involving a template template parameter

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

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

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

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

commit r12-1374-gedec2660ff4890ecf8cc191f7c92cf527de51fe2
Author: Patrick Palka 
Date:   Thu Jun 10 18:31:21 2021 -0400

c++: matching deduced template template parameters [PR67829]

During deduction, when the template of the argument for a bound ttp
is a template template parameter, we need to consider the
TEMPLATE_TEMPLATE_PARAMETER for matching rather than the TEMPLATE_DECL
thereof, because the canonical form of a template template parameter as
a template argument is the former tree, not the latter.

PR c++/67829

gcc/cp/ChangeLog:

* pt.c (unify) : When
the TEMPLATE_DECL of a BOUND_TEMPLATE_TEMPLATE_PARM argument is
a template template parameter, adjust to the
TEMPLATE_TEMPLATE_PARAMETER before falling through.

gcc/testsuite/ChangeLog:

* g++.dg/template/ttp34.C: New test.
* g++.dg/template/ttp34a.C: New test.
* g++.dg/template/ttp34b.C: New test.

[Bug c++/100946] [11/12 Regression] [concepts] nonsensical results of compound requirements in requires expressions

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

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

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

https://gcc.gnu.org/g:206db06ee380f490db0293af4ea7a4d590abd78c

commit r12-1373-g206db06ee380f490db0293af4ea7a4d590abd78c
Author: Patrick Palka 
Date:   Thu Jun 10 18:31:18 2021 -0400

c++: normalization of non-templated return-type-req [PR100946]

Here the satisfaction cache is conflating the satisfaction value of the
two return-type-requirements because the corresponding constrained
'auto's have level 2, but they capture an empty current_template_parms.
This ultimately causes the satisfaction cache to think the type
constraint doesn't depend on the deduced type of the expression.

When normalizing the constraints on an 'auto', the assumption made by
normalize_placeholder_type_constraints is that the level of the 'auto'
is one greater than the depth of the captured current_template_parms, an
assumption which is not holding here.  So this patch just makes n_p_t_c
adjust the normalization context appropriately in this situation.

PR c++/100946

gcc/cp/ChangeLog:

* constraint.cc (normalize_placeholder_type_constraints): When
normalizing a non-templated return-type-requirement, add a dummy
level to initial_parms.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/concepts-return-req3.C: New test.

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

[cel at us dot ibm.com via Gcc-bugs]

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

Carl Love  changed:

   What|Removed |Added

 CC||cel at us dot ibm.com

--- Comment #3 from Carl Love  ---
I will work on the fix.

[Bug target/89021] Implement mmintrin.h in SSE

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

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

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

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

commit r12-1372-ga325bdd195ee96f826b208c3afb9bed2ec077e12
Author: Peter Bergner 
Date:   Thu Jun 10 13:54:12 2021 -0500

i386: Add V8QI and other 64bit vector permutations [PR89021]

In addition to V8QI permutations, several other missing permutations are
added for 64bit vector modes for TARGET_SSSE3 and TARGET_SSE4_1 targets.

2021-06-10  Uroš Bizjak  

gcc/
PR target/89021
* config/i386/i386-expand.c (ix86_split_mmx_punpck):
Handle V2SF mode.  Emit SHUFPS to fixup unpack-high for V2SF mode.
(expand_vec_perm_blend): Handle 64bit modes for TARGET_SSE4_1.
(expand_vec_perm_pshufb): Handle 64bit modes for TARGET_SSSE3.
(expand_vec_perm_pblendv): Handle 64bit modes for TARGET_SSE4_1.
(expand_vec_perm_interleave2): Handle 64bit modes.
(expand_vec_perm_even_odd_pack): Handle V8QI mode.
(expand_vec_perm_even_odd_1): Ditto.
(ix86_vectorize_vec_perm_const): Ditto.
* config/i386/i386.md (UNSPEC_PSHUFB): Move from ...
* config/i386/sse.md: ... here.
* config/i386/mmx.md (*vec_interleave_lowv2sf):
New insn_and_split pattern.
(*vec_interleave_highv2sf): Ditto.
(mmx_pshufbv8qi3): New insn pattern.
(*mmx_pblendw): Ditto.

[Bug libstdc++/100577] [11/12 Regression] Unhelpful diagnostics for ill-formed call to partially applied range adaptor object

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

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

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #6 from Patrick Palka  ---
Fixed for GCC 11.2/12

[Bug libstdc++/100577] [11/12 Regression] Unhelpful diagnostics for ill-formed call to partially applied range adaptor object

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

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

--- Comment #5 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Patrick Palka
:

https://gcc.gnu.org/g:80495610eb8c3b1395073cebd26a079d81b73403

commit r11-8547-g80495610eb8c3b1395073cebd26a079d81b73403
Author: Patrick Palka 
Date:   Thu Jun 3 09:49:30 2021 -0400

libstdc++: Simplify range adaptors' forwarding of bound args [PR100577]

r11-8053 rewrote the range adaptor implementation in conformance with
P2281R1, making partial application act like a SFINAE-friendly perfect
forwarding call wrapper.  Making SFINAE-friendliness coexist with
perfect forwarding here requires adding fallback deleted operator()
overloads (as described in e.g. section 5.5 of P0847R6).  But
unfortunately, as reported in PR100577, this necessary technique of
using of deleted overloads regresses diagnostics for ill-formed calls to
partially applied range adaptors in GCC.

Although GCC's diagnostics can arguably be improved here by having the
compiler explain why the other candidates weren't viable when overload
resolution selects a deleted candidate, we can also largely work around
this on the library side (and achieve more concise diagnostics than by
a frontend-side improvement alone) if we take advantage of the
observation that not all range adaptors need perfect forwarding call
wrapper semantics, in fact only views::split currently needs it, because
all other range adaptors either take no extra arguments or only
arguments that are expected to be freely/cheaply copyable, e.g. function
objects and integer-like types.  (The discussion section in P2281R1 goes
into detail about why views::split is special.)

To that end, this introduces opt-in flags for denoting a range adaptor
as having "simple" extra arguments (in the case of a range adaptor
non-closure) or having a "simple" call operator (in the case of a range
adaptor closure).  These flags are then used to conditionally simplify
the operator() for the generic _Partial and _Pipe class templates, down
from needing three overloads thereof (including one defined as deleted)
to just needing a single overload.  The end result is that diagnostic
quality is restored for all adaptors except for views::split, and
diagnostics for the adaptors are generally made more concise since
there's only a single _Partial/_Pipe overload to diagnose instead of
three of them.

libstdc++-v3/ChangeLog:

PR libstdc++/100577
* include/std/ranges (_RangeAdaptorClosure): Document
_S_has_simple_call_op mechanism.
(_RangeAdaptor): Document _S_has_simple_extra_args mechanism.
(__closure_has_simple_call_op): New concept.
(__adaptor_has_simple_extra_args): Likewise.
(_Partial<_Adaptor, _Args...>): New partial specialization.
(_Partial<_Adaptor, _Arg>): Likewise.
(_Pipe<_Lhs, _Rhs>): Likewise.
(views::_All::_S_has_simple_call_op): Define to true.
(views::_Filter::_S_has_simple_extra_args): Likewise.
(views::_Transform::_S_has_simple_extra_args): Likewise.
(views::_Take::_S_has_simple_extra_args): Likewise.
(views::_TakeWhile::_S_has_simple_extra_args): Likewise.
(views::_Drop::_S_has_simple_extra_args): Likewise.
(views::_DropWhile::_S_has_simple_extra_args): Likewise.
(views::_Join::_S_has_simple_call_op): Likewise.
(views::_Split): Document why we don't define
_S_has_simple_extra_args to true for this adaptor.
(views::_Common::_S_has_simple_call_op): Define to true.
(views::_Reverse::_S_has_simple_call_op): Likewise.
(views::_Elements::_S_has_simple_call_op): Likewise.
* testsuite/std/ranges/adaptors/100577.cc: New test.

(cherry picked from commit 57ed620ebfa4275d04efeec973e88f506b0e3ba8)

[Bug libstdc++/100770] Incorrect if constexpr statement in ranges::unique_copy

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

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

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #5 from Patrick Palka  ---
Fixed for GCC 10.4/11.2/12

[Bug libstdc++/100770] Incorrect if constexpr statement in ranges::unique_copy

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

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

--- Comment #4 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Patrick Palka
:

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

commit r10-9908-gbee80d74f7ebc8e1ada913aa059dedc0976f28c0
Author: Patrick Palka 
Date:   Thu Jun 3 12:30:29 2021 -0400

libstdc++: Avoid hard error in ranges::unique_copy [PR100770]

Here, in the constexpr if condition within ranges::unique_copy, when
input_iterator<_Out> isn't satisfied we must avoid substituting into
iter_value_t<_Out> because the latter isn't necessarily well-formed
then.  To that end, this patch factors out the condition into a concept
and uses it throughout.

This patch also makes the definition of our testsuite
output_iterator_wrapper more minimal by setting its value_type, pointer
and reference member types to void.  This means our existing tests for
unique_copy already exercise the fix for this bug, so we don't need
to add another test.  The only other fallout of this testsuite iterator
change appears in std/ranges/range.cc, where the use of range_value_t
on a test_output_range is now ill-formed.

PR libstdc++/100770

libstdc++-v3/ChangeLog:

* include/bits/ranges_algo.h (__detail::__can_reread_output):
Factor out this concept from ...
(__unique_copy_fn::operator()): ... here.  Use the concept
throughout.
* testsuite/std/ranges/range.cc: Remove now ill-formed use
of range_value_t on an output_range.
* testsuite/util/testsuite_iterators.h (output_iterator_wrapper):
Define value_type, pointer and reference member types to void.

(cherry picked from commit 0614bbbe59c6953e088cffa39dfe63d86fc1fa96)

[Bug target/101023] New: [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

Bug ID: 101023
   Summary: [11/12 Regression] wrong code with -mstackrealign
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu

Created attachment 50981
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50981=edit
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)

$ x86_64-pc-linux-gnu-g++ -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-g++
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r12-1366-20210610095751-g6fcba9ef23e-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/12.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--disable-bootstrap --with-cloog --with-ppl --with-isl
--build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
--target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r12-1366-20210610095751-g6fcba9ef23e-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.0.0 20210610 (experimental) (GCC)

[Bug libstdc++/100770] Incorrect if constexpr statement in ranges::unique_copy

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

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

--- Comment #3 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Patrick Palka
:

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

commit r11-8546-ga35c5a5fc3eb610b77833855048163486c2fdb49
Author: Patrick Palka 
Date:   Thu Jun 3 12:30:29 2021 -0400

libstdc++: Avoid hard error in ranges::unique_copy [PR100770]

Here, in the constexpr if condition within ranges::unique_copy, when
input_iterator<_Out> isn't satisfied we must avoid substituting into
iter_value_t<_Out> because the latter isn't necessarily well-formed
then.  To that end, this patch factors out the condition into a concept
and uses it throughout.

This patch also makes the definition of our testsuite
output_iterator_wrapper more minimal by setting its value_type, pointer
and reference member types to void.  This means our existing tests for
unique_copy already exercise the fix for this bug, so we don't need
to add another test.  The only other fallout of this testsuite iterator
change appears in std/ranges/range.cc, where the use of range_value_t
on a test_output_range is now ill-formed.

PR libstdc++/100770

libstdc++-v3/ChangeLog:

* include/bits/ranges_algo.h (__detail::__can_reread_output):
Factor out this concept from ...
(__unique_copy_fn::operator()): ... here.  Use the concept
throughout.
* testsuite/std/ranges/range.cc: Remove now ill-formed use
of range_value_t on an output_range.
* testsuite/util/testsuite_iterators.h (output_iterator_wrapper):
Define value_type, pointer and reference member types to void.

(cherry picked from commit 0614bbbe59c6953e088cffa39dfe63d86fc1fa96)

[Bug c++/101010] Feature request: add builtins to provide mangled symbols, optionally with a prefix

[hedayat.fwd at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Hedayat Vatankhah  ---
(In reply to Martin Sebor from comment #1)
> Does the type_info::name() string match what you're looking for?

No, not at all. Looks like I've not clearly described my intent. 

First of all, type_info::name() is a runtime function. Both builtins I asked
are compile-time builtins: they should be replaced at compile time with the
desired string or symbol.

Also, I want the symbol name of the referred function or variable, not its
type. What your sample program outputs is the mangled name of type "void
(MyClass::*)(MyClass*, int)", but what I want is the mangled name of symbol
"void MyClass::member(MyClass*, int)". 

Finally, I asked about two distinct type of builtins:
1. The first kind is replaced at compile time with the mangled name as a
string. This kind, makes the following possible (note that probably dropping &
makes it more clear):
void f() __attribute__ ((weak, alias (__builtin_mangle(MyClass::member;
Should become same as the following:
void f() __attribute__ ((weak, alias ("_ZN7MyClass6memberEi")));


2. The second kind, does not generate a "string"; It generates a symbol at
compile time. Consider the example I provided in comment 0, it should be
converted to the following at compile time:

void __wrap__ZN7MyClass6memberEi(MyClass *mc_this, int a)
{
   if (call_real)
   __real__ZN7MyClass6memberEi(mc_this, a);
   else
   {...}
}

[Bug middle-end/101018] ICE when enabling OpenMP on a simple loop with SVE intrinsics (aarch64)

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

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

Alex Coplan  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Keywords||ice-on-valid-code
  Component|c   |middle-end
 Target||aarch64
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2021-06-10
 CC||acoplan at gcc dot gnu.org,
   ||rsandifo at gcc dot gnu.org
  Known to fail||10.3.0, 11.1.0, 12.0

--- Comment #1 from Alex Coplan  ---
Confirmed on trunk. ICEs with simply:

$ cat test.c
#include 
void f() {
  svfloat64_t x;
#pragma omp parallel
  x;
}
$ aarch64-linux-gnu-gcc -c -march=armv8.2-a+sve -fopenmp test.c
test.c: In function ‘f’:
test.c:5:3: internal compiler error: Segmentation fault
5 |   x;
  |   ^
0xe089b3 crash_signal
/home/alecop01/toolchain/src/gcc/gcc/toplev.c:327
0xad6abc omp_add_variable
/home/alecop01/toolchain/src/gcc/gcc/gimplify.c:7028
0xad7f55 omp_notice_variable
/home/alecop01/toolchain/src/gcc/gcc/gimplify.c:7622
0xad84ee gimplify_var_or_parm_decl
/home/alecop01/toolchain/src/gcc/gcc/gimplify.c:2851
0xadd82b gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/home/alecop01/toolchain/src/gcc/gcc/gimplify.c:14540
0xae15aa gimplify_stmt(tree_node**, gimple**)
/home/alecop01/toolchain/src/gcc/gcc/gimplify.c:6863
0xae1dae gimplify_bind_expr
/home/alecop01/toolchain/src/gcc/gcc/gimplify.c:1424
0xadc932 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/home/alecop01/toolchain/src/gcc/gcc/gimplify.c:14280
0xae15aa gimplify_stmt(tree_node**, gimple**)
/home/alecop01/toolchain/src/gcc/gcc/gimplify.c:6863
0xae3f6a gimplify_and_add(tree_node*, gimple**)
/home/alecop01/toolchain/src/gcc/gcc/gimplify.c:492
0xae3f6a gimplify_and_return_first
/home/alecop01/toolchain/src/gcc/gcc/gimplify.c:504
0xb08ed9 gimplify_omp_parallel
/home/alecop01/toolchain/src/gcc/gcc/gimplify.c:11428
0xadd8c3 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/home/alecop01/toolchain/src/gcc/gcc/gimplify.c:14568
0xae15aa gimplify_stmt(tree_node**, gimple**)
/home/alecop01/toolchain/src/gcc/gcc/gimplify.c:6863
0xadd753 gimplify_statement_list
/home/alecop01/toolchain/src/gcc/gcc/gimplify.c:1885
0xadd753 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/home/alecop01/toolchain/src/gcc/gcc/gimplify.c:14524
0xae15aa gimplify_stmt(tree_node**, gimple**)
/home/alecop01/toolchain/src/gcc/gcc/gimplify.c:6863
0xae1dae gimplify_bind_expr
/home/alecop01/toolchain/src/gcc/gcc/gimplify.c:1424
0xadc932 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/home/alecop01/toolchain/src/gcc/gcc/gimplify.c:14280
0xae15aa gimplify_stmt(tree_node**, gimple**)
/home/alecop01/toolchain/src/gcc/gcc/gimplify.c:6863
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/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 #2 from Bill Schmidt  ---
Looks like the proper pattern should be altivec_eqv1ti.

[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

Bill Schmidt  changed:

   What|Removed |Added

 CC||bergner at gcc dot gnu.org,
   ||carll at gcc dot gnu.org,
   ||segher at gcc dot gnu.org
  Known to fail||12.0
   Keywords||wrong-code
 Status|UNCONFIRMED |NEW
 Target||powerpc*-*-*
 Ever confirmed|0   |1
   Target Milestone|--- |12.0
   Last reconfirmed||2021-06-10

--- Comment #1 from Bill Schmidt  ---
Confirmed.

[Bug target/101022] New: 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

Bug ID: 101022
   Summary: rs6000: __builtin_altivec_vcmpequt expands to wrong
pattern
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wschmidt at gcc dot gnu.org
  Target Milestone: ---

This line appears in a recent patch committed this week:

+BU_P10V_AV_2 (VCMPEQUT,"vcmpequt", CONST,  eqvv1ti3)   

This builtin should expand to the ISA 3.1 vcmpequq instruction, but this
definition causes it to expand to bitwise equivalence (not-XOR).  That violates
the definition of vec_cmpeq, which must return all 0s or all 1s for each lane
element.  For this type, that means all 0s or all 1s in the entire register.

[Bug target/101019] GCC should consider using PLI/SLDI/PADDI to load up 64-bit constants on power10

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

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

Michael Meissner  changed:

   What|Removed |Added

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

--- Comment #1 from Michael Meissner  ---
I'm working on patches.

[Bug libstdc++/100690] ranges::iota_view::_Sentinel cannot access _M_current of _Iterator

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

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

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #4 from Patrick Palka  ---
Fixed for 10.4/11.2/12

[Bug libstdc++/100690] ranges::iota_view::_Sentinel cannot access _M_current of _Iterator

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

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

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

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

commit r10-9907-g8f5cda0e646822bbd01e642ed28a4f4f0cca8c59
Author: Patrick Palka 
Date:   Thu May 20 23:39:05 2021 -0400

libstdc++: Fix access issue in iota_view::_Sentinel [PR100690]

libstdc++-v3/ChangeLog:

PR libstdc++/100690
* include/std/ranges (iota_view::_Sentinel::_M_distance_from):
Split out this member function from ...
(iota_view::_Sentinel::operator-): ... here, for sake of access
control.
* testsuite/std/ranges/iota/iota_view.cc (test05): New test.

(cherry picked from commit 317a38cd468d565dc8ce45c6da0dbccf38808f70)

[Bug libstdc++/100690] ranges::iota_view::_Sentinel cannot access _M_current of _Iterator

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

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

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

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

commit r11-8545-gc6ccaf17ddbe8adb76475826be02580790ab28ca
Author: Patrick Palka 
Date:   Thu May 20 23:39:05 2021 -0400

libstdc++: Fix access issue in iota_view::_Sentinel [PR100690]

libstdc++-v3/ChangeLog:

PR libstdc++/100690
* include/std/ranges (iota_view::_Sentinel::_M_distance_from):
Split out this member function from ...
(iota_view::_Sentinel::operator-): ... here, for sake of access
control.
* testsuite/std/ranges/iota/iota_view.cc (test05): New test.

(cherry picked from commit 317a38cd468d565dc8ce45c6da0dbccf38808f70)

[Bug c/100993] ICE with -O2: Segmentation fault, cgraph_update_edges_for_call_stmt(gimple*, tree_node*, gimple*)

[joseph at codesourcery dot com via Gcc-bugs]

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

--- Comment #3 from joseph at codesourcery dot com  ---
Rejecting __builtin_* declarations was previously discussed in bug 32455.  
If we do, it would probably be worth testing building various software 
with the patched GCC to see what issues arise.

For many purposes, __sync_* and __atomic_* are built-in function 
namespaces just like __builtin_* (see builtins.c:is_builtin_name).  
However, functions with such names are definitely defined in libgcc and 
libatomic, and quite possibly might be defined elsewhere.

[Bug libstdc++/100631] ranges::elements_view:: _Sentinel is missing __distance_from() that can access _M_current of _Iterator

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

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

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #14 from Patrick Palka  ---
Fixed for 10.4/11.2/12

[Bug libstdc++/100631] ranges::elements_view:: _Sentinel is missing __distance_from() that can access _M_current of _Iterator

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

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

--- Comment #13 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Patrick Palka
:

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

commit r10-9904-gb1f54b2b7d876c72ab05afb0df214aba205f94ad
Author: Patrick Palka 
Date:   Tue May 18 10:21:27 2021 -0400

libstdc++: Fix access issue in elements_view::_Sentinel [PR100631]

In the earlier commit r12-854 I forgot to also rewrite the other operator-
overload in terms of the split-out member function _M_distance_from.

libstdc++-v3/ChangeLog:

PR libstdc++/100631
* include/std/ranges (elements_view::_Sentinel::operator-): Use
_M_distance_from in the other operator- overload too.
* testsuite/std/ranges/adaptors/elements.cc (test06): Augment test.

(cherry picked from commit 38751c4d5e15bd1c682ac4c868a2c4ce48ca5503)

[Bug libstdc++/100631] ranges::elements_view:: _Sentinel is missing __distance_from() that can access _M_current of _Iterator

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

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

--- Comment #12 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Patrick Palka
:

https://gcc.gnu.org/g:648c786bc6451115604c60abcc7977b3c6987ae4

commit r10-9903-g648c786bc6451115604c60abcc7977b3c6987ae4
Author: Patrick Palka 
Date:   Tue May 18 00:26:07 2021 -0400

libstdc++: Fix miscellaneous issues with elements_view::_Sentinel
[PR100631]

libstdc++-v3/ChangeLog:

PR libstdc++/100631
* include/std/ranges (elements_view::_Iterator): Also befriend
_Sentinel.
(elements_view::_Sentinel::_M_equal): Templatize.
(elements_view::_Sentinel::_M_distance_from): Split out from ...
(elements_view::_Sentinel::operator-): ... here.  Depend on
_Base2 instead of _Base in the return type.
* testsuite/std/ranges/adaptors/elements.cc (test06, test07):
New tests.

(cherry picked from commit 2e2eef80ac0c21f9533e6791ccf5e29458cbb77c)

[Bug libstdc++/100631] ranges::elements_view:: _Sentinel is missing __distance_from() that can access _M_current of _Iterator

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

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

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

https://gcc.gnu.org/g:3b93d61be5a5a93e95783b80c58b297e215badf1

commit r11-8542-g3b93d61be5a5a93e95783b80c58b297e215badf1
Author: Patrick Palka 
Date:   Tue May 18 10:21:27 2021 -0400

libstdc++: Fix access issue in elements_view::_Sentinel [PR100631]

In the earlier commit r12-854 I forgot to also rewrite the other operator-
overload in terms of the split-out member function _M_distance_from.

libstdc++-v3/ChangeLog:

PR libstdc++/100631
* include/std/ranges (elements_view::_Sentinel::operator-): Use
_M_distance_from in the other operator- overload too.
* testsuite/std/ranges/adaptors/elements.cc (test06): Augment test.

(cherry picked from commit 38751c4d5e15bd1c682ac4c868a2c4ce48ca5503)

[Bug libstdc++/100631] ranges::elements_view:: _Sentinel is missing __distance_from() that can access _M_current of _Iterator

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

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

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

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

commit r11-8541-gfd4db3ddc3639e03f557010b8e0e947e4b51633e
Author: Patrick Palka 
Date:   Tue May 18 00:26:07 2021 -0400

libstdc++: Fix miscellaneous issues with elements_view::_Sentinel
[PR100631]

libstdc++-v3/ChangeLog:

PR libstdc++/100631
* include/std/ranges (elements_view::_Iterator): Also befriend
_Sentinel.
(elements_view::_Sentinel::_M_equal): Templatize.
(elements_view::_Sentinel::_M_distance_from): Split out from ...
(elements_view::_Sentinel::operator-): ... here.  Depend on
_Base2 instead of _Base in the return type.
* testsuite/std/ranges/adaptors/elements.cc (test06, test07):
New tests.

(cherry picked from commit 2e2eef80ac0c21f9533e6791ccf5e29458cbb77c)

[Bug libstdc++/100639] reverse_iterator::reference erroneously uses iterator_traits::reference instead of iter_reference_t

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

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

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #5 from Patrick Palka  ---
Fixed for 10.4/11.2/12

[Bug libstdc++/100639] reverse_iterator::reference erroneously uses iterator_traits::reference instead of iter_reference_t

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

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

--- Comment #4 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Patrick Palka
:

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

commit r10-9902-gc8bd39bc10eac3028dbf509b27457172360e6e8c
Author: Patrick Palka 
Date:   Thu May 20 14:08:17 2021 -0400

libstdc++: Implement missing P0896R4 changes to reverse_iterator [PR100639]

This implements the P0896R4 changes to reverse_iterator's member types
value_type, difference_type and reference in C++20 mode, which fixes
taking the reverse_iterator of an iterator with a non-integral
difference_type (such as iota_view).

libstdc++-v3/ChangeLog:

PR libstdc++/100639
* include/bits/stl_iterator.h (reverse_iterator::difference_type):
In C++20 mode, define in terms of iter_difference_t as per P0896R4.
(reverse_iterator::reference): Likewise, but with iter_reference_t.
(reverse_iterator::value_type): Likewise, but with iter_value_t.
* testsuite/std/ranges/adaptors/reverse.cc (test08): New test.
* testsuite/24_iterators/reverse_iterator/100639.cc: New test.

(cherry picked from commit d5cbe0f0d4b7bc11f80b2236521f90ec94e95767)

[Bug libstdc++/100639] reverse_iterator::reference erroneously uses iterator_traits::reference instead of iter_reference_t

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

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

--- Comment #3 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Patrick Palka
:

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

commit r11-8540-ga50cc70f1b5ce3ae11528095fa3a1feadb206357
Author: Patrick Palka 
Date:   Thu May 20 14:08:17 2021 -0400

libstdc++: Implement missing P0896R4 changes to reverse_iterator [PR100639]

This implements the P0896R4 changes to reverse_iterator's member types
value_type, difference_type and reference in C++20 mode, which fixes
taking the reverse_iterator of an iterator with a non-integral
difference_type (such as iota_view).

libstdc++-v3/ChangeLog:

PR libstdc++/100639
* include/bits/stl_iterator.h (reverse_iterator::difference_type):
In C++20 mode, define in terms of iter_difference_t as per P0896R4.
(reverse_iterator::reference): Likewise, but with iter_reference_t.
(reverse_iterator::value_type): Likewise, but with iter_value_t.
* testsuite/std/ranges/adaptors/reverse.cc (test08): New test.
* testsuite/24_iterators/reverse_iterator/100639.cc: New test.

(cherry picked from commit d5cbe0f0d4b7bc11f80b2236521f90ec94e95767)

[Bug tree-optimization/97770] [ICELAKE]suboptimal vectorization for vpopcntw/b/q

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

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

--- Comment #19 from H.J. Lu  ---
(In reply to rguent...@suse.de from comment #18)
> 
> That's going to work I guess but it will pessimize general optimization
> which no longer know this is computing popcount (not sure if the old
> version exposed that fact).

Do we have testcase for that?

[Bug d/100967] d: ICE: Segmentation fault (../../gcc/d/dmd/declaration.c:1258)

[ibuclaw at gdcproject dot org via Gcc-bugs]

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

Iain Buclaw  changed:

   What|Removed |Added

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

--- Comment #6 from Iain Buclaw  ---
Fix committed and backported.

[Bug d/100967] d: ICE: Segmentation fault (../../gcc/d/dmd/declaration.c:1258)

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

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

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

https://gcc.gnu.org/g:3cf5b2930c22497617a535802b0c55248d688069

commit r9-9579-g3cf5b2930c22497617a535802b0c55248d688069
Author: Iain Buclaw 
Date:   Thu Jun 10 19:59:23 2021 +0200

d: Fix ICE in TypeInfoDeclaration, at dmd/declaration.c (PR100967)

Generate a stub TypeInfo class even if the root Object class is missing.
The front-end will take care of issuing an error and abort the
compilation when running semantic on constructed TypeInfo objects.

The errors issued by the code generation pass relating to missing or
disabled RTTI has been consolidated into a single function, so that a
meaningful error will be emitted before the front-end terminates.

gcc/d/ChangeLog:

PR d/100967
* d-frontend.cc (getTypeInfoType): Move TypeInfo checks to
check_typeinfo_type and call new function.
* d-tree.h (check_typeinfo_type): Declare.
* typeinfo.cc: Include dmd/scope.h.
(create_frontend_tinfo_types): Generate front-end types even if
Object
is missing.
(build_typeinfo): Move TypeInfo checks to check_typeinfo_type and
call
new function.
(check_typeinfo_type): New function.

gcc/testsuite/ChangeLog:

PR d/100967
* gdc.dg/pr100967.d: New test.

(cherry picked from commit 5ae4a73057dd26e7f09b5ba5190b84b1bbea4368)

[Bug d/100967] d: ICE: Segmentation fault (../../gcc/d/dmd/declaration.c:1258)

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

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

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

https://gcc.gnu.org/g:06b794846f1d8fa55133a257f6d7af39398b9cdc

commit r10-9901-g06b794846f1d8fa55133a257f6d7af39398b9cdc
Author: Iain Buclaw 
Date:   Thu Jun 10 19:59:23 2021 +0200

d: Fix ICE in TypeInfoDeclaration, at dmd/declaration.c (PR100967)

Generate a stub TypeInfo class even if the root Object class is missing.
The front-end will take care of issuing an error and abort the
compilation when running semantic on constructed TypeInfo objects.

The errors issued by the code generation pass relating to missing or
disabled RTTI has been consolidated into a single function, so that a
meaningful error will be emitted before the front-end terminates.

gcc/d/ChangeLog:

PR d/100967
* d-frontend.cc (getTypeInfoType): Move TypeInfo checks to
check_typeinfo_type and call new function.
* d-tree.h (check_typeinfo_type): Declare.
* typeinfo.cc: Include dmd/scope.h.
(create_frontend_tinfo_types): Generate front-end types even if
Object
is missing.
(build_typeinfo): Move TypeInfo checks to check_typeinfo_type and
call
new function.
(check_typeinfo_type): New function.

gcc/testsuite/ChangeLog:

PR d/100967
* gdc.dg/pr100967.d: New test.

(cherry picked from commit 5ae4a73057dd26e7f09b5ba5190b84b1bbea4368)

[Bug d/100967] d: ICE: Segmentation fault (../../gcc/d/dmd/declaration.c:1258)

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

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

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

https://gcc.gnu.org/g:228bcaca4286196d33741256dcd54b60e58b2b2f

commit r11-8539-g228bcaca4286196d33741256dcd54b60e58b2b2f
Author: Iain Buclaw 
Date:   Thu Jun 10 19:59:23 2021 +0200

d: Fix ICE in TypeInfoDeclaration, at dmd/declaration.c (PR100967)

Generate a stub TypeInfo class even if the root Object class is missing.
The front-end will take care of issuing an error and abort the
compilation when running semantic on constructed TypeInfo objects.

The errors issued by the code generation pass relating to missing or
disabled RTTI has been consolidated into a single function, so that a
meaningful error will be emitted before the front-end terminates.

gcc/d/ChangeLog:

PR d/100967
* d-frontend.cc (getTypeInfoType): Move TypeInfo checks to
check_typeinfo_type and call new function.
* d-tree.h (check_typeinfo_type): Declare.
* typeinfo.cc: Include dmd/scope.h.
(create_frontend_tinfo_types): Generate front-end types even if
Object
is missing.
(build_typeinfo): Move TypeInfo checks to check_typeinfo_type and
call
new function.
(check_typeinfo_type): New function.

gcc/testsuite/ChangeLog:

PR d/100967
* gdc.dg/pr100967.d: New test.

(cherry picked from commit 5ae4a73057dd26e7f09b5ba5190b84b1bbea4368)

[Bug d/100967] d: ICE: Segmentation fault (../../gcc/d/dmd/declaration.c:1258)

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

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

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

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

commit r12-1369-g5ae4a73057dd26e7f09b5ba5190b84b1bbea4368
Author: Iain Buclaw 
Date:   Thu Jun 10 19:59:23 2021 +0200

d: Fix ICE in TypeInfoDeclaration, at dmd/declaration.c (PR100967)

Generate a stub TypeInfo class even if the root Object class is missing.
The front-end will take care of issuing an error and abort the
compilation when running semantic on constructed TypeInfo objects.

The errors issued by the code generation pass relating to missing or
disabled RTTI has been consolidated into a single function, so that a
meaningful error will be emitted before the front-end terminates.

gcc/d/ChangeLog:

PR d/100967
* d-frontend.cc (getTypeInfoType): Move TypeInfo checks to
check_typeinfo_type and call new function.
* d-tree.h (check_typeinfo_type): Declare.
* typeinfo.cc: Include dmd/scope.h.
(create_frontend_tinfo_types): Generate front-end types even if
Object
is missing.
(build_typeinfo): Move TypeInfo checks to check_typeinfo_type and
call
new function.
(check_typeinfo_type): New function.

gcc/testsuite/ChangeLog:

PR d/100967
* gdc.dg/pr100967.d: New test.

[Bug target/101021] New: 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

Bug ID: 101021
   Summary: PSHUFB is emitted instead of PSHUFD, PSHUFLW and
PSHUFHW with -msse4
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ubizjak at gmail dot com
  Target Milestone: ---

Following testcase:

--cut here--
typedef char S;
typedef S VV __attribute__((vector_size(16 * sizeof(S;

VV ref_perm_pshufd (VV x, VV y)
{
  return __builtin_shuffle (x, y, (VV) { 8,9,10,11, 8,9,10,11, 8,9,10,11,
12,13,14,15 });
}

VV ref_perm_pshuflw (VV x)
{
  return __builtin_shuffle (x, (VV) { 0,1, 2,3, 2,3, 6,7, 8,9,10,11,12,13,14,15
});
}

VV ref_perm_pshufhw (VV x)
{
  return __builtin_shuffle (x, (VV) { 0,1,2,3,4,5,6,7, 8,9, 10,11, 10,11, 14,15
});
--cut here--

compiles with -O2 -msse2 to:

:

 pshufd $0xea,%xmm0,%xmm0
 retq   

:

 pshuflw $0xd4,%xmm0,%xmm0
 retq   

:

 pshufhw $0xd4,%xmm0,%xmm0
 retq   

Using -msse4 (or higher ISA), the compiler is too eager to emit less optimal
PSHUFB:

:

 pshufb 0x0(%rip),%xmm0
 retq   

:

 pshufb 0x0(%rip),%xmm0
 retq   

:

 pshufb 0x0(%rip),%xmm0
 retq

[Bug d/90651] ICE in FuncDeclaration::semantic3, at d/dmd/func.c:1524

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

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

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

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

commit r9-9578-gdcde4afec2a25a5fa69d1e5eec022768340fa1ab
Author: Iain Buclaw 
Date:   Thu Jun 10 19:48:49 2021 +0200

PR d/90651 (ICE in FuncDeclaration::semantic3, at d/dmd/func.c:1524)

Fixes segmentation fault in FuncDeclaration::semantic3.

gcc/d/ChangeLog:

PR d/90651
* dmd/expressionsem.c (ExpressionSemanticVisitor::visit
(TypeidExp)):
Error when TypeInfo doesn't exist.
* dmd/func.c (FuncDeclaration::semantic3): Likewise.
* dmd/mtype.c (TypeClass::dotExp): Likewise.
* typeinfo.cc (object_module): New variable.
(make_frontend_typeinfo): Update signature.  Set temporary on
generated TypeInfo classes.
(create_tinfo_types): Set object_module.  Move generation of
front-end
typeinfo into ...
(create_frontend_tinfo_types): ... New function.
(layout_typeinfo): Call create_frontend_tinfo_types.
(layout_classinfo): Likewise.
(layout_cpp_typeinfo): Likewise.
(create_typeinfo): Likewise.

gcc/testsuite/ChangeLog:

PR d/90651
* gdc.test/fail_compilation/extra-files/minimal/object.d: New file.
* gdc.test/fail_compilation/fail19911a.d: New test.
* gdc.test/fail_compilation/fail19911b.d: New test.
* gdc.test/fail_compilation/fail19911c.d: New test.
* gdc.test/fail_compilation/fail19922.d: New test.
* gdc.test/fail_compilation/fail19923.d: New test.

(cherry picked from commit 88ad43b1f91f7cd2ba9c342c6c1a6da82e6088bf)

[Bug c++/101010] Feature request: add builtins to provide mangled symbols, optionally with a prefix

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

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

--- Comment #1 from Martin Sebor  ---
Does the type_info::name() string match what you're looking for?

$ cat t.C && g++ t.C && ./a.out
#include 

struct MyClass
{
  void member (MyClass*, int);
};

int main ()
{
  __builtin_puts (typeid (::member).name ());
}
M7MyClassFvPS_iE

[Bug ada/70867] [9/10/11/12 regression] access discriminant in return aggregate wrongly detected as dangling

[demoonlit at panathenaia dot halfmoon.jp via Gcc-bugs]

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

--- Comment #13 from yuta tomino  ---
Sorry, perhaps my example is illegal in Ada 2012.
"aliased" is required to return a reference of a part of the parameter.

Randy explained the change in
https://groups.google.com/g/comp.lang.ada/c/7dw7Oqi8lIk/m/5NUBhFN8DQAJ .
(I wonder if it was legal before Ada 2005?? Because aliased parameter is added
in Ada 2012 and the relevant text has been changed by AI05-0234-1.)

I think Nicolas's example is always legal.

Thanks.

[Bug fortran/56670] Allocatable-length character var causes bogus warning with -Wuninitialized

[johnsonsr at ornl dot gov via Gcc-bugs]

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

Seth Johnson  changed:

   What|Removed |Added

 CC||johnsonsr at ornl dot gov

--- Comment #11 from Seth Johnson  ---
I confirm that with both 10.2 and 8.3, the example code prints the erroneous
warning with `-O0` and works as expected (no warning) with `-O1` and higher.

```
$FC "-Wall" -O1 -c ./ftest.f90
```

```fortran
subroutine do_stuff()
character(len=*), parameter :: src = "nope"
character(len=:), allocatable :: dst
dst = src
write(*,*) dst
end subroutine
```

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

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

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

Bug ID: 101020
   Summary: [12 regression] Several test case failures after
r12-1316
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

g:f700e4b0ee3ef53b48975cf89be26b9177e3a3f3, r12-1316

FAIL: gcc.target/powerpc/float128-call.c scan-assembler lvx 2
FAIL: gcc.target/powerpc/float128-call.c scan-assembler lvx 2
FAIL: gcc.target/powerpc/float128-call.c scan-assembler stvx 2
FAIL: gcc.target/powerpc/float128-call.c scan-assembler stvx 2
FAIL: gcc.target/powerpc/pr100085.c (test for excess errors)

The changes fail and new test fails on powerpc64 BE.


commit f700e4b0ee3ef53b48975cf89be26b9177e3a3f3
Author: Xionghu Luo 
Date:   Tue Jun 8 21:48:12 2021 -0500

rs6000: Support doubleword swaps removal in rot64 load store [PR100085]


* gcc.target/powerpc/float128-call.c: Adjust.
* gcc.target/powerpc/pr100085.c: New test.

[Bug target/101019] GCC should consider using PLI/SLDI/PADDI to load up 64-bit constants on power10

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

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

Michael Meissner  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2021-06-10
   Severity|normal  |enhancement
 CC||bergner at gcc dot gnu.org,
   ||dje at gcc dot gnu.org,
   ||meissner at gcc dot gnu.org,
   ||segher at gcc dot gnu.org,
   ||willschm at gcc dot gnu.org,
   ||wschmidt at gcc dot gnu.org

[Bug target/101019] New: GCC should consider using PLI/SLDI/PADDI to load up 64-bit constants on power10

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

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

Bug ID: 101019
   Summary: GCC should consider using PLI/SLDI/PADDI to load up
64-bit constants on power10
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: meissner at gcc dot gnu.org
  Target Milestone: ---

GCC should consider using a sequence of PLI, SLDI, and PADDI to load up 64-bit
constants on power10.

For example:
long foo_2 (void) { return (1L << 53) | (1L << 35) | (1L << 30) | (1L << 2); }

Generates:
lis 3,0x20
ori 3,3,0x8
sldi 3,3,32
oris 3,3,0x4000
ori 3,3,0x4

when it could generate:
pli 3,2097160
sldi 3,3,32
paddi 3,3,1073741828

[Bug ipa/67014] builtin_tolower is inefficient.

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

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #2 from Martin Liška  ---
I can take a look.

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

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

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

--- Comment #1 from Peter Bergner  ---
Are these tests valid for long double == double?  Ie, do we just need to
disable them when using -mlong-double-64 or are these real bugs?  I'm guessing
the latter for most of these tests, but just checking.

[Bug c/101018] New: ICE when enabling OpenMP on a simple loop with SVE intrinsics (aarch64)

[romain.gcc at dolbeau dot name via Gcc-bugs]

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

Bug ID: 101018
   Summary: ICE when enabling OpenMP on a simple loop with SVE
intrinsics (aarch64)
   Product: gcc
   Version: 11.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: romain.gcc at dolbeau dot name
  Target Milestone: ---

Created attachment 50980
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50980=edit
Simple SVE loop in a function illustrating the ICE with OpenMP

I have a simple loop in SVE intrinsics (see attached file).

Compiling with:
`gcc -O3 -march=armv8.2-a+sve -S bug.c`
works fine whereas:
`gcc -O3 -march=armv8.2-a+sve -fopenmp -S bug.c`

causes:

```
bug.c: In function ‘tuned_STREAM_Triad’:
bug.c:19:16: internal compiler error: Segmentation fault
   19 |   va = svmla_f64_z(svptrue_b64(), vb , vscalar, vc );
  |^
0xb8a6b3 crash_signal
../../gcc-11.1.0/gcc/toplev.c:327
0x9323d4 omp_add_variable
../../gcc-11.1.0/gcc/gimplify.c:7042
0x932cf3 omp_add_variable
../../gcc-11.1.0/gcc/gimplify.c:6989
0x932cf3 omp_notice_variable
../../gcc-11.1.0/gcc/gimplify.c:7636
0x932a8f omp_notice_variable
../../gcc-11.1.0/gcc/gimplify.c:7705
0x934573 gimplify_var_or_parm_decl
../../gcc-11.1.0/gcc/gimplify.c:2845
0x93a8cf gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc-11.1.0/gcc/gimplify.c:14544
0x93f9bb gimplify_expr
../../gcc-11.1.0/gcc/gimplify.c:15118
0x94072f gimplify_call_expr
../../gcc-11.1.0/gcc/gimplify.c:3521
0x93b1b3 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc-11.1.0/gcc/gimplify.c:14055
0x94512b gimplify_modify_expr
../../gcc-11.1.0/gcc/gimplify.c:5818
0x93a8f3 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc-11.1.0/gcc/gimplify.c:14083
0x93b64b gimplify_stmt(tree_node**, gimple**)
../../gcc-11.1.0/gcc/gimplify.c:6877
0x93b64b gimplify_statement_list
../../gcc-11.1.0/gcc/gimplify.c:1879
0x93b64b gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc-11.1.0/gcc/gimplify.c:14528
0x94161b gimplify_stmt(tree_node**, gimple**)
../../gcc-11.1.0/gcc/gimplify.c:6877
0x94161b gimplify_bind_expr
../../gcc-11.1.0/gcc/gimplify.c:1421
0x93b22f gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc-11.1.0/gcc/gimplify.c:14284
0x9483af gimplify_stmt(tree_node**, gimple**)
../../gcc-11.1.0/gcc/gimplify.c:6877
0x9483af gimplify_and_add(tree_node*, gimple**)
../../gcc-11.1.0/gcc/gimplify.c:489
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
```

I originally found this in a home-compiled 10.2.0, and was able to reproduce it
after recompiling 11.1.0 on a Ubuntu 20.04.2 LTS distribution.

Cordially,

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

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

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

--- Comment #13 from Steven Munroe  ---
"We want to use plain TImode instead of V1TImode on newer cpus."

Actually I disagree. We have vector __int128 in the ABI and with POWER10 a
complete set arithmetic operations for 128-bit in VRs.

Also this issue is not restricted to TImode. It also effects _Float128
(KFmode), _ibm128 (TFmode) and Libmvec for vector float/double. The proper and
optimum handling of these "union transfers" has been broken in GCC for years.

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

[Bug gcov-profile/100938] [GCOV] Coverage changes when a statement is divided in multiple lines

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

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2021-06-10

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

[Bug gcov-profile/100980] [GCOV]The assignment statement in the “for” structure caused the wrong coverage

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

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2021-06-10

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

[Bug c/100913] cppcheck: 2 * pointless new assignments in the parser ?

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

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

Martin Liška  changed:

   What|Removed |Added

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

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

[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

--- Comment #12 from Martin Liška  ---
(In reply to seberg from comment #11)
> Does that mean that fixing the `#line` directives (or inserting additional
> ones) should be able to fix the issue?  (Or work around it, if you consider
> it a bug.)

Yes. I've got an approved patch for the current master:
https://gcc.gnu.org/pipermail/gcc-patches/2021-June/571593.html

For older releases, I consider relaxation of the assert.

> 
> I tried to figure out where the `#line` directives currently causes this
> situation, and add new ones in some places in the templater.  But I don't
> really see where it goes wrong.  That is, unless `#if 0` causes the
> directives within the block to be ignored?

Well, the problematic function is:

numpy/core/src/multiarray/einsum_sumprod.c.src: In function
‘longdouble_sum_of_products_contig_three’:

So one should see a line directives in the function body that cause it ends
before it begins.

[Bug c++/98401] Temporaries passed to co_await sometimes cause an extraneous call to destructor at incorrect address

[davidledger at live dot com.au via Gcc-bugs]

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

David Ledger  changed:

   What|Removed |Added

 CC||davidledger at live dot com.au

--- Comment #3 from David Ledger  ---
I'm seeing the same double destructor:
https://godbolt.org/z/8r8oGG4z5

This appears to have many equivilent:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98401
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99576
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100611

[Bug c/101017] New: ICE: Segmentation fault, convert_memory_address_addr_space_1(scalar_int_mode, rtx_def*, unsigned char, bool, bool)

[cnsun at uwaterloo dot ca via Gcc-bugs]

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

Bug ID: 101017
   Summary: ICE: Segmentation fault,
convert_memory_address_addr_space_1(scalar_int_mode,
rtx_def*, unsigned char, bool, bool)
   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.MAuXx9TiBr-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
:71aa05def:4f625f47b4456e5c05a025fca4d072831e59126c] (GCC)

$ cat mutant.c
typedef v32qi __attribute__((vector_size(32)));
__attribute__((target_clones("arch=core-avx2", "default"))) v32qi
foo_ashift_256() {}

$ gcc-trunk  mutant.c
mutant.c:1:9: warning: type defaults to ‘int’ in declaration of ‘v32qi’
[-Wimplicit-int]
1 | typedef v32qi __attribute__((vector_size(32)));
  | ^
mutant.c: In function ‘foo_ashift_256’:
mutant.c:3:1: warning: AVX vector return without AVX enabled changes the ABI
[-Wpsabi]
3 | foo_ashift_256() {}
  | ^~
during RTL pass: expand
mutant.c: In function ‘foo_ashift_256.arch_core_avx2.0’:
mutant.c:3:19: internal compiler error: Segmentation fault
3 | foo_ashift_256() {}
  |   ^
0xf0a1a3 crash_signal
/tmp/tmp.MAuXx9TiBr-gcc-builder/gcc/gcc/toplev.c:327
0xb53029 convert_memory_address_addr_space_1(scalar_int_mode, rtx_def*,
unsigned char, bool, bool)
/tmp/tmp.MAuXx9TiBr-gcc-builder/gcc/gcc/explow.c:309
0xbdf25b expand_function_end()
/tmp/tmp.MAuXx9TiBr-gcc-builder/gcc/gcc/function.c:5517
0xa50992 construct_exit_block
/tmp/tmp.MAuXx9TiBr-gcc-builder/gcc/gcc/cfgexpand.c:6194
0xa50992 execute
/tmp/tmp.MAuXx9TiBr-gcc-builder/gcc/gcc/cfgexpand.c:6812
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

[Bug target/100930] PPC: Missing builtins for P9 vextsb2w, vextsb2w, vextsb2d, vextsh2d, vextsw2d

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

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

--- Comment #2 from Bill Schmidt  ---
Carl Love implemented these on trunk yesterday.  They will be backported to GCC
11 in a week or so, at which point we can close this.

[Bug c++/100611] coroutines: destructor called too many times for coroutine lambda stored object

[davidledger at live dot com.au via Gcc-bugs]

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

David Ledger  changed:

   What|Removed |Added

 CC||davidledger at live dot com.au

--- Comment #3 from David Ledger  ---
Ah, yeah this seems to be the same:
https://godbolt.org/z/8r8oGG4z5

[Bug c++/99576] [coroutines] destructor of a temporary called too early within co_await expression

[davidledger at live dot com.au via Gcc-bugs]

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

David Ledger  changed:

   What|Removed |Added

 CC||davidledger at live dot com.au

--- Comment #3 from David Ledger  ---
I'm seeing the same double destructor:
https://godbolt.org/z/8r8oGG4z5

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

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

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

SRINATH PARVATHANENI  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |sripar01 at gcc dot 
gnu.org
 Status|UNCONFIRMED |ASSIGNED
  Known to fail||10.3.0, 11.1.0
   Last reconfirmed||2021-06-10
 Ever confirmed|0   |1

[Bug target/101016] New: Arm: vld1q polymorphic variants failing with __ARM_undef undefined reference error during linking.

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

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

Bug ID: 101016
   Summary: Arm: vld1q polymorphic variants failing with
__ARM_undef undefined reference error during linking.
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sripar01 at gcc dot gnu.org
  Target Milestone: ---

The following testcase test.c is failing with undefined reference to
`__ARM_undef' at linking.

$cat test.c
#include "arm_mve.h"
void fn1() {
  uint32_t orgOffsetArray[1];
  vld1q(orgOffsetArray);
}

$arm-none-eabi-gcc test.c -mcpu=cortex-m55 -mfloat-abi=hard
--specs=rdimon.specs
/media/sripar01/2tb_work/CDE/build-arm-none-eabi/install/lib/gcc/arm-none-eabi/12.0.0/../../../../arm-none-eabi/bin/ld:
/media/sripar01/2tb_work/CDE/build-arm-none-eabi/install/lib/gcc/arm-none-eabi/12.0.0/../../../../arm-none-eabi/lib/thumb/v8-m.main+dp/hard/rdimon-crt0.o:
in function `_mainCRTStartup':
/media/sripar01/2tb_work/CDE/src/newlib-cygwin/libgloss/arm/crt0.S:545:
undefined reference to `main'
/media/sripar01/2tb_work/CDE/build-arm-none-eabi/install/lib/gcc/arm-none-eabi/12.0.0/../../../../arm-none-eabi/bin/ld:
/tmp/ccqfgEBM.o: in function `fn1':
test.c:(.text+0x1c): undefined reference to `__ARM_undef'
collect2: error: ld returned 1 exit status

$arm-none-eabi-gcc -v
Using built-in specs.
COLLECT_GCC=/media/sripar01/2tb_work/CDE/build-arm-none-eabi/install/bin/arm-none-eabi-gcc
COLLECT_LTO_WRAPPER=/media/sripar01/2tb_work/CDE/build-arm-none-eabi/install/libexec/gcc/arm-none-eabi/12.0.0/lto-wrapper
Target: arm-none-eabi
Configured with: /media/sripar01/2tb_work/CDE/src/gcc/configure
--target=arm-none-eabi
--prefix=/media/sripar01/2tb_work/CDE/build-arm-none-eabi/install//
--with-gmp=/media/sripar01/2tb_work/CDE/build-arm-none-eabi/host-tools
--with-mpfr=/media/sripar01/2tb_work/CDE/build-arm-none-eabi/host-tools
--with-mpc=/media/sripar01/2tb_work/CDE/build-arm-none-eabi/host-tools
--with-isl=/media/sripar01/2tb_work/CDE/build-arm-none-eabi/host-tools
--disable-shared --disable-nls --disable-threads --disable-tls
--enable-checking=yes --enable-languages=c,c++,fortran --with-newlib
--with-multilib-list=rmprofile --with-pkgversion=unknown
Thread model: single
Supported LTO compression algorithms: zlib
gcc version 12.0.0 20210608 (experimental) (unknown)

[Bug c++/101013] Rejects-valid for alias template in a different namespace with a lambda in unevaluated context

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

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

Marek Polacek  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2021-06-10
 Status|UNCONFIRMED |NEW
   Keywords||rejects-valid
 CC||mpolacek at gcc dot gnu.org

--- Comment #1 from Marek Polacek  ---
Thanks for the report, confirmed.

[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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #1 from Marek Polacek  ---
Confirmed.

[Bug tree-optimization/101014] [12 Regression] Big compile time hog with -O3 since r12-1268-g9858cd1a6827ee7a

[amacleod at redhat dot com via Gcc-bugs]

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

Andrew Macleod  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |amacleod at redhat dot 
com
 Status|NEW |ASSIGNED

--- Comment #3 from Andrew Macleod  ---
Yeah thats fine, I'll look at the original.

[Bug tree-optimization/101009] [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

Jakub Jelinek  changed:

   What|Removed |Added

   Keywords|needs-bisection |
 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
Started with r12-145-gd1d01a66012a93cc8cb7dafbe1b5ec453ec96b59

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

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

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

Bug ID: 101015
   Summary: Poor diagnostic for deprecated alias-declaration
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

struct A {
  typedef int good [[deprecated]];
  using bad [[deprecated]] = int;
};

A::good i = 0;
A::bad j = 0;

This prints:

depr.C:6:9: warning: 'A::good' is deprecated [-Wdeprecated-declarations]
6 | A::good i = 0;
  | ^
depr.C:2:15: note: declared here
2 |   typedef int good [[deprecated]];
  |   ^~~~
depr.C:7:8: warning: 'using bad = int' is deprecated
[-Wdeprecated-declarations]
7 | A::bad j = 0;
  |^
depr.C:3:9: note: declared here
3 |   using bad [[deprecated]] = int;
  | ^~~


When it is good it is very very good, but when it is bad it is horrid.

The second warning should print 'A::bad' not 'using bad = int'.

[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

--- Comment #3 from Jakub Jelinek  ---
Created attachment 50979
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50979=edit
gcc12-pr101008.patch

Untested fix.

[Bug tree-optimization/101014] [12 Regression] Big compile time hog with -O3 since r12-1268-g9858cd1a6827ee7a

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

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

--- Comment #2 from Martin Liška  ---
Unfortunately, the reduction is stuck at 200KB. Please let me know if you can
analyze the original test-case?

[Bug c++/92806] Suboptimal diagnostic for concept that depends on non-bool value

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

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

--- Comment #1 from Jonathan Wakely  ---
This seems to be fixed now:

a.C:8:9:   required by the constraints of 'template concept foo'
a.C:8:25: error: constraint 'trait::value [with T = int]' has type
'trait::', not 'bool'
8 | concept foo = trait::value;
  | ^
a.C:10:15: error: non-constant condition for static assertion
   10 | static_assert(foo);
  |   ^~~~
a.C:8:9:   required by the constraints of 'template concept foo'
a.C:8:25: error: constraint 'trait::value [with T = int]' has type
'trait::', not 'bool'
8 | concept foo = trait::value;
  | ^

[Bug c++/101006] Request diagnostic for likely concept syntax errors

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=98768

--- Comment #1 from Jonathan Wakely  ---
Your #1 is a dup of PR 98768

[Bug c++/97407] Expanding alias template in concept satisfaction error is undesirable

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

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

--- Comment #4 from Jonathan Wakely  ---
See also PR 89370 comment 2

[Bug c++/101006] Request diagnostic for likely concept syntax errors

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Blocks||67491
   Last reconfirmed||2021-06-10
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=92044
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491
[Bug 67491] [meta-bug] concepts issues

[Bug tree-optimization/101014] [12 Regression] Big compile time hog with -O3 since r12-1268-g9858cd1a6827ee7a

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

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

Martin Liška  changed:

   What|Removed |Added

   Keywords||needs-reduction

--- Comment #1 from Martin Liška  ---
I'm reducing the test-case now..

[Bug tree-optimization/101014] [12 Regression] Big compile time hog with -O3 since r12-1268-g9858cd1a6827ee7a

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

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

Martin Liška  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 CC||tnfchris at gcc dot gnu.org
   Last reconfirmed||2021-06-10
   Target Milestone|--- |12.0
 Status|UNCONFIRMED |NEW
  Known to fail||12.0
  Known to work||11.1.0

[Bug tree-optimization/101014] New: [12 Regression] Big compile time hog with -O3 since r12-1268-g9858cd1a6827ee7a

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

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

Bug ID: 101014
   Summary: [12 Regression] Big compile time hog with -O3 since
r12-1268-g9858cd1a6827ee7a
   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: aldyh at gcc dot gnu.org, amacleod at redhat dot com
  Target Milestone: ---

Created attachment 50978
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50978=edit
testcase

Noticed in a yarpget test-case and WRF for instance.
-O3 runs really slowly

[Bug c++/101013] New: Rejects-valid for alias template in a different namespace with a lambda in unevaluated context

[tartanllama at gmail dot com via Gcc-bugs]

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

Bug ID: 101013
   Summary: Rejects-valid for alias template in a different
namespace with a lambda in unevaluated context
   Product: gcc
   Version: 11.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tartanllama at gmail dot com
  Target Milestone: ---

Code:
namespace ns {
  template 
  using void_t = decltype([]{}());
}

template
struct oh_no {
using type = ns::void_t;
};

Compiler output:
:8:22: error: '' in namespace 'ns' does not name a
type
8 | using type = ns::void_t;
  |  ^

Expected behaviour: 
Compile cleanly

Additional information:
The code compiles if oh_no and void_t are in the same namespace

GCC version and configuration options:
GCC 11.1.0
../gcc-11.1.0/configure --prefix=/opt/compiler-explorer/gcc-build/staging
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
--disable-bootstrap --enable-multiarch --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --enable-clocale=gnu
--enable-languages=c,c++,fortran,ada,go,d --enable-ld=yes --enable-gold=yes
--enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-linker-build-id
--enable-lto --enable-plugins --enable-threads=posix
--with-pkgversion=Compiler-Explorer-Build

Command line: 
-std=c++20

Compiler explorer link:
https://godbolt.org/z/EYsbbjodj

[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

   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Seems to be a simplify-rtx.c bug.
simplify_binary_operation (IOR, V4SImode, (ne:V4SI (reg:V4SI 82 [ v.0_2 ])
(reg:V4SI 83 [ _4 ])), (eq:V4SI (reg:V4SI 82 [ v.0_2 ]) (reg:V4SI 83 [ _4 ])))
returns (const_int 1 [0x1]), which is wrong.

[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

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

--- Comment #4 from Jakub Jelinek  ---
Created attachment 50977
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50977=edit
gcc12-pr101007.patch

Untested fix.
The *vec_concat_0 insn the new define_insn_and_split wants to split into
(or *vec_concatv2di_0) have TARGET_SSE2 in condition, while the
define_insn_and_split does not.

[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

--- Comment #3 from Jakub Jelinek  ---
But it is actually caused by r12-760-g94de7e225c1fda079052c3f0725c926437d56c94

[Bug tree-optimization/101003] [12 regression] ICE compiling gcc.dg/pr86179.c after r12-1329

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||dcb314 at hotmail dot com

--- Comment #4 from Richard Biener  ---
*** Bug 101012 has been marked as a duplicate of this bug. ***

[Bug c/101012] ice in vect_slp_analyze_node_operations

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #2 from Richard Biener  ---
dup (and fixed)

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

[Bug tree-optimization/101009] [12 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

--- Comment #2 from Richard Biener  ---
  (overlap_iterations_a = [0])
  (overlap_iterations_b = [0]))
(build_classic_dist_vector
  dist_vector = (  1
  )
)
)
(compute_affine_dependence
  stmt_a: g[1].c = 1;
  stmt_b: *f.0_1 = g[1];
) -> no dependence

Hmm, we shouldn't be able to use affine dependence checking here since
g[1].c has an additional subsetting.  Or maybe the code to handle this
case has a bug at least.

[Bug c/101012] ice in vect_slp_analyze_node_operations

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #1 from David Binderman  ---
Reduced C code seems to be:

putRGBAAseparate8bittile_w(int *cp, unsigned char *g) {
  char *a, *r;
  unsigned *b;
  int _x;
  for (; _x; _x -= 8) {
*cp++ = *r++ | (unsigned)*g++ << 8 | *b++ << 16 | (unsigned)*a++ << 24;
*cp++ = *r++ | (unsigned)*g++ << 8 | *b++ << 16 | (unsigned)*a++ << 24;
  }
}

This bug seems strongly related to gcc bugzilla # 86179, which was 
# 446 on my list of 724.

[Bug c/101012] New: ice in vect_slp_analyze_node_operations

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 101012
   Summary: ice in vect_slp_analyze_node_operations
   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 50976
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50976=edit
C source code

For the attached C code, compiled with today's gcc trunk and
compiler flag -O3, does this:

bug446
during GIMPLE pass: vect
tif_getimage.c: In function ‘putRGBseparate8bittile’:
tif_getimage.c:1618:13: internal compiler error: in
vect_slp_analyze_node_operations, at tree-vect-slp.c:4442
0x5fd6fd vect_slp_analyze_node_operations
../../trunk.git/gcc/tree-vect-slp.c:4442
0xd902b3 vect_slp_analyze_node_operations
../../trunk.git/gcc/tree-vect-slp.c:4385
0xd902b3 vect_slp_analyze_node_operations
../../trunk.git/gcc/tree-vect-slp.c:4385
0xd902b3 vect_slp_analyze_node_operations
../../trunk.git/gcc/tree-vect-slp.c:4385

The bug first seems to occur sometime after git hash 
91349e57bbfd0101, dated a couple of days ago, and git
hash f8b067056ba5dd53, dated today.

I will have my usual go at reducing the code. If someone
else wants to do the git bisect, then that's fine by me.

[Bug tree-optimization/101009] [12 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

   Keywords||needs-bisection, wrong-code
   Target Milestone|--- |12.0
Summary|wrong code with "-O3|[12 Regression] wrong code
   |-fno-tree-sra"  |with "-O3 -fno-tree-sra"
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2021-06-10
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed.  loop distribution distributes

   [local count: 955630225]:
  # d.2_15 = PHI <_2(6), d.2_14(5)>
  g[1].b = 2;
  g[1].c = 1;
  f.0_1 = f;
  *f.0_1 = g[1];
  g ={v} {CLOBBER};
  _2 = d.2_15 + -1;
  d = _2;
  if (_2 != 0)

to

   [local count: 955630225]:
  # d.2_17 = PHI <_22(11), d.2_14(5)>
  g[1].b = 2;
  f.0_19 = f;
  *f.0_19 = g[1];
  _22 = d.2_17 + -1;
  d = _22;
  if (_22 != 0)

and

   [local count: 955630225]:
  # d.2_15 = PHI <_2(6), d.2_14(8)>
  g[1].c = 1;
  _2 = d.2_15 + -1;
  if (_2 != 0)

doesn't seem to happen with the GCC 11 copy I have around.

[Bug debug/101011] New: Inconsistent debug info for "while (1);"

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

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

Bug ID: 101011
   Summary: Inconsistent debug info for "while (1);"
   Product: gcc
   Version: 11.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

I.

Consider test-cases:
...
$ cat -n test.c
 1  int
 2  main (void)
 3  {
 4while (1);
 5
 6return 0;
 7  }
$ cat -n test2.c
 1  int
 2  main (void)
 3  {
 4int spin = 1;
 5while (spin);
 6
 7return 0;
 8  }
...

Compiled with gcc-10:
...
$ gcc-10 test.c -g -o 1
$ gcc-10 test2.c -g -o 2
...
we get the same behaviour when setting the breakpoint on the loop line 4/5.

We stop twice here:
...
$ gdb -q -batch 1 -ex "break 4" -ex run -ex "continue"
Breakpoint 1 at 0x40049a: file test.c, line 4.

Breakpoint 1, main () at test.c:4
4 while (1);

Breakpoint 1, main () at test.c:4
4 while (1);
$
...
and here:
...
$ gdb -q -batch 2 -ex "break 5" -ex run -ex "continue"
Breakpoint 1 at 0x4004a1: file test2.c, line 5.

Breakpoint 1, main () at test2.c:5
5 while (spin);

Breakpoint 1, main () at test2.c:5
5 while (spin);
$
...

Now, with gcc-11:
...
$ gcc-11 test.c -g -o 1
$ gcc-11 test2.c -g -o 2
...
we have the same behaviour for test.c:
...
$ gdb -q -batch 1 -ex "break 4" -ex run -ex "continue"
Breakpoint 1 at 0x40049a: file test.c, line 4.

Breakpoint 1, main () at test.c:4
4 while (1);

Breakpoint 1, main () at test.c:4
4 while (1);
$
...
but for test2.c:
...
$ gdb -q -batch 2 -ex "break 5" -ex run -ex "continue"
Breakpoint 1 at 0x4004a1: file test2.c, line 5.

Breakpoint 1, main () at test2.c:5
5 while (spin);

...


II.

The difference can be seen in the .s file for test2.c.

With gcc-10, we have:
...
.loc 1 4 7
movl$1, -4(%rbp)
.L2:
.loc 1 5 9 discriminator 1
cmpl$0, -4(%rbp)
jne .L2
.loc 1 7 10
movl$0, %eax
...
but with gcc-11 there's an extra nop, with a corresponding .loc for line 5:
...
.loc 1 4 7
movl$1, -4(%rbp)
.loc 1 5 9
nop
.L2:
.loc 1 5 10 discriminator 1
cmpl$0, -4(%rbp)
jne .L2
.loc 1 7 10
movl$0, %eax
...


III.

OTOH, the behaviour has changed, so it's tempting to say that this is a
regression.

However, my feeling is that this is actually a progression: we stop at the
start of the line.

Either way:
- if this is a regression is needs to be fixed.
- if this is a progression, then can we have the same for test.c?


IV.

FWIW, I tracked down where the nop is inserted.  It happens during
outof_cfglayout, in fixup_reorder_chain, here:
...
  if (!INSN_P (BB_END (nb)))
BB_END (nb) = emit_insn_after_noloc (gen_nop (), BB_END (nb),
 nb);
  INSN_LOCATION (BB_END (nb)) = e->goto_locus;
...


V.

Funnily enough, with clang the opposite seems to be the case
(https://bugs.llvm.org/show_bug.cgi?id=49614 ): the example with test.c hangs,
and the example with test2.c finishes.

[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

Summary|ICE: in extract_insn, at|[12 Regression] ICE: in
   |recog.c:2770|extract_insn, at
   |(unrecognizable insn) with  |recog.c:2770
   |-mno-sse2   |(unrecognizable insn) with
   ||-mno-sse2
 CC||jakub at gcc dot gnu.org
   Target Milestone|--- |12.0

--- Comment #2 from Jakub Jelinek  ---
ICEs since r12-1128-gef8176e0fac935c095cc39f4ecdfd43cdb8cb3f3 when
__builtin_shufflevector has been introduced.

[Bug tree-optimization/101003] [12 regression] ICE compiling gcc.dg/pr86179.c after r12-1329

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

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/101003] [12 regression] ICE compiling gcc.dg/pr86179.c after r12-1329

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

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

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

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

commit r12-1357-gcce1697e6fe0134616ebc8f7040d99e66c12241a
Author: Richard Biener 
Date:   Thu Jun 10 10:39:31 2021 +0200

tree-optimization/101003 - use pattern defs when linearizing

We of course have to use pattern stmt defs for the linearized
chain operands which is what I failed to ensure.

2021-06-10  Richard Biener  

PR tree-optimization/101003
* tree-vect-slp.c (vect_build_slp_tree_2): Appropriately
use the pattern stmt defs when linearizing a chain.

[Bug c++/101010] Feature request: add builtins to provide mangled symbols, optionally with a prefix

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug c++/101010] New: Feature request: add builtins to provide mangled symbols, optionally with a prefix

[hedayat.fwd at gmail dot com via Gcc-bugs]

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

Bug ID: 101010
   Summary: Feature request: add builtins to provide mangled
symbols, optionally with a prefix
   Product: gcc
   Version: 11.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hedayat.fwd at gmail dot com
  Target Milestone: ---

Currently, there is no method to generate mangled symbol as an string or as a
symbol. 

A mangled symbol as string is useful in many cases for GCC itself, e.g. to use
with alias or ifunc attributes. Currently, you should find the mangled name
yourself and use it there, which is both inconvenient and also might change in
future (or it might be even different for example when compiled with mingw). 

Having a mangled symbol with a prefix (not as a string), is useful when using
the '--wrap' option to ld, to generate __real_SYMBOL and __wrap_SYMBOLs.
Actually, I'm more interested in this one, but found that the former one
(mangled name as string) is also useful. 

Sample intended usage:
void __builtin_mangled_symbol(__wrap_, ::member)(MyClass *mc_this, int
a)
{
   if (call_real)
   __builtin_mangled_symbol(__real_, ::member)(mc_this, a);
   else
   {...}
}

[Bug tree-optimization/101009] New: wrong code with "-O3 -fno-tree-sra"

[suochenyao at 163 dot com via Gcc-bugs]

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

Bug ID: 101009
   Summary: wrong code with "-O3 -fno-tree-sra"
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: suochenyao at 163 dot com
  Target Milestone: ---

***
OS and Platform:
CentOS Linux release 7.8.2003 (Core), x86_64 GNU/Linux
***
Program:
int printf(const char *, ...);
struct a {
  unsigned b;
  unsigned c;
} e, *f = 
int d = 1;
int main() {
  for (; d; d--) {
struct a g[] = {{2, 1}, {2, 1}};
*f = g[1];
  }
  printf("%d\n", e.c);
}
***
gcc version:
$ gcc -v
Using built-in specs.
COLLECT_GCC=/data/bin/gcc-dev/bin/gcc
COLLECT_LTO_WRAPPER=/data/bin/gcc-dev/libexec/gcc/x86_64-pc-linux-gnu/12.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure --prefix=/data/bin/gcc-dev --disable-multilib
--enable-languages=c,c++
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.0.0 20210609 (experimental) (GCC)

git version: 53cb324cb4f9475d4eabcd9f5a858c5edaacc0cf
***
Command Lines:
$ gcc -O3 -fno-tree-sra -Wall -Wextra -fno-strict-aliasing -fwrapv a.c -o
a1.out
$ gcc a.c -o a2.out
$ ./a1.out
0
$ ./a2.out
1

[Bug tree-optimization/100981] [11 Regression] ICE in info_for_reduction, at tree-vect-loop.c:4897

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

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

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

https://gcc.gnu.org/g:7d19a50ea1e5e9858bb7cd258fa4f9db89ecfcb2

commit r12-1355-g7d19a50ea1e5e9858bb7cd258fa4f9db89ecfcb2
Author: Jakub Jelinek 
Date:   Thu Jun 10 09:31:06 2021 +0200

testsuite: Fix up libgomp.fortran/pr100981-2.f90 testcase [PR100981]

The dsdotr and dsdoti variables uninitialized and the testcase fails e.g.
on i686-linux.  Fixed by zero initialization.

2021-06-10  Jakub Jelinek  

PR tree-optimization/100981
* testsuite/libgomp.fortran/pr100981-2.f90 (cdcdot): Initialize
dsdotr and dsdoti to 0.