[Bug c++/92136] cc1plus segv with CTAD and -fchecking

[pilarlatiesa at gmail dot com]

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

Pilar Latiesa  changed:

   What|Removed |Added

 CC||pilarlatiesa at gmail dot com

--- Comment #4 from Pilar Latiesa  ---
The issue vanished for 10.0.0 20191126 (x86_64-pc-linux-gnu). Maybe Jason fixed
it while implementing CTAD for alias templates.

The testcases, however, produce an ICE in 9.2, 8.3, and 7.5, when compiled with
-std=c++17 -fchecking.

[Bug c++/92695] P1064R0 - virtual constexpr fails if object taken from array

[jakub at gcc dot gnu.org]

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

--- Comment #10 from Jakub Jelinek  ---
Author: jakub
Date: Thu Nov 28 08:06:09 2019
New Revision: 278802

URL: https://gcc.gnu.org/viewcvs?rev=278802&root=gcc&view=rev
Log:
PR c++/92695
* decl2.c (mark_used): Don't call note_vague_linkage_fn for pure
virtual functions, even if they are declared inline.

* g++.dg/warn/inline3.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/warn/inline3.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl2.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/92123] [F2018/array-descriptor] Scalar allocatable/pointer with array descriptor (via bind(C)): ICE with select rank or error scalar variable with POINTER or ALLOCATABLE in procedure wit

[rguenther at suse dot de]

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

--- Comment #22 from rguenther at suse dot de  ---
On Wed, 27 Nov 2019, jakub at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92123
> 
> --- Comment #20 from Jakub Jelinek  ---
> Created attachment 47377
>   --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47377&action=edit
> gcc10-fnspec-test.patch
> 
> Just for archival purposes, here is a short gcc plugin that allows testing "fn
> spec" attribute (on direct function calls only, not on indirect calls), by
> registering a fn_spec attribute and remapping it to "fn spec" when finish_decl
> is called.

I guess sth like -fenable-internal-attributes registering both
fn_spec and no_vops would be nice for testing those.  Or better
an (undocumented) --param.  There's also "asan odr inidicator"
and various "omp declare .." ones, eventually generically adjusting
matching of the attribute names with the param/flag set can be done.

[Bug preprocessor/92696] #pragma GCC diagnostic ... interferes with if/else

[sbergman at redhat dot com]

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

--- Comment #5 from Stephan Bergmann  ---
...but something that needs proper documentation?

[Bug tree-optimization/92691] [10 Regression] ICE in strlen_dom_walker::before_dom_children at gcc/tree-ssa-strlen.c:5177 since r274933

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Thu Nov 28 08:36:06 2019
New Revision: 278803

URL: https://gcc.gnu.org/viewcvs?rev=278803&root=gcc&view=rev
Log:
PR tree-optimization/92691
* tree-ssa-strlen.c (handle_store): Clarify return value meaning
in function comment.
(strlen_check_and_optimize_call): Likewise.  For handle_printf_call
calls, return !handle_printf_call rather than always returning true.
(check_and_optimize_stmt): Describe return value meaning in function
comment.  Formatting fix.

* gcc.dg/tree-ssa/builtin-snprintf-10.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/builtin-snprintf-10.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-strlen.c

[Bug c++/88136] -Wdeprecated-copy is draconian and shouldn't be in -Wall

[sbergman at redhat dot com]

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

Stephan Bergmann  changed:

   What|Removed |Added

 CC||sbergman at redhat dot com

--- Comment #9 from Stephan Bergmann  ---
(In reply to Ville Voutilainen from comment #2)
> This is not just a Qt problem. I will write a proposal to undeprecate this
> deprecation for C++20 before the next committee meeting.

Can you give a link to that proposal?

[Bug tree-optimization/92691] [10 Regression] ICE in strlen_dom_walker::before_dom_children at gcc/tree-ssa-strlen.c:5177 since r274933

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug c++/88136] -Wdeprecated-copy is draconian and shouldn't be in -Wall

[redi at gcc dot gnu.org]

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

--- Comment #10 from Jonathan Wakely  ---
I don't think it has been written yet.

[Bug c++/92411] conformance issue with reinterpret_cast in constant expressions

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-11-28
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=82304
 Ever confirmed|0   |1

--- Comment #2 from Jonathan Wakely  ---
I see no regression, it has always been accepted by G++.

Possibly a dup of Bug 82304.

[Bug c++/82304] GCC compiles constexpr function with double reinterpret_cast in a constant context

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Last reconfirmed|2017-09-25 00:00:00 |2019-11-28

--- Comment #2 from Jonathan Wakely  ---
Reduced:

constexpr const char* testfunc(const char* p)
{
  auto l = reinterpret_cast(p);
  ++l
  return reinterpret_cast(l);
}

constexpr auto s = testfunc("Hello");

I assume the problem here and in Bug 92411 is that the compiler is folding the
casts away.

[Bug target/92190] [10 Regression] ICE in sp_valid_at, at config/i386/i386.c:6162 since r276648

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #11 from Jakub Jelinek  ---
Is CLOBBER the right representation of what vzeroupper does anyway?
I mean, for AVX512F+, shouldn't it be
(set (reg:V8DI xmm0) (vec_merge:V8DI (reg:V8DI xmm0) (const_vector:V8DI 0)
(const_int 3)))
...
and similarly for AVX/AVX2 (in that case V4DI instead of V8DI)?
And, as mentioned earlier, it could leave out register that aren't ever live in
the function, as long as it can't be introduced into the function later on.

[Bug libstdc++/91997] pretty printers: The __node_type type alias in _Hashtable is not available

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-11-28
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
>From https://bugzilla.redhat.com/show_bug.cgi?id=1053438 this also happens with
std::list

#include 
#include 
#include 
int main() {
  std::list list;
  list.push_back("a");
  std::list::iterator it=list.begin();
  return 0;
}


$ gdb -q -ex "br 8" -ex r -ex "p it"  a.out
Reading symbols from a.out...
Breakpoint 1 at 0x401237: file 91997.cc, line 8.
Starting program: /tmp/a.out 

Breakpoint 1, main () at 91997.cc:8
8 return 0;
Python Exception  Cannot find type
std::__cxx11::list,
std::allocator >, std::allocator, std::allocator > > >::iterator::_Node: 
$1 = 
(gdb)

[Bug c/91839] missing error diagnosis for undeclared identifier

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||dmalcolm at gcc dot gnu.org

--- Comment #2 from Jonathan Wakely  ---
I can confirm GCC doesn't suggest l_24, but I'm not sure it's reasonable to
expect it to do so after so many parse errors.

If you fix the first two errors then you do get it:

91839.c:6:10: error: ‘l_2’ undeclared (first use in this function); did you
mean ‘l_24’?
6 |   return l_2[0];  //error
  |  ^~~
  |  l_24


Your code is ill-formed. GCC tells you it's ill-formed. I don't see a bug here.

[Bug fortran/92702] New: [F2008] (and hence [F2018]) Implement VALUE support for arrays

[burnus at gcc dot gnu.org]

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

Bug ID: 92702
   Summary: [F2008] (and hence [F2018]) Implement VALUE support
for arrays
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: burnus at gcc dot gnu.org
  Target Milestone: ---

Currently, everything with 'dimension' is rejected, but F2008 (and F2018) now
permits everything with known size.

F2018:

C557 An entity with the VALUE attribute shall be a dummy data object that is
not an assumed-size array or a coarray, and does not have a coarray ultimate
component.

C558 An entity with the VALUE attribute shall not have the ALLOCATABLE, INTENT
(INOUT), INTENT(OUT), POINTER, or VOLATILE attributes.


F2008:
C557 An entity with the VALUE attribute shall be a dummy data object that is
not an assumed-size array or a coarray, and does not have a coarray ultimate
component.

By contrast, F2003 didn't permit DIMENSION:

C527   (R501) If the VALUE attribute is specified, the PARAMETER, EXTERNAL,
POINTER, ALLOCATABLE, DIMENSION, VOLATILE, INTENT(INOUT), or INTENT(OUT)
attribute shall not be specified.

[Bug c++/88136] -Wdeprecated-copy is draconian and shouldn't be in -Wall

[ville.voutilainen at gmail dot com]

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

--- Comment #11 from Ville Voutilainen  ---
(In reply to Jonathan Wakely from comment #10)
> I don't think it has been written yet.

Right; I decided against it, since the cats are out of the bag and shipping
implementations voted with their feet, so Rule of Five is now the law of the
land, as far as I care.

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

[burnus at gcc dot gnu.org]

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

Bug ID: 92703
   Summary: VALUE attribute: CLASS and derived-type with
allocatable components mishandled
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: burnus at gcc dot gnu.org
Blocks: 92702
  Target Milestone: ---

The test case shows that allocatable components of derived types are not copied
– just the derived type is (automatically) passed by value (according to the
platform ABI).

Hence, it works fine for data which is directly in the derived type – but not
for allocatable components.

With CLASS, I am not quite sure what goes wrong. I initially thought it is just
a missing copy – as the dump shows:

  class.20._data = &var;
  classy (&class.20);

But if I print x%A(:), it looks complete random and uninitialized.


Xref: PR 92702 – As it is also about copy-in of data (and later
finalizing/deallocation, if needed), I cross reference PR fortran/92702 which
is about VALUE + DIMENSION (permitted since F2008).


Testcase:

! { dg-do run }
!
! VALUE mishandled for CLASS and with ALLOCATABLE components
!
program main
  implicit none (type, external)
  type t
integer :: A(100)
complex :: B(1000,1000)
  end type t
  type t2
integer, allocatable :: C(:)
  end type t2
  type(t) :: var
  type(t2) :: var2
  integer :: i

  allocate(var2%C(5))
  var2%C = [1,2,3,4,5]
  call foo(var2) ! var passed by value but var2%C not copied, hence:
  if (any(var2%C /= [1,2,3,4,5])) stop 2 ! FAILS HERE

  var%A = [((21*i), i = 1,100)]
  call classy(var)
  if (any(var%A /= [((21*i), i = 1, 100)])) stop 1

contains
  subroutine foo(y)
type(t2), value :: y

if (any(y%C /= [1,2,3,4,5])) stop 11
y%C = [99,98,97,96,95]
if (any(y%C /= [99,98,97,96,95])) stop 13
  end subroutine foo

  subroutine classy(y)
class(t), value :: y

if (any(y%A /= [((21*i), i = 1, 100)])) stop 1  ! FAILS HERE
y%A(1) = 4
if (y%A(1) /= 4) stop 22
  end subroutine classy
end program main


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92702
[Bug 92702] [F2008] (and hence [F2018]) Implement VALUE support for arrays

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

[burnus at gcc dot gnu.org]

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

--- Comment #1 from Tobias Burnus  ---
(In reply to Tobias Burnus from comment #0)
> With CLASS, I am not quite sure what goes wrong. I initially thought it is
> just a missing copy – as the dump shows:
> 
>   class.20._data = &var;
>   classy (&class.20);
> 
> But if I print x%A(:), it looks complete random and uninitialized.

With -O0, one indeed runs into 'stop 2' - i.e. '&var' is not copied.

However, with -O1 it fails with the uninit memory. I assume that the alias
analysis gets in trouble, cf. PR 92123.

I think alias analysis will turn out to be a non-issue once VALUE is proper
handled, but I wonder whether some corner case can still cause problems.

[Bug tree-optimization/83819] [meta-bug] missing strlen optimizations

[ro at gcc dot gnu.org]

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

Bug 92683 Summary: [10 Regression] strncmp incorrect result with equal 
substrings and non-const bound
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92683

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

[Bug tree-optimization/92683] [10 Regression] strncmp incorrect result with equal substrings and non-const bound

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 CC||ro at gcc dot gnu.org
 Resolution|FIXED   |---

--- Comment #3 from Rainer Orth  ---
The new gcc.dg/strcmpopt_8.c test FAILs on 64-bit i386-pc-solaris2.11,
sparc-sun-solaris2.11, and (according to gcc-testresults)
powerpc-apple-darwin9:

+FAIL: gcc.dg/strcmpopt_8.c (test for excess errors)
+FAIL: gcc.dg/strcmpopt_8.c scan-tree-dump-not forwprop1 "strncmp"

Excess errors:
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.dg/strcmpopt_8.c:22:15: warning:
'__builtin_strncmp' specified bound 18446744073709551615 exceeds maximum object
size 9223372036854775807 [-Wstringop-overflow=]
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.dg/strcmpopt_8.c:22:15: warning:
'__builtin_strncmp' specified bound 18446744073709551615 exceeds maximum object
size 9223372036854775807 [-Wstringop-overflow=]
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.dg/strcmpopt_8.c:22:15: warning:
'__builtin_strncmp' specified bound 18446744073709551615 exceeds maximum object
size 9223372036854775807 [-Wstringop-overflow=]
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.dg/strcmpopt_8.c:22:15: warning:
'__builtin_strncmp' specified bound 18446744073709551615 exceeds maximum object
size 9223372036854775807 [-Wstringop-overflow=]
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.dg/strcmpopt_8.c:22:15: warning:
'__builtin_strncmp' specified bound 18446744073709551615 exceeds maximum object
size 9223372036854775807 [-Wstringop-overflow=]
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.dg/strcmpopt_8.c:22:15: warning:
'__builtin_strncmp' specified bound 18446744073709551615 exceeds maximum object
size 9223372036854775807 [-Wstringop-overflow=]
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.dg/strcmpopt_8.c:22:15: warning:
'__builtin_strncmp' specified bound 18446744073709551615 exceeds maximum object
size 9223372036854775807 [-Wstringop-overflow=]

[Bug fortran/92123] [F2018/array-descriptor] Scalar allocatable/pointer with array descriptor (via bind(C)): ICE with select rank or error scalar variable with POINTER or ALLOCATABLE in procedure wit

[burnus at gcc dot gnu.org]

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

--- Comment #23 from Tobias Burnus  ---
I have the feeling that some other use also disagrees between ME and FE/Fortran
semantics assumptions.

I just run into PR 92703: if one comments the unrelated 'foo', with -O0 one
gets the expected 'stop 2' but with -O1 one gets 'stop 21' as (effectively) the
'class.20._data = &var;' has been optimized away. — For that PR, to properly
handle Fortran semantic, a copy of 'var' had to be created and used instead. I
think that would have solved the alias/ME problem for *that* usage/test case.

Still, I fear that similar test cases can be created where for -O0 the
executable produces the correct result – but where with optimization, the
result will be wrong.

Based on the test case in PR 92703, I wonder about types like:
  type t
integer, allocatable :: A
integer, pointer :: P
  end type t

  type(t) :: var
  call foo(var)

'var' has no pointer/target attribute and, hence, it cannot alias (or if it
does as in 'call bar(var, var)' it may not be modified in bar). – Also 'var%A'
cannot alias – but 'var%P' can – as it has the pointer attribute.

If 'foo' has 'intent(in)' for 'var', 'var' and 'var%A' may not be modified nor
the pointer address (pointer association) of 'var%P'. But the value of 'var%P'
may.

With CLASS and descriptor handling with BIND(C) [cf. this PR], I fear there are
extra issues due to the auxiliary variables/wrappers generated by the FE.  

[Besides the general issue of Fortran semantic and mapping it to TYPE_RESTRICT
and 'fn spec', I have also the feeling that such auxiliary vars cause breakage
as they do not always follow the Fortran semantic.]

[Bug target/92055] [avr] Support 64-bit double

[gjl at gcc dot gnu.org]

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

--- Comment #11 from Georg-Johann Lay  ---
Author: gjl
Date: Thu Nov 28 10:29:30 2019
New Revision: 278805

URL: https://gcc.gnu.org/viewcvs?rev=278805&root=gcc&view=rev
Log:
Must use push insn to pass varargs arguments of DFmode because
otherwise the middle-end generates wrong code.
PR target/92055
* config/avr/avr.md (MPUSH) [DF, DC]: Add modes to mode iterator.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/avr/avr.md

[Bug tree-optimization/92704] New: [8/9/10 Regression] ICE: Segmentation fault (in process_bb)

[asolokha at gmx dot com]

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

Bug ID: 92704
   Summary: [8/9/10 Regression] ICE: Segmentation fault (in
process_bb)
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: ice-on-invalid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---
Target: x86_64-pc-linux-gnu

gcc-10.0.0-alpha20191124 snapshot (r278660) and 9.2.0 ICE when compiling the
following testcase w/ -O3 -fexceptions -fnon-call-exceptions -fno-tree-dce:

int zr, yx;

void __attribute__ ((simd))
oj (int rd, int q7)
{
  int wo = &rd;

  while (q7 < 1)
{
  int kv;
  short int v3;

  for (v3 = 0; v3 < 82; v3 += 3)
{
}

  kv = zr ? 0 : v3;
  yx = kv < rd;
  zr = zr && yx;
  ++q7;
}
}

% x86_64-pc-linux-gnu-gcc-10.0.0-alpha20191124 -O3 -fexceptions
-fnon-call-exceptions -fno-tree-dce -w -c xmnlq6pk.c
during GIMPLE pass: ifcvt
xmnlq6pk.c: In function 'oj.simdclone.0':
xmnlq6pk.c:4:1: internal compiler error: Segmentation fault
4 | oj (int rd, int q7)
  | ^~
0xd11940 crash_signal
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191124/work/gcc-10-20191124/gcc/toplev.c:328
0xec0494 process_bb
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191124/work/gcc-10-20191124/gcc/tree-ssa-sccvn.c:6705
0xec1818 do_rpo_vn
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191124/work/gcc-10-20191124/gcc/tree-ssa-sccvn.c:7168
0xec2e63 do_rpo_vn(function*, edge_def*, bitmap_head*)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191124/work/gcc-10-20191124/gcc/tree-ssa-sccvn.c:7265
0xd8071f tree_if_conversion(loop*, vec*)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191124/work/gcc-10-20191124/gcc/tree-if-conv.c:3090
0xd822e6 execute
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191124/work/gcc-10-20191124/gcc/tree-if-conv.c:3170
0xd822e6 execute
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191124/work/gcc-10-20191124/gcc/tree-if-conv.c:3157

gcc 8.3.0 fails differently (via godbolt):

: In function 'oj.simdclone.0':
:4:1: error: missing PHI def
 oj (int rd, int q7)
 ^~
.MEM_110 = PHI <(5), .MEM_103(50)>
:4: confused by earlier errors, bailing out

[Bug tree-optimization/91790] ICE: verify_ssa failed (error: definition in block 2 follows the use)

[asolokha at gmx dot com]

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

Arseny Solokha  changed:

   What|Removed |Added

  Known to work|9.2.1   |

--- Comment #13 from Arseny Solokha  ---
I believe some backports are pending?

[Bug libstdc++/91997] pretty printers: The __node_type type alias in _Hashtable is not available

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

[Bug libstdc++/91997] pretty printers: The __node_type type alias in _Hashtable is not available

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
   Target Milestone|--- |10.0

[Bug c++/92705] New: [10 Regression] ICE: Segmentation fault (in build_new_op_1)

[asolokha at gmx dot com]

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

Bug ID: 92705
   Summary: [10 Regression] ICE: Segmentation fault (in
build_new_op_1)
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: error-recovery, ice-on-invalid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

g++-10.0.0-alpha20191124 snapshot (r278660) ICEs when compiling the following
testcase reduced from test/SemaCXX/builtin-ptrtomember-overload-1.cpp from the
clang 9.0.0 test suite:

struct A {};
struct E {};

struct R {
operator E*();
};

struct S {
operator E*();
};

struct B1  : R, S {
operator A*();
};

void foo1(B1 b1, int E::* pmf) {
int i = b1->*pmf;
}

% g++-10.0.0-alpha20191124 -c gmnbcjli.cpp
gmnbcjli.cpp: In function 'void foo1(B1, int E::*)':
gmnbcjli.cpp:17:22: internal compiler error: Segmentation fault
   17 | int i = b1->*pmf;
  |  ^~~
0xf36080 crash_signal
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191124/work/gcc-10-20191124/gcc/toplev.c:328
0x839d0e build_new_op_1
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191124/work/gcc-10-20191124/gcc/cp/call.c:6375
0x83a33a build_new_op(op_location_t const&, tree_code, int, tree_node*,
tree_node*, tree_node*, tree_node**, int)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191124/work/gcc-10-20191124/gcc/cp/call.c:6500
0x9f8dd1 build_x_binary_op(op_location_t const&, tree_code, tree_node*,
tree_code, tree_node*, tree_code, tree_node**, int)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191124/work/gcc-10-20191124/gcc/cp/typeck.c:4223
0x92d178 cp_parser_binary_expression
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191124/work/gcc-10-20191124/gcc/cp/parser.c:9645
0x92e026 cp_parser_assignment_expression
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191124/work/gcc-10-20191124/gcc/cp/parser.c:9780
0x92d869 cp_parser_constant_expression
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191124/work/gcc-10-20191124/gcc/cp/parser.c:10074
0x92dfcb cp_parser_initializer_clause
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191124/work/gcc-10-20191124/gcc/cp/parser.c:23032
0x9320b7 cp_parser_initializer
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191124/work/gcc-10-20191124/gcc/cp/parser.c:22970
0x957b5b cp_parser_init_declarator
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191124/work/gcc-10-20191124/gcc/cp/parser.c:20678
0x93aa52 cp_parser_simple_declaration
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191124/work/gcc-10-20191124/gcc/cp/parser.c:13624
0x93c87f cp_parser_declaration_statement
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191124/work/gcc-10-20191124/gcc/cp/parser.c:13055
0x93d3c4 cp_parser_statement
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191124/work/gcc-10-20191124/gcc/cp/parser.c:11380
0x93e3c5 cp_parser_statement_seq_opt
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191124/work/gcc-10-20191124/gcc/cp/parser.c:11742
0x93e492 cp_parser_compound_statement
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191124/work/gcc-10-20191124/gcc/cp/parser.c:11696
0x953e74 cp_parser_function_body
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191124/work/gcc-10-20191124/gcc/cp/parser.c:22876
0x953e74 cp_parser_ctor_initializer_opt_and_function_body
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191124/work/gcc-10-20191124/gcc/cp/parser.c:22927
0x957005 cp_parser_function_definition_after_declarator
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191124/work/gcc-10-20191124/gcc/cp/parser.c:28597
0x957fe4 cp_parser_function_definition_from_specifiers_and_declarator
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191124/work/gcc-10-20191124/gcc/cp/parser.c:28513
0x957fe4 cp_parser_init_declarator
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191124/work/gcc-10-20191124/gcc/cp/parser.c:20505

[Bug tree-optimization/92706] New: SRA confuses FRE

[rguenth at gcc dot gnu.org]

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

Bug ID: 92706
   Summary: SRA confuses FRE
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

Reduced from one of the issues in PR92645

struct S { int i[4]; } __attribute__((aligned(128)));
typedef __int128_t my_int128 __attribute__((may_alias));
__int128_t load (void *p)
{
  struct S v;
  __builtin_memcpy (&v, p, sizeof (struct S));
  struct S u;
  u = v;
  struct S w;
  w = u;
  return *(my_int128 *)&w;
}

[Bug tree-optimization/92706] SRA confuses FRE

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
 CC||jamborm at gcc dot gnu.org

--- Comment #1 from Richard Biener  ---
Martin - ESRA does something odd here, I see it turning

  MEM[(charD.7 * {ref-all})&vD.1911] = MEM[(charD.7 * {ref-all})p_3(D)];
  uD.1912 = vD.1911;
  wD.1913 = uD.1912;
  _7 = MEM[(my_int128D.1907 * {ref-all})&wD.1913];

into

  MEM[(charD.7 * {ref-all})&vD.1911] = MEM[(charD.7 * {ref-all})p_3(D)];
  uD.1912 = vD.1911;
  u$i$0_1 = MEM[(struct S *)&vD.1911];
  u$i$1_11 = MEM[(struct S *)&vD.1911 + 4B];
  u$i$2_12 = MEM[(struct S *)&vD.1911 + 8B];
  u$i$3_13 = MEM[(struct S *)&vD.1911 + 12B];
  MEM[(struct S *)&wD.1913] = u$i$0_1;
  MEM[(struct S *)&wD.1913 + 4B] = u$i$1_11;
  MEM[(struct S *)&wD.1913 + 8B] = u$i$2_12;
  MEM[(struct S *)&wD.1913 + 12B] = u$i$3_13;
  w_18 = MEM[(struct S *)&wD.1913];
  _7 = w_18;

where it totally scalarizes uD.1912 without factoring in the access
loading to w_18.

This creates a pass ordering issue with FRE which on the aggregate code
would have happily elided the aggregate copy but is confused about
the "scalarized" variant.

SRA sees

Access trees for w (UID: 1913):
access { base = (1913)'w', offset = 0, size = 1024, expr = w, type = struct S,
non_addressable = 0, reverse = 0, grp_read = 1, grp_write = 1,
grp_assignment_read = 0, grp_assignment_write = 1, grp_scalar_read = 0,
grp_scalar_write = 0, grp_total_scalarization = 0, grp_hint = 0, grp_covered =
0, grp_unscalarizable_region = 0, grp_unscalarized_data = 1, grp_partial_lhs =
0, grp_to_be_replaced = 0, grp_to_be_debug_replaced = 0, grp_maybe_modified =
0, grp_not_necessarilly_dereferenced = 0
* access { base = (1913)'w', offset = 0, size = 128, expr = MEM[(my_int128 *
{ref-all})&w], type = my_int128, non_addressable = 0, reverse = 0, grp_read =
1, grp_write = 1, grp_assignment_read = 1, grp_assignment_write = 1,
grp_scalar_read = 1, grp_scalar_write = 0, grp_total_scalarization = 0,
grp_hint = 0, grp_covered = 1, grp_unscalarizable_region = 0,
grp_unscalarized_data = 0, grp_partial_lhs = 0, grp_to_be_replaced = 1,
grp_to_be_debug_replaced = 0, grp_maybe_modified = 0,
grp_not_necessarilly_dereferenced = 0

so I wonder why it chooses to totally scalarize instead of using the
int128 access?

[Bug tree-optimization/92706] SRA confuses FRE

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
That is, I had the impression that for total scalarization SRA considers both
the accesses of the ultimate sources and the destinations?

[Bug tree-optimization/92645] Hand written vector code is 450 times slower when compiled with GCC compared to Clang

[rguenth at gcc dot gnu.org]

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

--- Comment #15 from Richard Biener  ---
Author: rguenth
Date: Thu Nov 28 12:22:04 2019
New Revision: 278806

URL: https://gcc.gnu.org/viewcvs?rev=278806&root=gcc&view=rev
Log:
2019-11-28  Richard Biener  

PR tree-optimization/92645
* tree-ssa-forwprop.c (get_bit_field_ref_def): Also handle
conversions inside a mode class.  Remove restriction on
preserving the element size.
(simplify_vector_constructor): Deal with the above and for
identity permutes also try using VEC_UNPACK_[FLOAT_]LO_EXPR
and VEC_PACK_TRUNC_EXPR.

* gcc.target/i386/pr92645-4.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.target/i386/pr92645-4.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-forwprop.c

[Bug tree-optimization/92704] [8/9/10 Regression] ICE: Segmentation fault (in process_bb)

[prathamesh3492 at gcc dot gnu.org]

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

prathamesh3492 at gcc dot gnu.org changed:

   What|Removed |Added

 CC||prathamesh3492 at gcc dot 
gnu.org

--- Comment #1 from prathamesh3492 at gcc dot gnu.org ---
This seems, to happen because we end up with following phi defining .MEM_113 in
ifcvt dump:

   [local count: 3667364]:
  # q7_91 = PHI 
  # zr_lsm.55_92 = PHI 
  # .MEM_113 = PHI <(5), .MEM_106(50)>

.MEM_113 phi seems to have NULL (!) arg, which then causes segfault in
following hunk in tree-ssa-sccvn.c:process_bb()

  gphi *phi = gsi.phi ();
  use_operand_p use_p = PHI_ARG_DEF_PTR_FROM_EDGE (phi, e);
  tree arg = USE_FROM_PTR (use_p);
  if (TREE_CODE (arg) != SSA_NAME
  || virtual_operand_p (arg))
continue;

Passing -fno-tree-loop-ifconvert in addition to other options, doesn't cause
the segfault. I assume phi args cannot be NULL ?

Thanks,
Prathamesh

[Bug tree-optimization/92645] Hand written vector code is 450 times slower when compiled with GCC compared to Clang

[rguenth at gcc dot gnu.org]

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

--- Comment #16 from Richard Biener  ---
Author: rguenth
Date: Thu Nov 28 12:26:50 2019
New Revision: 278807

URL: https://gcc.gnu.org/viewcvs?rev=278807&root=gcc&view=rev
Log:
2019-11-28  Richard Biener  

PR tree-optimization/92645
* tree-inline.c (remap_gimple_stmt): When the return value
is not wanted, elide GIMPLE_RETURN.

* gcc.dg/tree-ssa/inline-12.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/inline-12.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-inline.c

[Bug c++/92707] New: type alias on type alias on lambda in unevaluated context does not work

[vanyacpp at gmail dot com]

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

Bug ID: 92707
   Summary: type alias on type alias on lambda in unevaluated
context does not work
   Product: gcc
   Version: 9.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vanyacpp at gmail dot com
  Target Milestone: ---

GCC shows an error on this code:

template 
using foo = decltype([] {});

template 
using bar = foo;

extern foo a;
extern bar a; // error: 'bar' does not name a type

The error is wrong because bar is a regular type alias. Clearly it names a
type.

If I replace the lambda with an integer the error goes away.

[Bug rtl-optimization/92176] LRA problem with reloads for subreg operands

[krebbel at gcc dot gnu.org]

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

--- Comment #1 from Andreas Krebbel  ---
Created attachment 47387
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47387&action=edit
Another reduced testcase

gcc -O3 -march=z13 t.c -o t

./t

prints "checksum = 0" with head GCC
prints "checksum = 5" with GCCs before r272639 but this patch only appears to
reveal the actual issue

[Bug rtl-optimization/92176] LRA problem with reloads for subreg operands

[krebbel at gcc dot gnu.org]

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

--- Comment #2 from Andreas Krebbel  ---
Created attachment 47388
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47388&action=edit
Experimental patch

This patch fixes the second testcase. The first one currently doesn't fail on
head.

[Bug rtl-optimization/92176] LRA problem with reloads for subreg operands

[krebbel at gcc dot gnu.org]

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

Andreas Krebbel  changed:

   What|Removed |Added

   Priority|P3  |P2
   Severity|normal  |major

[Bug c++/92675] sign-conversion C++ unsigned int j = -1;

[jg at jguk dot org]

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

--- Comment #6 from Jonny Grant  ---
Is the clearest way to write this as follows?
unsigned int j = (unsigned int)-1;

Likewise for the template example:

  U max = (U)-1;   // good

[Bug rtl-optimization/92176] LRA problem with reloads for subreg operands

[krebbel at gcc dot gnu.org]

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

--- Comment #3 from Andreas Krebbel  ---
276.ira:

(insn 6 85 11 2 (set (reg:SI 100 [ f ])
(mem/c:SI (symbol_ref:DI ("*.LANCHOR0") [flags 0x182]) [2 f+0 S4 A32]))
"t.c":13:8 1372 {*movsi_zarch}
 (expr_list:REG_EQUIV (mem/c:SI (symbol_ref:DI ("*.LANCHOR0") [flags
0x182]) [2 f+0 S4 A32])
(nil)))
...

(insn 87 75 207 2 (parallel [
(set (mem/c:QI (plus:DI (reg/f:DI 165)
(const_int 16 [0x10])) [0 b+0 S1 A16])
(and:QI (mem/c:QI (plus:DI (reg/f:DI 165)
(const_int 16 [0x10])) [0 b+0 S1 A16])
(subreg:QI (reg:SI 100 [ f ]) 3)))
(clobber (reg:CC 33 %cc))
]) "t.c":13:8 1830 {*andqi3_zarch}
 (expr_list:REG_DEAD (reg/f:DI 165)
(expr_list:REG_DEAD (reg:SI 100 [ f ])
(expr_list:REG_UNUSED (reg:CC 33 %cc)
(nil)

277.reload:

Reload at first generates two reloads for insn 87:

Changing pseudo 100 in operand 2 of insn 87 on equiv [`*.LANCHOR0']
  Creating newreg=202, assigning class ALL_REGS to slow/invalid mem r202
  Creating newreg=203, assigning class ALL_REGS to slow/invalid mem r203
   87: {[r165:DI+0x10]=[r165:DI+0x10]&r203:QI;clobber %cc:CC;}
  REG_DEAD r165:DI
  REG_DEAD r100:SI
  REG_UNUSED %cc:CC
Inserting slow/invalid mem reload before:
  254: r202:SI=[`*.LANCHOR0']
  255: r203:QI=r202:SI#3

(insn 254 0 0 (set (reg:SI 202)
(mem/c:SI (symbol_ref:DI ("*.LANCHOR0") [flags 0x182]) [2 f+0 S4 A32]))
1372 {*movsi_zarch}
 (nil))
(insn 255 254 0 (set (reg:QI 203)
(subreg:QI (reg:SI 202) 3)) -1
 (nil))


Both r202 as well as r203 get f0 assigned as hard register. In
lra_final_code_change-> alter_subregs-> alter_subreg -> simplify_subreg  this
gets simplified to:

(insn 255 254 256 2 (set (reg:QI 16 %f0 [203])
(reg:QI 16 %f0 [orig:202+3 ] [202])) "t.c":13:8 1379 {*movqi}
 (expr_list:REG_DEAD (reg:SI 16 %f0 [202])
(nil)))

Simplifying (subreg:QI (reg:SI 202) 3) to (reg:QI 16 %f0) is wrong on IBM Z
since floating point registers have a different endianess than general purpose
registers. Hence we forbid it via TARGET_CAN_CHANGE_MODE_CLASS. However, in
simplify_subreg_regno there is a check for lra_in_progress which leads to the
value of the target hook being ignored. Removing the lra_in_progress check
fixes the problem for. That change got in with the LRA patchset.

  /* Give the backend a chance to disallow the mode change.  */
  if (GET_MODE_CLASS (xmode) != MODE_COMPLEX_INT
  && GET_MODE_CLASS (xmode) != MODE_COMPLEX_FLOAT
  && !REG_CAN_CHANGE_MODE_P (xregno, xmode, ymode)
  /* We can use mode change in LRA for some transformations.  */
  && ! lra_in_progress) <-   ?
return -1;

I'm currently checking whether removing it makes any difference in code
generation - apart from fixing the testcase.

[Bug tree-optimization/92706] SRA confuses FRE

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-11-28
 Ever confirmed|0   |1

--- Comment #3 from Richard Biener  ---
Testcase w/o too excessive alignment (and not relying on __int128):

typedef __UINT64_TYPE__ uint64_t;
typedef __UINT32_TYPE__ uint32_t;
struct S { uint32_t i[2]; } __attribute__((aligned(__alignof__(uint64_t;
typedef uint64_t my_int64 __attribute__((may_alias));
uint64_t load (void *p)
{
  struct S u, v, w;
  uint64_t tem;
  tem = *(my_int64 *)p;
  *(my_int64 *)&v = tem;
  u = v;
  w = u;
  return *(my_int64 *)&w;
}

nicely showing a case where the total scalarized aggregate doesn't
even go away?!

@@ -20,11 +64,13 @@
   tem_5 = MEM[(my_int64 * {ref-all})p_4(D)];
   MEM[(my_int64 * {ref-all})&v] = tem_5;
   u = v;
-  w = u;
-  _9 = MEM[(my_int64 * {ref-all})&w];
-  u ={v} {CLOBBER};
+  u$i$0_1 = v.i[0];
+  u$i$1_2 = v.i[1];
+  MEM  [(struct S *)&u] = u$i$0_1;
+  MEM  [(struct S *)&u + 4B] = u$i$1_2;
+  w_15 = MEM[(struct S *)&u];
+  _9 = w_15;
   v ={v} {CLOBBER};
-  w ={v} {CLOBBER};
   return _9;

maybe it's because SRA arrives late at the decision to scalarize w?

[Bug c++/60228] ICE using lambda in #pragma omp declare reduction

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #6 from Jakub Jelinek  ---
Created attachment 47389
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47389&action=edit
gcc10-pr60228.patch

Untested fix.

[Bug fortran/92702] [F2008] (and hence [F2018]) Implement VALUE support for arrays + deferred-length parameters

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

Summary|[F2008] (and hence [F2018]) |[F2008] (and hence [F2018])
   |Implement VALUE support for |Implement VALUE support for
   |arrays  |arrays + deferred-length
   ||parameters

--- Comment #1 from Tobias Burnus  ---
The following restriction of F2003 is also gone:

C528   (R501) If the VALUE attribute is specified, the length type parameter
values shall be omitted or specified by initialization expressions.

F2008 + F2018 permit them.

Implementation choice (for characters and arrays): One can pass those with
known bounds as ARRAY_TYPE (i.e. by value) or one passes them as a pointer to
an ARRAY_TYPE (i.e. by reference).

Currently, for character they are passed by value as (known string-length)
ARRAY_TYPE.

[Bug c++/92708] New: [Issue] dynamic_cast unexpected behavior in my code

[akhilesh.k at samsung dot com]

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

Bug ID: 92708
   Summary: [Issue] dynamic_cast unexpected behavior in my code
   Product: gcc
   Version: 6.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: akhilesh.k at samsung dot com
  Target Milestone: ---

Hello 

In below code I used class A and a class B which is derived from A. Now, I did 
dynamic_cast  I got segmentation fault. same behaviors I observed on ARM also. 

is this expected behavior ? or some limitation.   

As per below link seems some limitation with shared libraries. 
https://gcc.gnu.org/faq.html#dso


akhilesh.k@DELL-BUILD10:$ cat hello.c 
#include 
#include 
using namespace std;

class A
{
public:
A(){}
virtual ~A(){};
};

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

int main()
{
A *pa, *pa2;
B *pb, *pb2;
pa = new A; 
pb = new B; 

delete pb;
pa2 = dynamic_cast(pb);
pb2 = dynamic_cast(pb);
pb2 = dynamic_cast(pa2);
printf("pb2 = %p\n", pb2);

pb2 = dynamic_cast(pa);
printf("pb2 = %p\n", pb2);

delete pa;
delete pb;

return 0; 
}

akhilesh.k@DELL-BUILD10:$ g++ -g hello.c 
akhilesh.k@DELL-BUILD10:$ gdb a.out 
GNU gdb (Ubuntu 7.7.1-0ubuntu5~14.04.3) 7.7.1
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from a.out...done.
(gdb) r
Starting program: /data2/2706/akhilesh.k/a.out 

Program received signal SIGSEGV, Segmentation fault.
0x77b33156 in __dynamic_cast () from
/usr/lib/x86_64-linux-gnu/libstdc++.so.6
(gdb) bt
#0  0x77b33156 in __dynamic_cast () from
/usr/lib/x86_64-linux-gnu/libstdc++.so.6
#1  0x0040095d in main () at hello.c:29
(gdb)

[Bug c++/92705] [10 Regression] ICE: Segmentation fault (in build_new_op_1)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |10.0

[Bug tree-optimization/92704] [8/9/10 Regression] ICE: Segmentation fault (in process_bb)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-11-28
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
   Target Milestone|--- |8.4
 Ever confirmed|0   |1

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

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

[burnus at gcc dot gnu.org]

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

--- Comment #2 from Tobias Burnus  ---
Actually, w/o checking the finally generated code, I have the feeling that for
*absent* arguments, the wrong code might be generated for:

character → dummy argument is ARRAY_TYPE
derived type + class → dummy argument is a struct

In both cases, null_pointer_node is passed as actual argument. Depending how
the argument is put on the stack and where the next argument is placed to, it
might work or not. Cf. also PR 92305 which feels related.

[Bug libgcc/92709] New: Cross Compilation failed for Latest GCC riscv64-linux-gnu on Linux/WSL2

[euloanty at live dot com]

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

Bug ID: 92709
   Summary: Cross Compilation failed for Latest GCC
riscv64-linux-gnu on Linux/WSL2
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: accepts-invalid
  Severity: normal
  Priority: P3
 Component: libgcc
  Assignee: unassigned at gcc dot gnu.org
  Reporter: euloanty at live dot com
  Target Milestone: ---

make[3]: Entering directory
'/home/cqwrteur/gcc-riscv64-build/riscv64-linux-gnu/libgcc'
if [ -z "lib32/ilp32 lib32/ilp32d lib64/lp64 lib64/lp64d" ]; then \
  true; \
else \
  rootpre=`${PWDCMD-pwd}`/; export rootpre; \
  srcrootpre=`cd ../../../gcc/libgcc; ${PWDCMD-pwd}`/; export srcrootpre; \
  lib=`echo "${rootpre}" | sed -e 's,^.*/\([^/][^/]*\)/$,\1,'`; \
  compiler="/home/cqwrteur/gcc-riscv64-build/./gcc/xgcc
-B/home/cqwrteur/gcc-riscv64-build/./gcc/ -B/usr/local/riscv64-linux-gnu/bin/
-B/usr/local/riscv64-linux-gnu/lib/ -isystem
/usr/local/riscv64-linux-gnu/include -isystem
/usr/local/riscv64-linux-gnu/sys-include   "; \
  for i in `${compiler} --print-multi-lib 2>/dev/null`; do \
dir=`echo $i | sed -e 's/;.*$//'`; \
if [ "${dir}" = "." ]; then \
  true; \
else \
  if [ -d ../${dir}/${lib} ]; then \
flags=`echo $i | sed -e 's/^[^;]*;//' -e 's/@/ -/g'`; \
if (cd ../${dir}/${lib}; make "AR=riscv64-linux-gnu-ar" "AR_FLAGS=rc"
"CC=/home/cqwrteur/gcc-riscv64-build/./gcc/xgcc
-B/home/cqwrteur/gcc-riscv64-build/./gcc/ -B/usr/local/riscv64-linux-gnu/bin/
-B/usr/local/riscv64-linux-gnu/lib/ -isystem
/usr/local/riscv64-linux-gnu/include -isystem
/usr/local/riscv64-linux-gnu/sys-include   " "CFLAGS=-g -O2" "DESTDIR="
"EXTRA_OFILES=" "HDEFINES=" "INSTALL=/usr/bin/install -c"
"INSTALL_DATA=/usr/bin/install -c -m 644" "INSTALL_PROGRAM=/usr/bin/install -c"
"LDFLAGS=" "LOADLIBES=" "RANLIB=riscv64-linux-gnu-ranlib" "SHELL=/bin/bash"
"prefix=/usr/local" "exec_prefix=/usr/local" "libdir=/usr/local/lib"
"libsubdir=/usr/local/lib/gcc/riscv64-linux-gnu/10.0.0"
"tooldir=/usr/local/riscv64-linux-gnu" \
CFLAGS="-g -O2 ${flags}" \
CCASFLAGS=" ${flags}" \
FCFLAGS=" ${flags}" \
FFLAGS=" ${flags}" \
ADAFLAGS=" ${flags}" \
prefix="/usr/local" \
exec_prefix="/usr/local" \
GOCFLAGS="-O2 -g ${flags}" \
GDCFLAGS="-O2 -g ${flags}" \
CXXFLAGS="-g -O2 -D_GNU_SOURCE ${flags}" \
LIBCFLAGS="-g -O2 ${flags}" \
LIBCXXFLAGS="-g -O2 -D_GNU_SOURCE
-fno-implicit-templates ${flags}" \
LDFLAGS=" ${flags}" \
MULTIFLAGS="${flags}" \
DESTDIR="" \
INSTALL="/usr/bin/install -c" \
INSTALL_DATA="/usr/bin/install -c -m 644" \
INSTALL_PROGRAM="/usr/bin/install -c" \
INSTALL_SCRIPT="/usr/bin/install -c" \
all); then \
  true; \
else \
  exit 1; \
fi; \
  else true; \
  fi; \
fi; \
  done; \
fi
make[4]: Entering directory
'/home/cqwrteur/gcc-riscv64-build/riscv64-linux-gnu/lib32/ilp32/libgcc'
make[4]: *** No rule to make target 'all'.  Stop.
make[4]: Leaving directory
'/home/cqwrteur/gcc-riscv64-build/riscv64-linux-gnu/lib32/ilp32/libgcc'
Makefile:1211: recipe for target 'multi-do' failed
make[3]: *** [multi-do] Error 1
make[3]: Leaving directory
'/home/cqwrteur/gcc-riscv64-build/riscv64-linux-gnu/libgcc'
Makefile:125: recipe for target 'all-multi' failed
make[2]: *** [all-multi] Error 2
make[2]: Leaving directory
'/home/cqwrteur/gcc-riscv64-build/riscv64-linux-gnu/libgcc'
Makefile:14125: recipe for target 'all-target-libgcc' failed
make[1]: *** [all-target-libgcc] Error 2
make[1]: Leaving directory '/home/cqwrteur/gcc-riscv64-build'
Makefile:964: recipe for target 'all' failed
make: *** [all] Error 2

[Bug fortran/92123] [F2018/array-descriptor] Scalar allocatable/pointer with array descriptor (via bind(C)): ICE with select rank or error scalar variable with POINTER or ALLOCATABLE in procedure wit

[rguenth at gcc dot gnu.org]

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

--- Comment #24 from Richard Biener  ---
(In reply to Tobias Burnus from comment #23)
> I have the feeling that some other use also disagrees between ME and
> FE/Fortran semantics assumptions.
> 
> I just run into PR 92703: if one comments the unrelated 'foo', with -O0 one
> gets the expected 'stop 2' but with -O1 one gets 'stop 21' as (effectively)
> the 'class.20._data = &var;' has been optimized away. — For that PR, to
> properly handle Fortran semantic, a copy of 'var' had to be created and used
> instead. I think that would have solved the alias/ME problem for *that*
> usage/test case.

Note it's not the semantic of the Fortran language that matters but the
actual semantics of the GFortran frontend generated IL that does.  If
the Fortran language says for INTENT(IN) the variable isn't modified but
the underlying IL GFortran creates does exactly that then this is what
matters when you compute what to describe to the middle-end since the
middle-end cannot distinguish between "The Fortran Code" and the
"GFortran Implementation Details".

For example array descriptor handling is an important implementation detail
and INTENT() probably does _not_ talk about modifications/ownership of those.

[Bug c++/92708] [Issue] dynamic_cast unexpected behavior in my code

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
(In reply to Akhilesh Kumar from comment #0)
> delete pb;
> pa2 = dynamic_cast(pb);

This is undefined behaviour, the pointer pb is no longer valid.

Also be aware that GCC 8.3 is the oldest release still supported by the GCC
project.

[Bug bootstrap/92484] In tree build of ISL 0.22 fails: requires C++11

[irfanadilovic at gmail dot com]

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

Irfan Adilovic  changed:

   What|Removed |Added

 CC||irfanadilovic at gmail dot com

--- Comment #6 from Irfan Adilovic  ---
Here's my take on this.

GCC configure.ac has this:

# When bootstrapping with GCC, build stage 1 in C++98 mode to ensure that a
# C++98 compiler can still start the bootstrap.
if test "$enable_bootstrap:$GXX" = "yes:yes"; then
  CXX="$CXX -std=gnu++98"
fi

which results in the CXX being defined as 'g++ -std=gnu++98 -std=c++11' in ISL
Makefiles (CXX propagated recursively). However this is *not* the problem, as
this CXX definition works just fine on C++11 source code.

This leads me to conclude that GCC must be using some kind of make variable
override mechanism, like invoking the ISL make with `make CXX="$CXX" all` which
leads to the complete override of CXX in ISL Makefiles, leaving out the
-std=c++11 flag, and leading to compilation failures of C++11 code in ISL.

Moreover, to reinforce this conclusion, running a plain 'make' in ISL build
subdir, right after the top-level make has failed, works just fine. It is only
when invoked recursively through toplevel Makefile, that it fails as described.

---

By invoking top-level make as 'make V=1 SHELL="/bin/bash -vx"' I've been able
to isolate the full make command used to build ISL (warning, it's a handful):

make "DESTDIR=" "RPATH_ENVVAR=LD_LIBRARY_PATH"
"TARGET_SUBDIR=x86_64-redhat-linux" "bindir=/usr/local/gcc-9.2.0/bin"
"datadir=/usr/local/gcc-9.2.0/share" "exec_prefix=/usr/local/gcc-9.2.0"
"includedir=/usr/local/gcc-9.2.0/include"
"datarootdir=/usr/local/gcc-9.2.0/share"
"docdir=/usr/local/gcc-9.2.0/share/doc/"
"infodir=/usr/local/gcc-9.2.0/share/info"
"pdfdir=/usr/local/gcc-9.2.0/share/doc/"
"htmldir=/usr/local/gcc-9.2.0/share/doc/" "libdir=/usr/local/gcc-9.2.0/lib"
"libexecdir=/usr/local/gcc-9.2.0/libexec" "lispdir="
"localstatedir=/usr/local/gcc-9.2.0/var"
"mandir=/usr/local/gcc-9.2.0/share/man" "oldincludedir=/usr/include"
"prefix=/usr/local/gcc-9.2.0" "sbindir=/usr/local/gcc-9.2.0/sbin"
"sharedstatedir=/usr/local/gcc-9.2.0/com" "sysconfdir=/usr/local/gcc-9.2.0/etc"
"tooldir=/usr/local/gcc-9.2.0/x86_64-redhat-linux"
"build_tooldir=/usr/local/gcc-9.2.0/x86_64-redhat-linux"
"target_alias=x86_64-redhat-linux" "AWK=gawk" "BISON=bison" "CC_FOR_BUILD=gcc"
"CFLAGS_FOR_BUILD=-g -O2" "CXX_FOR_BUILD=g++ -std=gnu++98" "EXPECT=expect"
"FLEX=flex" "INSTALL=/usr/bin/install -c" "INSTALL_DATA=/usr/bin/install -c -m
644" "INSTALL_PROGRAM=/usr/bin/install -c" "INSTALL_SCRIPT=/usr/bin/install -c"
"LDFLAGS_FOR_BUILD=" "LEX=flex" "M4=m4" "MAKE=make" "RUNTEST=runtest"
"RUNTESTFLAGS=" "SED=/bin/sed" "SHELL=/bin/bash -vx" "YACC=bison -y" "`echo
'ADAFLAGS=' | sed -e s'/[^=][^=]*=$/XFOO=/'`" "ADA_CFLAGS=" "AR_FLAGS=rc"
"`echo 'BOOT_ADAFLAGS=-gnatpg' | sed -e s'/[^=][^=]*=$/XFOO=/'`"
"BOOT_CFLAGS=-g -O2" "BOOT_LDFLAGS=" "CFLAGS=-g -O2" "CXXFLAGS=-g -O2"
"LDFLAGS=" "LIBCFLAGS=-g -O2" "LIBCXXFLAGS=-g -O2 -fno-implicit-templates"
"STAGE1_CHECKING=--enable-checking=release,types" "STAGE1_LANGUAGES=c,c++,lto"
"GNATBIND=no" "GNATMAKE=no" "GDC=@GDC@" "GDCFLAGS=-g -O2" "AR_FOR_TARGET=ar"
"AS_FOR_TARGET=as" "CC_FOR_TARGET=/root/gcc/gcc/build/./gcc/xgcc
-B/root/gcc/gcc/build/./gcc/" "CFLAGS_FOR_TARGET=-g -O2" "CPPFLAGS_FOR_TARGET="
"CXXFLAGS_FOR_TARGET=-g -O2 -D_GNU_SOURCE" "DLLTOOL_FOR_TARGET=dlltool"
"FLAGS_FOR_TARGET=-B/usr/local/gcc-9.2.0/x86_64-redhat-linux/bin/
-B/usr/local/gcc-9.2.0/x86_64-redhat-linux/lib/ -isystem
/usr/local/gcc-9.2.0/x86_64-redhat-linux/include -isystem
/usr/local/gcc-9.2.0/x86_64-redhat-linux/sys-include" "GFORTRAN_FOR_TARGET="
"GOC_FOR_TARGET=" "GOCFLAGS_FOR_TARGET=-O2 -g" "GDC_FOR_TARGET=@GDC@"
"GDCFLAGS_FOR_TARGET=-O2 -g" "LD_FOR_TARGET=ld" "LIPO_FOR_TARGET=lipo"
"LDFLAGS_FOR_TARGET=" "LIBCFLAGS_FOR_TARGET=-g -O2" "LIBCXXFLAGS_FOR_TARGET=-g
-O2 -D_GNU_SOURCE -fno-implicit-templates" "NM_FOR_TARGET=nm"
"OBJDUMP_FOR_TARGET=objdump" "OBJCOPY_FOR_TARGET=" "RANLIB_FOR_TARGET=ranlib"
"READELF_FOR_TARGET=readelf" "STRIP_FOR_TARGET=strip"
"WINDRES_FOR_TARGET=windres" "WINDMC_FOR_TARGET=windmc"
"BUILD_CONFIG=bootstrap-debug" "`echo 'LANGUAGES=' | sed -e
s'/[^=][^=]*=$/XFOO=/'`" "LEAN=false" "STAGE1_CFLAGS=-g" "STAGE1_CXXFLAGS=-g"
"STAGE1_GENERATOR_CFLAGS=" "STAGE1_TFLAGS=-fno-checking" "STAGE2_CFLAGS=-g -O2
-fno-checking -gtoggle" "STAGE2_CXXFLAGS=-g -O2 -fno-checking -gtoggle"
"STAGE2_GENERATOR_CFLAGS=" "STAGE2_TFLAGS=-fno-checking" "STAGE3_CFLAGS=-g -O2
-fchecking=1" "STAGE3_CXXFLAGS=-g -O2 -fchecking=1" "STAGE3_GENERATOR_CFLAGS="
"STAGE3_TFLAGS=-fchecking=1" "STAGE4_CFLAGS=-g -O2" "STAGE4_CXXFLAGS=-g -O2"
"STAGE4_GENERATOR_CFLAGS=" "STAGE4_TFLAGS=" "STAGEprofile_CFLAGS=-g -O2
-fno-checking -gtoggle -fprofile-generate" "STAGEprofile_CXXFLAGS=-g -O2
-fno-checking -gtoggle -fprofile-generate" "STAGEprofile_GENERATOR_CFLAGS="
"STAGEprofile

[Bug libstdc++/91997] pretty printers: The __node_type type alias in _Hashtable is not available

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
Rafael, I'm unable to reproduce this with unordered containers. Do you have a
testcase?

[Bug c++/92654] [8/9/10 Regression] internal compiler error: in lookup_template_class_1

[fiesh at zefix dot tv]

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

--- Comment #7 from fiesh at zefix dot tv ---
And creduce just finished:  (I left the ifdef unchanged so it can still be
compiled under clang.)



#ifdef __has_builtin
#define a 1
#endif
template  struct d {
  typedef b e;
  constexpr operator e() const { return c; }
};
template  using g = int;
template  struct h {};
template 
using i
#if a
= __make_integer_seq
#else
= h
#endif
;
template  void ae(j f, h) {
  (f(d{}), ...);
}
template  void af(j f) {
  using ac = g;
  using l = i;
  ae(f, l{});
}
template  using o = d;
template  struct t {
  j f;
  template  void operator()(u) { f(o{}); }
};
template  void ai(j f) {
  auto aj = t{f};
  af(aj);
}
enum q {};
constexpr int p(q) { return 2; }
enum r { s };
template  struct C;
template  int ak(int const &);
template  typename,
  template  typename al>
void am() {
  ai([](auto an) {
auto ao = decltype(an)();
[ao](auto ad) {
  using u = decltype(ad);
  if constexpr (al::ap)
;
};
  });
}
template  struct D;
template <> int ak(int const &) { am; }

[Bug tree-optimization/92710] New: [9/10 Regression] Vectoriser generates invalid simd call for bool arguments

[rsandifo at gcc dot gnu.org]

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

Bug ID: 92710
   Summary: [9/10 Regression] Vectoriser generates invalid simd
call for bool arguments
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rsandifo at gcc dot gnu.org
  Target Milestone: ---
Target: aarch64*-*-*

#pragma omp declare simd
bool foo (bool) __attribute__((const));

void
f (bool *__restrict x, char *__restrict y, char *__restrict z)
{
  for (int i = 0; i < 128; ++i)
x[i] = foo (y[i] == z[i]);
}

compiled with g++ -O3 -fopenmp-simd ICEs with:

foo.c: In function ‘void f(bool*, char*, char*)’:
foo.c:5:1: error: invalid conversion in gimple call
5 | f (bool *__restrict x, char *__restrict y, char *__restrict z)
  | ^
vector(16) unsigned char

vector(16) bool

vect__14.10_9 = _Z3foob.simdclone.2 (mask__6.9_17);
during GIMPLE pass: vect
foo.c:5:1: internal compiler error: verify_gimple failed
0x150013e verify_gimple_in_cfg(function*, bool)
.../tree-cfg.c:5386
0x12b3cf7 execute_function_todo
.../passes.c:1997
0x12b2c75 do_per_function
.../passes.c:1638
0x12b3ee7 execute_todo
.../passes.c:2051
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

This is because we use a vector mask type for the result of the
comparison, but the function expects a normal nonmask vector instead.

The bug doesn't trigger on x86_64 because there the bool argument
is promoted to int.

[Bug tree-optimization/92710] [9/10 Regression] Vectoriser generates invalid simd call for bool arguments

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-11-28
   Assignee|unassigned at gcc dot gnu.org  |rsandifo at gcc dot 
gnu.org
   Target Milestone|--- |9.3
 Ever confirmed|0   |1

--- Comment #1 from rsandifo at gcc dot gnu.org  
---
I have a fix.

[Bug ipa/92697] IPA-SRA modifies ifunc_resolvers

[jamborm at gcc dot gnu.org]

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

--- Comment #2 from Martin Jambor  ---
Author: jamborm
Date: Thu Nov 28 15:39:48 2019
New Revision: 278812

URL: https://gcc.gnu.org/viewcvs?rev=278812&root=gcc&view=rev
Log:
cgraph: ifunc resolvers cannot be made local (PR 92697)

2019-11-28  Martin Jambor  

PR ipa/92697
* cgraph.c (cgraph_node_cannot_be_local_p_1): Return true for
ifunc_resolvers.
* symtab.c (symtab_node::dump_base): Dump ifunc_resolver flag.
Removed trailig whitespace.

testsuite/
* g++.dg/ipa/pr92697.C: New.


Added:
trunk/gcc/testsuite/g++.dg/ipa/pr92697.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/cgraph.c
trunk/gcc/symtab.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/92711] New: GCC 10 libxul.so -fprofile-generate binary is 360MB while clang needs only 163MB.

[hubicka at gcc dot gnu.org]

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

Bug ID: 92711
   Summary: GCC 10 libxul.so -fprofile-generate binary is 360MB
while clang needs only 163MB.
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hubicka at gcc dot gnu.org
  Target Milestone: ---

It seems that profiling became more expensive in GCC10 compared to clang or
previous GCC releases.
Clang binary is here
https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/H_iSouCVTha9mEw9y5XO5Q/runs/0/artifacts/public/build/target.tar.bz2
more or less comparable GCC build is here 
https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/NOUqVShcSMaJn5j3g5nEYg/runs/0/artifacts/public/build/target.tar.bz2
It also seems that profile streaming is slower in GCC build (which is important
since Firefox forks multiple times on startup and then when creating new tab
and that triggers profile data streamout).

[Bug rtl-optimization/92712] New: Performance regression with assumed values

[mike.k at digitalcarbide dot com]

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

Bug ID: 92712
   Summary: Performance regression with assumed values
   Product: gcc
   Version: 9.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mike.k at digitalcarbide dot com
  Target Milestone: ---

The following code generates progressively worse code from GCC 7.5 to GCC 8.3
to GCC 9.1 (and trunk):

static void func_base(int t, const int v) {
int x = 0;
for (int i = 0; i < t; ++i) {
x += v;
}
volatile int d = x;
}

void func_default(int t, const int v) {
func_base(t, v);
}

void func_assumed(int t, const int v) {
if (t < 0) __builtin_unreachable();
func_base(t, v);
}

On GCC 7.5 (-O2):

func_default(int, int):
  test edi, edi
  jle .L3
  imul edi, esi
  mov DWORD PTR [rsp-4], edi
  ret
.L3:
  xor edi, edi
  mov DWORD PTR [rsp-4], edi
  ret
func_assumed(int, int):
  imul edi, esi
  mov DWORD PTR [rsp-4], edi
  ret

On GCC 8.3 (-O2):

func_default(int, int):
  test edi, edi
  jle .L3
  imul edi, esi
  mov DWORD PTR [rsp-4], edi
  ret
.L3:
  xor edi, edi
  mov DWORD PTR [rsp-4], edi
  ret
func_assumed(int, int):
  test edi, edi
  je .L6
  imul edi, esi
.L6:
  mov DWORD PTR [rsp-4], edi
  ret

On GCC 9.1 and trunk (-O2):

func_default(int, int):
  test edi, edi
  jle .L3
  sub edi, 1
  imul edi, esi
  add esi, edi
  mov DWORD PTR [rsp-4], esi
  ret
.L3:
  xor esi, esi
  mov DWORD PTR [rsp-4], esi
  ret
func_assumed(int, int):
  test edi, edi
  je .L6
  sub edi, 1
  imul edi, esi
  add edi, esi
.L6:
  mov DWORD PTR [rsp-4], edi
  ret

This occurs regardless of if `func_base` is allowed to inline, or if it is
manually inlined.

It does not occur in LLVM-Clang or in Microsoft Visual C++.

[Bug tree-optimization/92711] GCC 10 libxul.so -fprofile-generate binary is 360MB while clang needs only 163MB.

[hubicka at gcc dot gnu.org]

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

--- Comment #1 from Jan Hubicka  ---
https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/ObkoHsHHSriQdU0Twc12Wg/runs/0/artifacts/public/build/target.tar.bz2
This is GCC9 build. 310MB, so still a lot bigger than clang, but better than
gcc10.

[Bug target/92190] [10 Regression] ICE in sp_valid_at, at config/i386/i386.c:6162 since r276648

[rsandifo at gcc dot gnu.org]

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

--- Comment #12 from rsandifo at gcc dot gnu.org  
---
Sorry, I was wrong in comment 10.  I'd forgotten that the original
point of all this was that, without the clobber, -fipa-ra would
assume that the register isn't clobbered at all.  The RA could
then try to keep even a 256-bit value across a call.  Something
has to indicate that at least the upper bits of the register are
clobbered.

The choice of which registers we save and which we don't should
be final after RA.  So if we're trying to recompute that set
later then perhaps the fix is to stop doing that.

(In reply to Jakub Jelinek from comment #11)
> Is CLOBBER the right representation of what vzeroupper does anyway?
> I mean, for AVX512F+, shouldn't it be
> (set (reg:V8DI xmm0) (vec_merge:V8DI (reg:V8DI xmm0) (const_vector:V8DI 0)
> (const_int 3)))
> ...
> and similarly for AVX/AVX2 (in that case V4DI instead of V8DI)?

We use clobbers for registers that aren't live at that point and
sets for registers that are.  Using sets unconditionally makes
the register live on input and so leaves them upwards-exposed.

[Bug tree-optimization/92711] GCC 10 libxul.so -fprofile-generate binary is 360MB while clang needs only 163MB.

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

 CC||mliska at suse dot cz
 Blocks||45375

--- Comment #2 from Jan Hubicka  ---
Actually what I thought is GCC9 build is actually GCC10 build.  Seems that
today profile fixes made the binary noticeably smaller which seems promising.
But it is still very large.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
[Bug 45375] [meta-bug] Issues with building Mozilla (i.e. Firefox) with LTO

[Bug c++/88335] Implement P1073R3, C++20 immediate functions (consteval).

[jakub at gcc dot gnu.org]

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

--- Comment #14 from Jakub Jelinek  ---
I think we should remove the __cpp_consteval define until we implement virtual
consteval and should also mention in cxx-status.html that it is only partially
implemented.

I've tried to play with the virtual consteval support, but am stuck.

First, some testcases I've been playing with:
One for diagnostics:
struct S {
  virtual int foo () { return 42; } // { dg-message "overridden
function is 'virtual consteval int S::foo\\\(\\\)'" }
  consteval virtual int bar () { return 43; }   // { dg-message "overridden
function is 'virtual consteval int S::bar\\\(\\\)'" }
};
struct T : public S {
  int bar () { return 44; } // { dg-error "non-'consteval' function
'virtual int T::bar\\\(\\\)' overriding 'consteval' function" }
};
struct U : public S {
  consteval virtual int foo () { return 45; }   // { dg-error "'consteval'
function 'virtual consteval int U::foo\\\(\\\)' overriding non-'consteval'
function" }
};
And the main one:
struct S {
  constexpr S () : s (0) {}
  virtual int foo () const { return 42; }
  consteval virtual int bar () const { return 43; }
  consteval virtual int baz () const { return 44; }
  int s;
};
struct T : public S {
  constexpr T () : t (0) {}
  consteval int bar () const { return 45; }
  consteval virtual int baz () const { return 46; }
  int t;
};
struct U : public T {
  typedef int bar;
  typedef int baz;
};

consteval int
foo ()
{
  S s;
  T t;
  U u;
  S *v = (S *) &t;
  S *w = (S *) &u;
  if (s.bar () != 43) throw 1;
  if (s.baz () != 44) throw 2;
  if (t.bar () != 45) throw 3;
  if (t.baz () != 46) throw 4;
  if (v->bar () != 45) throw 5;
  if (v->baz () != 46) throw 6;
  if (w->bar () != 45) throw 7;
  if (w->baz () != 46) throw 8;
  if (t.S::bar () != 43) throw 9;
  if (t.T::baz () != 46) throw 10;
  if (v->S::bar () != 43) throw 11;
  if (w->S::baz () != 44) throw 12;
  return 0;
}

constexpr S s;
constexpr T t;

constexpr const S *
bar (bool x)
{
  return x ? &s : (const S *) &t;
}

int a = foo ();
int b = bar (false)->bar ();
int c = bar (true)->baz ();
static_assert (bar (false)->bar () == 45);
static_assert (bar (true)->baz () == 44);

Now, the issues:
1) (so far ignored); the standard says that classes where all virtual members
are immediate are still polymorphic,
   but I guess for the ABI we don't want a vtable pointer there.  So, I think
we want TYPE_POLYMORPHIC_P set on
   those, but e.g. TYPE_CONTAINS_VPTR_P probably shouldn't be true for them; do
we want TYPE_REALLY_POLYMORPHIC_P or
   similar for polymorphic types that contain at least one non-immediate
virtual function and thus need a vtable?
2) initially I thought I'd just always emit a direct call to the immediate
virtual method found by lookup and do the
   remapping of that during constexpr call evaluation; unfortunately as the
v->S::bar () etc. calls show, we only want
   to do that if LOOKUP_NONVIRTUAL wasn't set; unfortunately, when immediate
functions aren't in the binfo structures,
   DECL_VINDEX is error_mark_node and so I think we need some hack how to
preserve the info that we are going to
   call a virtual consteval method; could we e.g. abuse OBJ_TYPE_REF with
different arguments that would make it
   clear it is something different, or new tree?  We need to store the instance
on which it is called and the virtual
   consteval method originally chosen e.g. to compare the type
3) I'm afraid one can't use a lookup_member on the actual instance type,
because it could find all kinds of things,
   static member functions, typedefs, data members etc. in derived classes,
where we actually are only interested in
   in virtual methods.  So, shall we use something like look_for_overrides
does, except with the fndecl from the
   base rather than derived and of course don't do anything except return the
first found method (and ignore static member
   functions rather than handling them)?
4) guess covariant returns need to be handled at the end too somehow

Current WIP patch (though as mentioned in 2), in build_over_call we probably
just need some way note that it needs to be a virtual consteval call and
evaluate that only during constexpr evaluation):
--- gcc/cp/call.c.jj2019-11-28 09:02:26.953819534 +0100
+++ gcc/cp/call.c   2019-11-28 18:18:31.646444362 +0100
@@ -8369,6 +8369,7 @@ build_over_call (struct z_candidate *can
current_function_returns_abnormally = 1;
   if (TREE_CODE (fn) == FUNCTION_DECL
  && DECL_IMMEDIATE_FUNCTION_P (fn)
+ && !DECL_VINDEX (fn)
  && (current_function_decl == NULL_TREE
  || !DECL_IMMEDIATE_FUNCTION_P (current_function_decl))
  && (current_binding_level->kind != sk_function_parms
@@ -8962,7 +8963,40 @@ build_over_call (struct z_candidate *can
   && DECL_BUILT_IN_CLASS (fn) == BUILT_IN_NORMAL)
 maybe_warn_class_memaccess (input_location, fn, args);

-  if (DECL_VINDEX (fn) && (flags & LOOKUP_NONVIRTUAL) == 0)

[Bug target/92713] New: ICE in libsupc++ building an offload compiler targeting amdgcn-unknown-amdhsa

[doko at debian dot org]

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

Bug ID: 92713
   Summary: ICE in libsupc++ building an offload compiler
targeting amdgcn-unknown-amdhsa
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doko at debian dot org
  Target Milestone: ---

seen with trunk 20191128, building an offload compiler targeting
amdgcn-unknown-amdhsa:

during RTL pass: jump
error: Segmentation fault
  731 | }
  | ^
0xb1ef1f crash_signal
../../src/gcc/toplev.c:328
0x7fb91d05b0ff ???
   
/build/glibc-suXNNi/glibc-2.29/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0
0xfc40fc count_reg_usage
../../src/gcc/cse.c:6838
0xfc4024 count_reg_usage
../../src/gcc/cse.c:6879
0xfc947b delete_trivially_dead_insns(rtx_insn*, int)
../../src/gcc/cse.c:7104
0xfa5026 execute
../../src/gcc/cfgcleanup.c:3268
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
The bug is not reproducible, so it is likely a hardware or OS problem.
make[6]: *** [Makefile:761: eh_personality.lo] Error 1

it's reproducible, but failing to build a preprocessed source on retry.

[Bug tree-optimization/92677] [10 Regression] ICE in get_group_load_store_type, at tree-vect-stmts.c:2261 since r271704

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

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

--- Comment #1 from rsandifo at gcc dot gnu.org  
---
Testing a patch.

[Bug libfortran/90374] Fortran 2018: Support d0.d, e0.d, es0.d, en0.d, g0.d and ew.d e0 edit descriptors for output

[jvdelisle at gcc dot gnu.org]

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

--- Comment #5 from Jerry DeLisle  ---
Author: jvdelisle
Date: Thu Nov 28 18:33:20 2019
New Revision: 278817

URL: https://gcc.gnu.org/viewcvs?rev=278817&root=gcc&view=rev
Log:
PR fortran/90374
* io.c (check_format): Allow zero width expoenent with e0.

* io/format.c (parse_format_list): Relax format checking to allow
e0 exponent specifier.

* gfortran.dg/fmt_zero_width.f90: Update test.

Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/io.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/fmt_zero_width.f90
trunk/libgfortran/ChangeLog
trunk/libgfortran/io/format.c
trunk/libgfortran/io/write_float.def

[Bug c++/92714] New: [missed-optimization] aggregate initialization of an array fills the whole array with zeros first, including non-zero elements

[lassie.darkorbit at gmail dot com]

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

Bug ID: 92714
   Summary: [missed-optimization] aggregate initialization of an
array fills the whole array with zeros first,
including non-zero elements
   Product: gcc
   Version: 8.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lassie.darkorbit at gmail dot com
  Target Milestone: ---

void *sink;
void bar() {
int a[100]{1,2,3,4};
sink = a; // a escapes the function
asm("":::"memory");   // and compiler memory barrier
// forces the compiler to materialize a[] in memory instead of optimizing
away
}

gcc 8.1 and gcc 9.2 both make asm like this (even with -O3):

bar():
pushedi   # save call-preserved EDI which rep stos
uses
xor eax, eax  # eax=0
mov ecx, 100  # repeat-count = 100
sub esp, 400  # reserve 400 bytes on the stack
mov edi, esp  # dst for rep stos
mov DWORD PTR sink, esp   # sink = a
rep stosd # memset(a, 0, 400) 

mov DWORD PTR [esp], 1# then store the non-zero initializers
mov DWORD PTR [esp+4], 2  # over the zeroed part of the array
mov DWORD PTR [esp+8], 3
mov DWORD PTR [esp+12], 4

add esp, 400  # cleanup the stack
pop edi   # and restore caller's EDI
ret

[Bug tree-optimization/92711] GCC 10 libxul.so -fprofile-generate binary is 360MB while clang needs only 163MB.

[hubicka at gcc dot gnu.org]

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

--- Comment #3 from Jan Hubicka  ---
Proper GCC 9 -fprofile-generate build is 296MB
https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/aMGsffWPQ1qzjgj4LIqcwQ/runs/0/artifacts/public/build/target.tar.bz2
So about 5% regression compared to gcc9

[Bug libstdc++/91997] pretty printers: The __node_type type alias in _Hashtable is not available

[rafael at espindo dot la]

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

--- Comment #3 from Rafael Avila de Espindola  ---
(In reply to Jonathan Wakely from comment #2)
> Rafael, I'm unable to reproduce this with unordered containers. Do you have
> a testcase?

I was able to reproduce it with 2 files:

$ cat test.cc
#include 
void foo(std::unordered_map &map);
int main() {
  std::unordered_map map;
  map[42] = 1;
  foo(map);
  return 0;
}
$ cat test2.cc
#include 
#include 
void foo(std::unordered_map &map) {
  auto it = map.begin();
  printf("%d\n", *it);
}
$ g++ test.cc test2.cc -o t -g
$ /usr/bin/gdb -q -ex "b printf" -ex r -ex bt ./t
Reading symbols from ./t...
Breakpoint 1 at 0x204b10
Starting program: /home/espindola/scylla/t
warning: Loadable section ".note.gnu.property" outside of ELF segments
warning: Loadable section ".note.gnu.property" outside of ELF segments
warning: Loadable section ".note.gnu.property" outside of ELF segments

Breakpoint 1, __printf (format=0x20081b "%d\n") at printf.c:28
28  {
#0  __printf (format=0x20081b "%d\n") at printf.c:28
#1  0x0020494a in foo (Traceback (most recent call last):
  File "/lib64/../share/gcc-9/python/libstdcxx/v6/printers.py", line 957, in
children
data = self.flatten (imap (self.format_one, StdHashtableIterator
(self.hashtable(
  File "/lib64/../share/gcc-9/python/libstdcxx/v6/printers.py", line 880, in
__init__
self.node_type = find_type(hash.type, '__node_type').pointer()
  File "/lib64/../share/gcc-9/python/libstdcxx/v6/printers.py", line 97, in
find_type
field = typ.fields()[0]
IndexError: list index out of range
map=
std::unordered_map with 1 element) at test2.cc:5
#2  0x00203017 in main () at test.cc:6

[Bug c++/89640] [9 Regression] g++ chokes on lambda with __attribute__

[frankhb1989 at gmail dot com]

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

--- Comment #9 from frankhb1989 at gmail dot com ---
This seems still problematic.

void test1() {
[]() __attribute__((noreturn)) noexcept [[]] -> int{
return 0; // Warning expected.
}();
}

void test2() {
[]() noexcept [[]] __attribute__((noreturn)) -> int{
return 0; // Warning expected.
}();
}

Clang++ 9 accepts test1 but not test2. (However, it issues an error instead of
a warning.) Both fail in trunk G++.
Are they expected work?

[Bug c++/92715] New: error: position plus size exceeds size of referenced object in ‘bit_field_ref’

[dcb314 at hotmail dot com]

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

Bug ID: 92715
   Summary: error: position plus size exceeds size of referenced
object in  ‘bit_field_ref’
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

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

For the attached C++ source code, compiled by recent gcc trunk
and compiler flag -O3 -march=native, does this:

/home/dcb/gcc/results.278750/bin/g++
/home/dcb/gcc/results.278800/bin/g++
/home/dcb30/rpmbuild/BUILD/ompl-1.3.2-Source/src/ompl/geometric/planners/rrt/src
/VFRRT.cpp: In member function ‘Eigen::VectorXd
ompl::geometric::VFRRT::getNewDi
rection(const ompl::base::State*, const ompl::base::State*)’:
/home/dcb30/rpmbuild/BUILD/ompl-1.3.2-Source/src/ompl/geometric/planners/rrt/src
/VFRRT.cpp:93:17: error: position plus size exceeds size of referenced object
in
 ‘bit_field_ref’
   93 | Eigen::VectorXd ompl::geometric::VFRRT::getNewDirection(const
base::Stat
e *qnear, const base::State *qrand)
  | ^~~~
_69 = BIT_FIELD_REF <_67, 256, 0>;
during GIMPLE pass: forwprop
/home/dcb30/rpmbuild/BUILD/ompl-1.3.2-Source/src/ompl/geometric/planners/rrt/src
/VFRRT.cpp:93:17: internal compiler error: verify_gimple failed
0x1155fc9 verify_gimple_in_cfg(function*, bool)
../../trunk/gcc/tree-cfg.c:5445
0x1004a5f execute_function_todo
../../trunk/gcc/passes.c:1983
0x1005e11 do_per_function
../../trunk/gcc/passes.c:1638
0x1005e11 execute_todo
../../trunk/gcc/passes.c:2037

The bug seems to start sometime between revision 278750 and 278800.
/proc/cpuinfo says:

cpu family  : 21
model   : 2
model name  : AMD FX(tm)-8350 Eight-Core Processor
stepping: 0

I'll have my usual go at reducing the code.

[Bug bootstrap/92709] Cross Compilation failed for Latest GCC riscv64-linux-gnu on Linux/WSL2

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords|accepts-invalid |build
 Target||riscv64-linux-gnu
 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2019-11-28
  Component|libgcc  |bootstrap
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
The actual error is missing from the log.

[Bug bootstrap/92709] Cross Compilation failed for Latest GCC riscv64-linux-gnu on Linux/WSL2

[euloanty at live dot com]

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

--- Comment #2 from fdlbxtqi  ---
(In reply to Richard Biener from comment #1)
> The actual error is missing from the log.

Yea. It has no actual error. I have checked that.

[Bug tree-optimization/92711] GCC 10 libxul.so -fprofile-generate binary is 360MB while clang needs only 163MB.

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization

--- Comment #4 from Richard Biener  ---
Less early inlining causes more instrumentation?  You'd see the same for
tramp3d I guess.

[Bug libfortran/90374] Fortran 2018: Support d0.d, e0.d, es0.d, en0.d, g0.d and ew.d e0 edit descriptors for output

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 CC||anlauf at gcc dot gnu.org

--- Comment #6 from anlauf at gcc dot gnu.org ---
(In reply to Jerry DeLisle from comment #5)
> Author: jvdelisle
> Date: Thu Nov 28 18:33:20 2019
> New Revision: 278817

Jerry,

your change to format.c generates a warning here:

../../../trunk/libgfortran/io/format.c: In function 'parse_format_list':
../../../trunk/libgfortran/io/format.c:1029:7: warning: suggest explicit braces
to avoid am
biguous 'else' [-Wdangling-else]
 1029 |if (t != FMT_POSINT)
  |   ^

Looking at the context:

  t = format_lex (fmt);
  if (t != FMT_POSINT)
if (t == FMT_ZERO)
  {

this seems to make sense (to me).  Do you plan to add {}?

[Bug rtl-optimization/92712] [8/9/10 Regression] Performance regression with assumed values

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Known to work||7.5.0
   Keywords||missed-optimization
   Last reconfirmed||2019-11-28
 CC||rguenth at gcc dot gnu.org
 Ever confirmed|0   |1
Summary|Performance regression with |[8/9/10 Regression]
   |assumed values  |Performance regression with
   ||assumed values
   Target Milestone|--- |8.4
  Known to fail||9.2.0

--- Comment #1 from Richard Biener  ---
This is final value replacement becoming more correct wrt undefined overflow I
guess.

final value replacement:
  x_6 = PHI 
 with expr: (const int) ((unsigned int) t_1(D) + 4294967295) * v_3(D) + v_3(D)
 final stmt:
  x_6 = _14 + v_3(D);

Here we fail to optimize (t - 1)*v + v to t * v.  Not sure how the t >= 0
assert helped but we likely get rid of that earlier and earlier.

[Bug middle-end/92714] [missed-optimization] aggregate initialization of an array fills the whole array with zeros first, including leading non-zero elements

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-11-28
 CC||law at gcc dot gnu.org
Summary|[missed-optimization]   |[missed-optimization]
   |aggregate initialization of |aggregate initialization of
   |an array fills the whole|an array fills the whole
   |array with zeros first, |array with zeros first,
   |including non-zero elements |including leading non-zero
   ||elements
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
It's actually an optimization - it's cheaper to clear the whole object if most
of it is zero.  What we miss is to notice the special-case of only the tail
being zeros.

Jeff added memset pruning to DSE but this case has

   [local count: 1073741824]:
  a = {};
  MEM  [(int *)&a] = 8589934593;
  MEM  [(int *)&a + 8B] = 17179869187;
  sink = &a;

the other obvious place to fix it is in the gimplifier of course which
creates the above code in the first place.

The same issue happens with

void *sink;
void bar() {
int a[100] = { [96]=1,2,3,4};
sink = a; // a escapes the function
asm("":::"memory");   // and compiler memory barrier
// forces the compiler to materialize a[] in memory instead of optimizing
away
}

or

void *sink;
void bar() {
int a[100] = { 1,2,3,4,[96]=1,2,3,4};
sink = a; // a escapes the function
asm("":::"memory");   // and compiler memory barrier
// forces the compiler to materialize a[] in memory instead of optimizing
away
}

though the trailing zeros are probably the most common case.

[Bug target/92047] [10 regression] aarch64 regressions after r276645

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
I actually did.  Is it fixed?

[Bug tree-optimization/92715] [10 Regression] error: position plus size exceeds size of referenced object in ‘bit_field_ref’

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||needs-reduction
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-11-28
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
   Target Milestone|--- |10.0
Summary|error: position plus size   |[10 Regression] error:
   |exceeds size of referenced  |position plus size exceeds
   |object in  ‘bit_field_ref’  |size of referenced object
   ||in  ‘bit_field_ref’
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Mine I'm sure.  That CPU is bdver[234], right?

[Bug libstdc++/91997] pretty printers: The __node_type type alias in _Hashtable is not available

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
Thanks, I can confirm that error. Oddly, it works fine when printing the
variable within its own stack frame:

$ gdb -q -ex "br printf" -ex r -ex up -ex bt -ex down -ex bt -ex cont -ex q 
map
Reading symbols from map...
Breakpoint 1 at 0x401030
Starting program: /tmp/map 

Breakpoint 1, __printf (format=0x403007 "%d\n") at printf.c:28
28  {
#1  0x00401272 in foo (map=std::unordered_map with 1 element = {...})
at map.cc:16
16__builtin_printf("%d\n", *it);
#0  __printf (format=0x403007 "%d\n") at printf.c:28
#1  0x00401272 in foo (map=std::unordered_map with 1 element = {...})
at map.cc:16
#2  0x00401203 in main () at map.cc:9
#0  __printf (format=0x403007 "%d\n") at printf.c:28
28  {
#0  __printf (format=0x403007 "%d\n") at printf.c:28
#1  0x00401272 in foo (Python Exception  No type
named std::__detail::_Hash_node, false>.: 
map=std::unordered_map with 1 element) at map.cc:16
#2  0x00401203 in main () at map.cc:9
Continuing.
42
[Inferior 1 (process 679052) exited normally]

It fails when it's not at the top of the stack.

[Bug libstdc++/91997] pretty printers: The __node_type type alias in _Hashtable is not available

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #4)
> #1  0x00401272 in foo (Python Exception  No type
> named std::__detail::_Hash_node, false>.: 

N.B. That's a different error because I'm testing a fix. Apparently it doesn't
fix it.

[Bug tree-optimization/92715] [10 Regression] error: position plus size exceeds size of referenced object in ‘bit_field_ref’

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #2 from Martin Liška  ---
Confirmed, I see the same for a polyhedron benchmark.
Started with r278758. I'm going to reduce the Fortran test-case.

[Bug c/92716] New: -Os doesn't inline byteswap function even though it's a single instruction

[jwerner at chromium dot org]

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

Bug ID: 92716
   Summary: -Os doesn't inline byteswap function even though it's
a single instruction
   Product: gcc
   Version: 8.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jwerner at chromium dot org
  Target Milestone: ---

I compiled the following test code for both x86_64 and aarch64 on gcc 8.3.0:

static inline unsigned int byteswap(unsigned int x) 
{   
return (((x >> 24) & 0xff) << 0) |  
   (((x >> 16) & 0xff) << 8) |  
   (((x >> 8) & 0xff) << 16) |  
   (((x >> 0) & 0xff) << 24);   
}   

unsigned int test(unsigned int a, unsigned int b, unsigned int c) { 
return byteswap(a) + byteswap(b) + byteswap(c); 
}

On x86_64 I get:

  (File Offset: 0x40):
   0:   89 f8   mov%edi,%eax
   2:   0f c8   bswap  %eax
   4:   c3  retq   

0005  (File Offset: 0x45):
   5:   e8 f6 ff ff ff  callq  0  (File Offset: 0x40)
   a:   89 f7   mov%esi,%edi
   c:   89 c1   mov%eax,%ecx
   e:   e8 ed ff ff ff  callq  0  (File Offset: 0x40)
  13:   89 d7   mov%edx,%edi
  15:   01 c1   add%eax,%ecx
  17:   e8 e4 ff ff ff  callq  0  (File Offset: 0x40)
  1c:   01 c8   add%ecx,%eax
  1e:   c3  retq   

And on aarch64 I get:

  (File Offset: 0x40):
   0:   5ac00800rev w0, w0
   4:   d65f03c0ret

0008  (File Offset: 0x48):
   8:   a9bf7bfdstp x29, x30, [sp,#-16]!
   c:   910003fdmov x29, sp
  10:   97fcbl  0  (File Offset: 0x40)
  14:   2a0003e3mov w3, w0
  18:   2a0103e0mov w0, w1
  1c:   97f9bl  0  (File Offset: 0x40)
  20:   0b63add w3, w3, w0
  24:   2a0203e0mov w0, w2
  28:   97f6bl  0  (File Offset: 0x40)
  2c:   0b60add w0, w3, w0
  30:   a8c17bfdldp x29, x30, [sp],#16
  34:   d65f03c0ret

So the good news is that GCC recognized this code as a byteswap function that
can be implemented with a single instruction on both of these platforms. The
bad news is that it then doesn't seem to realize that inlining this single
instruction leads to smaller code size than wrapping it in a function and
calling it, even if it is called many times. If I instead compile with -O2, the
function is inlined as expected. (I also tried with clang 8.0.1 which manages
to inline correctly even with -Os.)

[Bug tree-optimization/92715] [10 Regression] error: position plus size exceeds size of referenced object in ‘bit_field_ref’

[dcb314 at hotmail dot com]

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

--- Comment #3 from David Binderman  ---
(In reply to Richard Biener from comment #1)
> That CPU is bdver[234], right?

Not sure. Piledriver certainly. 

I tried setting -march to each of bdver[234] and the problem still exists.

[Bug c/92716] -Os doesn't inline byteswap function even though it's a single instruction

[jwerner at chromium dot org]

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

--- Comment #1 from Julius Werner  ---
edit: Just noticed that when I implement it as

static inline unsigned int byteswap(unsigned int x) 
{   
return __builtin_bswap32(x);
}

instead, it is still compiled into the same single instruction, but then the
inlining works even with -Os. So I guess the decision to inline is made too
early in the optimization pipeline or something?

[Bug tree-optimization/92715] [10 Regression] error: position plus size exceeds size of referenced object in ‘bit_field_ref’

[marxin at gcc dot gnu.org]

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

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

Fails with:

$ gfortran -O3 -march=znver2 mdbx.f90
mdbx.f90:9:16:

9 |   PARAMETER NM=16384
  |1
Warning: Legacy Extension: PARAMETER without '()' at (1)
mdbx.f90:12:18:

   12 |  DO j = 1,HD0 (i)
  |  1
Warning: Deleted feature: End expression in DO loop at (1) must be integer
mdbx.f90:18:16:

   18 |   DO i = 1 , X0
  |1
Warning: Deleted feature: End expression in DO loop at (1) must be integer
mdbx.f90:7:0:

7 |   SUBROUTINE MSTEP
  | 
Error: position plus size exceeds size of referenced object in ‘bit_field_ref’
_13 = BIT_FIELD_REF <_68, 256, 0>;
during GIMPLE pass: forwprop
mdbx.f90:7:0: internal compiler error: verify_gimple failed
0xe9f031 verify_gimple_in_cfg(function*, bool)
/home/marxin/Programming/gcc/gcc/tree-cfg.c:5445
0xd7a3ef execute_function_todo
/home/marxin/Programming/gcc/gcc/passes.c:1983
0xd7b19e execute_todo
/home/marxin/Programming/gcc/gcc/passes.c:2037
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/92716] -Os doesn't inline byteswap function even though it's a single instruction

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
Most likely what is happening is the following:
inlining happens twice but the detection of bswap does not happen until after
both inlining so the cost huestric for byteswap function is high.

[Bug tree-optimization/92716] -Os doesn't inline byteswap function even though it's a single instruction

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-11-28
  Component|c   |tree-optimization
 Ever confirmed|0   |1
   Severity|normal  |enhancement

--- Comment #3 from Andrew Pinski  ---
>So I guess the decision to inline is made too early in the optimization 
>pipeline or something?

Or not optimizations before the second inliner.

[Bug c++/92717] New: precompiled headers non-deterministic

[gnu.org at mrks dot info]

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

Bug ID: 92717
   Summary: precompiled headers non-deterministic
   Product: gcc
   Version: 9.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gnu.org at mrks dot info
  Target Milestone: ---

I found that introducing precompiled headers to my project causes ccache
lookups to fail. I tracked it down to the gcc output not being deterministic:

# /usr/bin/c++ -x c++-header -include test.hxx -o test.hxx.gch -c test.hxx.cxx
&& md5sum test.hxx.gch
3a0efb998351939f4ed8efcfce1c0015  test.hxx.gch
# /usr/bin/c++ -x c++-header -include test.hxx -o test.hxx.gch -c test.hxx.cxx
&& md5sum test.hxx.gch
d295cbe3613100e6d989e62e3aafad6c  test.hxx.gch

Both test.hxx and test.hxx.cxx are empty. The used gcc version is
9.2.1-9ubuntu2.

With clang (clang++ -cc1 test.hxx -emit-pch -o test.hxx.pch), the hashes match.

When compiling with save-temps, the ii and s files match.

As builds of regular C(++) files are deterministic (as expected), I suspect
that this might be a bug.

[Bug ipa/92609] [10 Regression] ICE in warn_types_mismatch, at ipa-devirt.c:1000 since r265519

[marxin at gcc dot gnu.org]

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

--- Comment #3 from Martin Liška  ---
Author: marxin
Date: Thu Nov 28 20:56:23 2019
New Revision: 278819

URL: https://gcc.gnu.org/viewcvs?rev=278819&root=gcc&view=rev
Log:
Properly use TYPE_MAIN_VARIANT in warn_types_mismatch.

2019-11-28  Martin Liska  

PR lto/92609
* ipa-devirt.c (warn_types_mismatch): Use TYPE_MAIN_VARIANT
consistently.
2019-11-28  Martin Liska  

PR lto/92609
* g++.dg/lto/pr92609_0.C: New test.
* g++.dg/lto/pr92609_1.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/lto/pr92609_0.C
trunk/gcc/testsuite/g++.dg/lto/pr92609_1.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/ipa-devirt.c
trunk/gcc/testsuite/ChangeLog

[Bug debug/46558] dbgcnt.c messages not marked for translation

[marxin at gcc dot gnu.org]

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

--- Comment #5 from Martin Liška  ---
Author: marxin
Date: Thu Nov 28 20:56:51 2019
New Revision: 278820

URL: https://gcc.gnu.org/viewcvs?rev=278820&root=gcc&view=rev
Log:
Translate header for -fdbg-cnt-list.

2019-11-28  Martin Liska  

PR debug/46558
* dbgcnt.c (dbg_cnt_list_all_counters): Mark table
headers for translation.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/dbgcnt.c

[Bug ipa/92609] [10 Regression] ICE in warn_types_mismatch, at ipa-devirt.c:1000 since r265519

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #4 from Martin Liška  ---
Fixed.

[Bug debug/46558] dbgcnt.c messages not marked for translation

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #6 from Martin Liška  ---
Fixed.

[Bug translation/40883] [meta-bug] Translation breakage with trivial fixes

[marxin at gcc dot gnu.org]

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

Bug 46558 Summary: dbgcnt.c messages not marked for translation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46558

   What|Removed |Added

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

[Bug c++/92717] precompiled headers non-deterministic

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
I don't think this is a bug, __DATE__ is one of the predefined macros and I
think it is included in GCC's precompiled headers.

Really ccache is broken anyways.

>As builds of regular C(++) files are deterministic (as expected)

Try using __DATE__ macro and you will see it is not :).

[Bug c++/92717] precompiled headers non-deterministic

[gnu.org at mrks dot info]

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

--- Comment #2 from Markus Dreseler  ---
> Try using __DATE__ macro and you will see it is not :).

Can't confirm:

# /usr/bin/c++ -D__DATE__=0 -D__TIMESTAMP__=0 -D__TIME__=0 -x c++-header
-include test.hxx -o test.hxx.gch -c test.hxx.cxx && md5sum test.hxx.gch

produces some new warnings, but again different file hashes.

Here are some other options that I have tested but that have no effect:
* SOURCE_DATE_EPOCH=0
* -fno-pie
* -nodefaultlibs -nostartfiles -nostdlib

[Bug c++/92717] precompiled headers non-deterministic

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
By any chance, is your cc1plus built as PIE?  PCH doesn't work in that case.

[Bug c++/92717] precompiled headers non-deterministic

[gnu.org at mrks dot info]

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

--- Comment #4 from Markus Dreseler  ---
> By any chance, is your cc1plus built as PIE?  PCH doesn't work in that case.

I don't think so:

# file `find /usr -name cc1plus`
/usr/lib/gcc/x86_64-linux-gnu/9/cc1plus: ELF 64-bit LSB executable, x86-64,
version 1 (GNU/Linux), dynamically linked, interpreter
/lib64/ld-linux-x86-64.so.2,
BuildID[sha1]=ab2940b3dc6bbacbb2b3f15e7cdcdd416e74b3b8, for GNU/Linux 3.2.0,
stripped

This would say "LSB pie executable" otherwise, correct?

gcc 9.2.1 comes from the Ubuntu 19.10 repos.

[Bug c/92718] New: Bogus Wstringop-overflow in __builtin_memset() of an element of array of size 1 of struct

[rlibby at gmail dot com]

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

Bug ID: 92718
   Summary: Bogus Wstringop-overflow in __builtin_memset() of an
element of array of size 1 of struct
   Product: gcc
   Version: 8.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rlibby at gmail dot com
  Target Milestone: ---

Created attachment 47392
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47392&action=edit
Minimized test case

Gcc is emitting bogus, or maybe pessimistic, Wstringop-overflow or
Warray-bounds warnings (depending on warning flags).

$ cat min.c
struct s {
int x;
};

extern int n;
struct s a[1];

void
f(void)
{
struct s *ps;
int i;

for (i = 0; i < n; i++) {
ps = &a[i];
__builtin_memset(ps, 0, sizeof(*ps));
ps->x = 1;
}
}

$ /tmp/gcc/bin/bin/gcc -O -c min.c
min.c: In function ‘f’:
min.c:16:3: warning: ‘__builtin_memset’ writing 4 bytes into a region of size 0
overflows the destination [-Wstringop-overflow=]
   16 |   __builtin_memset(ps, 0, sizeof(*ps));
  |   ^~~~

$ /tmp/gcc/bin/bin/gcc -Wall -O -c min.c
min.c: In function ‘f’:
min.c:16:3: warning: ‘__builtin_memset’ offset [4, 7] is out of the bounds [0,
4] of object ‘a’ with type ‘struct s[1]’ [-Warray-bounds]
   16 |   __builtin_memset(ps, 0, sizeof(*ps));
  |   ^~~~
min.c:6:10: note: ‘a’ declared here
6 | struct s a[1];
  |  ^

My unprofessional opinion is that it seems like the compiler is emitting
a warning for when i >= 1, but the compiler does not know whether that
is actually possible.  Note that a warning is not emitted if any of
these changes are made:
 - The size of array "a" is changed from 1 to 2.
 - A check of "n" against the array size is inserted:
if (n > 1)
return;
 - The assignment of "x" after __builtin_memset() is deleted.
 - The array of struct is changed to array of int.

The warning is emitted as -Wstringop-overflow with the default warning
options.  In latest source, with -Wall, the warning is emitted as
Warray-bounds, but in previous versions (I checked 8.3.0) -Wall emits
Wstringop-overflow.  I'm not sure when this aspect may have changed.

I have tested this case and seen a warning on:
 - gcc 7.4.0
 - gcc 8.3.0
 - gcc current sources (r278812, "10.0.0")

I looked through the bugs linked to bug 88443 and was not immediately
able to identify this as a duplicate of one.  Apologies if it is.

[Bug c++/92717] precompiled headers non-deterministic

[gnu.org at mrks dot info]

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

--- Comment #5 from Markus Dreseler  ---
I took Andrew's __DATE__ suggestion as a reason to look at how much the files
actually differ. `cmp -l v1 v2 | wc -l` gives me 692634 differing bytes. This
sounds like the difference is bigger than just some macro values.

P.S.: Same issue on Mac with g++-8 (Homebrew GCC 8.2.0).

[Bug middle-end/92718] Bogus Wstringop-overflow in __builtin_memset() of an element of array of size 1 of struct

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek  ---
Started with r243419.
evrp is computing strange ranges, [0, 1] rather than just [0, 0] for the
iterator.  It is true that &a[1] is still valid, but the memset with non-zero
size at that spot or MEM[(struct s *)&a][i_2].x = 1; for i_2 equal to 1 is
already UB.
Later on cunroll completely unrolls the loop based on that, into two
iterations, the first one contains both the memset and ps->x and the second one
just memset (which is UB too) and ps->x already replaced by
__builtin_unreachable.
The warning is then during expansion of that second iteration.

[Bug middle-end/92718] [8/9/10 Regression] Bogus Wstringop-overflow in __builtin_memset() of an element of array of size 1 of struct

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-11-28
 CC||jakub at gcc dot gnu.org
   Target Milestone|--- |8.4
Summary|Bogus Wstringop-overflow in |[8/9/10 Regression] Bogus
   |__builtin_memset() of an|Wstringop-overflow in
   |element of array of size 1  |__builtin_memset() of an
   |of struct   |element of array of size 1
   ||of struct
 Ever confirmed|0   |1

[Bug tree-optimization/92716] -Os doesn't inline byteswap function even though it's a single instruction

[glisse at gcc dot gnu.org]

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

--- Comment #4 from Marc Glisse  ---
Yes, the pass that recognizes bswap (unsurprisingly called bswap) happens much
later than inlining in the pipeline. This kind of thing is unavoidable since
cycling through optimization passes is considered undesirable. In this
particular case, I don't know if there would be support for moving bswap, or
running it a second time, possibly just a restricted version if some parts are
less appropriate.