[Bug c++/96184] GCC treats "use of local variable with automatic storage from containing function" differently in versions

[haoxintu at gmail dot com]

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

--- Comment #1 from Haoxin Tu  ---
This behavior still exists in the current trunk.

Is this a bug or not?

Thanks

[Bug fortran/96325] Unclassifiable statement with syntax similar to a type-bound procedure call is accepted

[jvdelisle at charter dot net]

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

--- Comment #11 from jvdelisle at charter dot net ---
(In reply to kargl from comment #10)
---snip---
> Thanks for testing.  Does the patch that follows fix the regressions?
> gfortran treats components and type bound procedures separately.  I've
> (hopefully) adapted the patch to whether foo is either.
> 
---snip---

Patch at comment 10 passes patch provided in comment 10 passes regression
testing.

I will commit to trunk and use the original case as a test case tomorrow.

[Bug c++/96364] New: ICE on valid code in cp_finish_decl, at cp/decl.c:7537

[haoxintu at gmail dot com]

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

Bug ID: 96364
   Summary: ICE on valid code in cp_finish_decl, at cp/decl.c:7537
   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: haoxintu at gmail dot com
  Target Milestone: ---

Hi, all.

Weirdly, this simple valid code makes GCC ICE (clang,icc,or msvc accepts this
code).

Input:
//small.cc
auto a[[]] [[]]();

Command:
g++ small.cc

Output:
small.cc:1:17: internal compiler error: in cp_finish_decl, at cp/decl.c:7536
1 | auto a[[]] [[]]();
  | ^
0x63f6dc cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
../../gcc/cp/decl.c:7536
0x9ed9b9 cp_parser_init_declarator
../../gcc/cp/parser.c:20990
0x9cdacc cp_parser_simple_declaration
../../gcc/cp/parser.c:13799
0x9f8d2e cp_parser_declaration
../../gcc/cp/parser.c:13498
0x9f941b cp_parser_translation_unit
../../gcc/cp/parser.c:4781
0x9f941b c_parse_file()
../../gcc/cp/parser.c:44069
0xb13e2d c_common_parse_file()
../../gcc/c-family/c-opts.c:1188
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

I have tested this in GCC-7.1 onwards versions, and they all behave the same.

Thanks,
Haoxin

[Bug fortran/96325] Unclassifiable statement with syntax similar to a type-bound procedure call is accepted

[kargl at gcc dot gnu.org]

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

--- Comment #10 from kargl at gcc dot gnu.org ---
(In reply to jvdelisle from comment #9)
> I regression tested the patch in comment 8 and see these failures.
> 
> FAIL: gfortran.dg/pr93423.f90   -O  (test for excess errors)
> FAIL: gfortran.dg/typebound_call_31.f90   -O   (test for errors, line 14)
> FAIL: gfortran.dg/typebound_call_31.f90   -O  (test for excess errors)

Thanks for testing.  Does the patch that follows fix the regressions?
gfortran treats components and type bound procedures separately.  I've
(hopefully) adapted the patch to whether foo is either.

Index: gcc/fortran/primary.c
===
--- gcc/fortran/primary.c   (revision 280157)
+++ gcc/fortran/primary.c   (working copy)
@@ -2240,6 +2240,18 @@ gfc_match_varspec (gfc_expr *primary, int equiv_flag, 
  inquiry = is_inquiry_ref (name, );
  if (inquiry)
sym = NULL;
+ else
+   {
+ component = gfc_find_component (sym, name, false, false, );
+ tbp = gfc_find_typebound_proc (sym, , name, false,
_current_locus);
+ if (!component && !tbp)
+   {
+ gfc_error ("%qs at %C is neither a component nor a type "
+"bound procedure of the derived "
+"type %qs", name, sym->name);
+ return MATCH_ERROR;
+   }
+   }

  if (sep == '%' && primary->ts.type != BT_UNKNOWN)
intrinsic = true;

[Bug c++/96310] Ignoring Wnonnull via pragma gcc diagnostics still produces a unwanted note

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #3 from Eric Gallager  ---
These types of bugs seem kind of common; I keep thinking there should be some
way of automatically checking that call to inform() only come after warning()
or warning_at() if their return values got checked... I was thinking adding
__attribute__((warn_unused_result)) on warning() and warning_at() at first, but
that would also trigger in cases in which there's no following inform() call,
in which it's ok to ignore the return value... maybe some magic could happen
via David Malcolm's auto_diagnostic_group class?

[Bug target/96362] bootstrapping gcc 9.3.0 on sparc-sun-solaris2.11 fails compiling libgcc2.c (.group in output)

[nicholas.h.briggs at gmail dot com]

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

--- Comment #6 from Nick Briggs  ---
Perhaps the info at https://gcc.gnu.org/install/specific.html could be updated
in the sparc*solaris section to include the notes about gnu as in the same way
that the x86*solaris section mentions it?

[Bug target/96362] bootstrapping gcc 9.3.0 on sparc-sun-solaris2.11 fails compiling libgcc2.c (.group in output)

[pinskia at gcc dot gnu.org]

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

--- Comment #5 from Andrew Pinski  ---
This is documented on https://gcc.gnu.org/install/configure.html too:
Confusion may also result if the compiler finds the GNU assembler but has not
been configured with --with-gnu-as.
...
The following systems are the only ones where it makes a difference whether you
use the GNU assembler. On any other system, --with-gnu-as has no effect.

‘hppa1.0-any-any’
‘hppa1.1-any-any’
‘sparc-sun-solaris2.any’
‘sparc64-any-solaris2.any’

[Bug target/96362] bootstrapping gcc 9.3.0 on sparc-sun-solaris2.11 fails compiling libgcc2.c (.group in output)

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #4 from Andrew Pinski  ---
You need to use --with-gnu-as if you are using the GNU as on Solaris.
Note if you are using GNU ld, you might also need to use --with-gnu-ld .

[Bug target/96362] bootstrapping gcc 9.3.0 on sparc-sun-solaris2.11 fails compiling libgcc2.c (.group in output)

[nicholas.h.briggs at gmail dot com]

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

--- Comment #3 from Nick Briggs  ---
Could not configuring with "--with-gnu-as" have caused this?

Also, since it seems to be related to COMDAT, would "--disable-comdat" (if such
an option exists, since only --enable-comdat is documented) have avoided this?

[Bug fortran/96325] Unclassifiable statement with syntax similar to a type-bound procedure call is accepted

[jvdelisle at charter dot net]

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

jvdelisle at charter dot net changed:

   What|Removed |Added

 CC||jvdelisle at charter dot net

--- Comment #9 from jvdelisle at charter dot net ---
I regression tested the patch in comment 8 and see these failures.

FAIL: gfortran.dg/pr93423.f90   -O  (test for excess errors)
FAIL: gfortran.dg/typebound_call_31.f90   -O   (test for errors, line 14)
FAIL: gfortran.dg/typebound_call_31.f90   -O  (test for excess errors)

[Bug c/50584] No warning for passing small array to C99 static array declarator

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #16 from Martin Sebor  ---
Patch: https://gcc.gnu.org/pipermail/gcc-patches/2020-July/550920.html

[Bug ipa/96235] Segmentation fault with "-Og -fno-dce -fno-tree-dce -finline-small-functions -fipa-sra"

[suochenyao at 163 dot com]

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

--- Comment #9 from suochenyao at 163 dot com  ---
(In reply to Martin Jambor from comment #8)
> It is clearly a duplicate of PR 93385.
> 
> What was the reason to switch off DCE in the first place?  Was it just meant
> as a stress test for the compiler?
> 
> I'll try to come up with somewhat less controversial patch for the problem.
> 
> *** This bug has been marked as a duplicate of bug 93385 ***

Ummm, yes, this is just a stress test. And I get many, similar to this case.
Because there is generally no reason to switch off it.

[Bug c++/95977] No deallocation of temporary in return-statement during constant evaluation

[pkeir at outlook dot com]

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

Paul Keir  changed:

   What|Removed |Added

 CC||pkeir at outlook dot com

--- Comment #2 from Paul Keir  ---
I've also encountered this bug. I changed your code to:

struct X {
int* x{new int{42}};
constexpr ~X() { delete x; }
};

int main(int argc, char *argv[])
{
  static_assert(42 == *X{}.x);
  return 0;
}

...and now an extra note appears at compilation:

note: ‘’ was not declared ‘constexpr’

15 |   static_assert(42 == *X{}.x);
   |  ^

This made me think of the implicitly-defined default constructor for X, which
should be `constexpr`. But perhaps attribution of this `constexpr` qualifier is
failing due to the memory not having been freed at the point where the equality
is evaluated? This is certainly unintuitive, but I do note that the error
disappears when `static_assert(doit())` is used instead, with the following
definition: 

constexpr bool doit()
{
  int i = *X{}.x;
  return i==42;
}

...but while that perhaps make sense, I encountered two other changes to the
version above which surprisingly also remove the error:

1) Adding an explicitly defaulted constructor for X;
2) Using `X()` rather than `X{}` in the static assert.

[Bug fortran/96325] Unclassifiable statement with syntax similar to a type-bound procedure call is accepted

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4

--- Comment #8 from kargl at gcc dot gnu.org ---
(In reply to Kirill Chilikin from comment #7)
> Result of git bisect:
> 

(bisection removed)

> f79be3a7dbf8d9cd7e675918472ebc3c2c9d5e47 is the first bad commit
> commit f79be3a7dbf8d9cd7e675918472ebc3c2c9d5e47
> Author: Paul Thomas 
> Date:   Mon Sep 2 19:54:02 2019 +
> 
> re PR fortran/91589 (ICE in gfc_conv_component_ref, at
> fortran/trans-expr.c:2447)
> 
> 2019-09-02  Paul Thomas  
> 
> PR fortran/91589
> * primary.c (gfc_match_varspec): Return MATCH_NO on an apparent
> component ref, when the primary type is intrinsic.
> 
> 2019-09-02  Paul Thomas  
> 
> PR fortran/91589
> * gfortran.dg/pr91589.f90 : New test.
> 
> From-SVN: r275324

Thank for the bisection. The system I'm sitting in front of is too
slow to attempt a bisection.  I have developed a patch, which yields

% gfcx -c a.f90
a.f90:11:16:

   11 |a = t%r1%foo(1)   ! There is no foo component/TBP.
  |1
Error: 'foo' at (1) is not a component of the derived type 't2'

For the last testcase I posted.  I have not regression tested the
patch, so have no ideas if there are unforeseen side-effects.  I'll
just put the patch here for others to find.

Index: gcc/fortran/primary.c
===
--- gcc/fortran/primary.c   (revision 280157)
+++ gcc/fortran/primary.c   (working copy)
@@ -2240,6 +2240,16 @@ gfc_match_varspec (gfc_expr *primary, int equiv_flag, 
  inquiry = is_inquiry_ref (name, );
  if (inquiry)
sym = NULL;
+ else
+   {
+ component = gfc_find_component (sym, name, false, false, );
+ if (!component)
+   {
+ gfc_error ("%qs at %C is not a component of the derived "
+"type %qs", name, sym->name);
+ return MATCH_ERROR;
+   }
+   }

  if (sep == '%' && primary->ts.type != BT_UNKNOWN)
intrinsic = true;

[Bug ipa/96291] [10/11 Regression] -flto fails as "internal compiler error: Segmentation fault" during IPA pass: cp incall_for_symbol_thunks_and_aliases()

[cvs-commit at gcc dot gnu.org]

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

--- Comment #9 from CVS Commits  ---
The master branch has been updated by Sergei Trofimovich :

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

commit r11-2391-gcbf10ac51c0b889e930f260a3d1fb601332befdf
Author: Sergei Trofimovich 
Date:   Sat Jul 25 19:26:50 2020 +0100

ipa/96291: don't crash on unoptimized lto functions

In PR ipa/96291 the test contained an SCC with one
unoptimized function. This tricked ipa-cp into NULL dereference.

has_undead_caller_from_outside_scc_p() did not take into account
that unoptimized funtions don't have IPA summary analysis. And
dereferenced NULL pointer causing an ICE.

gcc/
PR ipa/96291
* ipa-cp.c (has_undead_caller_from_outside_scc_p): Consider
unoptimized callers as undead.

gcc/testsuite/
PR ipa/96291
* gcc.dg/lto/pr96291_0.c: New testcase.
* gcc.dg/lto/pr96291_1.c: Support file.
* gcc.dg/lto/pr96291_2.c: Likewise.
* gcc.dg/lto/pr96291.h: Likewise.

[Bug c++/96363] New: bogus error with constrained partial specialization

[nathan at gcc dot gnu.org]

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

Bug ID: 96363
   Summary: bogus error with constrained partial specialization
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nathan at gcc dot gnu.org
  Target Milestone: ---

template  class TPL;

template  struct Trait;

template 
  requires (Trait::val == 0)
class TPL;  // #1

template 
  requires (Trait::val == 1)
class TPL;  // #2 error here

cc1plus -quiet -std=c++20 par.cc 
par.cc:11:7: error: ‘TPL’ does not match original declaration
   11 | class TPL;
  |   ^~
par.cc:1:29: note: original template declaration here
1 | template  class TPL;
  | ^~~

ICBW, but if #2 is rejected, why is #1 accepted.  Aren't these just two partial
specializations with different constraints?

[Bug fortran/96325] Unclassifiable statement with syntax similar to a type-bound procedure call is accepted

[chilikin.k at gmail dot com]

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

--- Comment #7 from Kirill Chilikin  ---
Result of git bisect:

$ git bisect log
git bisect start
# bad: [6e6e3f144a33ae504149dc992453b4f6dea12fdb] Update ChangeLog and version
files for release
git bisect bad 6e6e3f144a33ae504149dc992453b4f6dea12fdb
# good: [406c2abec3f998e9064919b22db62f38a7c0e7b9] * gennews (files): Add files
for GCC 8.
git bisect good 406c2abec3f998e9064919b22db62f38a7c0e7b9
# good: [7d75ea04cf6d9c8960d5c6119d6203568b7069e9] re PR c++/85437 (member
pointer static upcast rejected in a constexpr context)
git bisect good 7d75ea04cf6d9c8960d5c6119d6203568b7069e9
# good: [5fae049dc272144f8e61af94ee0ba42b270915e5] OpenACC Profiling Interface
(incomplete)
git bisect good 5fae049dc272144f8e61af94ee0ba42b270915e5
# bad: [271da732841345d3834cf458d47f8242ac5ef513] PR testsuite/92127: Disable
unrolling for some vect code model cases
git bisect bad 271da732841345d3834cf458d47f8242ac5ef513
# good: [4a2e9be1ac7c8f4c37b5deb4ce0b0f39925e56c9] [Ada] New parameter Quiet
for procedure GNAT.Command_Line.Getopt
git bisect good 4a2e9be1ac7c8f4c37b5deb4ce0b0f39925e56c9
# bad: [0968003dd08a9e9f83bee955bbdc259a781f044f] PR c++/91819 - ICE with
operator++ and enum.
git bisect bad 0968003dd08a9e9f83bee955bbdc259a781f044f
# good: [32b1d51f16fe56b34e979fcfba4bc74dbd3592a9] runtime: move osinit to Go
git bisect good 32b1d51f16fe56b34e979fcfba4bc74dbd3592a9
# bad: [a1fc3891ebb77c1bdf68ce70c074eb907d21771a] go/internal/gccgoimporter:
support embedded field in pointer loop
git bisect bad a1fc3891ebb77c1bdf68ce70c074eb907d21771a
# bad: [e7414688f16c4c9db2dacbc31da683887b4ba1bd] re PR middle-end/90501 (ICE:
address taken, but ADDRESSABLE bit not set)
git bisect bad e7414688f16c4c9db2dacbc31da683887b4ba1bd
# good: [a37ab089c22f8be834bb1b5fd4c0454224db9b0f] 2019-09-01  François Dumont 

git bisect good a37ab089c22f8be834bb1b5fd4c0454224db9b0f
# bad: [c6c2d1bc9bc3eb3606af6a198e74170bd906e199] re PR other/79543
(Inappropriate "ld --version" checking)
git bisect bad c6c2d1bc9bc3eb3606af6a198e74170bd906e199
# good: [1525fa83cc704ba18738eb2eab76a7f4d6bfde6b] re PR
tree-optimization/91632 (Probably wrong code since r275026)
git bisect good 1525fa83cc704ba18738eb2eab76a7f4d6bfde6b
# bad: [75f935365dba3eb5e9cbd11bc0d75009cad3d019] [AArch64] Add Linux hwcap
strings for some extensions
git bisect bad 75f935365dba3eb5e9cbd11bc0d75009cad3d019
# bad: [f79be3a7dbf8d9cd7e675918472ebc3c2c9d5e47] re PR fortran/91589 (ICE in
gfc_conv_component_ref, at fortran/trans-expr.c:2447)
git bisect bad f79be3a7dbf8d9cd7e675918472ebc3c2c9d5e47
# good: [be0fb5484a64414878c31a1606b07175b54ecb90] re PR fortran/91552 (ICE
with valid array constructor)
git bisect good be0fb5484a64414878c31a1606b07175b54ecb90
# first bad commit: [f79be3a7dbf8d9cd7e675918472ebc3c2c9d5e47] re PR
fortran/91589 (ICE in gfc_conv_component_ref, at fortran/trans-expr.c:2447)

f79be3a7dbf8d9cd7e675918472ebc3c2c9d5e47 is the first bad commit
commit f79be3a7dbf8d9cd7e675918472ebc3c2c9d5e47
Author: Paul Thomas 
Date:   Mon Sep 2 19:54:02 2019 +

re PR fortran/91589 (ICE in gfc_conv_component_ref, at
fortran/trans-expr.c:2447)

2019-09-02  Paul Thomas  

PR fortran/91589
* primary.c (gfc_match_varspec): Return MATCH_NO on an apparent
component ref, when the primary type is intrinsic.

2019-09-02  Paul Thomas  

PR fortran/91589
* gfortran.dg/pr91589.f90 : New test.

From-SVN: r275324

[Bug c/96362] bootstrapping gcc 9.3.0 on sparc-sun-solaris2.11 fails compiling libgcc2.c (.group in output)

[nicholas.h.briggs at gmail dot com]

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

--- Comment #2 from Nick Briggs  ---
binutils/as version is:

/opt/binutils/bin/as --version
GNU assembler (GNU Binutils) 2.35
Copyright (C) 2020 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or later.
This program has absolutely no warranty.
This assembler was configured for a target of `sparc-sun-solaris2.11'.

[Bug c/96362] bootstrapping gcc 9.3.0 on sparc-sun-solaris2.11 fails compiling libgcc2.c (.group in output)

[nicholas.h.briggs at gmail dot com]

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

--- Comment #1 from Nick Briggs  ---
Created attachment 48948
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48948=edit
Intermediate output from gcc-9.3.0 compiling libgcc2 during bootstrap

[Bug c/96362] New: bootstrapping gcc 9.3.0 on sparc-sun-solaris2.11 fails compiling libgcc2.c (.group in output)

[nicholas.h.briggs at gmail dot com]

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

Bug ID: 96362
   Summary: bootstrapping gcc 9.3.0 on sparc-sun-solaris2.11 fails
compiling libgcc2.c (.group in output)
   Product: gcc
   Version: 9.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nicholas.h.briggs at gmail dot com
  Target Milestone: ---

Created attachment 48947
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48947=edit
Intermediate output from gcc-9.3.0 compiling libgcc2 during bootstrap

Attempting to bootstrap gcc 9.3.0 (and same problem with gcc 10.2.0) on
sparc-sun-solaris2.11 system fails at the point of compiling libgcc2.c for
_ffssi2 as the compiler generates a .group directive which is not understood by
the binutils-2.35 as.

Configured with:

'../gcc/configure'   '--prefix=/opt/gcc-9.3' '--disable-werror'
'--disable-checking' 'CC=gcc' 'CXX=g++' '--disable-multilib'
'--build=sparc-sun-solaris2.11' 'buil
d_alias=sparc-sun-solaris2.11' '--enable-languages=c,c++,lto'

Where it attempts to execute:

/export/home/briggs/gcc-9.3-objdir/./gcc/xgcc
-B/export/home/briggs/gcc-9.3-objdir/./gcc/
-B/opt/gcc-9.3/sparc-sun-solaris2.11/bin/
-B/opt/gcc-9.3/sparc-sun-solaris2.11/lib/ -isystem
/opt/gcc-9.3/sparc-sun-solaris2.11/include -isystem
/opt/gcc-9.3/sparc-sun-solaris2.11/sys-include   -fno-checking -g -O2 -O2  -g
-O2 -DIN_GCC-W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format
-Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition  -isystem
./include   -fPIC -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector  
-fPIC -I. -I. -I../.././gcc -I../../../gcc/libgcc -I../../../gcc/libgcc/.
-I../../../gcc/libgcc/../gcc -I../../../gcc/libgcc/../include  -DHAVE_CC_TLS 
-o _ffssi2.o -MT _ffssi2.o -MD -MP -MF _ffssi2.dep -DL_ffssi2 -c
../../../gcc/libgcc/libgcc2.c -fvisibility=hidden -DHIDE_EXPORTS

it fails with

_ffssi2.s: Assembler messages:
_ffssi2.s:1536: Error: unknown pseudo-op: `.group'

The complete _ffssi2.i and _ffssi2.s are attached.  The problematic section in
the _ffssi2.s is:

.LLASF11:
.asciz  "__seekable"
.ident  "GCC: (GNU) 9.3.0"
.section   
".text.__sparc_get_pc_thunk.l7%__sparc_get_pc_thunk.l7",#alloc,#execinstr,#progbits
.group 
__sparc_get_pc_thunk.l7,".text.__sparc_get_pc_thunk.l7%__sparc_get_pc_thunk.l7",#comdat
.align 4
.weak   __sparc_get_pc_thunk.l7
.hidden __sparc_get_pc_thunk.l7
.type   __sparc_get_pc_thunk.l7, #function
.proc   020
__sparc_get_pc_thunk.l7:
.cfi_startproc
jmp %o7+8
 add%o7, %l7, %l7
.cfi_endproc

[Bug c++/96361] New: return type not deduced for a function template specialization given as argument of a template function

[okannen at gmail dot com]

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

Bug ID: 96361
   Summary: return type not deduced for a function template
specialization given as argument of a template
function
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: okannen at gmail dot com
  Target Milestone: ---

This bug exist since GCC 6.1 and is still present in version GCC 10.2

The following code should compile:

template 
auto f(T v){
  return v+v;
}

template 
void g(T && v);

void h(){
  g(f);  //Error
}

GCC error message is: no matching function for call to 'g()'

There is no error if the return type of f is not deduced or if some code
is used to force the return type deduction. For exemple if the function h is
changed to:

void h(){
  using x  = decltype (f);
  g(f); // No error
}

the code compile.

[Bug c++/96354] [10/11 Regression] ICE in maybe_canonicalize_mem_ref_addr, at gimple-fold.c:4903 since r10-2271-gd81ab49d0586fca0

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Assignee|marxin at gcc dot gnu.org  |jakub at gcc dot gnu.org

--- Comment #10 from Jakub Jelinek  ---
Slightly adjusted testcase:

template  struct A { typedef double T[N]; };
template  struct B { typename A::T b; double *baz () { return b; } };
template  struct C { B d; C (); };
template  C::C () { double c = *d.baz (); }
template  void operator- (C, const C &);
template  struct D {};
template  C foo (D, C) { C t; return t; }
int e;
struct E { D<3> d; void bar (); };

void
E::bar ()
{
#pragma omp simd
  for (int i = 0; i < e; i++)
{
  C<3> f, g;
  g - foo (d, f);
}
}

[Bug c++/96360] New: ICE in tree check: expected integer_cst, have truth_orif_expr in get_len, at tree.h:5954

[haoxintu at gmail dot com]

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

Bug ID: 96360
   Summary: ICE in tree check: expected integer_cst, have
truth_orif_expr in get_len, at tree.h:5954
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: ice-on-invalid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: haoxintu at gmail dot com
  Target Milestone: ---

Hi, all.

This invalid code makes GCC ICE and without any error diagnostic messages.

Input:
//small.cc
short a = 0;
long const b = 0;
enum class c {e}; 
template  class A{}; 
template <> enum class c {};

Command:
g++ small.cc

Ouput:
small.cc:6:27: internal compiler error: tree check: expected integer_cst, have
truth_orif_expr in get_len, at tree.h:5954
6 | template <> enum class c {};
  |   ^
0x7ebb15 tree_check_failed(tree_node const*, char const*, int, char const*,
...)
../../gcc/tree.c:9687
0x8aeb5a tree_check(tree_node const*, char const*, int, char const*, tree_code)
../../gcc/tree.h:3559
0x8aeb5a wi::extended_tree<192>::get_len() const
../../gcc/tree.h:5954
0x8aeb5a wi::int_traits >
>::decompose(long*, unsigned int, generic_wide_int >
const&)
../../gcc/wide-int.h:985
0x8aeb5a wide_int_ref_storage::wide_int_ref_storage >
>(generic_wide_int > const&, unsigned int)
../../gcc/wide-int.h:1034
0x8aeb5a generic_wide_int
>::generic_wide_int >
>(generic_wide_int > const&, unsigned int)
../../gcc/wide-int.h:790
0x8aeb5a bool wi::lts_p >,
generic_wide_int >
>(generic_wide_int > const&,
generic_wide_int > const&)
../../gcc/wide-int.h:1901
0x93b738 wi::binary_traits >,
generic_wide_int >,
wi::int_traits > >::precision_type,
wi::int_traits >
>::precision_type>::signed_predicate_result operator<
 >,
generic_wide_int >
>(generic_wide_int > const&,
generic_wide_int > const&)
../../gcc/wide-int.h:3248
0x93b738 tree_int_cst_lt(tree_node const*, tree_node const*)
../../gcc/tree.h:6110
0x93b738 finish_enum_value_list(tree_node*)
../../gcc/cp/decl.c:15574
0x9cc32b cp_parser_enum_specifier
../../gcc/cp/parser.c:19471
0x9cc32b cp_parser_type_specifier
../../gcc/cp/parser.c:17757
0x9ccc0e cp_parser_decl_specifier_seq
../../gcc/cp/parser.c:14424
0x9f46d5 cp_parser_single_declaration
../../gcc/cp/parser.c:29487
0x9f59f0 cp_parser_explicit_specialization
../../gcc/cp/parser.c:17677
0x9f8e5d cp_parser_declaration
../../gcc/cp/parser.c:13444
0x9f941b cp_parser_translation_unit
../../gcc/cp/parser.c:4781
0x9f941b c_parse_file()
../../gcc/cp/parser.c:44069
0xb13e2d c_common_parse_file()
../../gcc/c-family/c-opts.c:1188
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

Every version of GCC-6.1 onwards behaves the same. (I didn't test older
versions)

[Bug fortran/96319] Don't warn for LOGICAL kind conversion with -Wconversion

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Severity|normal  |enhancement
   Priority|P3  |P5

[Bug c++/96359] New: ICE in cxx_eval_logical_expression, at cp/constexpr.c:3875

[haoxintu at gmail dot com]

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

Bug ID: 96359
   Summary: ICE in cxx_eval_logical_expression, at
cp/constexpr.c:3875
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: error-recovery, ice-on-invalid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: haoxintu at gmail dot com
  Target Milestone: ---

Hi, all.

This invlaid code makes GCC ICE. What shocked me is that when I change the
value of b (for example, let b=1), GCC performs well in error-recovery.

Input:
//small.cc
short a;
const char b = 5;
explicit void c (auto, int = b or a, enum {});

Command:
g++ -w small.cc

Output:
small.cc:4:38: error: types may not be defined in parameter types
4 | explicit void c (auto, int = b or a, enum {});
  |  ^~~~
small.cc:4:45: internal compiler error: in cxx_eval_logical_expression, at
cp/constexpr.c:3875
4 | explicit void c (auto, int = b or a, enum {});
  | ^
0x61b51e cxx_eval_logical_expression
../../gcc/cp/constexpr.c:3875
0x8d5fdf cxx_eval_constant_expression
../../gcc/cp/constexpr.c:6133
0x8d938f cxx_eval_outermost_constant_expr
../../gcc/cp/constexpr.c:6756
0x8dd7ab maybe_constant_value(tree_node*, tree_node*, bool)
../../gcc/cp/constexpr.c:7029
0x907264 cp_fully_fold(tree_node*)
../../gcc/cp/cp-gimplify.c:2464
0x90e7cf cp_convert_and_check(tree_node*, tree_node*, int)
../../gcc/cp/cvt.c:661
0x89a679 convert_like_internal
../../gcc/cp/call.c:7846
0x89bf59 convert_like
../../gcc/cp/call.c:7892
0x89bf59 perform_implicit_conversion_flags(tree_node*, tree_node*, int, int)
../../gcc/cp/call.c:11907
0x921e0f check_default_argument(tree_node*, tree_node*, int)
../../gcc/cp/decl.c:13924
0x92246f grokparms(tree_node*, tree_node**)
../../gcc/cp/decl.c:14112
0x933889 grokdeclarator(cp_declarator const*, cp_decl_specifier_seq*,
decl_context, int, tree_node**)
../../gcc/cp/decl.c:12393
0x93ed08 start_decl(cp_declarator const*, cp_decl_specifier_seq*, int,
tree_node*, tree_node*, tree_node**)
../../gcc/cp/decl.c:5232
0x9ed46d cp_parser_init_declarator
../../gcc/cp/parser.c:20846
0x9cdacc cp_parser_simple_declaration
../../gcc/cp/parser.c:13799
0x9f8d2e cp_parser_declaration
../../gcc/cp/parser.c:13498
0x9f941b cp_parser_translation_unit
../../gcc/cp/parser.c:4781
0x9f941b c_parse_file()
../../gcc/cp/parser.c:44069
0xb13e2d c_common_parse_file()
../../gcc/c-family/c-opts.c:1188
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

My gcc version is:
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/home/tuhaoxin/compilers/gcc-0726/build/bin/../libexec/gcc/x86_64-pc-linux-gnu/11.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure CC=gcc-10 CXX=g++-10
--prefix=/home/hatuhaoxin/compilers/gcc-0726/build/ --enable-languages=c,c++
--disable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.0.0 20200726 (experimental) (GCC) 

Thanks,
Haoxin

[Bug c++/64529] Noexcept New

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org
 Resolution|--- |INVALID
 Status|UNCONFIRMED |RESOLVED

--- Comment #1 from Marek Polacek  ---
Since C++11, we already have non-throwing allocation functions.

[Bug c++/96354] [10/11 Regression] ICE in maybe_canonicalize_mem_ref_addr, at gimple-fold.c:4903 since r10-2271-gd81ab49d0586fca0

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek  ---
(In reply to rguent...@suse.de from comment #8)
> We could allow this in debug stmts but pretty much any (or very many)
> workers on MEM_REFs will be quite unhappy about this. Of course we're not
> likely to run them on debug stmts. But then, we do have debug Temps for
> this...

I was wondering if we are ok with even MEM_REF with DEBUG_EXPR_DECL as the
address, but seems at least this routine is ok with that one.
The question is what we would do with that at cfgexpand.c time.
But I guess I can look at where this is folded into it and see if I can break
it out into a debug expr decl and then see what expansion does for it.

[Bug c++/96354] [10/11 Regression] ICE in maybe_canonicalize_mem_ref_addr, at gimple-fold.c:4903 since r10-2271-gd81ab49d0586fca0

[rguenther at suse dot de]

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

--- Comment #8 from rguenther at suse dot de  ---
On July 28, 2020 4:45:59 PM GMT+02:00, "jakub at gcc dot gnu.org"
 wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96354
>
>--- Comment #7 from Jakub Jelinek  ---
>So we have:
>  # DEBUG this => &
>   ={v} {CLOBBER};
>  # DEBUG D#1 => &.d
>  # DEBUG D#2 => MEM[(double *)&]
>  # DEBUG __trans_tmp_3 => D#2
>in matmul during inlining, and inline it as:
>  # DEBUG this => [_13]
>  _24 = [_13];
>  *_24 ={v} {CLOBBER};
>  # DEBUG D#1 => [_13].d
>  # DEBUG D#2 => MEM[(double *)[_13]]
>  # DEBUG __trans_tmp_3 => D#2
>  # DEBUG this => NULL
>Generally, we are more lax about IL restrictions we have in debug stmts
>compared to other stmts, e.g. verify_gimple_debug always returns false.
>So, do we want to allow this case?
>I believe cfgexpand.c handles that:
>case MEM_REF:
>  if (!is_gimple_mem_ref_addr (TREE_OPERAND (exp, 0)))
>{
>  tree newexp = fold_binary (MEM_REF, TREE_TYPE (exp),
> TREE_OPERAND (exp, 0),
> TREE_OPERAND (exp, 1));
>  if (newexp)
>return expand_debug_expr (newexp);
>}
>  /* FALLTHROUGH */
>case INDIRECT_REF:
>or punts if the folding doesn't come up with anything.
>So, we could e.g. add bool is_debug argument to
>maybe_canonicalize_mem_ref_addr, pass true only when in GIMPLE_DEBUG
>and
>instead of failing the assertion there return false (what about the
>other
>assertions in there?).
>Or instead of bool is_debug take bool *is_debug and if non-NULL (only
>for
>GIMPLE_DEBUG) set it to *false if we'd otherwise fail and tell that way
>to the
>caller that it should reset the debug stmt?
>richi, your thoughts on this?

We could allow this in debug stmts but pretty much any (or very many) workers
on MEM_REFs will be quite unhappy about this. Of course we're not likely to run
them on debug stmts. But then, we do have debug Temps for this...

[Bug d/96358] New: d: Merge indirect_ref and build_deref, represent with a MEM_REF expression

[ibuclaw at gdcproject dot org]

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

Bug ID: 96358
   Summary: d: Merge indirect_ref and build_deref, represent with
a MEM_REF expression
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: ibuclaw at gdcproject dot org
  Target Milestone: ---

Both functions do pretty much identical things, can build a MEM_REF expression
instead of INDIRECT_REF whilst that part of the code-gen is being refactored.

[Bug fortran/96325] Unclassifiable statement with syntax similar to a type-bound procedure call is accepted

[kargl at gcc dot gnu.org]

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

--- Comment #6 from kargl at gcc dot gnu.org ---
This is a nasty bug, and I've run out of ideas on how to find a fix. :(

Simplified testcase

   implicit none

   type t2
  integer r1
   end type

   type(t2) :: t
   integer :: a

   a = t%r1%foo(1) ! There is no foo component/TBP
   if (a == 42) stop

   end

-fdump-tree-original gives

MAIN__ ()
{
  integer(kind=4) a;
  struct t2 t;

  a = 1;
  if (a == 42)
{
  _gfortran_stop_string (0B, 0, 0);
}
  L.1:;
}

[Bug c/80076] -Wmisleading-indentation doesn't trigger when macro is misindented

[ppalka at gcc dot gnu.org]

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

Patrick Palka  changed:

   What|Removed |Added

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

[Bug fortran/96320] gfortran 8-10 shape mismatch in assumed-length dummy argument character array

[dominiq at lps dot ens.fr]

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

--- Comment #18 from Dominique d'Humieres  ---
With

--- ../_clean/gcc/fortran/interface.c   2020-07-11 20:06:47.0 +0200
+++ gcc/fortran/interface.c 2020-07-28 11:41:57.0 +0200
@@ -1466,8 +1466,19 @@ gfc_check_dummy_characteristics (gfc_sym
   int i, compval;
   gfc_expr *shape1, *shape2;

+  if (s1->ns->proc_name && s1->ns->proc_name->attr.module_procedure
+ && s1->as->type == AS_ASSUMED_SHAPE
+ && s2->as->type == AS_DEFERRED)
+   {
+ s2->as->type = AS_ASSUMED_SHAPE;
+ for (i = 0; i < s2->as->rank; i++)
+   if (s1->as->lower[i] != NULL)
+ s2->as->lower[i] = gfc_copy_expr (s1->as->lower[i]);
+   }
+
   if (s1->as->type != s2->as->type)
{
+/*   gfc_warning_now (0, "s1 %i   s2 %i \n", s1->as->type, s2->as->type);
*/
  snprintf (errmsg, err_len, "Shape mismatch in argument '%s'",
s1->name);
  return false;

the patch regtest without regression.

> > /opt/gcc/work/gcc/testsuite/gfortran.dg/whole_file_23.f90:18:32:
> > 
> >18 | pure integer function lensum (words, sep)
> > Warning: Interface mismatch in global procedure 'lensum' at (1): Shape 
> > mismatch
> > in argument 'words'
> 
> So, change the dg-error to "Interface mismatch in"  from
> "Shape mismatch in".  Clearly, Paul's patch detects an
> error earlier in the parsing than previously detected.

The warning is at least as old as GCC7 but is suppressed in the testsuite by
-pedantic-errors (very surprising) thus doesn't fail.

[Bug c++/96356] RTTI for non-polymorphic typeid

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
>From optimization POV (if we don't do that already), it would be nice to
optimize away after IPA comparisons the typeinfo comparisons, by making the
_ZT* symbols special (add some attribute them or whatever) and teaching the
middle-end the rules for those.

bool
foo ()
{
  return typeid (int) == typeid (long);
}

struct A { A (); virtual ~A (); };
struct B : public A {};

static inline bool
bar (A *p)
{
  return typeid (*p) == typeid (A);
}

bool
baz ()
{
  A a;
  return bar ();
}

bool
qux ()
{
  B a;
  return bar ();
}

[Bug target/96357] [10/11 Regression] could not split insn UNSPEC_COND_FSUB with AArch64 SVE

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

  Known to fail||10.2.1, 11.0
 Target||aarch64
   Target Milestone|--- |10.3
  Known to work||9.3.1

[Bug target/96357] New: [10/11 Regression] could not split insn UNSPEC_COND_FSUB with AArch64 SVE

[ktkachov at gcc dot gnu.org]

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

Bug ID: 96357
   Summary: [10/11 Regression] could not split insn
UNSPEC_COND_FSUB with AArch64 SVE
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ktkachov at gcc dot gnu.org
  Target Milestone: ---

The reduced testcase:
typedef int a;
int d;
void e(char f, char *g, char *h, char *l, char * n) {
  double i = d, j = 1.0 - f, k = j ? d : j;
  if (k == 1.0)
i = 0.0;
  *g = *h = i * 0.5;
  *l = *n = 0;
}

void o() {
  int  a, m, c = o;
  for (; c; c--) {
char b = a++;
e(b, m, m + 1, m + 2, m + 3);
m += 4;
  }
}

ICEs with -w -O3 -march=arvm8.2-a+sve
reduced.c: In function ‘o’:
reduced.c:18:1: error: could not split insn
   18 | }
  | ^
(insn 145 401 149 (set (reg:VNx2DF 39 v7 [orig:145 _127 ] [145])
(unspec:VNx2DF [
(reg:VNx2BI 69 p1 [318])
(unspec:VNx2DF [
(reg:VNx2BI 78 p10 [318])
(const_int 1 [0x1])
(const_vector:VNx2DF [
(const_double:DF 1.0e+0 [0x0.8p+1])
])
(reg:VNx2DF 37 v5 [orig:152 vect__27.15 ] [152])
] UNSPEC_COND_FSUB)
(reg:VNx2DF 48 v16 [orig:140 vect_i_26.13 ] [140])
] UNSPEC_SEL)) 5775 {*cond_subvnx2df_any_const}
 (expr_list:REG_DEAD (reg:VNx2BI 78 p10 [318])
(expr_list:REG_DEAD (reg:VNx2BI 69 p1 [318])
(expr_list:REG_DEAD (reg:VNx2DF 37 v5 [orig:152 vect__27.15 ]
[152])
(nil)
during RTL pass: final

[Bug target/96347] note: non-delegitimized UNSPEC UNSPEC_TP (19) found in variable location

[ibuclaw at gdcproject dot org]

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

--- Comment #3 from Iain Buclaw  ---
Created attachment 48946
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48946=edit
disallow tpoff+offset from being stored in a temp

Patch prevents the forced temp from being used to replace the rhs of the
original PLUS expr at memory_address_addr_space (explow.c:434), so the excess
errors are gone.

Alters the resultant assembly in the following way:
---
@@ -35,15 +35,11 @@ _Z5chain6Darray:
 main:
 .LFB4:
.cfi_startproc
-   pushq   %rbp
-   .cfi_def_cfa_offset 16
-   .cfi_offset 6, -16
-   leaq8+testYearsBC@tpoff, %rbp
pushq   %rbx
-   .cfi_def_cfa_offset 24
-   .cfi_offset 3, -24
-   subq$40, %rsp
-   .cfi_def_cfa_offset 64
+   .cfi_def_cfa_offset 16
+   .cfi_offset 3, -16
+   subq$32, %rsp
+   .cfi_def_cfa_offset 48
leaq17(%rsp), %rbx
jmp .L6
.p2align 4,,10
@@ -56,11 +52,11 @@ main:
movl$0, (%rbx)
movw%ax, 4(%rbx)
movb$0, 6(%rbx)
-   movq%fs:0(%rbp), %rdx
movq%fs:testYearsBC@tpoff, %rax
+   movq%fs:8+testYearsBC@tpoff, %rdx
movb$0, 16(%rsp)
-   movq%rdx, 8(%rsp)
movq%rax, (%rsp)
+   movq%rdx, 8(%rsp)
testq   %rax, %rax
je  .L7
jmp .L9
@@ -71,9 +67,8 @@ main:
 main.cold:
 .LFSB4:
 .L7:
-   .cfi_def_cfa_offset 64
-   .cfi_offset 3, -24
-   .cfi_offset 6, -16
+   .cfi_def_cfa_offset 48
+   .cfi_offset 3, -16
callabort@PLT
.cfi_endproc
 .LFE4:

[Bug c++/96356] RTTI for non-polymorphic typeid

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #2 from Jonathan Wakely  ---
It would be theoretically possible for the compiler to elide some RTTI code
when the effects are known at compile time, e.g. so typeid(int)==typeid(int) is
always true, and typeid(int)==typeid(long) is always false, even without RTTI.

But that isn't going to help your case, where std::any::type() still has to
return something, and unless the creation of the std::any and the call to
type() are both visible to the compiler and inlined, then you're not going
to get something equivalent to typeid(A)==typeid(B) where the types are known
at compile time.

Such an optimisation seems likely to only work in "embarrassingly simple" cases
where you don't actually need to use typeid anyway. If it doesn't work in
actually useful cases (where the types aren't known in advance because the
types depend on run time conditions) then implementing that optimisation seems
like a waste of time.  No sensible code is going to use typeid when all the
types are known at compile time, because you wouldn't bother using type erasure
or RTTI in such cases.

Not a bug.

[Bug c++/96354] [10/11 Regression] ICE in maybe_canonicalize_mem_ref_addr, at gimple-fold.c:4903 since r10-2271-gd81ab49d0586fca0

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
So we have:
  # DEBUG this => &
   ={v} {CLOBBER};
  # DEBUG D#1 => &.d
  # DEBUG D#2 => MEM[(double *)&]
  # DEBUG __trans_tmp_3 => D#2
in matmul during inlining, and inline it as:
  # DEBUG this => [_13]
  _24 = [_13];
  *_24 ={v} {CLOBBER};
  # DEBUG D#1 => [_13].d
  # DEBUG D#2 => MEM[(double *)[_13]]
  # DEBUG __trans_tmp_3 => D#2
  # DEBUG this => NULL
Generally, we are more lax about IL restrictions we have in debug stmts
compared to other stmts, e.g. verify_gimple_debug always returns false.
So, do we want to allow this case?
I believe cfgexpand.c handles that:
case MEM_REF:
  if (!is_gimple_mem_ref_addr (TREE_OPERAND (exp, 0)))
{
  tree newexp = fold_binary (MEM_REF, TREE_TYPE (exp),
 TREE_OPERAND (exp, 0),
 TREE_OPERAND (exp, 1));
  if (newexp)
return expand_debug_expr (newexp);
}
  /* FALLTHROUGH */
case INDIRECT_REF:
or punts if the folding doesn't come up with anything.
So, we could e.g. add bool is_debug argument to
maybe_canonicalize_mem_ref_addr, pass true only when in GIMPLE_DEBUG and
instead of failing the assertion there return false (what about the other
assertions in there?).
Or instead of bool is_debug take bool *is_debug and if non-NULL (only for
GIMPLE_DEBUG) set it to *false if we'd otherwise fail and tell that way to the
caller that it should reset the debug stmt?
richi, your thoughts on this?

[Bug c++/96356] RTTI for non-polymorphic typeid

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
Yes it's expected. The typeid operator has to return a std::typeinfo object. If
you disable generation of std::typeinfo objects, what is it supposed to return?

The savings from -fno-rtti come from not generating all the RTTI objects, not
just from refusing to use that info at runtime.

[Bug c++/96354] [10/11 Regression] ICE in maybe_canonicalize_mem_ref_addr, at gimple-fold.c:4903 since r10-2271-gd81ab49d0586fca0

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Sure.

[Bug c++/96354] [10/11 Regression] ICE in maybe_canonicalize_mem_ref_addr, at gimple-fold.c:4903 since r10-2271-gd81ab49d0586fca0

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|ASSIGNED|NEW

--- Comment #5 from Martin Liška  ---
Reduced test-case:

cat /tmp/RMSD.ii
template  struct __array_traits { typedef double _Type[_Nm]; };
template  struct array {
  typename __array_traits<_Nm>::_Type _M_elems;
  double *data() { return _M_elems; }
};
template  class VectorGeneric {
  array d;
public:
  VectorGeneric();
};
template  VectorGeneric::VectorGeneric() {
  double __trans_tmp_3 = *d.data();
}
template 
void operator-(VectorGeneric, const VectorGeneric &);
template  class TensorGeneric {};
template 
VectorGeneric matmul(TensorGeneric, VectorGeneric) {
  VectorGeneric t;
  return t;
}
int doCoreCalc_n;
class RMSDCoreData {
  TensorGeneric<3> rotation;
  void doCoreCalc();
};
void RMSDCoreData::doCoreCalc() {
  for (unsigned iat;;)
#pragma omp simd
for (iat = 0; iat < doCoreCalc_n; iat++) {
  VectorGeneric<3> __trans_tmp_2, __trans_tmp_4;
  __trans_tmp_4 - matmul(rotation, __trans_tmp_2);
}
}

@Jakub: Can you please take a look?

[Bug fortran/96320] gfortran 8-10 shape mismatch in assumed-length dummy argument character array

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #17 from Steve Kargl  ---
On Tue, Jul 28, 2020 at 10:32:50AM +, dominiq at lps dot ens.fr wrote:
> 
> What I guessed, but I still see (not new)
> 
> /opt/gcc/work/gcc/testsuite/gfortran.dg/whole_file_23.f90:18:32:
> 
>18 | pure integer function lensum (words, sep)
>   |1
> Warning: Interface mismatch in global procedure 'lensum' at (1): Shape 
> mismatch
> in argument 'words'
> 

So, change the dg-error to "Interface mismatch in"  from
"Shape mismatch in".  Clearly, Paul's patch detects an
error earlier in the parsing than previously detected.

[Bug c++/96354] [10/11 Regression] ICE in maybe_canonicalize_mem_ref_addr, at gimple-fold.c:4903 since r10-2271-gd81ab49d0586fca0

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org
Summary|[10 regression] ICE in  |[10/11 Regression] ICE in
   |maybe_canonicalize_mem_ref_ |maybe_canonicalize_mem_ref_
   |addr, at gimple-fold.c:4903 |addr, at gimple-fold.c:4903
   ||since
   ||r10-2271-gd81ab49d0586fca0
   Keywords||ice-on-valid-code, openmp

--- Comment #4 from Martin Liška  ---
Started with r10-2271-gd81ab49d0586fca0, I'm reducing that.

[Bug fortran/92703] VALUE attribute: CLASS and derived-type with allocatable components mishandled

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2020-07-28

--- Comment #3 from Dominique d'Humieres  ---
Confirmed down to GCC7.

[Bug preprocessor/96323] [11 Regression] ICE in lex_raw_string, at libcpp/lex.c:1764 since r11-498-ged63c387aa0bc184

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug middle-end/96335] [10/11 Regression] ICE in maybe_warn_rdwr_sizes since r10-4929

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #4 from Jakub Jelinek  ---
Fixed for 10.3 and later.

[Bug c++/96328] [11 Regression] Single keyword "friend" makes GCC ICE in cp_lexer_previous_token, at cp/parser.c:769 since r11-891-g1dc83b460653c29f

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug c++/96356] New: RTTI for non-polymorphic typeid

[c.de-claverie at pm dot me]

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

Bug ID: 96356
   Summary: RTTI for non-polymorphic typeid
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: c.de-claverie at pm dot me
  Target Milestone: ---

Hello,

I would like to bring the following possible issue to your attention to make
sure the behaviour is expected :
https://stackoverflow.com/questions/63132693

To sum up the problem, a "cannot use 'typeid' with '-fno-rtti'" error is thrown
when using the typeid operator on type-erased non-polymorphic types. It is
unclear to me whether this is the an expected behabiour or not, because the
typeid operator is resolved at compile time (according to cppreference) and, as
a result, should not be reliant on rtti.

This is my first contribution here. Please feel free to let me know if I can
add any useful information.

[Bug c++/96354] [10 regression] ICE in maybe_canonicalize_mem_ref_addr, at gimple-fold.c:4903

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #3 from Martin Liška  ---
Great, I was able to reproduce that. Working on that..

[Bug c++/96328] [11 Regression] Single keyword "friend" makes GCC ICE in cp_lexer_previous_token, at cp/parser.c:769 since r11-891-g1dc83b460653c29f

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:86cb35983f55d6039b99b82ace30d2730fcb1eb1

commit r11-2385-g86cb35983f55d6039b99b82ace30d2730fcb1eb1
Author: Jakub Jelinek 
Date:   Tue Jul 28 15:41:30 2020 +0200

c++: Fix up cp_lexer_safe_previous_token [PR96328]

The following testcase ICEs, because cp_lexer_safe_previous_token calls
cp_lexer_previous_token and that ICEs, because all tokens in the lexer
buffer before the current one (CPP_EOF) have been purged.

cp_lexer_safe_previous_token is used in the context where it is ok if it
punts, so the patch changes the function so that it doesn't assert there is
some previous token, but instead returns NULL like in other cases where it
punts.

In addition to this, in the last hunk it does a micro-optimization, don't
call the potentially expensive function if it will not need the result,
instead check the least expensive condition first.

And the middle hunk is a similar change from Mark's version of the patch,
to use the safe variant in there because it is again just about a hint
and it is better not to provide the hint than to ICE, though we don't have
a
testcase that would ICE.

2020-07-28  Jakub Jelinek  
Mark Wielaard  

PR c++/96328
* parser.c (cp_lexer_safe_previous_token): Don't call
cp_lexer_previous_token, instead inline it by hand and return NULL
instead of failing assertion if all previous tokens until the first
one are purged.
(cp_parser_error_1): Optimize - only call
cp_lexer_safe_previous_token
if token->type is CPP_NAME.  Use cp_lexer_safe_previous_token
instead
of cp_lexer_previous_token for the missing_token_desc != RT_NONE
case too.

* g++.dg/diagnostic/pr96328.C: New test.

Co-Authored-By: Mark Wielaard 

[Bug c++/96354] [10 regression] ICE in maybe_canonicalize_mem_ref_addr, at gimple-fold.c:4903

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org
   Target Milestone|--- |10.3

[Bug preprocessor/96323] [11 Regression] ICE in lex_raw_string, at libcpp/lex.c:1764 since r11-498-ged63c387aa0bc184

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r11-2384-gae49af94850b26e50268031e24f1559d5a51edec
Author: Jakub Jelinek 
Date:   Tue Jul 28 15:40:15 2020 +0200

libcpp: Fix up raw string literal parsing error-recovery [PR96323]

For (invalid) newline inside of the raw string literal delimiter, doing
continue means we skip the needed processing of newlines.  Instead of
duplicating that, this patch just doesn't continue for those.

2020-07-28  Jakub Jelinek  

PR preprocessor/96323
* lex.c (lex_raw_string): For c == '\n' don't continue after
reporting
an prefix delimiter error.

* c-c++-common/cpp/pr96323.c: New test.

[Bug other/92396] -ftime-trace support

[amonakov at gcc dot gnu.org]

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

Alexander Monakov  changed:

   What|Removed |Added

 CC||amonakov at gcc dot gnu.org

--- Comment #6 from Alexander Monakov  ---
Raw data from timevars is not suitable to make a useful-for-users -ftime-trace
report. The point of -ftime-trace is to present the person using the compiler
with a breakdown on the level of their source files, functions, template
instantiations, i.e. something they understand and can change. No need to show
users any sort of breakdown by individual GIMPLE/RTL passes: as far as they are
concerned it's one complex "code generation" phase they cannot substantially
change.

The original blog post by Aras Pranckevičius explains this well, contrasting
against GCC's and LLVM's -ftime-report:
https://aras-p.info/blog/2019/01/12/Investigating-compile-times-and-Clang-ftime-report/
(and part 2:
https://aras-p.info/blog/2019/01/16/time-trace-timeline-flame-chart-profiler-for-Clang/
).

GCC simply doesn't measure time on the relevant "axes": we don't split
preprocessing time by included files, nor do we split template instantiation
time in the C++ frontend by template.

[Bug c++/96354] [10 regression] ICE in maybe_canonicalize_mem_ref_addr, at gimple-fold.c:4903

[t...@dev-zero.ch]

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

--- Comment #2 from Tiziano Müller  ---
(In reply to Martin Liška from comment #1)
> Can you please provide steps how to build the project? I can reproduce it
> locally then.

Of course! :)

After unpacking you don't even have to configure it, simply doing the following
is enough. Note: it is only with the combination '-O2', '-g', '-fopenmp',
leaving away any one of them makes it build.

$ cd plumed-2.6.1/src/tools
$ c++ --version
c++ (GCC) 10.2.0
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ c++ -I.. -c -O2 -g -std=c++11 -fopenmp RMSD.cpp -o RMSD.o
during IPA pass: inline
RMSD.cpp: In member function ‘void
PLMD::RMSDCoreData::doCoreCalcWithCloseStructure(bool, bool, PLMD::Tensor&,
PLMD::Tensor&, std::array, 3>, 3>&)’:
RMSD.cpp:1134:6: internal compiler error: in maybe_canonicalize_mem_ref_addr,
at gimple-fold.c:4903
 1134 | void RMSDCoreData::doCoreCalcWithCloseStructure(bool safe,bool alEqDis,
Tensor & rotationPosClose, Tensor & rotationRefClose,
std::array,3> & drotationPosCloseDrr01) {
  |  ^~~~
0xa1bdac maybe_canonicalize_mem_ref_addr
   
/data/tiziano/cp2k/tools/toolchain/build/gcc-10.2.0/gcc/gimple-fold.c:4903
0xa20553 fold_stmt_1
   
/data/tiziano/cp2k/tools/toolchain/build/gcc-10.2.0/gcc/gimple-fold.c:5058
0xd26380 fold_marked_statements
   
/data/tiziano/cp2k/tools/toolchain/build/gcc-10.2.0/gcc/tree-inline.c:5342
0xd332b5 optimize_inline_calls(tree_node*)
   
/data/tiziano/cp2k/tools/toolchain/build/gcc-10.2.0/gcc/tree-inline.c:5448
0xac9f9e inline_transform(cgraph_node*)
   
/data/tiziano/cp2k/tools/toolchain/build/gcc-10.2.0/gcc/ipa-inline-transform.c:736
0xbf187e execute_one_ipa_transform_pass
/data/tiziano/cp2k/tools/toolchain/build/gcc-10.2.0/gcc/passes.c:2233
0xbf187e execute_all_ipa_transforms(bool)
/data/tiziano/cp2k/tools/toolchain/build/gcc-10.2.0/gcc/passes.c:2272
0x8dfdc4 cgraph_node::expand()
   
/data/tiziano/cp2k/tools/toolchain/build/gcc-10.2.0/gcc/cgraphunit.c:2293
0x8e117d expand_all_functions
   
/data/tiziano/cp2k/tools/toolchain/build/gcc-10.2.0/gcc/cgraphunit.c:2471
0x8e117d symbol_table::compile()
   
/data/tiziano/cp2k/tools/toolchain/build/gcc-10.2.0/gcc/cgraphunit.c:2822
0x8e325c symbol_table::finalize_compilation_unit()
   
/data/tiziano/cp2k/tools/toolchain/build/gcc-10.2.0/gcc/cgraphunit.c:3002
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++/96353] GCC internal compiler error: in implicitly_declare_fn, at cp/method.c:2058 when using coverage

[wallguide-software at yahoo dot com]

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

--- Comment #4 from Andrew Wall  ---
Created attachment 48945
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48945=edit
Zipped up TestAll_Of.ii

[Bug c++/96353] GCC internal compiler error: in implicitly_declare_fn, at cp/method.c:2058 when using coverage

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
(In reply to Andrew Wall from comment #2)
> I tried to attach the .ii file when I created this bug, but it is 1.2MB, so
> too large to attach.

Compress it then (zip, gzip, bzip2, xz) before attaching it.

[Bug target/96347] note: non-delegitimized UNSPEC UNSPEC_TP (19) found in variable location

[ibuclaw at gdcproject dot org]

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

--- Comment #2 from Iain Buclaw  ---
Possibly some useful information for context.

At expand_expr_real_1 (expr.c:10567) there is the following expression.
---
MEM  [(struct Darray *) + 8B]
---

Lowered to RTL as
---
(plus:DI (unspec:DI [
(const_int 0 [0])
] UNSPEC_TP)
(const:DI (plus:DI (unspec:DI [
(symbol_ref:DI ("testYearsBC") [flags 0x2a] )
] UNSPEC_NTPOFF)
(const_int 8 [0x8]
---

At break_out_memory_refs (explow.c:277) the rhs of the plus expression is
forced into a register.
---
(insn 18 17 0 (set (reg:DI 89)
(const:DI (plus:DI (unspec:DI [
(symbol_ref:DI ("testYearsBC") [flags 0x2a] )
] UNSPEC_NTPOFF)
(const_int 8 [0x8] -1
 (nil))

(mem/f/c:DI (plus:DI (unspec:DI [
(const_int 0 [0])
] UNSPEC_TP)
(reg:DI 89)) [1 MEM  [(struct Darray *) + 8B]+0 S8
A64])
---

And it is the second insn that reaches const_ok_for_output_1() at
mem_loc_descriptor (dwarf2out.c:15748)
---
(note 133 132 163 3 (var_location year (mem:SI (mem/f/c:DI (plus:DI (unspec:DI
[
(const_int 0 [0])
] UNSPEC_TP)
(reg/f:DI 6 bp [90])) [1 MEM  [(struct Darray *)
+ 8B]+0 S8 A64]) [6 *rs$pt
r_5+0 S4 A32])) NOTE_INSN_VAR_LOCATION)
---

[Bug c++/96353] GCC internal compiler error: in implicitly_declare_fn, at cp/method.c:2058 when using coverage

[wallguide-software at yahoo dot com]

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

--- Comment #2 from Andrew Wall  ---
I tried to attach the .ii file when I created this bug, but it is 1.2MB, so too
large to attach.

When I use the -E flag on the command line the error doesn't occur.

[Bug c++/96355] New: [concepts] internal compiler error: in tsubst_pack_expansion, at cp/pt.c:12928

[src at andyf dot de]

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

Bug ID: 96355
   Summary: [concepts] internal compiler error: in
tsubst_pack_expansion, at cp/pt.c:12928
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: src at andyf dot de
  Target Milestone: ---

The following code (https://godbolt.org/z/edTK48) causes an internal compiler
error:

template
requires requires
{
   requires sizeof...(Args) > 1;
}
auto add(const Args&... args)
{
   return (... + args);
}

int main()
{
   return add(2, 3, 4);
}


The error is:
: In instantiation of 'auto add(const Args& ...) [with Args = {int,
int, int}]':
:13:22:   required from here
:4:13: internal compiler error: in tsubst_pack_expansion, at
cp/pt.c:12922
4 |requires sizeof...(Args) > 1;
  | ^~~

Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.



With g++ 10.1 on godbolt there is no internal compiler error, but the compiler
concludes

:4:29: note: nested requirement '(sizeof... (Args) > 1)' is not
satisfied

which is also wrong. However, the behavior seems to have changed with 10.2.0
and exists in trunk (20200727). The code compiles, if I move the requirement
directly into the requires-clause:

template
requires(sizeof...(Args) > 1)
auto add(const Args&... args)
{
   return (... + args);
}

This version even produces the correct result. I suspect the error is in the
path of the nested requirement.

The failing code compiles with clang 10.0.0 and MSVC 19.24.


Cheers,
   Andreas

[Bug target/96350] [cet] For ENDBR immediate, the binary would include a gadget that starts with a fake ENDBR64 opcode.

[hjl.tools at gmail dot com]

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

--- Comment #4 from H.J. Lu  ---
Created attachment 48944
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48944=edit
An experimental patch

[Bug other/92396] -ftime-trace support

[marxin at gcc dot gnu.org]

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

--- Comment #5 from Martin Liška  ---
Created attachment 48943
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48943=edit
Time trace prototype

So I've just created a prototype patch, but I don't see it much useful:
https://gist.github.com/marxin/dc4354696bc5bd76cdc1d2ecaa4ab060

The main problem is that in case of tree/RTL passes, we run each pass for each
function. Which makes the report full of thin lines.
Thoughts?

[Bug c++/96353] GCC internal compiler error: in implicitly_declare_fn, at cp/method.c:2058 when using coverage

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Liška  ---
Can you please provide a pre-processed source file (using -E option)?
Thanks.

[Bug c++/96354] [10 regression] ICE in maybe_canonicalize_mem_ref_addr, at gimple-fold.c:4903

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Liška  ---
Can you please provide steps how to build the project? I can reproduce it
locally then.

[Bug c++/96354] New: [10 regression] ICE in maybe_canonicalize_mem_ref_addr, at gimple-fold.c:4903

[t...@dev-zero.ch]

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

Bug ID: 96354
   Summary: [10 regression] ICE in
maybe_canonicalize_mem_ref_addr, at gimple-fold.c:4903
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: t...@dev-zero.ch
  Target Milestone: ---

Unfortunately I wasn't able to isolate it (yet), but what I see with the
plumed-2.6.1 package from https://github.com/plumed/plumed2/releases with
gcc-10.2.0 (which should include the fix for issue #94216 already) is this:

during IPA pass: inline
RMSD.cpp: In member function ‘void
PLMD::RMSDCoreData::doCoreCalcWithCloseStructure(bool, bool, PLMD::Tensor&,
PLMD::Tensor&, std::array, 3>, 3>&)’:
RMSD.cpp:1134:6: internal compiler error: in maybe_canonicalize_mem_ref_addr,
at gimple-fold.c:4903
 1134 | void RMSDCoreData::doCoreCalcWithCloseStructure(bool safe,bool alEqDis,
Tensor & rotationPosClose, Tensor & rotationRefClose,
std::array,3> & drotationPosCloseDrr01) {
  |  ^~~~
0xa1bdac maybe_canonicalize_mem_ref_addr
/data/tiziano/cp2k/tools/toolchain/build/gcc-10.2.0/gcc/gimple-fold.c:4903
0xa20553 fold_stmt_1
/data/tiziano/cp2k/tools/toolchain/build/gcc-10.2.0/gcc/gimple-fold.c:5058
0xd26380 fold_marked_statements
/data/tiziano/cp2k/tools/toolchain/build/gcc-10.2.0/gcc/tree-inline.c:5342
0xd332b5 optimize_inline_calls(tree_node*)
/data/tiziano/cp2k/tools/toolchain/build/gcc-10.2.0/gcc/tree-inline.c:5448
0xac9f9e inline_transform(cgraph_node*)
   
/data/tiziano/cp2k/tools/toolchain/build/gcc-10.2.0/gcc/ipa-inline-transform.c:736
0xbf187e execute_one_ipa_transform_pass
/data/tiziano/cp2k/tools/toolchain/build/gcc-10.2.0/gcc/passes.c:2233
0xbf187e execute_all_ipa_transforms(bool)
/data/tiziano/cp2k/tools/toolchain/build/gcc-10.2.0/gcc/passes.c:2272
0x8dfdc4 cgraph_node::expand()
/data/tiziano/cp2k/tools/toolchain/build/gcc-10.2.0/gcc/cgraphunit.c:2293
0x8e117d expand_all_functions
/data/tiziano/cp2k/tools/toolchain/build/gcc-10.2.0/gcc/cgraphunit.c:2471
0x8e117d symbol_table::compile()
/data/tiziano/cp2k/tools/toolchain/build/gcc-10.2.0/gcc/cgraphunit.c:2822
0x8e325c symbol_table::finalize_compilation_unit()
/data/tiziano/cp2k/tools/toolchain/build/gcc-10.2.0/gcc/cgraphunit.c:3002
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.

The function would be this one here:
https://github.com/plumed/plumed2/blob/57fdb1ad1bcd4794190b97c22f86fec51d2a38be/src/tools/RMSD.cpp#L1133-L1203

[Bug c++/96353] New: GCC internal compiler error: in implicitly_declare_fn, at cp/method.c:2058 when using coverage

[wallguide-software at yahoo dot com]

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

Bug ID: 96353
   Summary: GCC internal compiler error: in implicitly_declare_fn,
at cp/method.c:2058 when using coverage
   Product: gcc
   Version: 9.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wallguide-software at yahoo dot com
  Target Milestone: ---

#gcc bug report (internal compiler error when using coverage)


# NB: Using this command line, the file compiles! ###
g++ -o test\TestAll_Of.o -c -Wall -Wextra -O0 -std=c++17 -Werror -Iapplib
-Izlib -Itest\testenv test\TestAll_Of.cpp


# This is the compiler failing: ###
g++ -v -save-temps -o test\TestAll_Of.o -c -Wall -Wextra -O0 -std=c++17 -Werror
--coverage -fno-elide-constructors -fno-default-inline -Iapplib -Izlib
-Itest\testenv test\TestAll_Of.cpp
Using built-in specs.
COLLECT_GCC=g++
Target: x86_64-w64-mingw32
Configured with: ../src/configure --enable-languages=c,c++
--build=x86_64-w64-mingw32 --host=x86_64-w64-mingw32
--target=x86_64-w64-mingw32 --disable-multilib --prefix=/c/temp/gcc/dest
--with-sysroot=/c/temp/gcc/dest --disable-libstdcxx-pch
--disable-libstdcxx-verbose --disable-nls --disable-shared
--disable-win32-registry --with-tune=haswell --enable-threads=posix
--enable-libgomp
Thread model: posix
gcc version 9.2.0 (GCC)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-o' 'test\TestAll_Of.o' '-c' '-Wall'
'-Wextra' '-O0' '-std=c++17' '-Werror' '-coverage' '-fno-elide-constructors'
'-I' 'applib' '-I' 'zlib' '-I' 'test\testenv' '-mtune=haswell' '-march=x86-64'
 d:/mingw17_1/bin/../libexec/gcc/x86_64-w64-mingw32/9.2.0/cc1plus.exe -E -quiet
-v -I applib -I zlib -I test\testenv -iprefix
d:\mingw17_1\bin\../lib/gcc/x86_64-w64-mingw32/9.2.0/ -D_REENTRANT
test\TestAll_Of.cpp -mtune=haswell -march=x86-64 -std=c++17 -Wall -Wextra
-Werror -fno-elide-constructors -O0 -fpch-preprocess -o TestAll_Of.ii
ignoring duplicate directory
"d:/mingw17_1/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../include/c++/9.2.0"
ignoring duplicate directory
"d:/mingw17_1/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../include/c++/9.2.0/x86_64-w64-mingw32"
ignoring duplicate directory
"d:/mingw17_1/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../include/c++/9.2.0/backward"
ignoring duplicate directory
"d:/mingw17_1/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/9.2.0/include"
ignoring nonexistent directory
"C:/temp/gcc/destC:/temp/gcc/dest/lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../include"
ignoring duplicate directory
"d:/mingw17_1/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/9.2.0/include-fixed"
ignoring duplicate directory
"d:/mingw17_1/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/include"
ignoring nonexistent directory "C:/temp/gcc/dest/mingw/include"
ignoring nonexistent directory "test\testenv"
#include "..." search starts here:
#include <...> search starts here:
 applib
 zlib
 D:\MinGW17_1\include
 D:\MinGW17_1\include\freetype2

d:\mingw17_1\bin\../lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../include/c++/9.2.0

d:\mingw17_1\bin\../lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../include/c++/9.2.0/x86_64-w64-mingw32

d:\mingw17_1\bin\../lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../include/c++/9.2.0/backward
 d:\mingw17_1\bin\../lib/gcc/x86_64-w64-mingw32/9.2.0/include
 d:\mingw17_1\bin\../lib/gcc/x86_64-w64-mingw32/9.2.0/include-fixed

d:\mingw17_1\bin\../lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-o' 'test\TestAll_Of.o' '-c' '-Wall'
'-Wextra' '-O0' '-std=c++17' '-Werror' '-coverage' '-fno-elide-constructors'
'-I' 'applib' '-I' 'zlib' '-I' 'test\testenv' '-mtune=haswell' '-march=x86-64'
 d:/mingw17_1/bin/../libexec/gcc/x86_64-w64-mingw32/9.2.0/cc1plus.exe
-fpreprocessed TestAll_Of.ii -quiet -dumpbase TestAll_Of.cpp -mtune=haswell
-march=x86-64 -auxbase-strip test\TestAll_Of.o -O0 -Wall -Wextra -Werror
-std=c++17 -version -fno-elide-constructors -fprofile-arcs -ftest-coverage -o
TestAll_Of.s
GNU C++17 (GCC) version 9.2.0 (x86_64-w64-mingw32)
compiled by GNU C version 9.2.0, GMP version 6.1.2, MPFR version
4.0.2-p1, MPC version 1.1.0, isl version isl-0.21-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++17 (GCC) version 9.2.0 (x86_64-w64-mingw32)
compiled by GNU C version 9.2.0, GMP version 6.1.2, MPFR version
4.0.2-p1, MPC version 1.1.0, isl version isl-0.21-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 59298311a00151dbb7f6557e142e1168
In file included from d:\mingw17_1\include\c++\9.2.0\bits\stl_algobase.h:71,
 from d:\mingw17_1\include\c++\9.2.0\vector:60,
 from test\TestAll_Of.cpp:2:

[Bug tree-optimization/96058] ICE in c_getstr at gcc/fold-const.c:15475

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

  Known to work||10.2.1
Summary|[11 Regression] ICE in  |ICE in c_getstr at
   |c_getstr at |gcc/fold-const.c:15475
   |gcc/fold-const.c:15475  |
  Known to fail|10.1.0  |

--- Comment #15 from Martin Liška  ---
Fixed on GCC 10 as well.

[Bug tree-optimization/96058] [11 Regression] ICE in c_getstr at gcc/fold-const.c:15475

[cvs-commit at gcc dot gnu.org]

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

--- Comment #14 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Martin Liska
:

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

commit r10-8542-gc0438ced53bcf57e4ebb1c38c226e41571aca892
Author: Martin Liska 
Date:   Mon Jul 27 12:30:24 2020 +0200

expr: build string_constant only for a char type

gcc/ChangeLog:

PR tree-optimization/96058
* expr.c (string_constant): Build string_constant only
for a type that has same precision as char_type_node
and is an integral type.

(cherry picked from commit 7355a9408b990cdd20db91e2e1ba0b03e801d6a6)

[Bug fortran/96320] gfortran 8-10 shape mismatch in assumed-length dummy argument character array

[dominiq at lps dot ens.fr]

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

--- Comment #16 from Dominique d'Humieres  ---
> Bother - I left the diagnostic line in the patch:
>
> +   gfc_warning_now (0, "s1 %i   s2 %i \n", s1->as->type, s2->as->type);
>
>Sorry about that

What I guessed, but I still see (not new)

/opt/gcc/work/gcc/testsuite/gfortran.dg/whole_file_23.f90:18:32:

   18 | pure integer function lensum (words, sep)
  |1
Warning: Interface mismatch in global procedure 'lensum' at (1): Shape mismatch
in argument 'words'

[Bug gcov-profile/96092] Should --coverage respect -ffile-prefix-map?

[marxin at gcc dot gnu.org]

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

--- Comment #4 from Martin Liška  ---
(In reply to Martin Liška from comment #2)
> Apparently we've got a patch in queue that does something similar:
> 
> +fprofile-prefix-path=
> +Common·Joined·RejectNegative·Var(profile_prefix_path) 
> +remove·prefix·from·absolute·path·before·manging·name·for·-fprofile-
> generate=·and·-fprofile-use=.

All right, we can definitely not come up with the suggested option.
We can adapt the Clang's approach of -fcoverage-prefix-map.
Please ping me once it lands to LLVM master and I'll implement it as well.

[Bug sanitizer/94307] Provide a way to declare the *SAN exception handler -fsanitize-undefined-trap-on-error

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #10 from Martin Liška  ---
Apparently there's not much interest. Leaving as unassigned.

[Bug fortran/96320] gfortran 8-10 shape mismatch in assumed-length dummy argument character array

[paul.richard.thomas at gmail dot com]

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

--- Comment #15 from paul.richard.thomas at gmail dot com  ---
Bother - I left the diagnostic line in the patch:

+ gfc_warning_now (0, "s1 %i   s2 %i \n", s1->as->type, s2->as->type);

Sorry about that


Paul



On Tue, 28 Jul 2020 at 10:24, dominiq at lps dot ens.fr <
gcc-bugzi...@gcc.gnu.org> wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96320
>
> --- Comment #14 from Dominique d'Humieres  ---
> After fixing the ICEs by replacing
> 's1->ns->proc_name->attr.module_procedure'
> with 's1->ns->proc_name && s1->ns->proc_name->attr.module_procedure' I am
> left
> with two regressions:
>
> FAIL: gfortran.dg/proc_decl_26.f90   -O   2 blank line(s) in output
> FAIL: gfortran.dg/proc_decl_26.f90   -O  (test for excess errors)
> FAIL: gfortran.dg/whole_file_23.f90   -O   1 blank line(s) in output
> FAIL: gfortran.dg/whole_file_23.f90   -O  (test for excess errors)
>
> % gfc /opt/gcc/work/gcc/testsuite/gfortran.dg/proc_decl_26.f90
> f951: Warning: s1 2   s2 1
>
> /opt/gcc/work/gcc/testsuite/gfortran.dg/proc_decl_26.f90:20:11:
>
>20 |   call foo(two)  ! { dg-error "Shape mismatch in argument" }
>   |   1
> Error: Interface mismatch in dummy procedure 'f1' at (1): Shape mismatch in
> argument 'a'
> f951: Warning: s1 2   s2 1
>
> /opt/gcc/work/gcc/testsuite/gfortran.dg/proc_decl_26.f90:21:11:
>
>21 |   call bar(two)  ! { dg-error "Shape mismatch in argument" }
>   |   1
> Error: Interface mismatch in dummy procedure 'f2' at (1): Shape mismatch in
> argument 'a'
> % gfc /opt/gcc/work/gcc/testsuite/gfortran.dg/whole_file_23.f90
> f951: Warning: s1 3   s2 2
>
> /opt/gcc/work/gcc/testsuite/gfortran.dg/whole_file_23.f90:18:32:
>
>18 | pure integer function lensum (words, sep)
>   |1
> Warning: Interface mismatch in global procedure 'lensum' at (1): Shape
> mismatch
> in argument 'words'
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
> You are the assignee for the bug.

[Bug ipa/96337] [10/11 Regression] GCC 10.2: twice as slow for -O2 -march=x86-64 vs. GCC 9.3/8.4

[hubicka at ucw dot cz]

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

--- Comment #11 from Jan Hubicka  ---
> 
> Maybe you want to use same GCC version as phoronix used (GCC 10.2)?
OK, I will give it a try, but there are no inliner changes in gcc 10.2
compared to 10.1.

Honza

Re: [Bug ipa/96337] [10/11 Regression] GCC 10.2: twice as slow for -O2 -march=x86-64 vs. GCC 9.3/8.4

[Jan Hubicka]

> 
> Maybe you want to use same GCC version as phoronix used (GCC 10.2)?
OK, I will give it a try, but there are no inliner changes in gcc 10.2
compared to 10.1.

Honza

[Bug fortran/96320] gfortran 8-10 shape mismatch in assumed-length dummy argument character array

[dominiq at lps dot ens.fr]

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

--- Comment #14 from Dominique d'Humieres  ---
After fixing the ICEs by replacing 's1->ns->proc_name->attr.module_procedure'
with 's1->ns->proc_name && s1->ns->proc_name->attr.module_procedure' I am left
with two regressions:

FAIL: gfortran.dg/proc_decl_26.f90   -O   2 blank line(s) in output
FAIL: gfortran.dg/proc_decl_26.f90   -O  (test for excess errors)
FAIL: gfortran.dg/whole_file_23.f90   -O   1 blank line(s) in output
FAIL: gfortran.dg/whole_file_23.f90   -O  (test for excess errors)

% gfc /opt/gcc/work/gcc/testsuite/gfortran.dg/proc_decl_26.f90
f951: Warning: s1 2   s2 1 

/opt/gcc/work/gcc/testsuite/gfortran.dg/proc_decl_26.f90:20:11:

   20 |   call foo(two)  ! { dg-error "Shape mismatch in argument" }
  |   1
Error: Interface mismatch in dummy procedure 'f1' at (1): Shape mismatch in
argument 'a'
f951: Warning: s1 2   s2 1 

/opt/gcc/work/gcc/testsuite/gfortran.dg/proc_decl_26.f90:21:11:

   21 |   call bar(two)  ! { dg-error "Shape mismatch in argument" }
  |   1
Error: Interface mismatch in dummy procedure 'f2' at (1): Shape mismatch in
argument 'a'
% gfc /opt/gcc/work/gcc/testsuite/gfortran.dg/whole_file_23.f90 
f951: Warning: s1 3   s2 2 

/opt/gcc/work/gcc/testsuite/gfortran.dg/whole_file_23.f90:18:32:

   18 | pure integer function lensum (words, sep)
  |1
Warning: Interface mismatch in global procedure 'lensum' at (1): Shape mismatch
in argument 'words'

[Bug c++/96137] [11 Regression] GCC hang on in invalid function definition

[haoxintu at gmail dot com]

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

--- Comment #4 from Haoxin Tu  ---
Add two cases. I guess the reason is the same.

//case1
static_assert (->operator a, "")

//case2
alignas (->operator a)

[Bug middle-end/96335] [10/11 Regression] ICE in maybe_warn_rdwr_sizes since r10-4929

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r10-8541-g7d88f924ad8d773cceb08e123cb2831f20d40cb4
Author: Jakub Jelinek 
Date:   Tue Jul 28 11:08:29 2020 +0200

expander: Fix ICE in maybe_warn_rdwr_sizes [PR96335]

The following testcase ICEs in maybe_warn_rdwr_sizes.  The problem is that
the caller uses its fndecl and fntype variables to fill up rdwr_map, and
the fntype in that case is a prototype with the access attribute and all
the checks needed for that performed.  But the maybe_warn_rdwr_sizes
function tries to rediscover fndecl/fntype itself and does it differently
from how the caller did (for fndecl get_callee_fndecl and fntype from that
FUNCTION_DECL, otherwise sets fntype to CALL_EXPR_FN's type).

On the testcase, get_callee_fndecl does find a FUNCTION_DECL because
it does STRIP_NOPS in between.

Instead of trying to rediscover those, this patch just passes them down,
like is done in several other functions.

2020-07-28  Jakub Jelinek  

PR middle-end/96335
* calls.c (maybe_warn_rdwr_sizes): Add FNDECL and FNTYPE arguments,
instead of trying to rediscover them in the body.
(initialize_argument_information): Adjust caller.

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

(cherry picked from commit f9264b9008386ac3b5c795472c222fa524b127b0)

[Bug middle-end/96335] [10/11 Regression] ICE in maybe_warn_rdwr_sizes since r10-4929

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r11-2379-gf9264b9008386ac3b5c795472c222fa524b127b0
Author: Jakub Jelinek 
Date:   Tue Jul 28 11:08:29 2020 +0200

expander: Fix ICE in maybe_warn_rdwr_sizes [PR96335]

The following testcase ICEs in maybe_warn_rdwr_sizes.  The problem is that
the caller uses its fndecl and fntype variables to fill up rdwr_map, and
the fntype in that case is a prototype with the access attribute and all
the checks needed for that performed.  But the maybe_warn_rdwr_sizes
function tries to rediscover fndecl/fntype itself and does it differently
from how the caller did (for fndecl get_callee_fndecl and fntype from that
FUNCTION_DECL, otherwise sets fntype to CALL_EXPR_FN's type).

On the testcase, get_callee_fndecl does find a FUNCTION_DECL because
it does STRIP_NOPS in between.

Instead of trying to rediscover those, this patch just passes them down,
like is done in several other functions.

2020-07-28  Jakub Jelinek  

PR middle-end/96335
* calls.c (maybe_warn_rdwr_sizes): Add FNDECL and FNTYPE arguments,
instead of trying to rediscover them in the body.
(initialize_argument_information): Adjust caller.

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

[Bug libstdc++/96345] __cxa demangle fails to demangle a very long string

[hededrk at gmail dot com]

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

--- Comment #5 from V  ---
(In reply to Andrew Pinski from comment #3)
> Does c++filt demangle it?

I've fed output of nm into c++filt and this function came out mangled, while
others were demangled.

[Bug tree-optimization/96351] missed opportunity to optimize out redundant loop

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-07-28

--- Comment #1 from Richard Biener  ---
VRP doesn't work "backwards", it also does an incredibly bad job at
tracking pointer ranges where it simply prefers to track non-NULL.
Here we'd need to track symbolic [str_7 + [2, +INF] ] or so which
it cannot do either.

Eventually other analyses (SCEV?) could derive sth for

  # pszTmp_8 = PHI 
  _14 = pszTmp_8 - str_7;
  _15 = _14 /[ex] 2;

but even there, since we do not know the number of iterations, the
representation will have its limits.

[Bug ipa/96337] [10/11 Regression] GCC 10.2: twice as slow for -O2 -march=x86-64 vs. GCC 9.3/8.4

[david.bolvansky at gmail dot com]

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

--- Comment #10 from Dávid Bolvanský  ---
>> Compiler version : GCC10.1.1

Maybe you want to use same GCC version as phoronix used (GCC 10.2)?

[Bug ipa/96337] [10/11 Regression] GCC 10.2: twice as slow for -O2 -march=x86-64 vs. GCC 9.3/8.4

[hubicka at gcc dot gnu.org]

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

--- Comment #9 from Jan Hubicka  ---
scimark
GCC 9:
**  **
** SciMark2 Numeric Benchmark, see http://math.nist.gov/scimark **
** for details. (Results can be submitted to p...@nist.gov) **
**  **
Using   2.00 seconds min time per kenel.
Composite Score: 1062.28
FFT Mflops:   189.17(N=1048576)
SOR Mflops:   947.53(1000 x 1000)
MonteCarlo: Mflops:   710.10
Sparse matmult  Mflops:  1402.08(N=10, nz=100)
LU  Mflops:  2062.49(M=1000, N=1000)

GCC 10:
**  **
** SciMark2 Numeric Benchmark, see http://math.nist.gov/scimark **
** for details. (Results can be submitted to p...@nist.gov) **
**  **
Using   2.00 seconds min time per kenel.
Composite Score: 1176.22
FFT Mflops:   201.17(N=1048576)
SOR Mflops:   961.33(1000 x 1000)
MonteCarlo: Mflops:   708.62
Sparse matmult  Mflops:  1639.66(N=10, nz=100)
LU  Mflops:  2370.30(M=1000, N=1000)

So again around 10% improvement for gcc10

[Bug ipa/96352] inflated text section with ipa inline

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Biener  ---
It was a bugfix.  If you want to have small binaries use -Os.  You can also
tune the inliner with various knobs, the most important maybe
--param inline-unit-growth which defaults to 40 (40% growth).

[Bug ipa/96337] [10/11 Regression] GCC 10.2: twice as slow for -O2 -march=x86-64 vs. GCC 9.3/8.4

[hubicka at gcc dot gnu.org]

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

--- Comment #8 from Jan Hubicka  ---
This is the built withour release flags override as seems to be done by
phoronix:

GCC 9:
y4m  [info]: 1920x1080 fps 30/1 i420p8 frames 0 - 599 of 600
raw  [info]: output file: /dev/null
x265 [info]: HEVC encoder version 3.1.2+1-76650bab70f9
x265 [info]: build info [Linux][GCC 9.3.1][64 bit][noasm] 8bit
x265 [info]: using cpu capabilities: none!
x265 [info]: Main profile, Level-4 (Main tier)
x265 [info]: Thread pool created using 4 threads
x265 [info]: Slices  : 1
x265 [info]: frame threads / pool features   : 2 / wpp(17 rows)
x265 [info]: Coding QT: max CU size, min CU size : 64 / 8
x265 [info]: Residual QT: max TU size, max depth : 32 / 1 inter / 1 intra
x265 [info]: ME / range / subpel / merge : hex / 57 / 2 / 3
x265 [info]: Keyframe min / max / scenecut / bias: 25 / 250 / 40 / 5.00
x265 [info]: Lookahead / bframes / badapt: 20 / 4 / 2
x265 [info]: b-pyramid / weightp / weightb   : 1 / 1 / 0
x265 [info]: References / ref-limit  cu / depth  : 3 / off / on
x265 [info]: AQ: mode / str / qg-size / cu-tree  : 2 / 1.0 / 32 / 1
x265 [info]: Rate Control / qCompress: CRF-28.0 / 0.60
x265 [info]: tools: rd=3 psy-rd=2.00 early-skip rskip signhide tmvp b-intra
x265 [info]: tools: strong-intra-smoothing lslices=6 deblock sao
x265 [info]: frame I:  3, Avg QP:27.57  kb/s: 14018.64  
x265 [info]: frame P:146, Avg QP:28.84  kb/s: 4313.98 
x265 [info]: frame B:451, Avg QP:35.29  kb/s: 204.06  
x265 [info]: Weighted P-Frames: Y:0.0% UV:0.0%
x265 [info]: consecutive B-frames: 0.7% 0.0% 0.0% 94.6% 4.7% 

encoded 600 frames in 171.30s (3.50 fps), 1273.22 kb/s, Avg QP:33.68
599.58user 1.62system 2:51.33elapsed 350%CPU (0avgtext+0avgdata
416976maxresident)k
225384inputs+0outputs (0major+95380minor)pagefaults 0swaps

GCC 10:
y4m  [info]: 1920x1080 fps 30/1 i420p8 frames 0 - 599 of 600
raw  [info]: output file: /dev/null
x265 [info]: HEVC encoder version 3.1.2+1-76650bab70f9
x265 [info]: build info [Linux][GCC 10.1.1][64 bit][noasm] 8bit
x265 [info]: using cpu capabilities: none!
x265 [info]: Main profile, Level-4 (Main tier)
x265 [info]: Thread pool created using 4 threads
x265 [info]: Slices  : 1
x265 [info]: frame threads / pool features   : 2 / wpp(17 rows)
x265 [info]: Coding QT: max CU size, min CU size : 64 / 8
x265 [info]: Residual QT: max TU size, max depth : 32 / 1 inter / 1 intra
x265 [info]: ME / range / subpel / merge : hex / 57 / 2 / 3
x265 [info]: Keyframe min / max / scenecut / bias: 25 / 250 / 40 / 5.00
x265 [info]: Lookahead / bframes / badapt: 20 / 4 / 2
x265 [info]: b-pyramid / weightp / weightb   : 1 / 1 / 0
x265 [info]: References / ref-limit  cu / depth  : 3 / off / on
x265 [info]: AQ: mode / str / qg-size / cu-tree  : 2 / 1.0 / 32 / 1
x265 [info]: Rate Control / qCompress: CRF-28.0 / 0.60
x265 [info]: tools: rd=3 psy-rd=2.00 early-skip rskip signhide tmvp b-intra
x265 [info]: tools: strong-intra-smoothing lslices=6 deblock sao
x265 [info]: frame I:  3, Avg QP:27.57  kb/s: 14018.64  
x265 [info]: frame P:146, Avg QP:28.84  kb/s: 4313.98 
x265 [info]: frame B:451, Avg QP:35.29  kb/s: 204.06  
x265 [info]: Weighted P-Frames: Y:0.0% UV:0.0%
x265 [info]: consecutive B-frames: 0.7% 0.0% 0.0% 94.6% 4.7% 

encoded 600 frames in 168.97s (3.55 fps), 1273.22 kb/s, Avg QP:33.68
592.69user 1.89system 2:49.00elapsed 351%CPU (0avgtext+0avgdata
416184maxresident)k
476408inputs+0outputs (1major+95191minor)pagefaults 0swaps

So a small improvement.

[Bug ipa/96352] New: inflated text section with ipa inline

[rjiejie at me dot com]

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

Bug ID: 96352
   Summary: inflated text section with ipa inline
   Product: gcc
   Version: 10.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rjiejie at me dot com
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

Created attachment 48942
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48942=edit
inflated text section with ipa inline

My case is compare size of object between two versions.

>From v8.3, the text section size is 3232,
but from v8.4, the text section size is 5692.

My test command line: 

cc1 bitstream.i  -march=rv64gc -mabi=lp64  -O3 -o a.s
as --traditional-format -march=rv64gc -mabi=lp64 -o a.o a.s
size a.o

I found this issue from gcc version v8.4 and
it is present at gcc version 10.2.1 also :(

I have researched gcc sources and found the issue comes from
edge_badness@ipa-inline.c at commit be917808aa3310d46f586e6586ef08d302837f1e :

diff --git a/gcc/ipa-inline.c b/gcc/ipa-inline.c
index 73da38c..8e34400 100644
--- a/gcc/ipa-inline.c
+++ b/gcc/ipa-inline.c
@@ -1173,7 +1173,7 @@ edge_badness (struct cgraph_edge *edge, bool dump)
overall_growth += 256 * 256 - 256;
  denominator *= overall_growth;
 }
-  denominator *= inlined_time;
+  denominator *= ipa_fn_summaries->get (caller)->self_size + growth;

   badness = - numerator / denominator;

[Bug ipa/96337] [10/11 Regression] GCC 10.2: twice as slow for -O2 -march=x86-64 vs. GCC 9.3/8.4

[hubicka at gcc dot gnu.org]

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

--- Comment #7 from Jan Hubicka  ---
X265
GCC 9:
y4m  [info]: 1920x1080 fps 30/1 i420p8 frames 0 - 599 of 600
raw  [info]: output file: /dev/null
x265 [info]: HEVC encoder version 3.1.2+1-76650bab70f9
x265 [info]: build info [Linux][GCC 9.3.1][64 bit][noasm] 8bit
x265 [info]: using cpu capabilities: none!
x265 [info]: Main profile, Level-4 (Main tier)
x265 [info]: Thread pool created using 4 threads
x265 [info]: Slices  : 1
x265 [info]: frame threads / pool features   : 2 / wpp(17 rows)
x265 [info]: Coding QT: max CU size, min CU size : 64 / 8
x265 [info]: Residual QT: max TU size, max depth : 32 / 1 inter / 1 intra
x265 [info]: ME / range / subpel / merge : hex / 57 / 2 / 3
x265 [info]: Keyframe min / max / scenecut / bias: 25 / 250 / 40 / 5.00
x265 [info]: Lookahead / bframes / badapt: 20 / 4 / 2
x265 [info]: b-pyramid / weightp / weightb   : 1 / 1 / 0
x265 [info]: References / ref-limit  cu / depth  : 3 / off / on
x265 [info]: AQ: mode / str / qg-size / cu-tree  : 2 / 1.0 / 32 / 1
x265 [info]: Rate Control / qCompress: CRF-28.0 / 0.60
x265 [info]: tools: rd=3 psy-rd=2.00 early-skip rskip signhide tmvp b-intra
x265 [info]: tools: strong-intra-smoothing lslices=6 deblock sao
x265 [info]: frame I:  3, Avg QP:27.57  kb/s: 14018.64  
x265 [info]: frame P:146, Avg QP:28.84  kb/s: 4313.98 
x265 [info]: frame B:451, Avg QP:35.29  kb/s: 204.06  
x265 [info]: Weighted P-Frames: Y:0.0% UV:0.0%
x265 [info]: consecutive B-frames: 0.7% 0.0% 0.0% 94.6% 4.7% 

encoded 600 frames in 279.98s (2.14 fps), 1273.22 kb/s, Avg QP:33.68
1056.04user 1.31system 4:40.01elapsed 377%CPU (0avgtext+0avgdata
432688maxresident)k
0inputs+0outputs (0major+102385minor)pagefaults 0swaps


GCC 10:
y4m  [info]: 1920x1080 fps 30/1 i420p8 frames 0 - 599 of 600
raw  [info]: output file: /dev/null
x265 [info]: HEVC encoder version 3.1.2+1-76650bab70f9
x265 [info]: build info [Linux][GCC 10.1.1][64 bit][noasm] 8bit
x265 [info]: using cpu capabilities: none!
x265 [info]: Main profile, Level-4 (Main tier)
x265 [info]: Thread pool created using 4 threads
x265 [info]: Slices  : 1
x265 [info]: frame threads / pool features   : 2 / wpp(17 rows)
x265 [info]: Coding QT: max CU size, min CU size : 64 / 8
x265 [info]: Residual QT: max TU size, max depth : 32 / 1 inter / 1 intra
x265 [info]: ME / range / subpel / merge : hex / 57 / 2 / 3
x265 [info]: Keyframe min / max / scenecut / bias: 25 / 250 / 40 / 5.00
x265 [info]: Lookahead / bframes / badapt: 20 / 4 / 2
x265 [info]: b-pyramid / weightp / weightb   : 1 / 1 / 0
x265 [info]: References / ref-limit  cu / depth  : 3 / off / on
x265 [info]: AQ: mode / str / qg-size / cu-tree  : 2 / 1.0 / 32 / 1
x265 [info]: Rate Control / qCompress: CRF-28.0 / 0.60
x265 [info]: tools: rd=3 psy-rd=2.00 early-skip rskip signhide tmvp b-intra
x265 [info]: tools: strong-intra-smoothing lslices=6 deblock sao
x265 [info]: frame I:  3, Avg QP:27.57  kb/s: 14018.64  
x265 [info]: frame P:146, Avg QP:28.84  kb/s: 4313.98 
x265 [info]: frame B:451, Avg QP:35.29  kb/s: 204.06  
x265 [info]: Weighted P-Frames: Y:0.0% UV:0.0%
x265 [info]: consecutive B-frames: 0.7% 0.0% 0.0% 94.6% 4.7% 

encoded 600 frames in 292.63s (2.05 fps), 1273.22 kb/s, Avg QP:33.68
1079.80user 1.76system 4:52.65elapsed 369%CPU (0avgtext+0avgdata
427464maxresident)k
0inputs+0outputs (0major+73644minor)pagefaults 0swaps

So 5% difference instead of 50%. This is a codebase that I would build with
-O3.  Looking at perf reports there is a difference in inlining.

GCC 9:
   8.74%  x265 libx265.so.176   [.] (anonymous namespace)::satd_8x4
   5.67%  x265 libx265.so.176   [.] (anonymous
namespace)::filterVertical_sp_c<8>
   4.44%  x265 libx265.so.176   [.] (anonymous
namespace)::pixelavg_pp<8, 8>
   4.11%  x265 libx265.so.176   [.] (anonymous
namespace)::psyCost_pp<3>   
   3.81%  x265 libx265.so.176   [.] (anonymous
namespace)::interp_horiz_ps_c<8, 64, 64>
   3.33%  x265 libx265.so.176   [.] (anonymous namespace)::sad<8, 8>
   3.29%  x265 libx265.so.176   [.] partialButterfly32

GCC 10:
   9.17%  x265 libx265.so.176   [.] (anonymous namespace)::_sa8d_8x8
   8.70%  x265 libx265.so.176   [.] (anonymous namespace)::satd_8x4 
   5.80%  x265 libx265.so.176   [.] (anonymous
namespace)::pixelavg_pp<8, 8>
   5.55%  x265 libx265.so.176   [.] (anonymous
namespace)::filterVertical_sp_c<8> 
   3.90%  x265 libx265.so.176   [.] (anonymous namespace)::sad<8, 8>
   3.71%  x265 libx265.so.176   [.] (anonymous
namespace)::interp_horiz_ps_c<8, 64, 64> 
   3.48%  x265 libx265.so.176   [.] (anonymous namespace)::sad_x4<8, 8>

I build with 
cmake ../source/ -DCMAKE_CXX_FLAGS=-O2 

[Bug preprocessor/95889] __has_include evaluated even if disabled (with cpp in traditional-mode)

[t...@dev-zero.ch]

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

--- Comment #3 from Tiziano Müller  ---
Created attachment 48941
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48941=edit
fix __has_include with traditional-cpp

as posted on the gcc-patches ml

[Bug c/96284] Outdated C features should be made errors with newer standards

[fw at gcc dot gnu.org]

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

--- Comment #7 from Florian Weimer  ---
(In reply to David Brown from comment #6)
> I'm not bothered about my own code - I have makefiles with the relevant
> options set in case I make mistakes.  My hope is for gcc to be able to have
> stricter warnings to reduce bugs in code written now and in the future.  But
> I understand that it's also important not to cause trouble for existing code
> and build systems.

The implicit function declaration warning does not seem to be quite enough, it
would help programmers to turn it into an error. But that's what also impacts
configure scripts.

[Bug tree-optimization/96351] New: missed opportunity to optimize out redundant loop

[felix.yang at huawei dot com]

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

Bug ID: 96351
   Summary: missed opportunity to optimize out redundant loop
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: felix.yang at huawei dot com
  Target Milestone: ---

inline unsigned int
stringLen(const short* const src)
{
if (src == 0 || *src == 0) {
return 0;
} else {
const short* pszTmp = src + 1;

while (*pszTmp)
++pszTmp;

return (unsigned int)(pszTmp - src);
}
}

extern void bar();

void foo(const short* const str) {
unsigned int len = stringLen(str);
if (!len) {
bar();
}
}

When stringLen is inlined into foo, the else block in stringLen can be
simplified into non-zero, thus eliminating the while loop. This looks like a
tree VRP issue, but this pass does not work as expected for this test case.

$ g++ -S -O2 foo.cpp -fdump-tree-vrp

Consider function foo, value ranges after VRP does not help here:
 48
 49 .MEM_1: <<< error >>> VARYING
 50 str_3(D): const short int * const VARYING
 51 _6: short int VARYING
 52 str_7: const short int * const [1B, +INF]  EQUIVALENCES: { str_3(D) } (1
elements)
 53 pszTmp_8: const short int * [1B, +INF]  EQUIVALENCES: { pszTmp_10 } (1
elements)
 54 pszTmp_9: const short int * const [1B, +INF]
 55 pszTmp_10: const short int * const [1B, +INF]
 56 _11: short int VARYING
 57 pszTmp_12: const short int * [1B, +INF]
 58 _13: unsigned int [0, 0]
 59 _14: long int VARYING
 60 _15: long int [-4611686018427387904, 4611686018427387903]
 61 _16: unsigned int VARYING
 62 _18: unsigned int [0, 0]
 63 pszTmp_19: const short int * [1B, +INF]  EQUIVALENCES: { pszTmp_10 } (1
elements)

 ..

 93[local count: 439750964]:
 94   pszTmp_9 = str_3(D) + 2;
 95
 96[local count: 3997736055]:
 97   # pszTmp_10 = PHI 
 98   _11 = *pszTmp_10;
 99   if (_11 == 0)
100 goto ; [11.00%]
101   else
102 goto ; [89.00%]
103
104[local count: 3557985095]:
105   pszTmp_12 = pszTmp_10 + 2;
106   goto ; [100.00%]
107
108[local count: 439750964]:
109   # pszTmp_8 = PHI 
110   _14 = pszTmp_8 - str_3(D);
111   _15 = _14 /[ex] 2;
112   _16 = (unsigned int) _15;
113   if (_16 == 0)
114 goto ; [3.91%]
115   else
116 goto ; [96.09%]
117
118[local count: 354334798]:
119   bar ();
120
121[local count: 1073741824]:
122   return;

Any suggestions to proceed?

[Bug tree-optimization/96349] [10/11 Regression] ICE: SSA corruption (Unable to coalesce ssa_names 2 and 3 which are marked as MUST COALESCE.) [in fail_abnormal_edge_coalesce]

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #3 from Martin Liška  ---
Started with r10-4447-g095f78c62157124a, but it's just an inroduction of a
param that exposed it.

[Bug c/96284] Outdated C features should be made errors with newer standards

[david at westcontrol dot com]

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

--- Comment #6 from David Brown  ---
(In reply to Eric Gallager from comment #5)
> (In reply to David Brown from comment #0)

> > Could this be made an error by default
> > (-Werror=implicit-function-declarations) ?  Let those who want to compile
> > old code with implicit function declarations, do so with an explicit flag.
> 
> I think Florian Weimer tried this and it broke the majority of configure
> scripts in existence...

Fixing existing code and build systems is always hard - backwards compatibility
is C's biggest strength and its biggest weakness.

I'm not bothered about my own code - I have makefiles with the relevant options
set in case I make mistakes.  My hope is for gcc to be able to have stricter
warnings to reduce bugs in code written now and in the future.  But I
understand that it's also important not to cause trouble for existing code and
build systems.

[Bug ipa/96337] [10/11 Regression] GCC 10.2: twice as slow for -O2 -march=x86-64 vs. GCC 9.3/8.4

[hubicka at gcc dot gnu.org]

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

--- Comment #6 from Jan Hubicka  ---
Coremark.

GCC 9 run1:
CoreMark Size: 666
Total ticks  : 12310
Total time (secs): 12.31
Iterations/Sec   : 24370.430544
Iterations   : 30
Compiler version : GCC9.3.1 20200406 [revision
6db837a5288ee3ca5ec504fbd5a765817e556ac2]
Compiler flags   : -O2 -DPERFORMANCE_RUN=1  -lrt

GCC 9 run2:
CoreMark Size: 666
Total ticks  : 12471
Total time (secs): 12.471000
Iterations/Sec   : 24055.809478
Iterations   : 30
Compiler version : GCC9.3.1 20200406 [revision
6db837a5288ee3ca5ec504fbd5a765817e556ac2]
Compiler flags   : -O2 -DPERFORMANCE_RUN=1  -lrt


GCC 10 run1:
CoreMark Size: 666
Total ticks  : 15269
Total time (secs): 15.269000
Iterations/Sec   : 26196.869474
Iterations   : 40
Compiler version : GCC10.1.1 20200507 [revision
dd38686d9c810cecbaa80bb82ed91caaa58ad635]
Compiler flags   : -O2 -DPERFORMANCE_RUN=1  -lrt

GCC 10 run2:
CoreMark Size: 666
Total ticks  : 11770
Total time (secs): 11.77
Iterations/Sec   : 25488.530161
Iterations   : 30
Compiler version : GCC10.1.1 20200507 [revision
dd38686d9c810cecbaa80bb82ed91caaa58ad635]
Compiler flags   : -O2 -DPERFORMANCE_RUN=1  -lrt

[Bug ipa/96337] [10/11 Regression] GCC 10.2: twice as slow for -O2 -march=x86-64 vs. GCC 9.3/8.4

[hubicka at gcc dot gnu.org]

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

--- Comment #5 from Jan Hubicka  ---
OK, I started with checking Himeno where phoronix reports 4377->2681
on my notebook (Intel(R) Core(TM) i7-6600U CPU) there may be around 1-5%
regression that is not inliner related

GCC 10
 Loop executed for 7445 times
 Gosa : 2.924613e-08 
 MFLOPS measured : 2346.645663  cpu : 50.172505
 Score based on Pentium III 600MHz using Fortran 77: 28.617630

GCC 9
 Loop executed for 8253 times
 Gosa : 9.062229e-09 
 MFLOPS measured : 2454.019320  cpu : 53.184180
 Score based on Pentium III 600MHz using Fortran 77: 29.927065

The internal loops and inlining looks almost identical.

[Bug ipa/96337] [10/11 Regression] GCC 10.2: twice as slow for -O2 -march=x86-64 vs. GCC 9.3/8.4

[hubicka at gcc dot gnu.org]

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

--- Comment #4 from Jan Hubicka  ---
There was changes to -O2 inliner.  I have
 - enabled auto-inlininig
 - reduced early inlining a bit
 - reduced limits for inlining functions declared inline
The second two was needed to keep code size under control and did well on
overall -O2 spec and Firefox performance (without FDO, with FDO we indeed had
some performance loss and code size gains, which I plan to revisit).

This should not be visible on linux kernel though since it does always inline.
The linked patch to enable -O3 by default does not make too much sense to me. 

I will see if I can reproduce phoronix benchmarks - indeed those workloads are
not typical -O2 workloads and may be affected by the inline limits.

Honza

[Bug target/96350] [cet] For ENDBR immediate, the binary would include a gadget that starts with a fake ENDBR64 opcode.

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
The endbr are way too short to make this practical - ISTR I raised this exact
issue at a presentation about CET ... CET simply makes the gadget finding less
likely to succeed.

There's always the possibility that text relocations end up making ENDBR{32,64}
appear.

Eventually the assembler (and ld.so?) can receive a hardening flag to scan for
those byte sequences.

[Bug ada/96344] [11 regerssion] gnat.dg/opt86a.adb fails starting with r11-

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |11.0

[Bug tree-optimization/96349] [10/11 Regression] ICE: SSA corruption (Unable to coalesce ssa_names 2 and 3 which are marked as MUST COALESCE.) [in fail_abnormal_edge_coalesce]

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||fxue at os dot 
amperecomputing.com
   ||, matz at gcc dot gnu.org

--- Comment #2 from Richard Biener  ---
-fno-split-loops fixes it.

t.c:16:8: optimized: loop split on semi-invariant condition at false branch

so it's the new splitting code, still going to give it a quick shot at a fix.

[Bug lto/96343] LTO ICE on PPC64le

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2020-07-28
 Ever confirmed|0   |1

--- Comment #5 from Richard Biener  ---
lto1: internal compiler error: invalid resolution in the resolution file

it would be interesting to see the actual resolution file.  When you
lto-link with -v -save-temps added you'll see a lto1 -fwpa invocation
with a -fresolution=FILENAME argument, attach FILENAME here.

[Bug ipa/96337] [10/11 Regression] GCC 10.2: twice as slow for -O2 -march=x86-64 vs. GCC 9.3/8.4

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Component|rtl-optimization|ipa
Summary|GCC 10.2: twice as slow for |[10/11 Regression] GCC
   |-O2 -march=x86-64 vs. GCC   |10.2: twice as slow for -O2
   |9.3/8.4 |-march=x86-64 vs. GCC
   ||9.3/8.4
   Keywords||missed-optimization
 CC||hubicka at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org

--- Comment #3 from Richard Biener  ---
Well, the workloads tested are not -O2 workloads but yes, distros likely still
will use -O2 for them unless the package itself overrides.

But IIRC the main change was that -O2 -fprofile-use no longer uses -O3
inliner settings, the settings for -O2 itself were not changed much?  Honza?

[Bug tree-optimization/96349] [10/11 Regression] ICE: SSA corruption (Unable to coalesce ssa_names 2 and 3 which are marked as MUST COALESCE.) [in fail_abnormal_edge_coalesce]

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
   Target Milestone|--- |10.3
   Last reconfirmed||2020-07-28
 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed, I'll take a look.

[Bug ipa/96337] [10/11 Regression] GCC 10.2: twice as slow for -O2 -march=x86-64 vs. GCC 9.3/8.4

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |10.3