[Bug c++/95473] GCC misses -Wnull-dereference warning in a simple code

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 CC||law at gcc dot gnu.org,
   ||manu at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
   Last reconfirmed||2020-06-02
 Ever confirmed|0   |1

[Bug middle-end/95472] various diagnostics for C/C++ hyperlinks to gfortran doc

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

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

[Bug c++/95468] ICE in expression sfinae

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Keywords||ice-on-invalid-code
   Last reconfirmed||2020-06-02

[Bug c++/95465] [8/9/10/11 Regression] ICE on jump into a statement expression

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

[Bug fortran/95467] ICE in parse_omp_structured_block: OpenMP Offload (target_parallel__simd)

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |WAITING
 CC||marxin at gcc dot gnu.org
   Last reconfirmed||2020-06-02

--- Comment #1 from Martin Liška  ---
I see something like:

gcc pr95467.F90 -c -fopenmp -O2
pr95467.F90:11:18:

   11 | !$OMP END PARALLEL
  |  1
Error: Unexpected !$OMP END PARALLEL statement at (1)
pr95467.F90:12:4:

   12 | END PROGRAM target_parallel__simd
  |1
Error: Unexpected END statement at (1)
f951: Error: Unexpected end of file in ‘pr95467.F90’

[Bug c++/95473] New: GCC misses -Wnull-dereference warning in a simple code

[haoxintu at gmail dot com]

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

Bug ID: 95473
   Summary: GCC misses -Wnull-dereference warning in a simple code
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: haoxintu at gmail dot com
  Target Milestone: ---

$cat null_ref.cc
int main(){
int  = *(int *)nullptr; // null reference
return 0;
}

GCC can not catch any warning when I use -Wnull-dereference option. 
I also try to add -O1~Os, but GCC still produces nothing.

While in clang

$clang++-trunk -Wnull-dereference null_ref.cc 
null_ref.cc:2:15: warning: binding dereferenced null pointer to reference has
undefined behavior [-Wnull-dereference]
int  = *(int *)nullptr; // null reference
  ^~~
1 warning generated.

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

[Bug middle-end/95472] various diagnostics for C/C++ hyperlinks to gfortran doc

[xry111 at mengyan1223 dot wang]

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

--- Comment #1 from Xi Ruoyao  ---
(In reply to Xi Ruoyao from comment #0)

> This also happens to -Wreturn-type and -Wuninitialized.  Strangely these two
> entries don't even exist in gfortran doc.  But it does not happens to
> -Wformat or -Wimplicit-function-declaration etc.

Sorry I can't type.  Should be:

This also happens to -Wreturn-type.  Strangely the entries for -Wreturn-type
and -Wuninitialized don't even exist in gfortran doc.

[Bug middle-end/95472] New: various diagnostics for C/C++ hyperlinks to gfortran doc

[xry111 at mengyan1223 dot wang]

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

Bug ID: 95472
   Summary: various diagnostics for C/C++ hyperlinks to gfortran
doc
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: xry111 at mengyan1223 dot wang
  Target Milestone: ---

$ cat t1.c
int main()
{
int x;
return x;
}
$ gcc t1.c -Wall
t1.c: In function 'main':
t1.c:4:9: warning: 'x' is used uninitialized in this function [-Wuninitialized]
4 |  return x;
  | ^

It looks OK, but in GCC-10 we have diagnostics with hyperlink.  If you click "-
Wuninitialized" you'll be diverted to gfortran doc:

https://gcc.gnu.org/onlinedocs/gfortran/Error-and-Warning-Options.html#index-Wuninitialized

This also happens to -Wreturn-type and -Wuninitialized.  Strangely these two
entries don't even exist in gfortran doc.  But it does not happens to -Wformat
or -Wimplicit-function-declaration etc.

[Bug target/95237] LOCAL_DECL_ALIGNMENT shrinks alignment, FAIL gcc.target/i386/pr69454-2.c

[kito at gcc dot gnu.org]

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

--- Comment #6 from Kito Cheng  ---
Created attachment 48658
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48658=edit
i386-Implement-ROUND_TYPE_ALIGN-to-make-sure-alignme.patch

Some optimization might made decision depend on the alignment, and alignment
shrinking might made the decision become wrong.

So I prefer keep the assertion checking and implement ROUND_TYPE_ALIGN for x86,
so that it will set the alignment properly from the beginning.

PoC/untested  patch attached.

[Bug tree-optimization/88398] vectorization failure for a small loop to do byte comparison

[guojiufu at gcc dot gnu.org]

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

--- Comment #36 from Jiu Fu Guo  ---
(In reply to Jakub Jelinek from comment #10)
> If the compiler knew say from PGO that pos is usually a multiple of certain
> power of two and that the loop usually iterates many times (I guess the
> latter can be determined from comparing the bb count of the loop itself and
> its header), it could emit something like:
> static int func2(int max, int pos, unsigned char *cur)
> {
>   unsigned char *p = cur + pos;
>   int len = 0;
>   if (max > 32 && (pos & 7) == 0)
> {
>   int l = ((1 - ((uintptr_t) cur)) & 7) + 1;
>   while (++len != l)
> if (p[len] != cur[len])
>   goto end;
>   unsigned long long __attribute__((may_alias)) *p2 = (unsigned long
> long *) [len];
>   unsigned long long __attribute__((may_alias)) *cur2 = (unsigned long
> long *) [len];
>   while (len + 8 < max)
> {
>   if (*p2++ != *cur2++)
> break;
>   len += 8;
> }
>   --len;
> }
>   while (++len != max)
> if (p[len] != cur[len])
>   break;
> end:
>   return cur[len];
> }
> 
> or so (untested).  Of course, it could be done using SIMD too if there is a
> way to terminate the loop if any of the elts is different and could be done
> in that case at 16 or 32 or 64 characters at a time etc.
> But, without knowing that pos is typically some power of two this would just
> waste code size, dealing with the unaligned cases would be more complicated
> (one can't read the next elt until proving that the current one is all
> equal), so it would need to involve some rotations (or permutes for SIMD).

Unaligned reading is supported on some platforms already, and reading
multi-bytes(64/128bits) takes far less cost than reading 8bits multi-times,
extremely, dword reading may cost the same cycles as byte reading.
As the above discussions, there are still a few kinds of stuff need to take
care of.  I’m wondering if we could introduce this as a compiler optimization
in some circumstances.

[Bug target/95471] New: vrndvq_f32 not supported on armv8

[e...@coeus-group.com]

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

Bug ID: 95471
   Summary: vrndvq_f32 not supported on armv8
   Product: gcc
   Version: 9.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: e...@coeus-group.com
  Target Milestone: ---

With -march=armv8-a -mfpu=neon, arm_neon.h exposes vrndnq_f32, but the
intrinsic used to implement it (__builtin_neon_vrintnv4sf) emits an "error:
this builtin is not supported for this target".

Here is a trivial test case:

  #include 

  #if defined(__ARM_NEON)
  float32x4_t foo(float32x4_t a) {
return vrndnq_f32(a);
  }
  #endif

On Compiler Explorer: https://godbolt.org/z/ThfJQe

Relevant documentation from ARM:
.

[Bug target/37759] powerpc option -mabi=no-spe still generates SPE instructions

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WONTFIX
 CC||egallager at gcc dot gnu.org

--- Comment #11 from Eric Gallager  ---
(In reply to Eric Gallager from comment #10)
> (In reply to Arseny Solokha from comment #9)
> > Yes, but AFAIK none of the PRs specific to powerpcspe have been closed so
> > far. And, personally, I'd like them to stay open for another release cycle
> > in the hope Andrew would actually revive the target this year. But it's up
> > to gcc maintainers to decide, of course.
> 
> OK, leaving this open then...

The consensus here seemed to be to close them:
https://gcc.gnu.org/pipermail/gcc/2020-May/232591.html

So, I'm closing this.

[Bug c++/92838] ICE (internal compiler error) calling lambda object with requires clause (in in dependent_type_p)

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r11-779-gc2449995ca36ea955e3c6d4ee7f0d401b512c897
Author: Patrick Palka 
Date:   Mon Jun 1 21:37:04 2020 -0400

c++: constrained lambda inside template [PR92633]

When regenerating a constrained lambda during instantiation of an
enclosing template, we are forgetting to substitute into the lambda's
constraints.  Fix this by substituting through the constraints during
tsubst_lambda_expr.

gcc/cp/ChangeLog:

PR c++/92633
PR c++/92838
* pt.c (tsubst_function_decl): Don't do set_constraints when
regenerating a lambda.
(tsubst_lambda_expr): Substitute into the lambda's constraints
and do set_constraints here.

gcc/testsuite/ChangeLog:

PR c++/92633
PR c++/92838
* g++.dg/cpp2a/concepts-lambda11.C: New test.
* g++.dg/cpp2a/concepts-lambda12.C: New test.

[Bug c++/92633] [concepts] constrained lambda with placehoder syntax getting wrong substitution

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r11-779-gc2449995ca36ea955e3c6d4ee7f0d401b512c897
Author: Patrick Palka 
Date:   Mon Jun 1 21:37:04 2020 -0400

c++: constrained lambda inside template [PR92633]

When regenerating a constrained lambda during instantiation of an
enclosing template, we are forgetting to substitute into the lambda's
constraints.  Fix this by substituting through the constraints during
tsubst_lambda_expr.

gcc/cp/ChangeLog:

PR c++/92633
PR c++/92838
* pt.c (tsubst_function_decl): Don't do set_constraints when
regenerating a lambda.
(tsubst_lambda_expr): Substitute into the lambda's constraints
and do set_constraints here.

gcc/testsuite/ChangeLog:

PR c++/92633
PR c++/92838
* g++.dg/cpp2a/concepts-lambda11.C: New test.
* g++.dg/cpp2a/concepts-lambda12.C: New test.

[Bug jit/95470] New: Type checking too rigid for shifts

[bouanto at zoho dot com]

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

Bug ID: 95470
   Summary: Type checking too rigid for shifts
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: jit
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: bouanto at zoho dot com
  Target Milestone: ---

Hi.
It seems the type checking for gcc_jit_context_new_binary_op
(GCC_JIT_BINARY_OP_LSHIFT) is too rigid.
For instance, you cannot shift an unsigned number with a negative (signed
number) because it wants both type to match.
I think it would make sense to allow a negative shift for unsigned numbers.
Thanks.

[Bug libstdc++/95392] [11 Regression] Build failure on MinGW

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work|10.1.0  |
 Resolution|--- |FIXED

--- Comment #3 from Jonathan Wakely  ---
Should be fixed now, thanks for reporting it.

[Bug libstdc++/95392] [11 Regression] Build failure on MinGW

[cvs-commit at gcc dot gnu.org]

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Jonathan Wakely :

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

commit r11-777-gcd3f067b82a1331f5fb695879ba5c3d9bb2cca3a
Author: Jonathan Wakely 
Date:   Tue Jun 2 00:07:05 2020 +0100

libstdc++: Fix filesystem::u8path for mingw targets (PR 95392)

When I refactored filesystem::path string conversions in
r11-587-584d52b088f9fcf78704b504c3f1f07e17c1cded I failed to update the
mingw-specific code in filesystem::u8path, causing a bootstrap failure.

This fixes it, and further refactors the mingw-specific code along the
same lines as the previous commit. All conversions from UTF-8 strings to
wide strings now use the same helper function, __wstr_from_utf8.

PR libstdc++/95392
* include/bits/fs_path.h (path::_S_to_string): Move to
namespace-scope and rename to ...
(__detail::__string_from_range): ... this.
[WINDOWS] (__detail::__wstr_from_utf8): New function template to
convert a char sequence containing UTF-8 to wstring.
(path::_S_convert(Iter, Iter)): Adjust call to _S_to_string.
(path::_S_convert_loc(Iter, Iter, const locale&)): Likewise.
(u8path(InputIterator, InputIterator)) [WINDOWS]: Use
__string_from_range to obtain a contiguous range and
__wstr_from_utf8 to obtain a wide string.
(u8path(const Source&)) [WINDOWS]: Use __effective_range to
obtain a contiguous range and __wstr_from_utf8 to obtain a wide
string.
(path::_S_convert(const _EcharT*, const _EcharT)) [WINDOWS]:
Use __wstr_from_utf8.

[Bug target/95469] New: [11 regression] several vperm test case failures after r11-736 on power 9 (only)

[seurer at linux dot vnet.ibm.com]

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

Bug ID: 95469
   Summary: [11 regression] several vperm test case failures after
r11-736 on power 9 (only)
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at linux dot vnet.ibm.com
  Target Milestone: ---

g:ee969a36d9887e1a3230fe3de2d398fd6c6dac49, r11-736

> FAIL: gcc.target/powerpc/fold-vec-perm-char.c scan-assembler-times vperm 3
> FAIL: gcc.target/powerpc/fold-vec-perm-double.c scan-assembler-times vperm 1
> FAIL: gcc.target/powerpc/fold-vec-perm-float.c scan-assembler-times vperm 1
> FAIL: gcc.target/powerpc/fold-vec-perm-int.c scan-assembler-times vperm 3
> FAIL: gcc.target/powerpc/fold-vec-perm-longlong.c scan-assembler-times vperm 3
> FAIL: gcc.target/powerpc/fold-vec-perm-pixel.c scan-assembler-times vperm 1
> FAIL: gcc.target/powerpc/fold-vec-perm-short.c scan-assembler-times vperm 3
> FAIL: gcc.target/powerpc/lvsl-lvsr.c scan-assembler-times vperm 2
> FAIL: gcc.target/powerpc/vec-mult-char-2.c scan-assembler-times vperm 2
> FAIL: gcc.target/powerpc/vsx-vector-6.p9.c scan-assembler-times 
> \\m(?:vpermr?|xxperm)\\M 1

[Bug middle-end/95395] gcc.dg/builtin-bswap-11.c FAILs

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #3 from Eric Botcazou  ---
Fixing.

[Bug middle-end/95395] gcc.dg/builtin-bswap-11.c FAILs

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

   Last reconfirmed||2020-06-01
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #2 from Eric Botcazou  ---
Likewise on Linux.

[Bug target/84553] -rdynamic generates TEXTREL relocations on ia64

[slyfox at inbox dot ru]

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

--- Comment #6 from Sergei Trofimovich  ---
Gentoo runs the patch for a while system-wide and it seems to work fine. Worth
submitting the patch for review?

[Bug target/95237] LOCAL_DECL_ALIGNMENT shrinks alignment, FAIL gcc.target/i386/pr69454-2.c

[hjl.tools at gmail dot com]

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

--- Comment #5 from H.J. Lu  ---
On i386, we don't do dynamic stack realignment for long long objects with
-mpreferred-stack-boundary=2 on purpose.  A backend should be allowed to
opt-out

gcc_assert (align >= DECL_ALIGN (var));

based one variable type.

[Bug c++/95232] [11 Regression] ICE in make_ssa_name_fn, at tree-ssanames.c:279 since r11-283-gf315d1477d5164cb

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug c++/95193] [11 Regression] ICE in tsubst_decl, at cp/pt.c:14624

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug c++/95466] [11 Regression] ICE in tree_operand_check, at tree.h:3794 since r11-578-g72af65b91cc2a2eb

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #2 from Jason Merrill  ---
Fixed.

[Bug c++/95466] [11 Regression] ICE in tree_operand_check, at tree.h:3794 since r11-578-g72af65b91cc2a2eb

[cvs-commit at gcc dot gnu.org]

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

--- Comment #1 from CVS Commits  ---
The master branch has been updated by Jason Merrill :

https://gcc.gnu.org/g:172f2c42a10fd470c93f1e84575de9766c157591

commit r11-775-g172f2c42a10fd470c93f1e84575de9766c157591
Author: Jason Merrill 
Date:   Mon Jun 1 16:20:38 2020 -0400

c++: vptr ubsan and object of known type [PR95466]

Another case where we can't find the OBJ_TYPE_REF_OBJECT in the
OBJ_TYPE_REF_EXPR.  So let's just evaluate the sanitize call first.

gcc/cp/ChangeLog:

PR c++/95466
PR c++/95311
PR c++/95221
* class.c (build_vfn_ref): Revert 95311 change.
* cp-ubsan.c (cp_ubsan_maybe_instrument_member_call): Build a
COMPOUND_EXPR.

gcc/testsuite/ChangeLog:

PR c++/95466
* g++.dg/ubsan/vptr-17.C: New test.

[Bug c++/95311] [11 Regression] ICE in cp_ubsan_maybe_instrument_member_call at gcc/cp/cp-ubsan.c:136 since r11-578-g72af65b91cc2a2eb

[cvs-commit at gcc dot gnu.org]

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

--- Comment #5 from CVS Commits  ---
The master branch has been updated by Jason Merrill :

https://gcc.gnu.org/g:172f2c42a10fd470c93f1e84575de9766c157591

commit r11-775-g172f2c42a10fd470c93f1e84575de9766c157591
Author: Jason Merrill 
Date:   Mon Jun 1 16:20:38 2020 -0400

c++: vptr ubsan and object of known type [PR95466]

Another case where we can't find the OBJ_TYPE_REF_OBJECT in the
OBJ_TYPE_REF_EXPR.  So let's just evaluate the sanitize call first.

gcc/cp/ChangeLog:

PR c++/95466
PR c++/95311
PR c++/95221
* class.c (build_vfn_ref): Revert 95311 change.
* cp-ubsan.c (cp_ubsan_maybe_instrument_member_call): Build a
COMPOUND_EXPR.

gcc/testsuite/ChangeLog:

PR c++/95466
* g++.dg/ubsan/vptr-17.C: New test.

[Bug c++/95221] g++.dg/ubsan/vptr-12.C fails with -fstrong-eval-order=all

[cvs-commit at gcc dot gnu.org]

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

--- Comment #9 from CVS Commits  ---
The master branch has been updated by Jason Merrill :

https://gcc.gnu.org/g:172f2c42a10fd470c93f1e84575de9766c157591

commit r11-775-g172f2c42a10fd470c93f1e84575de9766c157591
Author: Jason Merrill 
Date:   Mon Jun 1 16:20:38 2020 -0400

c++: vptr ubsan and object of known type [PR95466]

Another case where we can't find the OBJ_TYPE_REF_OBJECT in the
OBJ_TYPE_REF_EXPR.  So let's just evaluate the sanitize call first.

gcc/cp/ChangeLog:

PR c++/95466
PR c++/95311
PR c++/95221
* class.c (build_vfn_ref): Revert 95311 change.
* cp-ubsan.c (cp_ubsan_maybe_instrument_member_call): Build a
COMPOUND_EXPR.

gcc/testsuite/ChangeLog:

PR c++/95466
* g++.dg/ubsan/vptr-17.C: New test.

[Bug target/95237] LOCAL_DECL_ALIGNMENT shrinks alignment, FAIL gcc.target/i386/pr69454-2.c

[skpgkp2 at gmail dot com]

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

--- Comment #4 from Sunil Pandey  ---
This test case and many other regression on x86 caused by following change set
r11-508

Good

$
/local/skpandey/gccwork/pr95237/tools-build/gcc-debug-r11-507/release/usr/gcc-11.0.0-x86-64/bin/gcc
-m32 -mpreferred-stack-boundary=2 foo.c
bash-5.0$ echo $?
0

Bad
===
bash-5.0$
/local/skpandey/gccwork/pr95237/tools-build/gcc-debug-r11-508/release/usr/gcc-11.0.0-x86-64/bin/gcc
-m32 -mpreferred-stack-boundary=2 foo.c
during GIMPLE pass: adjust_alignment
foo.c: In function ??main??:
foo.c:7:5: internal compiler error: in execute, at adjust-alignment.c:73
7 | int main()
  | ^~~~
0x206a091 execute
/local/skpandey/gccwork/pr95237/gcc/gcc/adjust-alignment.c:73
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

$git show dfa4fcdba374ed44d4aa1a22b2738f3f5c5b37af
commit dfa4fcdba374ed44d4aa1a22b2738f3f5c5b37af
Author: Kito Cheng 
Date:   Tue Apr 14 14:53:19 2020 +0800

Fix alignment for local variable [PR90811]

 - The alignment for local variable was adjust during
estimate_stack_frame_size,
   however it seems wrong spot to adjust that, expand phase will adjust
that
   but it little too late to some gimple optimization, which rely on
certain
   target hooks need to check alignment, forwprop is an example for
   that, result of simplify_builtin_call rely on the alignment on some
   target like ARM or RISC-V.

 - Exclude static local var and hard register var in the process of
   alignment adjustment.

 - This patch fix gfortran.dg/pr45636.f90 for arm and riscv.

 - Regression test on riscv32/riscv64 and x86_64-linux-gnu, no new fail
   introduced.

gcc/ChangeLog

PR target/90811
* Makefile.in (OBJS): Add adjust-alignment.o.
* adjust-alignment.c (pass_data_adjust_alignment): New.
(pass_adjust_alignment): New.
(pass_adjust_alignment::execute): New.
(make_pass_adjust_alignment): New.
* tree-pass.h (make_pass_adjust_alignment): New.
* passes.def: Add pass_adjust_alignment.

diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 9eee988e12c..fdaa94ae8b9 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,14 @@
+2020-05-20  Kito Cheng  
+
+   PR target/90811
+   * Makefile.in (OBJS): Add adjust-alignment.o.
+   * adjust-alignment.c (pass_data_adjust_alignment): New.
+   (pass_adjust_alignment): New.
+   (pass_adjust_alignment::execute): New.
+   (make_pass_adjust_alignment): New.
+   * tree-pass.h (make_pass_adjust_alignment): New.
+   * passes.def: Add pass_adjust_alignment.


GDB dump:
=

The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program:
/local/skpandey/gccwork/pr95237/tools-build/gcc-debug-r11-508/release/usr/gcc-11.0.0-x86-64/libexec/gcc/x86_64-pc-linux-gnu/11.0.0/cc1
-quiet -imultilib 32 -iprefix
/local/skpandey/gccwork/pr95237/tools-build/gcc-debug-r11-508/release/usr/gcc-11.0.0-x86-64/bin/../lib/gcc/x86_64-pc-linux-gnu/11.0.0/
foo.c -quiet -dumpbase foo.c -m32 -mpreferred-stack-boundary=2 -mtune=generic
-march=x86-64 -auxbase foo -o /tmp/ccEnTcu1.s
  File "/usr/share/gdb/auto-load/usr/lib64/libisl.so.15.1.1-gdb.py", line 67
print "No isl printer for this type"
   ^
SyntaxError: Missing parentheses in call to 'print'. Did you mean print("No isl
printer for this type")?

Breakpoint 1, (anonymous namespace)::pass_adjust_alignment::execute
(this=0x32fbb10, fun=0x7fffea9340b0)
at /local/skpandey/gccwork/pr95237/gcc/gcc/adjust-alignment.c:73
73gcc_assert (align >= DECL_ALIGN (var));
(gdb) c
Continuing.

Breakpoint 1, (anonymous namespace)::pass_adjust_alignment::execute
(this=0x32fbb10, fun=0x7fffea9340b0)
at /local/skpandey/gccwork/pr95237/gcc/gcc/adjust-alignment.c:73
73gcc_assert (align >= DECL_ALIGN (var));
(gdb) n
during GIMPLE pass: adjust_alignment
foo.c: In function ??main??:
foo.c:7:5: internal compiler error: in execute, at adjust-alignment.c:73
7 | int main()
  | ^~~~
0x206a091 execute
/local/skpandey/gccwork/pr95237/gcc/gcc/adjust-alignment.c:73
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
[Inferior 1 (process 4132225) exited with code 04]
(gdb) 

Can we just exclude adjust-alignment pass for x86?

[Bug libfortran/95418] [11 Regression] Static assert going off on MinGW

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED
 Target||x86_64-w64-mingw32

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

[Bug libfortran/95418] [11 Regression] Static assert going off on MinGW

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:832c1192eba6dd100e2f757e30ea6373f782ff55

commit r11-774-g832c1192eba6dd100e2f757e30ea6373f782ff55
Author: Uros Bizjak 
Date:   Mon Jun 1 22:23:51 2020 +0200

i386: Add __attribute__ ((gcc_struct)) to struct fenv [PR95418]

Windows ABI (MinGW) is different than Linux ABI when bitfileds are
involved.
The following patch adds __attribute__ ((gcc_struct)) to struct fenv in
order
to match the layout of x87 state image in memory.

2020-06-01  Uroš Bizjak  

libatomic/ChangeLog:
* config/x86/fenv.c (struct fenv): Add __attribute__
((gcc_struct)).

libgcc/ChangeLog:
* config/i386/sfp-exceptions.c (struct fenv):
Add __attribute__ ((gcc_struct)).

libgfortran/ChangeLog:
PR libfortran/95418
* config/fpu-387.h (struct fenv): Add __attribute__ ((gcc_struct)).

[Bug middle-end/95464] [10/11 Regression] Miscompilation of mesa on x86_64-linux since r10-6426

[vmakarov at gcc dot gnu.org]

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

--- Comment #1 from Vladimir Makarov  ---
Jakub, thank you for working on the PR and providing the test case.

It seems to me that the problem occurs in inheritance sub-pass of LRA.  It is a
very complicated sub-pass.  Making a fix and testing it can take a few days. 
But I hope to fix the PR on this week.

[Bug c++/95468] New: ICE in expression sfinae

[kab at acm dot org]

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

Bug ID: 95468
   Summary: ICE in expression sfinae
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kab at acm dot org
  Target Milestone: ---

The code below gets ICE with gcc9.2 and gcc7.5 (the versions I have immediately
available to test with).

The error message is:
internal compiler error: unexpected expression '(bool)(true)' of kind cast_expr

To test:
g++ -c -std=c++11 ice-expr-sfinae.cpp

Strangely, using a namespace scope function template instead of a static member
function template works fine.  To demonstrate that, compile with
-DTRIGGER_ICE=0.

- ice-expr-sfinae.cpp -

#include 

#ifndef TRIGGER_ICE
#define TRIGGER_ICE 1
#endif

#if TRIGGER_ICE

struct slip {
  template static constexpr bool condition() { return C; }
};

template(), int>::type = 0>
static bool dispatch() { return true; }

bool test() {
  return dispatch();
}

#else

// No ICE if the condition function is at namespace scope.

template static constexpr bool noslip_condition() { return C; }

template(), int>::type =
0>
static bool dispatch() { return true; }

bool test() {
  return dispatch();
}

#endif

- end of file -

[Bug c++/95466] [11 Regression] ICE in tree_operand_check, at tree.h:3794 since r11-578-g72af65b91cc2a2eb

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug c++/95181] [10/11 Regression] ICE in push_access_scope, at cp/pt.c:241 since r10-3735-gcb57504a55015891

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #10 from Jason Merrill  ---
Fixed for 10.2/11.

[Bug c++/95371] [10/11 Regression] ICE concepts with template template parameter since r10-3735-gcb57504a55015891

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #4 from Jason Merrill  ---
Fixed for 10.2/11.

[Bug jit/95426] libgccjit.so: error: RTL check: expected elt 2 type 'B', have '0' (rtx barrier) in BLOCK_FOR_INSN

[dmalcolm at gcc dot gnu.org]

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

--- Comment #5 from David Malcolm  ---
Created attachment 48657
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48657=edit
Reduced test case

I've reduced the reproducer you posted to this test case.

Seems to require a call to __builtin_unreachable followed by code, without
optimization, leading to a crash in the "expand" pass when transitioning from
gimple to RTL internally, due to an unexpected barrier insn in the RTL.

[Bug fortran/94109] Memory leak introduced in 8.3.0->8.3.1

[tkoenig at gcc dot gnu.org]

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

--- Comment #5 from Thomas Koenig  ---
So, fixed with the patch for PR 94109?

[Bug tree-optimization/50439] gfortran infinite loop with -floop-interchange

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 CC||tkoenig at gcc dot gnu.org
 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2020-06-01

--- Comment #11 from Thomas Koenig  ---
I just stumbled across this, and it seems fixed.

Commit the test case and close?

[Bug fortran/95467] New: ICE in parse_omp_structured_block: OpenMP Offload (target_parallel__simd)

[tapplencourt at anl dot gov]

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

Bug ID: 95467
   Summary: ICE in parse_omp_structured_block: OpenMP Offload
(target_parallel__simd)
   Product: gcc
   Version: lto
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tapplencourt at anl dot gov
  Target Milestone: ---

Created attachment 48656
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48656=edit
compilation.log

Hi, 

The following F90 OpenMP code causea ICE (see log attached): 


PROGRAM target_parallel__simd
USE OMP_LIB
implicit none
INTEGER :: i
INTEGER :: counter
!$OMP TARGET PARALLEL MAP(TOFROM: counter)
!$OMP SIMD
DO i = 1 , 262144
counter = 1
END DO
!$OMP END PARALLEL
END PROGRAM target_parallel__simd

I was able to reproduce it on GCC9.2 and GCC10.0

Don't hesitation if you have any question,
Regards,
Thomas

[Bug c++/95466] [11 Regression] ICE in tree_operand_check, at tree.h:3794 since r11-578-g72af65b91cc2a2eb

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

[Bug c++/95466] New: [11 Regression] ICE in tree_operand_check, at tree.h:3794 since r11-578-g72af65b91cc2a2eb

[marxin at gcc dot gnu.org]

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

Bug ID: 95466
   Summary: [11 Regression] ICE in tree_operand_check, at
tree.h:3794 since r11-578-g72af65b91cc2a2eb
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: jason at gcc dot gnu.org
  Target Milestone: ---

Since the revision I see:

$ cat multi.ii
class A {
  virtual void m_fn1();
};
class C {
public:
  virtual void m_fn2();
};
class B : A, public C {};
main() {
  B b;
  static_cast()->m_fn2();
}

$ g++ multi.ii -c -fsanitize=vptr
multi.ii:9:1: warning: ISO C++ forbids declaration of ‘main’ with no type
[-Wreturn-type]
9 | main() {
  | ^~~~
multi.ii: In function ‘int main()’:
multi.ii:12:1: internal compiler error: tree check: expected class
‘expression’, have ‘declaration’ (var_decl) in tree_operand_check, at
tree.h:3794
   12 | }
  | ^
0x848dc6 tree_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)
/home/marxin/Programming/gcc/gcc/tree.c:9756
0x641b85 expr_check(tree_node*, char const*, int, char const*)
/home/marxin/Programming/gcc/gcc/tree.h:3465
0x641b85 tree_operand_check(tree_node*, int, char const*, int, char const*)
/home/marxin/Programming/gcc/gcc/tree.h:3794
0x641b85 cp_ubsan_maybe_instrument_member_call(tree_node*)
/home/marxin/Programming/gcc/gcc/cp/cp-ubsan.c:136
0x9a5f93 cp_genericize_r
/home/marxin/Programming/gcc/gcc/cp/cp-gimplify.c:1775
0x138abf3 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
/home/marxin/Programming/gcc/gcc/tree.c:11978
0x9a66ca cp_genericize_r
/home/marxin/Programming/gcc/gcc/cp/cp-gimplify.c:1847
0x138abf3 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
/home/marxin/Programming/gcc/gcc/tree.c:11978
0x9a78b2 cp_genericize_r
/home/marxin/Programming/gcc/gcc/cp/cp-gimplify.c:1456
0x138abf3 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
/home/marxin/Programming/gcc/gcc/tree.c:11978
0x9a66ca cp_genericize_r
/home/marxin/Programming/gcc/gcc/cp/cp-gimplify.c:1847
0x138abf3 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
/home/marxin/Programming/gcc/gcc/tree.c:11978
0x9a4de8 cp_genericize_tree
/home/marxin/Programming/gcc/gcc/cp/cp-gimplify.c:1882
0x9a5074 cp_genericize(tree_node*)
/home/marxin/Programming/gcc/gcc/cp/cp-gimplify.c:2031
0x9e6d61 finish_function(bool)
/home/marxin/Programming/gcc/gcc/cp/decl.c:17201
0xa92eaa cp_parser_function_definition_after_declarator
/home/marxin/Programming/gcc/gcc/cp/parser.c:29024
0xa93c81 cp_parser_function_definition_from_specifiers_and_declarator
/home/marxin/Programming/gcc/gcc/cp/parser.c:28937
0xa93c81 cp_parser_init_declarator
/home/marxin/Programming/gcc/gcc/cp/parser.c:20685
0xa72ea3 cp_parser_simple_declaration
/home/marxin/Programming/gcc/gcc/cp/parser.c:13749
0xa9bbc7 cp_parser_declaration
/home/marxin/Programming/gcc/gcc/cp/parser.c:13448
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug c++/95350] [coroutines] coroutines with move-only by-value parameters attempt to copy parameter instead of move it

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:88f48e2967ead9be262483618238efa9c7c842ec

commit r11-773-g88f48e2967ead9be262483618238efa9c7c842ec
Author: Iain Sandoe 
Date:   Mon Jun 1 08:28:35 2020 +0100

coroutines: Correct handling of references in parm copies [PR95350].

Adjust to handle rvalue refs the same way as clang, and to correct
the handling of moves when a copy CTOR is present.  This is one area
where we could make things easier for the end-user (as was implemented
before this change), however there needs to be agreement about when the
full statement containing a coroutine call ends (i.e. when the ramp
terminates or when the coroutine terminates).

gcc/cp/ChangeLog:

PR c++/95350
* coroutines.cc (struct param_info): Remove rv_ref field.
(build_actor_fn): Remove specifial rvalue ref handling.
(morph_fn_to_coro): Likewise.

gcc/testsuite/ChangeLog:

PR c++/95350
* g++.dg/coroutines/torture/func-params-08.C: Adjust test to
reflect that all rvalue refs are dangling.
* g++.dg/coroutines/torture/func-params-09-awaitable-parms.C:
Likewise.
* g++.dg/coroutines/pr95350.C: New test.

[Bug fortran/93691] Type bound assignment causes too many finalization of derived type when part of other type

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 CC||tkoenig at gcc dot gnu.org
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-06-01

--- Comment #1 from Thomas Koenig  ---
Confirmed.

[Bug fortran/94361] [8/9/10/11 Regression] Memory leak in nested types with final

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

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

--- Comment #10 from Thomas Koenig  ---
Fixed on all open branches.

Thanks for the bug report!

[Bug fortran/37336] [F03] Finish derived-type finalization

[tkoenig at gcc dot gnu.org]

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

Bug 94361 Summary: [8/9/10/11 Regression] Memory leak in nested types with final
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94361

   What|Removed |Added

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

[Bug fortran/94361] [8/9/10/11 Regression] Memory leak in nested types with final

[cvs-commit at gcc dot gnu.org]

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

--- Comment #9 from CVS Commits  ---
The releases/gcc-8 branch has been updated by Thomas Kथà¤nig
:

https://gcc.gnu.org/g:75f5824b77632ef583a7a65302b326e8bf1b851c

commit r8-10289-g75f5824b77632ef583a7a65302b326e8bf1b851c
Author: Thomas Koenig 
Date:   Sun May 31 10:26:40 2020 +0200

Finalization depends on the expression, not on the component.

This patch fixes a 8/9/10/11 regression, where finalized types
were not finalized (and deallocated), which led to memory
leaks.

gcc/fortran/ChangeLog:

2020-05-24  Thomas Koenig  

PR fortran/94361
* class.c (finalize_component): Use expr->finalized instead of
comp->finalized.
* gfortran.h (gfc_component): Remove finalized member.
(gfc_expr): Add it here instead.

gcc/testsuite/ChangeLog:

2020-05-24  Thomas Koenig  

PR fortran/94361
* gfortran.dg/finalize_28.f90: Adjusted free counts.
* gfortran.dg/finalize_34.f90: Likewise.
* gfortran.dg/finalize_35.f90: New test.

(cherry picked from commit 2a0de88ccf2ecc6659b0f1e4580c1ce5cff976b3)

[Bug fortran/94361] [8/9/10/11 Regression] Memory leak in nested types with final

[cvs-commit at gcc dot gnu.org]

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

--- Comment #8 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Thomas Kथà¤nig
:

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

commit r9-8643-g2a0de88ccf2ecc6659b0f1e4580c1ce5cff976b3
Author: Thomas Koenig 
Date:   Sun May 31 10:26:40 2020 +0200

Finalization depends on the expression, not on the component.

This patch fixes a 8/9/10/11 regression, where finalized types
were not finalized (and deallocated), which led to memory
leaks.

gcc/fortran/ChangeLog:

2020-05-24  Thomas Koenig  

PR fortran/94361
* class.c (finalize_component): Use expr->finalized instead of
comp->finalized.
* gfortran.h (gfc_component): Remove finalized member.
(gfc_expr): Add it here instead.

gcc/testsuite/ChangeLog:

2020-05-24  Thomas Koenig  

PR fortran/94361
* gfortran.dg/finalize_28.f90: Adjusted free counts.
* gfortran.dg/finalize_33.f90: Likewise.
* gfortran.dg/finalize_34.f90: Likewise.
* gfortran.dg/finalize_35.f90: New test.

(cherry picked from commit 811f902b764c5a13178cbd7588e96c16b3fab504)

[Bug c++/95465] [8/9/10/11 Regression] ICE on jump into a statement expression

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||gabravier at gmail dot com
   Target Milestone|--- |8.5

--- Comment #1 from Jakub Jelinek  ---
Guess could be considered a dup of PR772.

[Bug c++/95465] New: [8/9/10/11 Regression] ICE on jump into a statement expression

[jakub at gcc dot gnu.org]

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

Bug ID: 95465
   Summary: [8/9/10/11 Regression] ICE on jump into a statement
expression
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

void
foo ()
{
  sizeof (({ label: 0; }));
  goto label;
}

ICEs with C++:
during GIMPLE pass: cfg
rh1842304.C: In function ‘void foo()’:
rh1842304.C:2:1: internal compiler error: Segmentation fault
2 | foo ()
  | ^~~
0x15fc130 crash_signal
../../gcc/toplev.c:328
0x1658942 main_block_label
../../gcc/tree-cfg.c:1455
0x16590e4 cleanup_dead_labels()
../../gcc/tree-cfg.c:1639
but with C is rejected:
rh1842304.C: In function ‘foo’:
rh1842304.C:5:3: error: jump into statement expression
5 |   goto label;
  |   ^~~~
rh1842304.C:4:14: note: label ‘label’ defined here
4 |   sizeof (({ label: 0; }));
  |  ^

Used to be accepted by both C and C++ in GCC 3.4, but already r105000 ICEs in
C++ and rejects it in C.

[Bug fortran/94361] [8/9/10/11 Regression] Memory leak in nested types with final

[cvs-commit at gcc dot gnu.org]

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

--- Comment #7 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Thomas Kथà¤nig
:

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

commit r10-8218-gb703627d668257c0955a43838288e91973bf2721
Author: Thomas Koenig 
Date:   Sun May 31 10:26:40 2020 +0200

Finalization depends on the expression, not on the component.

This patch fixes a 8/9/10/11 regression, where finalized types
were not finalized (and deallocated), which led to memory
leaks.

gcc/fortran/ChangeLog:

2020-05-24  Thomas Koenig  

PR fortran/94361
* class.c (finalize_component): Use expr->finalized instead of
comp->finalized.
* gfortran.h (gfc_component): Remove finalized member.
(gfc_expr): Add it here instead.

gcc/testsuite/ChangeLog:

2020-05-24  Thomas Koenig  

PR fortran/94361
* gfortran.dg/finalize_28.f90: Adjusted free counts.
* gfortran.dg/finalize_33.f90: Likewise.
* gfortran.dg/finalize_34.f90: Likewise.
* gfortran.dg/finalize_35.f90: New test.

(cherry picked from commit 811f902b764c5a13178cbd7588e96c16b3fab504)

[Bug middle-end/95464] New: [10/11 Regression] Miscompilation of mesa on x86_64-linux since r10-6426

[jakub at gcc dot gnu.org]

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

Bug ID: 95464
   Summary: [10/11 Regression] Miscompilation of mesa on
x86_64-linux since r10-6426
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

Since r10-6426-g5f0653a8b75a5ad5a5405a27dd92d3a5759eed4c we on x86_64-linux
miscompile following testcase at -O2:
struct S { unsigned a:1, b:1, c:1, d:1, e:14, f:14; };

__attribute__((noipa)) int
foo (struct S x)
{
  if (x.a != 0 || x.b != 1 || x.c != 0 || x.d != 1
  || x.e != 7239 || x.f != 6474)
__builtin_abort ();
}

__attribute__((noipa)) void
bar (struct S x, struct S y)
{
  if (x.a != 0 || x.b != 1 || x.c != 0 || x.d != 1
  || x.e != 7239 || x.f != 6474)
__builtin_abort ();
  if (y.a != 0 || y.b != 1 || y.c != 1 || y.d != 1
  || y.e != 16320 || y.f != 7315)
__builtin_abort ();
}

__attribute__((noipa)) void
baz (struct S x)
{
  if (x.a != 1 || x.b != 1 || x.c != 1 || x.d != 1
  || x.e != 16320 || x.f != 7315)
__builtin_abort ();
}

__attribute__((noipa)) void
qux (struct S x, struct S y, unsigned z)
{
  struct S a = x, b;
  for (unsigned i = 0; i < z; ++i)
foo (x);
  if (x.a && x.e == 16)
a.e = 32;
  b = a;
  b.c = y.c;
  b.e = y.e;
  b.f = y.f;
  bar (a, b);
  a = b;
  __asm volatile ("" : : : "ax", "bx", "cx", "dx", "si", "di",
#ifdef __OPTIMIZE__
   "bp",
#endif
   "r8", "r9", "r10", "r11", "r12", "r13", "r14",
"r15");
  a.a = 1;
  a.c = 1;
  baz (a);
}

int
main ()
{
  struct S x = { 0, 1, 0, 1, 7239, 6474 };
  struct S y = { 1, 0, 1, 0, 16320, 7315 };
  qux (x, y, 1);
  return 0;
}

(in original source obviously there was no inline asm, but instead the function
was large enough that the variable got spilled).
I believe this is a RA bug though.  In *.ira we have:
(insn 67 66 68 3 (parallel [
(set (strict_low_part (subreg:QI (reg/v:SI 94 [ a ]) 0))
(ior:QI (subreg:QI (reg/v:SI 94 [ a ]) 0)
(const_int 5 [0x5])))
(clobber (reg:CC 17 flags))
]) "gallivm2.c":51:3 492 {*iorqi_1_slp}
 (expr_list:REG_UNUSED (reg:CC 17 flags)
(nil)))
(insn 68 67 69 3 (set (reg:SI 5 di)
(reg/v:SI 94 [ a ])) "gallivm2.c":51:3 67 {*movsi_internal}
 (expr_list:REG_DEAD (reg/v:SI 94 [ a ])
(nil)))
which looks good to me, the strict_low_part in there says that the low 8 bits
of pseudo 94 are ored with 5 and the upper 24 bits stay as is (so, in the end
it is the same as SImode |= 5, not really sure why we ended up with that, e.g.
if the loop calling foo is changed into a single call to foo, it doesn't
happen).
But LRA changes this into:
(insn 120 66 67 3 (set (reg:QI 0 ax [137])
(mem/c:QI (plus:DI (reg/f:DI 7 sp)
(const_int 8 [0x8])) [4 %sfp+-8 S1 A32])) "gallivm2.c":51:3 69
{*movqi_internal}
 (nil))
(insn 67 120 121 3 (parallel [
(set (strict_low_part (reg:QI 0 ax [137]))
(ior:QI (reg:QI 0 ax [137])
(const_int 5 [0x5])))
(clobber (reg:CC 17 flags))
]) "gallivm2.c":51:3 492 {*iorqi_1_slp}
 (nil))
(insn 121 67 122 3 (set (reg:QI 5 di [orig:94 a ] [94])
(reg:QI 0 ax [137])) "gallivm2.c":51:3 69 {*movqi_internal}
 (nil))
which is not equivalent, because it makes the upper 24 bits undefined instead
of  loaded from the spill slot.

[Bug middle-end/95464] [10/11 Regression] Miscompilation of mesa on x86_64-linux since r10-6426

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Last reconfirmed||2020-06-01
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Keywords||ra, wrong-code
 CC||vmakarov at gcc dot gnu.org
   Priority|P3  |P2
   Target Milestone|--- |10.2

[Bug middle-end/78678] possibly missing -Warray-bounds warning without -fsanitize=object-size

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

  Known to fail||10.1.0, 11.0, 7.3.0, 8.2.0,
   ||9.1.0
   Last reconfirmed|2017-05-02 00:00:00 |2020-6-1
Summary|possibly missing|possibly missing
   |-Warray-bounds warning  |-Warray-bounds warning
   ||without
   ||-fsanitize=object-size

--- Comment #11 from Martin Sebor  ---
Reconfirming with trunk (GCC 11).

[Bug tree-optimization/65461] -Warray-bounds due to loop unrolling in the linux kernel (free_area_init_nodes)

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

Summary|-Warray-bounds warnings in  |-Warray-bounds due to loop
   |the linux kernel|unrolling in the linux
   |(free_area_init_nodes)  |kernel
   ||(free_area_init_nodes)
  Known to fail||10.1.0, 11.0, 9.2.0
   Last reconfirmed|2017-09-28 00:00:00 |2020-6-1

--- Comment #5 from Martin Sebor  ---
Reconfirmed with GCC 10.1 and trunk:

$ gcc -O2 -S -Wall -fdump-tree-vrp=/dev/stdout pr65461.c
int f (void)
{
  int a[10] = { 0 };
  int i = 0;
  return i ? a[11] : 0;
}

;; Function func (func, funcdef_no=0, decl_uid=1934, cgraph_uid=1,
symbol_order=0)

;; 2 loops found
;;
;; Loop 0
;;  header 0, latch 1
;;  depth 0, outer -1
;;  nodes: 0 1 2 3 4 5 6 7
;;
;; Loop 1
;;  header 6, latch 5
;;  depth 1, outer 0
;;  nodes: 6 5 3 4
;; 2 succs { 6 }
;; 3 succs { 5 4 }
;; 4 succs { 5 }
;; 5 succs { 6 }
;; 6 succs { 3 7 }
;; 7 succs { 1 }

SSA replacement table
N_i -> { O_1 ... O_j } means that N_i replaces O_1, ..., O_j

i.3_12 -> { i.3_3 }
i.3_13 -> { i.3_3 }
i.3_14 -> { i.3_3 }
Incremental SSA update started at block: 6
Number of blocks in CFG: 9
Number of blocks to update: 5 ( 56%)



Value ranges after VRP:

_1: int [-INF, -1]
_2: int [-2147483647, 2]
i.3_3: int VARYING
.MEM_4: <<< error >>> VARYING
.MEM_5: <<< error >>> VARYING
i.3_12: int [-INF, 1]  EQUIVALENCES: { i.3_3 } (1 elements)
i.3_13: int [-INF, 0]  EQUIVALENCES: { i.3_3 i.3_12 } (2 elements)
i.3_14: int [1, 1]  EQUIVALENCES: { i.3_3 i.3_12 } (2 elements)


pr65461.c: In function ‘func’:
pr65461.c:10:14: warning: array subscript -1 is below array bounds of ‘int[2]’
[-Warray-bounds]
   10 | array[i-1] = 0;
  | ~^
pr65461.c:3:12: note: while referencing ‘array’
3 | extern int array[2];
  |^
Removing basic block 8
func ()
{
  int i;
  int _1;
  int _2;
  int i.3_3;

   [local count: 118111600]:
  i = 1;
  goto ; [100.00%]

   [local count: 955630225]:
  if (i.3_3 == 1)
goto ; [20.24%]
  else
goto ; [79.76%]

   [local count: 762210669]:
  _1 = i.3_3 + -1;
  array[_1] = 0;

   [local count: 955630227]:
  _2 = i.3_3 + 1;
  i = _2;

   [local count: 1073741824]:
  i.3_3 = i;
  if (i.3_3 <= 1)
goto ; [89.00%]
  else
goto ; [11.00%]

   [local count: 118111600]:
  foo ();
  i ={v} {CLOBBER};
  return;

}



;; Function func (func, funcdef_no=0, decl_uid=1934, cgraph_uid=1,
symbol_order=0)

;; 2 loops found
;;
;; Loop 0
;;  header 0, latch 1
;;  depth 0, outer -1
;;  nodes: 0 1 2
;; 2 succs { 1 }

Value ranges after VRP:



func ()
{
  int i;

   [local count: 118111600]:
  i = 2;
  foo ();
  i ={v} {CLOBBER};
  return;

}

[Bug tree-optimization/56456] [meta-bug] bogus/missing -Warray-bounds

[msebor at gcc dot gnu.org]

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

Bug 95461 Summary: GCC misses -Warray-bounds warning message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95461

   What|Removed |Added

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

[Bug middle-end/95461] GCC misses -Warray-bounds warning message

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #2 from Martin Sebor  ---
Duplicate of pr35587.

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

[Bug middle-end/35587] -Warray-bounds does not work at all or does not find all trivial cases, and :works only with -O2 or -O3

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||haoxintu at gmail dot com

--- Comment #13 from Martin Sebor  ---
*** Bug 95461 has been marked as a duplicate of this bug. ***

[Bug middle-end/95461] GCC misses -Warray-bounds warning message

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org
  Component|c++ |middle-end
 Blocks||56456

--- Comment #1 from Martin Sebor  ---
_Warray-bounds relies on optimization which includes removing unused
assignments as in the test case in comment #0, as well folding reads from many
objects to constants (valid or otherwise).  This makes it possible to detect
many non-trivial instances of the problem, such as when the index isn't
constant or the array is accessed via a pointer.

The Clang implementation, on the other hand, doesn't depend on optimization, so
it detects this simple case but not anything more interesting.

It's possible to enhance the warning so that it also triggers earlier and
detects even more instances of the problem, including some of those that don't
take place at runtime.  But doing that might also trigger what most would
consider false positives.  For instance:

$ cat x.c && clang -S -Wall x.c
int f (void)
{
  int a[10] = { 0 };
  int i = 0;
  return i ? a[11] : 0;
}
x.c:5:14: warning: array index 11 is past the end of the array (which contains
  10 elements) [-Warray-bounds]
  return i ? a[11] : 0;
 ^ ~~
x.c:3:3: note: array 'a' declared here
  int a[10] = { 0 };
  ^
1 warning generated.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456
[Bug 56456] [meta-bug] bogus/missing -Warray-bounds

[Bug middle-end/95463] missing -Warray-bounds caused by assuming unsigned integer wrapping

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Blocks||56456
   Severity|normal  |enhancement
   Keywords||diagnostic


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456
[Bug 56456] [meta-bug] bogus/missing -Warray-bounds

[Bug middle-end/95463] New: missing -Warray-bounds caused by assuming unsigned integer wrapping

[msebor at gcc dot gnu.org]

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

Bug ID: 95463
   Summary: missing -Warray-bounds caused by assuming unsigned
integer wrapping
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

GCC avoids issuing -Warray-bounds for indices whose range wraps around zero,
such as in g() below.  Since unsigned wraparound is unlikely intended, issuing
a warning in these cases would be justified even if a subset of the cases is
valid.

$ cat x.c && gcc -O2 -S -Wall x.c
char a[2];

void f (unsigned i)
{
  if (i > 2)
return;
  a[i + 2] = 0;// -Warray-bounds (good)
}

void g (unsigned i)
{
  if (i < 2) return;
  a[i + 2] = 0;// missing -Warray-bounds
}
x.c: In function ‘f’:
x.c:7:4: warning: array subscript 2 is above array bounds of ‘char[2]’
[-Warray-bounds]
7 |   a[i + 2] = 0;// -Warray-bounds (good)
  |   ~^~~
x.c:1:6: note: while referencing ‘a’
1 | char a[2];
  |  ^

[Bug sanitizer/95385] GCC stop detect UBs after a divide by zero in for statement

[haoxintu at gmail dot com]

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

--- Comment #4 from Haoxin Tu  ---
(In reply to Haoxin Tu from comment #3)

Hi, so sorry to bother you.

Is still there any problem here? Please take a look at test3.cc and test4.cc.
Thank you so much.

[Bug target/95252] testcase gcc.dg/torture/pr67916.c failure when testing with -msave-restore

[kito.cheng at gmail dot com]

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

Kito Cheng  changed:

   What|Removed |Added

 CC||kito.cheng at gmail dot com

--- Comment #8 from Kito Cheng  ---
It seems like because register rename thought all callee-saved register can be
used, because df_regs_ever_live_p return true for all callee-saved register
now, so seems like we really need an exact pattern to describe that, that's put
into my tomorrows TODO list.

[Bug jit/95462] New: Different int types for the same call to gcc_jit_context_get_int_type()

[bouanto at zoho dot com]

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

Bug ID: 95462
   Summary: Different int types for the same call to
gcc_jit_context_get_int_type()
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: jit
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: bouanto at zoho dot com
  Target Milestone: ---

Hi.
Sometimes, when I call gcc_jit_context_get_int_type(ctxt, 8, 1), I will get a
long, and sometimes I will get a long long.
On my platform, they are the same, but libgccjit will complain when giving a
long where a long long was expected.

What I suggest is to be able to get the sized type, like int64_t.
Could you please add all sized integer types (like int64_t) in the enum
gcc_jit_types?

Thanks.

[Bug gcov-profile/95348] GCC records zero functions and modules in the profiling data file, ICC does NOT

[qing.zhao at oracle dot com]

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

--- Comment #19 from Qing Zhao  ---
Hi, Martin,

I attached 3 profiling data files with this email (among over 5000 files under
one typical directory), 
Hope this is helpful.

Thanks.

Qing

[Bug gcov-profile/95348] GCC records zero functions and modules in the profiling data file, ICC does NOT

[qing.zhao at oracle dot com]

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

--- Comment #20 from Qing Zhao  ---
Created attachment 48653
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48653=edit
A.data

--- Comment #21 from Qing Zhao  ---
Created attachment 48654
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48654=edit
B.data

--- Comment #22 from Qing Zhao  ---
Created attachment 48655
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48655=edit
C.data

[Bug c++/95461] New: GCC misses -Warray-bounds warning message

[haoxintu at gmail dot com]

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

Bug ID: 95461
   Summary: GCC misses -Warray-bounds warning message
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: haoxintu at gmail dot com
  Target Milestone: ---

This case test.cc

#include
int main () {
int a[10] = {0};
a[11] = 0;
std::cout << "ok" << std::endl;
return 0;
}

produce nothing in gcc-trunk.


While in clang

$clang++ test.cc
test.cc:4:5: warning: array index 11 is past the end of the array (which
contains 10 elements) [-Warray-bounds]
a[11] = 0;
^ ~~
test.cc:3:5: note: array 'a' declared here
int a[10] = {0};
^
1 warning generated.


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

All GCC versions have this missing.

[Bug c++/92633] [concepts] constrained lambda with placehoder syntax getting wrong substitution

[ppalka at gcc dot gnu.org]

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

Patrick Palka  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |ppalka at gcc dot 
gnu.org
 CC||ppalka at gcc dot gnu.org
 Status|NEW |ASSIGNED
   Last reconfirmed|2019-11-22 00:00:00 |2020-6-1

--- Comment #1 from Patrick Palka  ---
Reconfirmed with GCC master, looking into it.

[Bug gcov-profile/95348] GCC records zero functions and modules in the profiling data file, ICC does NOT

[qinzhao at gcc dot gnu.org]

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

--- Comment #18 from qinzhao at gcc dot gnu.org ---
(In reply to Martin Liška from comment #16)
> > For our application, all processes generating profiling feedback data to a
> > single directory seems is not a choice. 
> 
> Why is it problem? You need to provide reasoning for that.

this is a long time ago. If I remembered correctly, we tried the scheme that 
all the processes generate profiling feedback data to the single directory, 
but looks like a lot of info got lost, resulting bad performance effect. 
then we switched to this current approach. 

> 
> > We chose -fprofile-dir=%p and then use gcov-merge to merge them.
> 
> Sure, that's possible but you pay with a lot of disk space needed.
> Btw. how long does it take to merge all the collected data with gcov-tool?
I didn't get very accurate info on this, but it's over 24 hours for merging.

[Bug gcov-profile/95348] GCC records zero functions and modules in the profiling data file, ICC does NOT

[qinzhao at gcc dot gnu.org]

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

--- Comment #17 from qinzhao at gcc dot gnu.org ---
(In reply to Martin Liška from comment #6)

more details:

> 
> Which means one run takes 100MB is size, right? As you mentioned, having
> 1000 .gcda files, it means that one takes 0.1MB?
> 

Out of the 14,239 processes, the amount of gcda data saved is:

- Around 6500 processes in the 120-130M range.
- Around 1000 processes in the 16M-18M range
- Around   10 processes in the 736K - 764K range
- Around 6000 processes in the 8K-32K range

we are mostly interested in those 120-130M range, a typical process in the 130M
bucket has over 5000 gcd files per directory.

> 
> Can you please provide dump of one directory? At least for portion of .gcda
> files?
> How is it common that an entire module is empty?

I compared the GCC profiling data and ICC profiling data for the similar
process, the following are some interesting data:

for GCC, among 5144 modules, there are 4308 empty modules, i.e 83% modules in
GCC are empty;
on function level, among all 187338 functions, only 3524 functions executed,
i.e, 98% functions have zero counts. 

GCC records all the zero count functions and modules, But ICC ONLY records
functions and modules that have non-zero count.

So, GCC's profiling data is MUCH larger than ICC's. 

I believe that this is a big issue that need to be fixed from GCC.

[Bug c++/94867] [9 Regression] New (since gcc 8) false positive with -Wnull-dereference in very simple code

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||law at gcc dot gnu.org

--- Comment #5 from Martin Liška  ---
You are right, it started with r9-7156-g33579b59aaf02eb7.

[Bug target/95459] aarch64: ICE in in aarch64_short_vector_p, at config/aarch64/aarch64.c:16803

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

 CC||rsandifo at gcc dot gnu.org

--- Comment #1 from rsandifo at gcc dot gnu.org  
---
(In reply to Fei Yang from comment #0)
> -   gcc_assert (aarch64_sve_mode_p (mode));
> +   gcc_assert (TARGET_SVE ? aarch64_sve_mode_p (mode) : true);

Probably clearer as:

  !TARGET_SVE || aarch64_sve_mode_p (mode)

Might be worth adding a comment like:

  /* Leave later code to report an error if SVE is disabled.  */

[Bug fortran/42693] Missing gcc-internal-format on messages from gfc_arith_error

[markeggleston at gcc dot gnu.org]

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

markeggleston at gcc dot gnu.org changed:

   What|Removed |Added

 CC||markeggleston at gcc dot 
gnu.org

--- Comment #4 from markeggleston at gcc dot gnu.org ---
I note from the current code all the strings in gfc_arith_error are enclosed in
_(). Does this mean that this is fixed?

I don't know how to test for message translation so can not confirm.

[Bug c++/95428] ABI breakage for "base object constructor" for final classes

[nathan at gcc dot gnu.org]

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

--- Comment #5 from Nathan Sidwell  ---
i have filed ABI issue 104
https://github.com/itanium-cxx-abi/cxx-abi/issues/104

[Bug c/95460] ice in execute, at adjust-alignment.c:74

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-06-01
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=95237
 CC||marxin at gcc dot gnu.org

--- Comment #1 from Martin Liška  ---
Very likely dup of PR95237.

[Bug c/95460] New: ice in execute, at adjust-alignment.c:74

[dcb314 at hotmail dot com]

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

Bug ID: 95460
   Summary: ice in execute, at adjust-alignment.c:74
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

Derived from yesterday's 5.7 linux kernel, this C code:

a() { long long b; }

when compiled with flags m16 -mpreferred-stack-boundary=2
and recent gcc trunk on x86_64, does this:

$ /home/dcb/gcc/results/bin/gcc -m16 -mpreferred-stack-boundary=2 bug617.c
bug617.c:1:1: warning: return type defaults to ‘int’ [-Wimplicit-int]
1 | a() { long long b; }
  | ^
during GIMPLE pass: adjust_alignment
bug617.c: In function ‘a’:
bug617.c:1:1: internal compiler error: in execute, at adjust-alignment.c:74
0x81c323 execute
../../trunk.git/gcc/adjust-alignment.c:74
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

The bug first seems to occur sometime between 20200520 and 20200521.

[Bug c++/94867] [9 Regression] New (since gcc 8) false positive with -Wnull-dereference in very simple code

[vz-gcc at zeitlins dot org]

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

--- Comment #4 from Vadim Zeitlin  ---
(In reply to Martin Liška from comment #3)
> It's gone since r10-3311-gff6686d2e5f797d6.

This commit is included in releases/gcc-10.1.0 tag, but I still see the warning
with the provided example when using g++ 10.1 with -O, as mentioned in comment
#2, even though I indeed don't see it with -O2 any longer.

[Bug c++/94485] [10.0.1, c++2a] g++ optimizes away necessary code, accepts arbitrary inline asm

[dimitri.gorokhovik at free dot fr]

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

--- Comment #6 from Dimitri Gorokhovik  ---
I bisected this issue to the commit:

commit 35a952ba70028b50fbd2fd19f7dc91f2da45371e
Author: Martin Jambor 
Date:   Tue Jun 13 13:34:51 2017 +0200

[PR80803 1/2] Streamline SRA access enqueuing

2017-06-13  Martin Jambor  

* tree-sra.c (add_access_to_work_queue): Only enqueue accesses
that have a first_link.
(sort_and_splice_var_accesses): Do not check first_link before
enquing.
(subtree_mark_written_and_enqueue): Likewise.
(propagate_all_subaccesses): Likewise and do not stop at first
parent with a first_link.

From-SVN: r249153

on the branch gcc-8 and on. (gcc-7.5.0 and clang-11 don't have the issue.
Adding 2/2 of the change doesn't help.)

So I have the following fragment of code:

template 
struct index : public std::array 
{
 constexpr index () : std::array  {0} {};
 constexpr bool can_be_incremented (tesselation_of_two_cubes const&);
};
...

struct iterator
{
tesselation_of_two_cubes const* me_;
index  idx_;
bool reached_end_;

constexpr iterator (tesselation_of_two_cubes const& ts) noexcept
: me_ {  },
  idx_ {},
 reached_end_ { ! idx_.can_be_incremented (ts) } <<
eliminated
{};
...

If compiling as shown, SRA and subsequent passes make the line above go away
(replace by 'true' which shouldn't be). This is because the ctor for idx_ is
also eliminated, so idx_.can_be_incremented() probably considered reading from
uninitialised data by SRA.

If I change the layout of 'struct iterator', move the member 'idx_' above
'me_', or below 'reached_end_', the issue goes away.

Still struggling with producing small good code sample.

[Bug c++/94867] [9 Regression] New (since gcc 8) false positive with -Wnull-dereference in very simple code

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #3 from Martin Liška  ---
It's gone since r10-3311-gff6686d2e5f797d6.

[Bug c++/95202] Assignment to a member is wrongly optimized away by g++ with -fstrict-aliasing

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org
   Last reconfirmed||2020-06-01
 Status|UNCONFIRMED |NEW
   Keywords|needs-bisection |
 Ever confirmed|0   |1

--- Comment #2 from Martin Liška  ---
> # -O1 with -fstrict-aliasing
> $ rm gccBug; g++ -o gccBug -Wall -Werror -O1 -fstrict-aliasing TestGccBug.cpp 
> && ./gccBug 

This configuration fails on GCC 8 and 9 branches, started with:

$   r9-4245-gdc3221e1e3d3a39d(20 Nov 2018 09:31)(rguent...@suse.de): [took:
0.754s] result: FAILED (1)
ERROR: Invalid idx: 0! Capacity: 4, number elements: 0
re PR middle-end/83215 (C++: struct with char-array assumed to alias with
everything)

2018-11-20  Richard Biener  

PR middle-end/83215
* alias.c (component_uses_parent_alias_set_from): Remove
alias-set zero and TYPE_TYPELESS_STORAGE case both already
handled in other ways.

* g++.dg/tree-ssa/pr83215.C: New testcase.

From-SVN: r266305

and is gone since:

  r10-5940-g6b8df3e421b56bb7(14 Jan 2020 09:47)(rguent...@suse.de): [took:
0.822s] result: OK
Test finished.
PR middle-end/93246 - missing alias subsets

Starting with the introduction of TYPE_TYPELESS_STORAGE the situation
of having a alias-set zero aggregate field became more common which
prevents recording alias-sets of fields of said aggregate as subset
of the outer aggregate.  component_uses_parent_alias_set_from in the
past fended off some of the issues with that but the alias oracles
use of the alias set of the base of an access path never appropriately
handled it.

The following makes it so that alias-sets of fields of alias-set zero
aggregate fields are still recorded as subset of the container.

2020-01-14  Richard Biener  

PR middle-end/93246
* alias.c (record_component_aliases): Take superset to record
into, recurse for alias-set zero fields.
(record_component_aliases): New oveerload wrapping around the above.

* g++.dg/torture/pr93246.C: New testcase.

[Bug target/95459] New: aarch64: ICE in in aarch64_short_vector_p, at config/aarch64/aarch64.c:16803

[felix.yang at huawei dot com]

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

Bug ID: 95459
   Summary: aarch64: ICE in in aarch64_short_vector_p, at
config/aarch64/aarch64.c:16803
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: felix.yang at huawei dot com
  Target Milestone: ---
Target: aarch64

Another sve-related ICE issue triggered under option -mgeneral-regs-only. 

Reduced test case:

#include 

svint8x2_t
callee_s8 (svint8_t x0, svint8_t x1)
{
  return svcreate2 (x0, x1);
}

$aarch64-linux-gnu-gcc -O2 -S -mgeneral-regs-only -march=armv8.2-a+sve bar.c

bar.c: In function ‘callee_s8’:
bar.c:6:10: error: ACLE function ‘svcreate2_s8’ is incompatible with the use of
‘-mgeneral-regs-only’
6 |   return svcreate2 (x0, x1);
  |  ^
bar.c:4:1: internal compiler error: in aarch64_short_vector_p, at
config/aarch64/aarch64.c:16803
4 | callee_s8 (svint8_t x0, svint8_t x1)
  | ^
0x17d5887 aarch64_short_vector_p
../../gcc-git/gcc/config/aarch64/aarch64.c:16803
0x17d5993 aarch64_composite_type_p
../../gcc-git/gcc/config/aarch64/aarch64.c:16838
0x17d5aab aarch64_vfp_is_call_or_return_candidate
../../gcc-git/gcc/config/aarch64/aarch64.c:16877
0x17b4a07 aarch64_init_cumulative_args(CUMULATIVE_ARGS*, tree_node const*,
rtx_def*, tree_node const*, unsigned int, bool)
../../gcc-git/gcc/config/aarch64/aarch64.c:5988
0xdbf60f assign_parms_initialize_all
../../gcc-git/gcc/function.c:2298 0xdc5b8b
gimplify_parameters(gimple**)
../../gcc-git/gcc/function.c:3863 0xe86a8b gimplify_body(tree_node*,
bool)
../../gcc-git/gcc/gimplify.c:14776
0xe872cf gimplify_function_tree(tree_node*)
../../gcc-git/gcc/gimplify.c:14934
0xbe4a4b cgraph_node::analyze()
../../gcc-git/gcc/cgraphunit.c:671
0xbe70ef analyze_functions
../../gcc-git/gcc/cgraphunit.c:1231
0xbecba3 symbol_table::finalize_compilation_unit()
../../gcc-git/gcc/cgraphunit.c:2975

Here, input param 'type' for aarch64_short_vector_p() looks like:

 
unit-size 
align:128 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0xb22300a8 precision:128 min  max
>
constant
elt0:   elt1:  >
...

aarch64_short_vector_p() calls aarch64_sve_mode_p() and aarch64_sve_mode_p()
depends on TARGET_SVE which is false under option -mgeneral-regs-only. As a
result, aarch64_sve_mode_p() returns false and this triggers the ICE.  I think
we are simply checking whether a type (and a mode) is a 64/128-bit short vector
or not, TARGET_SVE should not make a difference here.

Proposed patch is trivial:
diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c index
7feff77adf6..4f00a8c2063 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -16800,7 +16800,7 @@ aarch64_short_vector_p (const_tree type,
 {
   /* Rely only on the type, not the mode, when processing SVE types.  */
   if (type && aarch64_some_values_include_pst_objects_p (type))
-   gcc_assert (aarch64_sve_mode_p (mode));
+   gcc_assert (TARGET_SVE ? aarch64_sve_mode_p (mode) : true);
   else
size = GET_MODE_SIZE (mode);
 }

With this fix, we have:
$aarch64-linux-gnu-gcc -O2 -S -mgeneral-regs-only -march=armv8.2-a+sve bar.c

bar.c: In function ‘callee_s8’:
bar.c:6:10: error: ACLE function ‘svcreate2_s8’ is incompatible with the use of
‘-mgeneral-regs-only’
6 |   return svcreate2 (x0, x1);
  |  ^
bar.c:4:1: fatal error: ‘callee_s8’ requires the SVE ISA extension
4 | callee_s8 (svint8_t x0, svint8_t x1)
  | ^
compilation terminated.

[Bug target/95458] New: Inline strncmp is *much* slower than glibc

[hjl.tools at gmail dot com]

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

Bug ID: 95458
   Summary: Inline strncmp is *much* slower than glibc
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: crazylht at gmail dot com
Depends on: 43052
  Target Milestone: ---

Similar to PR 43052, inline strncmp is *much* slower than glibc.  PR 43052
was "fixed" by accident:

commit 9b0f6f5e511ca512e4faeabc81d2fd3abad9b02f
Author: Nick Clifton 
Date:   Fri Aug 12 16:26:11 2011 +

builtins.c (expand_builtin_memcmp): Do not use cmpstrnsi pattern.

* builtins.c (expand_builtin_memcmp): Do not use cmpstrnsi
pattern.
* doc/md.texi (cmpstrn): Note that the comparison stops if both
fetched bytes are zero.
(cmpstr): Likewise.
(cmpmem): Note that the comparison does not stop if both of the
fetched bytes are zero.

strncmp should be inlined only for -minline-all-stringops.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43052
[Bug 43052] [4.9/5/6 Regression] Inline memcmp is *much* slower than glibc's,
no longer expanded inline

[Bug target/79451] [8/9/10/11 Regression] ICE in expand_expr_real_2, at expr.c:9021 w/ -O3 -floop-nest-optimize

[asolokha at gmx dot com]

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

Arseny Solokha  changed:

   What|Removed |Added

 Resolution|--- |WONTFIX
 Status|UNCONFIRMED |RESOLVED

--- Comment #5 from Arseny Solokha  ---
The powerpcspe backend has been deprecated in GCC 8 and removed during GCC 9
development. See corresponding mailing list threads[1,2,3] for details.

[1] https://gcc.gnu.org/legacy-ml/gcc/2018-04/msg00102.html
[2] https://gcc.gnu.org/legacy-ml/gcc-patches/2018-12/msg00123.html
[3] https://gcc.gnu.org/pipermail/gcc/2020-May/232342.html

[Bug target/85121] Assembler messages: Error: operand out of range (264 is not between 0 and 248)

[asolokha at gmx dot com]

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

Arseny Solokha  changed:

   What|Removed |Added

 Resolution|--- |WONTFIX
 Status|UNCONFIRMED |RESOLVED

--- Comment #1 from Arseny Solokha  ---
The powerpcspe backend has been deprecated in GCC 8 and removed during GCC 9
development. See corresponding mailing list threads[1,2,3] for details.

[1] https://gcc.gnu.org/legacy-ml/gcc/2018-04/msg00102.html
[2] https://gcc.gnu.org/legacy-ml/gcc-patches/2018-12/msg00123.html
[3] https://gcc.gnu.org/pipermail/gcc/2020-May/232342.html

[Bug target/80700] [8 Regression] ICE: Bus error (on SPE target)

[asolokha at gmx dot com]

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

Arseny Solokha  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #12 from Arseny Solokha  ---
The powerpcspe backend has been deprecated in GCC 8 and removed during GCC 9
development. See corresponding mailing list threads[1,2,3] for details.

[1] https://gcc.gnu.org/legacy-ml/gcc/2018-04/msg00102.html
[2] https://gcc.gnu.org/legacy-ml/gcc-patches/2018-12/msg00123.html
[3] https://gcc.gnu.org/pipermail/gcc/2020-May/232342.html

[Bug target/84302] ICE: Segmentation fault (in extract_insn) on SPE target

[asolokha at gmx dot com]

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

Arseny Solokha  changed:

   What|Removed |Added

 Resolution|--- |WONTFIX
 Status|UNCONFIRMED |RESOLVED

--- Comment #1 from Arseny Solokha  ---
The powerpcspe backend has been deprecated in GCC 8 and removed during GCC 9
development. See corresponding mailing list threads[1,2,3] for details.

[1] https://gcc.gnu.org/legacy-ml/gcc/2018-04/msg00102.html
[2] https://gcc.gnu.org/legacy-ml/gcc-patches/2018-12/msg00123.html
[3] https://gcc.gnu.org/pipermail/gcc/2020-May/232342.html

[Bug target/82138] [8/9/10/11 Regression] Assembler messages: Error: can't resolve `.got2' {.got2 section} - `.LCF0' {.text.unlikely section}

[asolokha at gmx dot com]

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

Arseny Solokha  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #6 from Arseny Solokha  ---
The powerpcspe backend has been deprecated in GCC 8 and removed during GCC 9
development. See corresponding mailing list threads[1,2,3] for details.

[1] https://gcc.gnu.org/legacy-ml/gcc/2018-04/msg00102.html
[2] https://gcc.gnu.org/legacy-ml/gcc-patches/2018-12/msg00123.html
[3] https://gcc.gnu.org/pipermail/gcc/2020-May/232342.html

[Bug target/87083] ICE in extract_insn, at recog.c:2305 (error: unrecognizable insn)

[asolokha at gmx dot com]

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

Arseny Solokha  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #1 from Arseny Solokha  ---
The powerpcspe backend has been deprecated in GCC 8 and removed during GCC 9
development. See corresponding mailing list threads[1,2,3] for details.

[1] https://gcc.gnu.org/legacy-ml/gcc/2018-04/msg00102.html
[2] https://gcc.gnu.org/legacy-ml/gcc-patches/2018-12/msg00123.html
[3] https://gcc.gnu.org/pipermail/gcc/2020-May/232342.html

[Bug target/81288] [8 Regression] ICE on 32-bit BE powerpcspe w/ -misel -O2 (-O3, -Ofast, -Os)

[asolokha at gmx dot com]

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

Arseny Solokha  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #11 from Arseny Solokha  ---
The powerpcspe backend has been deprecated in GCC 8 and removed during GCC 9
development. See corresponding mailing list threads[1,2,3] for details.

[1] https://gcc.gnu.org/legacy-ml/gcc/2018-04/msg00102.html
[2] https://gcc.gnu.org/legacy-ml/gcc-patches/2018-12/msg00123.html
[3] https://gcc.gnu.org/pipermail/gcc/2020-May/232342.html

[Bug rtl-optimization/79438] [8/9/10/11 Regression] ICE during RA w/ -O3 (or -Ofast) -funroll-loops for 32-bit BE SPE target

[asolokha at gmx dot com]

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

Arseny Solokha  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #7 from Arseny Solokha  ---
The powerpcspe backend has been deprecated in GCC 8 and removed during GCC 9
development. See corresponding mailing list threads[1,2,3] for details.

[1] https://gcc.gnu.org/legacy-ml/gcc/2018-04/msg00102.html
[2] https://gcc.gnu.org/legacy-ml/gcc-patches/2018-12/msg00123.html
[3] https://gcc.gnu.org/pipermail/gcc/2020-May/232342.html

[Bug target/85170] ICE: in final_scan_insn_1, at final.c:3139 (error: could not split insn)

[asolokha at gmx dot com]

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

Arseny Solokha  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #1 from Arseny Solokha  ---
The powerpcspe backend has been deprecated in GCC 8 and removed during GCC 9
development. See corresponding mailing list threads[1,2,3] for details.

[1] https://gcc.gnu.org/legacy-ml/gcc/2018-04/msg00102.html
[2] https://gcc.gnu.org/legacy-ml/gcc-patches/2018-12/msg00123.html
[3] https://gcc.gnu.org/pipermail/gcc/2020-May/232342.html

[Bug target/81628] Backport r250637 and r250638 to the powerpcspe* target

[asolokha at gmx dot com]

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

Arseny Solokha  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #1 from Arseny Solokha  ---
The powerpcspe backend has been deprecated in GCC 8 and removed during GCC 9
development. See corresponding mailing list threads[1,2,3] for details.

[1] https://gcc.gnu.org/legacy-ml/gcc/2018-04/msg00102.html
[2] https://gcc.gnu.org/legacy-ml/gcc-patches/2018-12/msg00123.html
[3] https://gcc.gnu.org/pipermail/gcc/2020-May/232342.html

[Bug target/95435] bad builtin memcpy performance with znver1/znver2 and 32bit

[marxin at gcc dot gnu.org]

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

--- Comment #10 from Martin Liška  ---
And this is for znver2:
AMD EPYC 7502P 32-Core Processor

64-bit:

memcpy
  block size  libcall rep1noalg   rep4noalg   rep8noalg   loop   
noalg   unrlnoalg   sse noalg   bytePGO dynamicBEST
 8192000  0:00.05 0:00.08 0:00.08 0:00.08 0:00.08 0:00.08 0:00.08 0:00.09
0:00.10 0:00.06 0:00.09 0:00.04 0:00.04 0:00.63 0:00.04 0:00.040:00.04 sse
  819200  0:00.03 0:00.07 0:00.07 0:00.06 0:00.06 0:00.06 0:00.06 0:00.08
0:00.09 0:00.05 0:00.08 0:00.03 0:00.04 0:00.61 0:00.03 0:00.030:00.03
libcall
   81920  0:00.02 0:00.06 0:00.05 0:00.05 0:00.05 0:00.05 0:00.05 0:00.08
0:00.09 0:00.05 0:00.08 0:00.02 0:00.03 0:00.63 0:00.03 0:00.020:00.02
libcall
   20480  0:00.02 0:00.05 0:00.05 0:00.05 0:00.06 0:00.05 0:00.05 0:00.08
0:00.10 0:00.05 0:00.09 0:00.03 0:00.04 0:00.75 0:00.02 0:00.020:00.02
libcall
8192  0:00.02 0:00.05 0:00.05 0:00.05 0:00.05 0:00.05 0:00.05 0:00.08
0:00.09 0:00.05 0:00.08 0:00.03 0:00.04 0:00.61 0:00.02 0:00.020:00.02
libcall
4096  0:00.02 0:00.06 0:00.06 0:00.06 0:00.07 0:00.06 0:00.06 0:00.08
0:00.09 0:00.05 0:00.08 0:00.04 0:00.05 0:00.60 0:00.02 0:00.030:00.02
libcall
2048  0:00.03 0:00.09 0:00.09 0:00.09 0:00.09 0:00.08 0:00.09 0:00.09
0:00.10 0:00.06 0:00.09 0:00.06 0:00.06 0:00.61 0:00.03 0:00.030:00.03
libcall
1024  0:00.04 0:00.13 0:00.13 0:00.12 0:00.12 0:00.11 0:00.11 0:00.09
0:00.11 0:00.07 0:00.09 0:00.09 0:00.09 0:00.58 0:00.04 0:00.040:00.04
libcall
 512  0:00.06 0:00.21 0:00.20 0:00.17 0:00.18 0:00.14 0:00.15 0:00.11
0:00.12 0:00.08 0:00.10 0:00.14 0:00.14 0:00.62 0:00.06 0:00.050:00.06
libcall
 256  0:00.10 0:00.33 0:00.33 0:00.23 0:00.24 0:00.12 0:00.12 0:00.13
0:00.14 0:00.11 0:00.11 0:00.21 0:00.20 0:00.64 0:00.10 0:00.100:00.10
libcall
 128  0:00.21 0:00.53 0:00.59 0:00.22 0:00.22 0:00.18 0:00.18 0:00.17
0:00.18 0:00.19 0:00.20 0:00.51 0:00.47 0:00.68 0:00.23 0:00.180:00.17 loop
  64  0:00.40 0:00.75 0:00.71 0:00.24 0:00.20 0:00.17 0:00.16 0:00.16
0:00.31 0:00.38 0:00.39 0:00.73 0:00.58 0:00.45 0:00.33 0:00.310:00.16 loop
  48  0:00.48 0:00.88 0:00.83 0:00.42 0:00.40 0:00.39 0:00.38 0:00.38
0:00.36 0:00.41 0:00.40 0:00.70 0:00.55 0:00.46 0:00.41 0:00.400:00.36
loopnoalign
  32  0:00.85 0:00.76 0:00.76 0:00.56 0:00.54 0:00.57 0:00.54 0:00.55
0:00.60 0:00.79 0:00.85 0:00.72 0:00.85 0:00.85 0:00.41 0:00.330:00.54
rep4noalign
  24  0:00.45 0:00.48 0:00.48 0:00.39 0:00.38 0:00.39 0:00.37 0:00.37
0:00.72 0:00.91 0:00.94 0:01.03 0:01.03 0:00.87 0:00.73 0:00.730:00.37 loop
  16  0:00.90 0:00.63 0:00.60 0:00.56 0:00.54 0:00.60 0:00.57 0:00.62
0:00.72 0:01.27 0:01.27 0:00.56 0:00.56 0:00.56 0:01.13 0:01.060:00.54
rep4noalign
  14  0:00.70 0:00.69 0:00.69 0:00.61 0:00.59 0:00.62 0:00.59 0:00.59
0:00.63 0:00.84 0:00.84 0:00.63 0:00.63 0:00.64 0:01.10 0:01.100:00.59 loop
  12  0:01.20 0:00.78 0:00.77 0:00.72 0:00.70 0:00.74 0:00.71 0:00.73
0:00.80 0:01.00 0:01.01 0:00.72 0:00.72 0:00.69 0:01.17 0:01.360:00.69 byte
  10  0:01.18 0:00.89 0:00.88 0:01.50 0:01.14 0:00.83 0:00.80 0:00.82
0:01.65 0:01.88 0:01.88 0:01.47 0:01.11 0:00.77 0:01.20 0:00.820:00.77 byte
   8  0:01.10 0:01.93 0:01.93 0:01.97 0:01.90 0:01.41 0:01.14 0:01.40
0:01.60 0:03.15 0:03.16 0:01.85 0:01.82 0:01.84 0:01.37 0:02.450:01.10
libcall
   6  0:02.16 0:02.37 0:01.39 0:02.18 0:02.14 0:01.39 0:02.21 0:01.43
0:01.38 0:01.37 0:02.41 0:02.10 0:01.26 0:01.16 0:01.30 0:01.300:01.16 byte
   4  0:02.07 0:01.96 0:01.95 0:02.00 0:01.96 0:03.61 0:03.59 0:03.61
0:04.76 0:04.71 0:03.65 0:03.26 0:02.15 0:03.19 0:03.98 0:03.200:01.95
rep1noalign
   1  0:02.21 0:06.20 0:06.14 0:00.63 0:00.70 0:00.63 0:00.63 0:00.63
0:00.63 0:01.22 0:01.06 0:01.78 0:01.27 0:01.78 0:00.82 0:00.970:00.63 loop
Aligned
  block size  libcall rep1noalg   rep4noalg   rep8noalg   loop   
noalg   unrlnoalg   sse noalg   bytePGO dynamicBEST
 8192000  0:00.08 0:00.10 0:00.10 0:00.11 0:00.11 0:00.11 0:00.11 0:00.10
0:00.10 0:00.09 0:00.09 0:00.09 0:00.08 0:00.65 0:00.08 0:00.080:00.08
libcall
  819200  0:00.03 0:00.07 0:00.06 0:00.07 0:00.06 0:00.07 0:00.06 0:00.08
0:00.08 0:00.05 0:00.05 0:00.04 0:00.03 0:00.60 0:00.03 0:00.030:00.03
libcall
   81920  0:00.03 0:00.06 0:00.06 0:00.06 0:00.06 0:00.06 0:00.06 0:00.08
0:00.08 0:00.05 0:00.05 0:00.03 0:00.03 0:00.63 0:00.02 0:00.030:00.03
libcall
   20480  0:00.03 0:00.06 0:00.06 0:00.06 0:00.06 0:00.05 0:00.05 0:00.08
0:00.09 0:00.05 0:00.05 0:00.03 0:00.03 0:00.77 0:00.03 0:00.030:00.03
libcall
8192  0:00.03 0:00.06 0:00.06 0:00.05 0:00.05 0:00.05 0:00.05 0:00.09
0:00.09 0:00.05 0:00.05 0:00.03 0:00.03 0:00.61 0:00.02 0:00.020:00.03
libcall
4096  0:00.03 0:00.07 

[Bug target/95435] bad builtin memcpy performance with znver1/znver2 and 32bit

[ubizjak at gmail dot com]

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

--- Comment #9 from Uroš Bizjak  ---
(In reply to Alexander Monakov from comment #8)
> There's no tuning tables for memcmp at all, existing structs cover only
> memset and memcpy. So as far as I see retuning memset/memcpy doesn't need to
> wait for [1], because there's no infrastructure in place for memcmp tuning,
> and adding that can be done independently. Updating Ryzen tables would not
> touch any code updated by H.J.Lu's patchset at all.

Agreed.

[Bug target/95435] bad builtin memcpy performance with znver1/znver2 and 32bit

[amonakov at gcc dot gnu.org]

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

--- Comment #8 from Alexander Monakov  ---
There's no tuning tables for memcmp at all, existing structs cover only memset
and memcpy. So as far as I see retuning memset/memcpy doesn't need to wait for
[1], because there's no infrastructure in place for memcmp tuning, and adding
that can be done independently. Updating Ryzen tables would not touch any code
updated by H.J.Lu's patchset at all.

[Bug c++/95457] New: Inadequate diagnostics on constrained coroutines

[a...@cloudius-systems.com]

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

Bug ID: 95457
   Summary: Inadequate diagnostics on constrained coroutines
   Product: gcc
   Version: 10.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: a...@cloudius-systems.com
  Target Milestone: ---

Created attachment 48651
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48651=edit
test case

If a coroutine_traits specialization fails, and if the constraints is not
satisfied, gcc reports that it cannot find the promise type. However, it does
not report on the constraint failure, as it usually does with concepts.

The diagnostics for the attached test case are:

g++ -std=c++20 -fcoroutinesconstrained-coroutine.cc   -o
constrained-coroutine
constrained-coroutine.cc: In function ‘dummy_coroutine foo(int&&)’:
constrained-coroutine.cc:31:5: error: unable to find the promise type for this
coroutine
   31 | co_return x;
  | ^
cc1plus: warning: control reaches end of non-void function [-Wreturn-type]

[Bug target/95435] bad builtin memcpy performance with znver1/znver2 and 32bit

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 CC||hjl.tools at gmail dot com

--- Comment #7 from Uroš Bizjak  ---
I think that stringops (including memcmp) for x86 targets should be retuned for
new glibc, once [1] is approved and committed. Please note that currently
bench-stringop doesn't benchmark memcmp.

[1] https://gcc.gnu.org/pipermail/gcc-patches/2020-May/546919.html

[Bug target/95435] bad builtin memcpy performance with znver1/znver2 and 32bit

[marxin at gcc dot gnu.org]

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

--- Comment #6 from Martin Liška  ---
All right, there are results for a micro-benchmark that we have in contrib
folder:

ZNVER1 (AMD Ryzen 7 2700X):

64-bit:

contrib/bench-stringop 64 32000 gcc -march=znver1
memcpy
  block size  libcall rep1noalg   rep4noalg   rep8noalg   loop   
noalg   unrlnoalg   sse noalg   bytePGO dynamicBEST
 8192000  0:00.05 0:00.05 0:00.05 0:00.05 0:00.05 0:00.05 0:00.05 0:00.06
0:00.07 0:00.06 0:00.07 0:00.05 0:00.06 0:00.17 0:00.05 0:00.050:00.05
libcall
  819200  0:00.04 0:00.06 0:00.06 0:00.06 0:00.06 0:00.06 0:00.06 0:00.04
0:00.05 0:00.04 0:00.05 0:00.04 0:00.04 0:00.15 0:00.04 0:00.040:00.04
libcall
   81920  0:00.02 0:00.04 0:00.04 0:00.04 0:00.04 0:00.04 0:00.04 0:00.02
0:00.04 0:00.02 0:00.04 0:00.02 0:00.03 0:00.16 0:00.02 0:00.010:00.02
libcall
   20480  0:00.01 0:00.04 0:00.04 0:00.04 0:00.04 0:00.04 0:00.04 0:00.03
0:00.04 0:00.03 0:00.04 0:00.02 0:00.03 0:00.32 0:00.02 0:00.010:00.01
libcall
8192  0:00.02 0:00.04 0:00.04 0:00.04 0:00.04 0:00.04 0:00.04 0:00.03
0:00.04 0:00.02 0:00.04 0:00.02 0:00.03 0:00.16 0:00.02 0:00.020:00.02
libcall
4096  0:00.02 0:00.05 0:00.05 0:00.05 0:00.05 0:00.05 0:00.05 0:00.02
0:00.04 0:00.03 0:00.04 0:00.02 0:00.03 0:00.16 0:00.05 0:00.050:00.02
libcall
2048  0:00.02 0:00.07 0:00.07 0:00.07 0:00.07 0:00.06 0:00.07 0:00.03
0:00.05 0:00.03 0:00.05 0:00.03 0:00.03 0:00.17 0:00.06 0:00.060:00.02
libcall
1024  0:00.03 0:00.09 0:00.09 0:00.08 0:00.09 0:00.08 0:00.08 0:00.04
0:00.05 0:00.03 0:00.05 0:00.04 0:00.04 0:00.18 0:00.08 0:00.080:00.03
libcall
 512  0:00.03 0:00.12 0:00.12 0:00.10 0:00.11 0:00.08 0:00.09 0:00.05
0:00.06 0:00.04 0:00.05 0:00.05 0:00.05 0:00.19 0:00.08 0:00.080:00.03
libcall
 256  0:00.04 0:00.19 0:00.19 0:00.14 0:00.14 0:00.06 0:00.06 0:00.06
0:00.07 0:00.05 0:00.06 0:00.08 0:00.08 0:00.21 0:00.05 0:00.050:00.04
libcall
 128  0:00.08 0:00.29 0:00.29 0:00.10 0:00.10 0:00.08 0:00.08 0:00.09
0:00.09 0:00.09 0:00.09 0:00.14 0:00.11 0:00.24 0:00.08 0:00.080:00.08
libcall
  64  0:00.15 0:00.39 0:00.39 0:00.15 0:00.14 0:00.14 0:00.14 0:00.15
0:00.16 0:00.17 0:00.18 0:00.24 0:00.20 0:00.30 0:00.14 0:00.140:00.14
rep4noalign
  48  0:00.19 0:00.41 0:00.41 0:00.18 0:00.18 0:00.18 0:00.18 0:00.18
0:00.19 0:00.22 0:00.23 0:00.32 0:00.29 0:00.34 0:00.18 0:00.180:00.18 loop
  32  0:00.32 0:00.34 0:00.34 0:00.26 0:00.25 0:00.27 0:00.26 0:00.30
0:00.33 0:00.37 0:00.40 0:00.37 0:00.37 0:00.37 0:00.27 0:00.270:00.25
rep4noalign
  24  0:00.40 0:00.40 0:00.39 0:00.33 0:00.32 0:00.34 0:00.33 0:00.36
0:00.40 0:00.50 0:00.53 0:00.52 0:00.52 0:00.43 0:00.34 0:00.340:00.32
rep4noalign
  16  0:00.67 0:00.51 0:00.51 0:00.48 0:00.46 0:00.55 0:00.51 0:00.67
0:00.77 0:00.91 0:00.91 0:00.52 0:00.52 0:00.52 0:00.67 0:00.700:00.46
rep4noalign
  14  0:00.66 0:00.58 0:00.58 0:00.52 0:00.51 0:00.56 0:00.54 0:00.64
0:00.72 0:00.92 0:00.93 0:00.62 0:00.63 0:00.62 0:00.60 0:00.610:00.51
rep4noalign
  12  0:00.85 0:00.64 0:00.64 0:00.62 0:00.61 0:00.66 0:00.66 0:00.82
0:00.93 0:01.11 0:01.11 0:00.69 0:00.70 0:00.64 0:00.78 0:00.810:00.61
rep4noalign
  10  0:00.86 0:00.75 0:00.75 0:00.70 0:00.69 0:00.78 0:00.74 0:00.92
0:00.98 0:01.17 0:01.18 0:00.75 0:00.75 0:00.68 0:00.91 0:00.920:00.68 byte
   8  0:01.19 0:00.92 0:00.92 0:00.95 0:00.93 0:01.25 0:01.13 0:01.57
0:01.62 0:01.72 0:01.73 0:00.92 0:00.92 0:00.92 0:01.59 0:01.590:00.92 byte
   6  0:01.20 0:01.20 0:01.19 0:01.08 0:01.06 0:01.37 0:01.22 0:01.46
0:01.54 0:01.57 0:01.54 0:01.07 0:01.07 0:01.05 0:01.46 0:01.460:01.05 byte
   4  0:02.06 0:01.75 0:01.74 0:02.01 0:01.99 0:03.29 0:03.30 0:03.30
0:03.29 0:03.26 0:03.30 0:02.15 0:02.16 0:02.16 0:03.31 0:02.150:01.74
rep1noalign
   1  0:01.49 0:05.41 0:05.43 0:00.58 0:00.58 0:00.58 0:00.58 0:00.58
0:00.58 0:00.58 0:00.58 0:00.73 0:00.72 0:00.72 0:00.48 0:00.730:00.58 loop
Aligned
  block size  libcall rep1noalg   rep4noalg   rep8noalg   loop   
noalg   unrlnoalg   sse noalg   bytePGO dynamicBEST
 8192000  0:00.08 0:00.10 0:00.10 0:00.10 0:00.10 0:00.10 0:00.10 0:00.10
0:00.10 0:00.10 0:00.10 0:00.09 0:00.09 0:00.20 0:00.08 0:00.090:00.08
libcall
  819200  0:00.04 0:00.06 0:00.06 0:00.06 0:00.06 0:00.06 0:00.06 0:00.04
0:00.04 0:00.04 0:00.04 0:00.04 0:00.04 0:00.16 0:00.04 0:00.040:00.04
libcall
   81920  0:00.02 0:00.04 0:00.04 0:00.04 0:00.04 0:00.04 0:00.04 0:00.03
0:00.03 0:00.02 0:00.02 0:00.02 0:00.02 0:00.16 0:00.02 0:00.020:00.02
libcall
   20480  0:00.01 0:00.04 0:00.04 0:00.04 0:00.04 0:00.04 0:00.04 0:00.03
0:00.03 0:00.03 0:00.02 0:00.02 0:00.02 0:00.33 0:00.02 0:00.020:00.01
libcall
8192  0:00.02 0:00.04 0:00.04 0:00.04 0:00.04 

[Bug target/95435] bad builtin memcpy performance with znver1/znver2 and 32bit

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org
   Last reconfirmed||2020-06-01
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org
 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1

[Bug c++/95455] ICE in capture with initializer in requires block

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
Lambdas in unevaluated contexts should be valid since P0315R4 which is (so far)
only implemented in GCC but not clang nor other compilers.
So I'm not sure about the invalid classification.