[Bug tree-optimization/92430] New: [10 Regression] Compile-time hog w/ -Os -fno-if-conversion -fno-tree-dce -fno-tree-loop-optimize -fno-tree-vrp

[asolokha at gmx dot com]

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

Bug ID: 92430
   Summary: [10 Regression] Compile-time hog w/ -Os
-fno-if-conversion -fno-tree-dce
-fno-tree-loop-optimize -fno-tree-vrp
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: compile-time-hog
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

gcc-10.0.0-alpha20191103 snapshot (r277758) takes indefinite time when
compiling the following testcase w/ -Os -fno-if-conversion -fno-tree-dce
-fno-tree-loop-optimize -fno-tree-vrp:

int eb, ko;

void
e9 (int pe, int lx)
{
  int ir;

  for (ir = 0; ir < 1; ++ir)
{
  for (ko = 0; ko < 1; ++ko)
{
  for (eb = 0; eb < 1; ++eb)
ko += pe;

  for (ko = 0; ko < 1; ++ko)
;
}

  pe = ir = lx;
}
}

% timeout 30 gcc-10.0.0-alpha20191103 -Os -fno-if-conversion -fno-tree-dce
-fno-tree-loop-optimize -fno-tree-vrp -c aous70dh.c
zsh: exit 124   timeout 30 gcc-10.0.0-alpha20191103 -Os -fno-if-conversion
-fno-tree-dce   -c

[Bug tree-optimization/92347] [10 Regression] ICE in vect_get_vec_def_for_operand_1, at tree-vect-stmts.c:1537

[asolokha at gmx dot com]

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

--- Comment #2 from Arseny Solokha  ---
I believe I have something that is a different manifestation of the same
problem.

1. gcc-10.0.0-alpha20191103 snapshot (r277758) ICEs when compiling the
following testcase reduced from gcc/testsuite/gcc.dg/vect/vect-simd-clone-11.c
w/ -mavx2 -O1 -fopenmp -ftree-loop-vectorize -ftree-parallelize-loops=2
-fno-tree-loop-ivcanon:

#pragma omp declare simd linear (yu : 6)
int __attribute__ ((noinline))
ms (int yu)
{
  return yu;
}

void
fm (int *kq)
{
  int v1 = 0, r5 = 1;

  while (v1 < 200)
{
  kq[v1] = ms (r5 * 2);
  r5 += 3;
  ++v1;
}
}

% x86_64-unknown-linux-gnu-gcc-10.0.0-alpha20191103 -mavx2 -O1 -fopenmp
-ftree-loop-vectorize -ftree-parallelize-loops=2 -fno-tree-loop-ivcanon -c
ax2wgtfe.c
ax2wgtfe.c: In function 'fm._loopfn.0':
ax2wgtfe.c:13:9: error: definition in block 13 does not dominate use in block
22
   13 |   while (v1 < 200)
  | ^
for SSA_NAME: _84 in statement:
_147 = _84 + 1;
during GIMPLE pass: vect
ax2wgtfe.c:13:9: internal compiler error: verify_ssa failed
0xe4094c verify_ssa(bool, bool)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191103/work/gcc-10-20191103/gcc/tree-ssa.c:1208
0xbab70c execute_function_todo
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191103/work/gcc-10-20191103/gcc/passes.c:1990
0xbac460 do_per_function
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191103/work/gcc-10-20191103/gcc/passes.c:1638
0xbac460 execute_todo
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191103/work/gcc-10-20191103/gcc/passes.c:2037

2. When compiling the following testcase w/ -O1 -ftree-loop-vectorize:

short int zb;

void
gs (void)
{
  while (zb < 1)
{
  int at;

  zb %= 1;

  for (at = 0; at < 56; ++at)
zb += zb;

  ++zb;
}
}

% x86_64-unknown-linux-gnu-gcc-10.0.0-alpha20191103 -O1 -ftree-loop-vectorize
-c klumnm2e.c
klumnm2e.c: In function 'gs':
klumnm2e.c:4:1: error: excess use operand for statement
4 | gs (void)
  | ^~
0
_7 = 0 + 1;
during GIMPLE pass: vect
klumnm2e.c:4:1: internal compiler error: verify_ssa failed
0xe4094c verify_ssa(bool, bool)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191103/work/gcc-10-20191103/gcc/tree-ssa.c:1208
0xbab70c execute_function_todo
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191103/work/gcc-10-20191103/gcc/passes.c:1990
0xbac460 do_per_function
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191103/work/gcc-10-20191103/gcc/passes.c:1638
0xbac460 execute_todo
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191103/work/gcc-10-20191103/gcc/passes.c:2037

[Bug tree-optimization/92429] New: [10 Regression] ICE in vect_transform_stmt, at tree-vect-stmts.c:10918

[asolokha at gmx dot com]

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

Bug ID: 92429
   Summary: [10 Regression] ICE in vect_transform_stmt, at
tree-vect-stmts.c:10918
   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: asolokha at gmx dot com
  Target Milestone: ---
Target: x86_64-unknown-linux-gnu

gcc-10.0.0-alpha20191103 snapshot (r277758) ICEs when compiling the following
testcase reduced from gcc/testsuite/gcc.dg/graphite/block-6.c w/ -mavx2 -O1
-ftree-loop-vectorize -fno-tree-fre:

void
as (int *gl, int k1)
{
  while (k1 < 1)
{
  gl[k1] = gl[k1] * gl[k1] / 2;
  ++k1;
}
}

% x86_64-unknown-linux-gnu-gcc-10.0.0-alpha20191103 -mavx2 -O1
-ftree-loop-vectorize -fno-tree-fre -c whpzikcj.c
during GIMPLE pass: vect
whpzikcj.c: In function 'as':
whpzikcj.c:2:1: internal compiler error: in vect_transform_stmt, at
tree-vect-stmts.c:10918
2 | as (int *gl, int k1)
  | ^~
0x6ba665 vect_transform_stmt(_stmt_vec_info*, gimple_stmt_iterator*,
_slp_tree*, _slp_instance*)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191103/work/gcc-10-20191103/gcc/tree-vect-stmts.c:10918
0xe81269 vect_transform_loop_stmt
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191103/work/gcc-10-20191103/gcc/tree-vect-loop.c:8008
0xe9534d vect_transform_loop(_loop_vec_info*)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191103/work/gcc-10-20191103/gcc/tree-vect-loop.c:8402
0xeadae0 try_vectorize_loop_1
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191103/work/gcc-10-20191103/gcc/tree-vectorizer.c:990
0xeadd2b try_vectorize_loop_1
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191103/work/gcc-10-20191103/gcc/tree-vectorizer.c:1027
0xeae6ed vectorize_loops()
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191103/work/gcc-10-20191103/gcc/tree-vectorizer.c:1127

[Bug libstdc++/90295] Please define ~exception_ptr inline

[redbeard0531 at gmail dot com]

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

Mathias Stearn  changed:

   What|Removed |Added

 CC||redbeard0531 at gmail dot com

--- Comment #2 from Mathias Stearn  ---
This will become more of a problem with C++ coroutines where in many cases the
compiler can prove that no exception will be thrown, but the generator or task
type will still have overhead from an exception_ptr member that the compiler
can't eliminate at the moment.

A handful of additional methods should probably either be completely inline or
have a nullptr fast-path: https://godbolt.org/z/zP6DSJ

default ctor
copy ctor
copy assign
swap
operator==
operator!=

Example showing significant codegen at -O3 which should all optimize away:

#include 
bool test() {
std::exception_ptr p1;
std::exception_ptr p2 (p1);
p1 = p2;
swap(p1, p2);
return p1 == nullptr && nullptr == p2 && p1 == p2;
}

[Bug c++/92357] ICE in IPA pass fnsummary in openmp offload

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Created attachment 47202
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47202=edit
pr92357.ii

Partially reduced testcase.

[Bug tree-optimization/85484] missing -Wstringop-overflow for strcpy with a string of non-const length

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-11-08
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Martin Sebor  ---
My WIP patch for pr91582 detects both of these bugs:

pr85484.c: In function ‘g’:
pr85484.c:7:3: warning: ‘__builtin_strcpy’ writing one too many bytes into a
region of a size that depends on ‘strlen’ [-Wstringop-overflow=]
7 |   __builtin_strcpy (d, s);  // missing -Wstringop-overflow
  |   ^~~
pr85484.c:6:13: note: at offset 0 to an object with size at most 4294967295
allocated by ‘__builtin_alloca’ here
6 |   char *d = __builtin_alloca (n);   // off-by-one error (should be n +
1)
  | ^~~~
pr85484.c: In function ‘h’:
pr85484.c:15:3: warning: ‘__builtin_strcpy’ writing one too many bytes into a
region of a size that depends on ‘strlen’ [-Wstringop-overflow=]
   15 |   __builtin___strcpy_chk (d, s, __builtin_object_size (d, 1));
  |   ^~~
pr85484.c:14:13: note: at offset 0 to an object with size at most 4294967295
allocated by ‘__builtin_alloca’ here
   14 |   char *d = __builtin_alloca (n);
  | ^~~~

[Bug fortran/82243] -fcheck=bounds not checking, and behaving differently with different real kinds

[anlauf at gcc dot gnu.org]

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

--- Comment #4 from anlauf at gcc dot gnu.org ---
I don't think that it has to do with kinds.  Currently there simply seems
to be no code being emitted for array constructors.

Example:

program p
  implicit none
  integer :: i, n = 40
  real:: a(40), b(40)
  a(1:n-1) = [ (b(i), i=1,n) ]  ! no bounds check generated
  a(1:n-1) = b(1:n) ! bounds check generated
end program p

Compile with -fdump-tree-original and look at the resulting code.

An alternative way to find issues with the posted code is compiling
with -fsanitize=address.

[Bug middle-end/79016] missing -Wstringop-overflow= overflowing allocated buffers

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||patch
   Target Milestone|--- |10.0

--- Comment #5 from Martin Sebor  ---
With the initial patch for pr91582 GCC issues the following warnings for the
test case in comment #0:

$ gcc -O2 -S -Wall -Wextra pr79016.c 
pr79016.c: In function ‘fauto’:
pr79016.c:7:3: warning: ‘__builtin_memset’ forming offset [3, 4] is out of the
bounds [0, 3] of object ‘d’ with type ‘char[3]’ [-Warray-bounds]
7 |   f (__builtin_memset (d, 0, 5));
  |   ^~
pr79016.c:5:8: note: ‘d’ declared here
5 |   char d[3];
  |^
pr79016.c: In function ‘funnamed’:
pr79016.c:12:3: warning: ‘__builtin_memset’ forming offset [3, 4] is out of the
bounds [0, 3] of object ‘({anonymous})’ with type ‘char[3]’ [-Warray-bounds]
   12 |   f (__builtin_memset ((char[3]){ 0 }, 1, 5));
  |   ^~~
pr79016.c:12:33: note: ‘({anonymous})’ declared here
   12 |   f (__builtin_memset ((char[3]){ 0 }, 1, 5));
  | ^
pr79016.c: In function ‘falloca’:
pr79016.c:19:3: warning: ‘__builtin_memset’ forming offset [3, 4] is out of the
bounds [0, 3] [-Warray-bounds]
   19 |   f (__builtin_memset (d, 0, 5));
  |   ^~
pr79016.c: In function ‘fmalloc’:
pr79016.c:26:3: warning: ‘__builtin_memset’ forming offset [3, 4] is out of the
bounds [0, 3] [-Warray-bounds]
   26 |   f (__builtin_memset (d, 0, 5));
  |   ^~
pr79016.c: In function ‘fvla’:
pr79016.c:36:3: warning: ‘__builtin_memset’ forming offset [3, 4] is out of the
bounds [0, 3] [-Warray-bounds]
   36 |   f (__builtin_memset (d, 0, 5));
  |   ^~


With -Wno-array-bounds the warning become more meaningful:

pr79016.c: In function ‘fauto’:
pr79016.c:7:3: warning: ‘__builtin_memset’ writing 5 bytes into a region of
size 3 overflows the destination [-Wstringop-overflow=]
7 |   f (__builtin_memset (d, 0, 5));
  |   ^~
pr79016.c: In function ‘funnamed’:
pr79016.c:12:3: warning: ‘__builtin_memset’ writing 5 bytes into a region of
size 3 overflows the destination [-Wstringop-overflow=]
   12 |   f (__builtin_memset ((char[3]){ 0 }, 1, 5));
  |   ^~~
pr79016.c: In function ‘falloca’:
pr79016.c:19:3: warning: ‘__builtin_memset’ writing 5 bytes into a region of
size 3 overflows the destination [-Wstringop-overflow=]
   19 |   f (__builtin_memset (d, 0, 5));
  |   ^~
pr79016.c: In function ‘fmalloc’:
pr79016.c:26:3: warning: ‘__builtin_memset’ writing 5 bytes into a region of
size 3 overflows the destination [-Wstringop-overflow=]
   26 |   f (__builtin_memset (d, 0, 5));
  |   ^~
pr79016.c: In function ‘fvla’:
pr79016.c:36:3: warning: ‘__builtin_memset’ writing 5 bytes into a region of
size 3 overflows the destination [-Wstringop-overflow=]
   36 |   f (__builtin_memset (d, 0, 5));
  |   ^~

[Bug middle-end/91582] missing heap overflow detection for strcpy

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #3 from Martin Sebor  ---
Patch: https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00652.html

[Bug c++/92426] ICE on spaceship declaration plus other P1185R2 interaction issue

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-11-08
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

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

92426.C: In member function ‘constexpr auto Basics::operator<=>(const Basics&)
const’:
92426.C:6:8: internal compiler error: tree check: expected class ‘type’, have
‘exceptional’ (error_mark) in is_cat, at cp/method.c:999
6 |   auto operator<=>(const Basics&) const = default;
  |^~~~
0x18bbf02 tree_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)
/home/mpolacek/src/gcc/gcc/tree.c:9726
0x87f90b tree_class_check(tree_node*, tree_code_class, char const*, int, char
const*)
/home/mpolacek/src/gcc/gcc/tree.h:3395
0xa33a2e is_cat
/home/mpolacek/src/gcc/gcc/cp/method.c:999
0xa33bc7 cat_tag_for
/home/mpolacek/src/gcc/gcc/cp/method.c:1011
0xa34a09 common_comparison_type
/home/mpolacek/src/gcc/gcc/cp/method.c:1150
0xa3560b build_comparison_op
/home/mpolacek/src/gcc/gcc/cp/method.c:1325
0xa3669c synthesize_method(tree_node*)
/home/mpolacek/src/gcc/gcc/cp/method.c:1485
0x9b7744 mark_used(tree_node*, int)
/home/mpolacek/src/gcc/gcc/cp/decl2.c:5485
0x8a02ec build_over_call
/home/mpolacek/src/gcc/gcc/cp/call.c:8946
0x8952f2 build_new_op_1
/home/mpolacek/src/gcc/gcc/cp/call.c:6224
0x895f2a build_new_op(op_location_t const&, tree_code, int, tree_node*,
tree_node*, tree_node*, tree_node**, int)
/home/mpolacek/src/gcc/gcc/cp/call.c:6490
0xa3555c build_comparison_op
/home/mpolacek/src/gcc/gcc/cp/method.c:1319
0xa3669c synthesize_method(tree_node*)
/home/mpolacek/src/gcc/gcc/cp/method.c:1485
0x9b7744 mark_used(tree_node*, int)
/home/mpolacek/src/gcc/gcc/cp/decl2.c:5485
0x8a02ec build_over_call
/home/mpolacek/src/gcc/gcc/cp/call.c:8946
0x8952f2 build_new_op_1
/home/mpolacek/src/gcc/gcc/cp/call.c:6224
0x895f2a build_new_op(op_location_t const&, tree_code, int, tree_node*,
tree_node*, tree_node*, tree_node**, int)
/home/mpolacek/src/gcc/gcc/cp/call.c:6490
0xbde344 build_x_binary_op(op_location_t const&, tree_code, tree_node*,
tree_code, tree_node*, tree_code, tree_node**, int)
/home/mpolacek/src/gcc/gcc/cp/typeck.c:4222
0xa789a3 cp_parser_binary_expression
/home/mpolacek/src/gcc/gcc/cp/parser.c:9645
0xa78e02 cp_parser_assignment_expression
/home/mpolacek/src/gcc/gcc/cp/parser.c:9780
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++/90998] [9 Regression] ICE (segfault) in gcc/cp/call.c compare_ics() with -std=c++17

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #7 from Marek Polacek  ---
Fixed.

[Bug c++/90998] [9 Regression] ICE (segfault) in gcc/cp/call.c compare_ics() with -std=c++17

[mpolacek at gcc dot gnu.org]

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

--- Comment #6 from Marek Polacek  ---
Author: mpolacek
Date: Fri Nov  8 21:52:39 2019
New Revision: 277992

URL: https://gcc.gnu.org/viewcvs?rev=277992=gcc=rev
Log:
PR c++/90998 - ICE with copy elision in init by ctor and -Wconversion.

* call.c (joust): Don't attempt to warn if ->second_conv is null.

* g++.dg/cpp0x/overload-conv-4.C: New test.

Added:
branches/gcc-9-branch/gcc/testsuite/g++.dg/cpp0x/overload-conv-4.C
Modified:
branches/gcc-9-branch/gcc/cp/ChangeLog
branches/gcc-9-branch/gcc/cp/call.c

[Bug c/92428] Crash on conflicting types

[joseph at codesourcery dot com]

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

--- Comment #1 from joseph at codesourcery dot com  ---
Each enum type is compatible with an integer type, and in GCC that's 
unsigned int by default (in the absence of values that don't fit in 
unsigned int), so it's valid to declare a function both as returning 
unsigned int and as returning a *complete* enum type.

The problem here is probably to do with forward declarations of enum types 
(which are a GNU extension).  If an enum type is incomplete when used, GCC 
can't know whether it will end up being compatible with unsigned int or 
not.

[Bug c++/92215] flawed diagnostic for bit-field with non-integral type

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
Author: mpolacek
Date: Fri Nov  8 21:48:47 2019
New Revision: 277991

URL: https://gcc.gnu.org/viewcvs?rev=277991=gcc=rev
Log:
PR c++/92215 - flawed diagnostic for bit-field with non-integral type.

I noticed that for code like

  struct S {
int *foo : 3;
  };

we generate nonsensical

  r.C:2:8: error: function definition does not declare parameters
  2 |   int *foo : 3;

It talks about a function because after parsing the declspecs of 'foo' we don't
see either ':' or "name :", so we think it's not a bit-field decl.  So we parse
the declarator and since a ctor-initializer begins with a ':', we try to parse
it as a function body, generating the awful diagnostic.  With this patch, we
issue:

  r.C:2:8: error: bit-field ‘foo’ has non-integral type ‘int*’
  2 |   int *foo : 3;

* parser.c (cp_parser_member_declaration): Add a diagnostic for
bit-fields with non-integral types.

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

Added:
trunk/gcc/testsuite/g++.dg/diagnostic/bitfld4.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/parser.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/92215] flawed diagnostic for bit-field with non-integral type

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

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

[Bug c++/92058] constinit disregards non-constexpr constructor

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #4 from Marek Polacek  ---
Fixed.

[Bug c++/92058] constinit disregards non-constexpr constructor

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek  ---
Author: mpolacek
Date: Fri Nov  8 21:40:45 2019
New Revision: 277990

URL: https://gcc.gnu.org/viewcvs?rev=277990=gcc=rev
Log:
PR c++/92058 - constinit malfunction in static data member.
* g++.dg/cpp2a/constinit15.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp2a/constinit15.C
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug fortran/83079] ICE in gfc_widechar_to_char, at fortran/scanner.c:198

[anlauf at gcc dot gnu.org]

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

--- Comment #4 from anlauf at gcc dot gnu.org ---
The following patch fixes the testcase in comment#3:

Index: gcc/fortran/trans-intrinsic.c
===
--- gcc/fortran/trans-intrinsic.c   (Revision 277989)
+++ gcc/fortran/trans-intrinsic.c   (Arbeitskopie)
@@ -8410,7 +8410,11 @@
   gfc_add_expr_to_block (>post, tmp);

   se->expr = tmpdecl;
-  se->string_length = fold_convert (gfc_charlen_type_node, dest_word_len);
+  tmp = fold_convert (gfc_charlen_type_node,
+ TYPE_SIZE_UNIT (gfc_get_char_type (expr->ts.kind)));
+  se->string_length = fold_build2_loc (input_location, TRUNC_DIV_EXPR,
+  gfc_charlen_type_node,
+  dest_word_len, tmp);
 }
   else
 {


I've tried to understand what happens when the MOLD argument is an array,
but got lost in mutually recursive functions in target-memory.c that seem
to try to convert char(kind=4) to default character, while I believe that
this should not happen.  Don't really understand that code, giving up.

[Bug c++/92427] Initializing an element which has a zero-length array of a type-with-destructor causes an internal compiler error

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
GCC 5 says:

92427.C:11:25: error: too many initializers for ‘C [0]’
 } y = { 1, { { 2, 3 } } };
 ^
then since r231665 we accepted the test.  Then since r233126

92427.C: In destructor ‘y::~y()’:
92427.C:9:8: error: unknown array size in delete
 struct y {
^
92427.C: In function ‘void __static_initialization_and_destruction_0(int,
int)’:
92427.C:11:3: note: synthesized method ‘y::~y()’ first required here 
 } y = { 1, { { 2, 3 } } };
   ^

And the ICE started with r233183.

[Bug c/92428] New: Crash on conflicting types

[dpotapov at gmail dot com]

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

Bug ID: 92428
   Summary: Crash on conflicting types
   Product: gcc
   Version: 8.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dpotapov at gmail dot com
  Target Milestone: ---

Created attachment 47201
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47201=edit
crash report

The following 4 lines of C code crashes the GCC compiler.

enum Foo;
typedef unsigned Foo;
enum Foo foo(void);
Foo foo(void){ return 0; }


I report it against gcc 8.1.0, but I have tried a few other versions, and all
of them crashed in the similar way (see crash.txt)

The program is incorrect, because the `foo` function declared as returning a
different type. So the expected behavior would be an error message:
enum.c:4:5: error: conflicting types for 'foo'

[Bug c++/92427] Initializing an element which has a zero-length array of a type-with-destructor causes an internal compiler error

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-11-08
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

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

[Bug c++/92427] New: Initializing an element which has a zero-length array of a type-with-destructor causes an internal compiler error

[nmehrotra at riorey dot com]

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

Bug ID: 92427
   Summary: Initializing an element which has a zero-length array
of a type-with-destructor causes an internal compiler
error
   Product: gcc
   Version: 8.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nmehrotra at riorey dot com
  Target Milestone: ---

Declaring and trying to initialize an element which has a zero-length array,
which itself is of a type that has a destructor, causes an internal compiler
error.

Proprocessed code:
--

# 1 "zz.cpp"
# 1 ""
# 1 ""
# 1 "/usr/include/stdc-predef.h" 1 3 4
# 1 "" 2
# 1 "zz.cpp"
class C {
private:
int a; int b;
public:
C(int A, int B) : a(A), b(B) { }
~C() { }
};

struct y {
int a; C b[];
} y = { 1, { { 2, 3 } } };

int main(void) { return 0; }


The error message:
--

zz.cpp: In function ‘void __static_initialization_and_destruction_0(int, int)’:
zz.cpp:11:3: internal compiler error: in finish_expr_stmt, at
cp/semantics.c:680
 } y = { 1, { { 2, 3 } } };
   ^
0x7f802a629e5a __libc_start_main
../csu/libc-start.c:308
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

The command line:
-
gcc zz.cpp


Compiler:
-
gcc -v zz.cpp
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/8.3.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with:
/var/tmp/portage/sys-devel/gcc-8.3.0-r1/work/gcc-8.3.0/configure
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr
--bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/8.3.0
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/8.3.0/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/8.3.0
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/8.3.0/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/8.3.0/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/8.3.0/include/g++-v8
--with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/8.3.0/python
--enable-languages=c,c++,fortran --enable-obsolete --enable-secureplt
--disable-werror --with-system-zlib --enable-nls --without-included-gettext
--enable-checking=release --with-bugurl=https://bugs.gentoo.org/
--with-pkgversion='Gentoo 8.3.0-r1 p1.1' --disable-esp --enable-libstdcxx-time
--enable-shared --enable-threads=posix --enable-__cxa_atexit
--enable-clocale=gnu --enable-multilib --with-multilib-list=m32,m64
--disable-altivec --disable-fixed-point --enable-targets=all --enable-libgomp
--disable-libmudflap --disable-libssp --disable-libmpx --disable-systemtap
--enable-vtable-verify --enable-lto --without-isl --enable-default-pie
--enable-default-ssp
Thread model: posix
gcc version 8.3.0 (Gentoo 8.3.0-r1 p1.1) 
COLLECT_GCC_OPTIONS='-v' '-mtune=generic' '-march=x86-64'
 /usr/libexec/gcc/x86_64-pc-linux-gnu/8.3.0/cc1plus -quiet -v -D_GNU_SOURCE
zz.cpp -quiet -dumpbase zz.cpp -mtune=generic -march=x86-64 -auxbase zz
-version -o /tmp/ccBqkqu4.s
GNU C++14 (Gentoo 8.3.0-r1 p1.1) version 8.3.0 (x86_64-pc-linux-gnu)
compiled by GNU C version 8.3.0, GMP version 6.1.2, MPFR version 3.1.6,
MPC version 1.0.3, isl version none
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory "/usr/local/include"
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-pc-linux-gnu/8.3.0/../../../../x86_64-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc/x86_64-pc-linux-gnu/8.3.0/include/g++-v8
 /usr/lib/gcc/x86_64-pc-linux-gnu/8.3.0/include/g++-v8/x86_64-pc-linux-gnu
 /usr/lib/gcc/x86_64-pc-linux-gnu/8.3.0/include/g++-v8/backward
 /usr/lib/gcc/x86_64-pc-linux-gnu/8.3.0/include
 /usr/lib/gcc/x86_64-pc-linux-gnu/8.3.0/include-fixed
 /usr/include
End of search list.
GNU C++14 (Gentoo 8.3.0-r1 p1.1) version 8.3.0 (x86_64-pc-linux-gnu)
compiled by GNU C version 8.3.0, GMP version 6.1.2, MPFR version 3.1.6,
MPC version 1.0.3, isl version none
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 8330a0e4e33b5f386c6a540b63a52c5e

System:
---

Linux buildm68 4.19.57-gentoo #2 SMP Thu Jul 18 20:31:51 UTC 2019 x86_64
Intel(R) Xeon(R) CPU E3-1220 V2 @ 3.10GHz GenuineIntel GNU/Linux

qlist -IRv|grep gcc
sys-devel/gcc-8.3.0-r1::gentoo
sys-devel/gcc-config-2.0::gentoo

--

The problem appears to be caused by the fact that gcc can't determine at
compile time the number of elements to be destroyed.  

Removing the destructor from the class definition fixes the failure.

[Bug c++/92425] Incorrect logical AND on 64bit variable using 32bit register

[akobets at mail dot ru]

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

Alexander Kobets  changed:

   What|Removed |Added

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

--- Comment #5 from Alexander Kobets  ---
It strange notation works correctly.

[Bug middle-end/92384] [8 Regression] Empty class instances have different equal testing result among GCC versions

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

  Known to work||10.0, 9.2.1
Summary|[8/9 Regression] Empty  |[8 Regression] Empty class
   |class instances have|instances have different
   |different equal testing |equal testing result among
   |result among GCC versions   |GCC versions
  Known to fail|10.0|

--- Comment #8 from Jakub Jelinek  ---
Should be fixed for 9.3+ too.

[Bug preprocessor/92296] [7/8 Regression] internal compiler error: Segmentation fault #pragma push_macro("__LINE__")

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[7/8/9 Regression] internal |[7/8 Regression] internal
   |compiler error: |compiler error:
   |Segmentation fault  #pragma |Segmentation fault  #pragma
   |push_macro("__LINE__")  |push_macro("__LINE__")

--- Comment #16 from Jakub Jelinek  ---
Fixed for 9.3+ too.

[Bug middle-end/92231] [9 Regression] ICE in gimple_fold_stmt_to_constant_1

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/85887] [7/8 Regression] Missing DW_TAG_lexical_block PC range

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
Summary|[7/8/9 Regression] Missing  |[7/8 Regression] Missing
   |DW_TAG_lexical_block PC |DW_TAG_lexical_block PC
   |range   |range

--- Comment #7 from Jakub Jelinek  ---
Fixed for 9.3+ too.

[Bug c++/92015] [9 Regression] internal compiler error: in cxx_eval_array_reference, at cp/constexpr.c:2568

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug c++/92426] New: ICE on spaceship declaration plus other P1185R2 interaction issue

[dacamara.cameron at gmail dot com]

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

Bug ID: 92426
   Summary: ICE on spaceship declaration plus other P1185R2
interaction issue
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dacamara.cameron at gmail dot com
  Target Milestone: ---

I was playing around with the spaceship operator using gcc10 on godbolt and
discovered an issue trying to compile the following program:

struct Basics {
  int i;
  char c;
  float f;
  double d;
  auto operator<=>(const Basics&) const = default;
};

struct Arrays {
  int ai[1];
  char ac[2];
  float af[3];
  double ad[2][2];
  auto operator<=>(const Arrays&) const = default;
};

struct Bases : Basics, Arrays {
  auto operator<=>(const Bases&) const = default;
};

int main() {
  constexpr Bases a = { { 0, 'c', 1.f, 1. },
{ { 1 }, { 'a', 'b' }, { 1.f, 2.f, 3.f }, { { 1., 2. },
{ 3., 4. } } } };
  constexpr Bases b = { { 0, 'c', 1.f, 1. },
{ { 1 }, { 'a', 'b' }, { 1.f, 2.f, 3.f }, { { 1., 2. },
{ 3., 4. } } } };
  static_assert(a == b);
  static_assert(!(a != b));
  static_assert(!(a < b));
  static_assert(a <= b);
  static_assert(!(a > b));
  static_assert(a >= b);
}

The program ultimately ICEs gcc10 but working with a reduced repro shows some
other gaps:

struct Arrays {
int a[2];
#ifdef MEMBERS
auto operator<=>(const Arrays&) const = default;
#endif
#ifdef FRIENDS
friend auto operator<=>(const Arrays&, const Arrays&) = default;
// friend bool operator==(const Arrays&, const Arrays&) = default; //
should be implicitly declared
#endif
};

int main() {
constexpr Arrays a1 { 1, 2 };
constexpr Arrays a2 { 3, 4 };
static_assert(a1 == a1);  // OK
static_assert(a1 != a2);  // OK
static_assert(a1 < a2);   // ICE
}

When MEMBERS is defined it only ICEs at the final static assert, but with
FRIENDS it both leaves the implicitly declared operator== undeclared _and_
ICEs.  Additionally, replacing `auto` with `std::strong_ordering` produces an
ICE in finish_expr_stmt so I assume arrays just aren't handled yet?

[Bug fortran/92358] libgfortran/io/async.c:548:37: warning: unused parameter 'cmp'

[jvdelisle at gcc dot gnu.org]

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

--- Comment #1 from Jerry DeLisle  ---
I notoced your report here. I do not get that warning on my system here.  I am
using gcc version 9.2.1 20190827 to build with.  What are you using?

[Bug target/91886] [10 regression] powerpc64 impossible constraint in asm

[dje at gcc dot gnu.org]

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

--- Comment #35 from David Edelsohn  ---
The ELFv2 ABI does not require Power8+ because the subroutine linkage
convention requires Power8 instructions.  It requires Power8+ because the ABI
provide a minimum guarantee to the programmer / developer / toolchain /
distribution of the minimum ISA that will be encountered. The ABI can function
on earlier hardware, but the ABI asserts to the programmer that one can utilize
the instructions available in Power8 without special accommodation or feature
tests. The authors of the ABI (IBM) didn't want to provide a guarantee of
backward compatibility to the beginning of time, which creates challenges for
the minimum ISA level supported by, for example, a GNU/Linux distribution.

[Bug middle-end/92384] [8/9 Regression] Empty class instances have different equal testing result among GCC versions

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
Author: jakub
Date: Fri Nov  8 19:02:24 2019
New Revision: 277989

URL: https://gcc.gnu.org/viewcvs?rev=277989=gcc=rev
Log:
PR c++/92384
* function.c (assign_parm_setup_block, assign_parm_setup_stack): Don't
copy TYPE_EMPTY_P arguments from data->entry_parm to data->stack_parm
slot.
(assign_parms): For TREE_ADDRESSABLE parms with TYPE_EMPTY_P type
force creation of a unique data.stack_parm slot.

* g++.dg/torture/pr92384.C: New test.

Added:
branches/gcc-9-branch/gcc/testsuite/g++.dg/torture/pr92384.C
Modified:
branches/gcc-9-branch/gcc/ChangeLog
branches/gcc-9-branch/gcc/function.c
branches/gcc-9-branch/gcc/testsuite/ChangeLog

[Bug c++/92343] [[likely]]/[[unlikely]] prevent method from being a constant expression

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Author: jakub
Date: Fri Nov  8 19:00:02 2019
New Revision: 277988

URL: https://gcc.gnu.org/viewcvs?rev=277988=gcc=rev
Log:
Backported from mainline
2019-11-05  Jakub Jelinek  

PR c++/92343
* constexpr.c (potential_constant_expression_1): Return true rather
than false for PREDICT_EXPR.

* g++.dg/cpp2a/attr-likely6.C: New test.

Added:
branches/gcc-9-branch/gcc/testsuite/g++.dg/cpp2a/attr-likely6.C
Modified:
branches/gcc-9-branch/gcc/cp/ChangeLog
branches/gcc-9-branch/gcc/cp/constexpr.c
branches/gcc-9-branch/gcc/testsuite/ChangeLog

[Bug preprocessor/92296] [7/8/9 Regression] internal compiler error: Segmentation fault #pragma push_macro("__LINE__")

[jakub at gcc dot gnu.org]

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

--- Comment #15 from Jakub Jelinek  ---
Author: jakub
Date: Fri Nov  8 18:59:14 2019
New Revision: 277987

URL: https://gcc.gnu.org/viewcvs?rev=277987=gcc=rev
Log:
Backported from mainline
2019-10-31  Jakub Jelinek  

PR preprocessor/92296
* internal.h (struct def_pragma_macro): Add is_builtin bitfield.
(_cpp_restore_special_builtin): Declare.
* init.c (_cpp_restore_special_builtin): New function.
* directives.c (do_pragma_push_macro): For NT_BUILTIN_MACRO
set is_builtin and don't try to grab definition.
(cpp_pop_definition): Use _cpp_restore_special_builtin to restore
builtin macros.

* c-c++-common/cpp/pr92296-1.c: New test.
* c-c++-common/cpp/pr92296-2.c: New test.

Added:
branches/gcc-9-branch/gcc/testsuite/c-c++-common/cpp/pr92296-1.c
branches/gcc-9-branch/gcc/testsuite/c-c++-common/cpp/pr92296-2.c
Modified:
branches/gcc-9-branch/gcc/testsuite/ChangeLog
branches/gcc-9-branch/libcpp/ChangeLog
branches/gcc-9-branch/libcpp/directives.c
branches/gcc-9-branch/libcpp/init.c
branches/gcc-9-branch/libcpp/internal.h

[Bug middle-end/92231] [9 Regression] ICE in gimple_fold_stmt_to_constant_1

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Fri Nov  8 18:58:14 2019
New Revision: 277986

URL: https://gcc.gnu.org/viewcvs?rev=277986=gcc=rev
Log:
Backported from mainline
2019-10-31  Jakub Jelinek  

PR middle-end/92231
* tree.h (fndecl_built_in_p): Use fndecl_built_in_p instead of
DECL_BUILT_IN in comment.  Remove redundant ()s around return
argument.
* tree.c (free_lang_data_in_decl): Check if var is FUNCTION_DECL
before calling fndecl_built_in_p.
* gimple-fold.c (gimple_fold_stmt_to_constant_1): Check if
TREE_OPERAND (fn, 0) is a FUNCTION_DECL before calling
fndecl_built_in_p on it.

* lto-lang.c (handle_const_attribute): Don't call fndecl_built_in_p
on *node that is not FUNCTION_DECL.

* gcc.c-torture/compile/pr92231.c: New test.

Added:
branches/gcc-9-branch/gcc/testsuite/gcc.c-torture/compile/pr92231.c
Modified:
branches/gcc-9-branch/gcc/ChangeLog
branches/gcc-9-branch/gcc/gimple-fold.c
branches/gcc-9-branch/gcc/lto/ChangeLog
branches/gcc-9-branch/gcc/lto/lto-lang.c
branches/gcc-9-branch/gcc/testsuite/ChangeLog
branches/gcc-9-branch/gcc/tree.c
branches/gcc-9-branch/gcc/tree.h

[Bug c++/90947] [9 Regression] Simple lookup table of array of strings is miscompiled

[jakub at gcc dot gnu.org]

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

--- Comment #15 from Jakub Jelinek  ---
Author: jakub
Date: Fri Nov  8 18:56:42 2019
New Revision: 277985

URL: https://gcc.gnu.org/viewcvs?rev=277985=gcc=rev
Log:
Backported from mainline
2019-10-31  Jakub Jelinek  

PR c++/90947
* tree.h (type_initializer_zero_p): Remove.
* tree.c (type_initializer_zero_p): Remove.

* cp-tree.h (type_initializer_zero_p): Declare.
* decl.c (reshape_init_array_1): Formatting fix.
* tree.c (type_initializer_zero_p): New function.  Moved from
../tree.c, use next_initializable_field, formatting fix.  Return
false for TYPE_NON_AGGREGATE_CLASS types.

Added:
branches/gcc-9-branch/gcc/testsuite/g++.dg/init/array54.C
Modified:
branches/gcc-9-branch/gcc/ChangeLog
branches/gcc-9-branch/gcc/cp/ChangeLog
branches/gcc-9-branch/gcc/cp/cp-tree.h
branches/gcc-9-branch/gcc/cp/decl.c
branches/gcc-9-branch/gcc/cp/tree.c
branches/gcc-9-branch/gcc/tree.c
branches/gcc-9-branch/gcc/tree.h

[Bug sanitizer/92154] new glibc breaks arm bootstrap due to libsanitizer

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Fri Nov  8 18:53:18 2019
New Revision: 277981

URL: https://gcc.gnu.org/viewcvs?rev=277981=gcc=rev
Log:
Backported from mainline
2019-10-22  Tamar Christina  

PR sanitizer/92154
* sanitizer_common/sanitizer_platform_limits_posix.cc:
Cherry-pick compiler-rt revision r375220.

Modified:
branches/gcc-9-branch/libsanitizer/ChangeLog
   
branches/gcc-9-branch/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc

[Bug tree-optimization/85887] [7/8/9 Regression] Missing DW_TAG_lexical_block PC range

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Author: jakub
Date: Fri Nov  8 18:53:46 2019
New Revision: 277982

URL: https://gcc.gnu.org/viewcvs?rev=277982=gcc=rev
Log:
Backported from mainline
2019-10-22  Jakub Jelinek  

PR tree-optimization/85887
* decl.c (expand_static_init): Drop ECF_LEAF from __cxa_guard_acquire
and __cxa_guard_release.

Modified:
branches/gcc-9-branch/gcc/cp/ChangeLog
branches/gcc-9-branch/gcc/cp/decl.c

[Bug c++/92015] [9 Regression] internal compiler error: in cxx_eval_array_reference, at cp/constexpr.c:2568

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Author: jakub
Date: Fri Nov  8 18:52:44 2019
New Revision: 277980

URL: https://gcc.gnu.org/viewcvs?rev=277980=gcc=rev
Log:
Backported from mainline
2019-10-21  Jakub Jelinek  

PR c++/92015
* constexpr.c (cxx_eval_component_reference, cxx_eval_bit_field_ref):
Use STRIP_ANY_LOCATION_WRAPPER on CONSTRUCTOR elts.

* g++.dg/cpp0x/constexpr-92015.C: New test.

Added:
branches/gcc-9-branch/gcc/testsuite/g++.dg/cpp0x/constexpr-92015.C
Modified:
branches/gcc-9-branch/gcc/cp/ChangeLog
branches/gcc-9-branch/gcc/cp/constexpr.c
branches/gcc-9-branch/gcc/testsuite/ChangeLog

[Bug target/91886] [10 regression] powerpc64 impossible constraint in asm

[bugdal at aerifal dot cx]

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

--- Comment #34 from Rich Felker  ---
> Does musl not support BE?  There is nothing about this that is LE-only
> as far as I can see.

For powerpc64, musl supports both BE and LE, and uses "elfv2" ABI for both
(since it was not present as a target for musl before the new ABI existed). Per
the IBM docs, LE/elfv2 (which they confusingly equate) "require" power8+, but
there are not actually any constraints in the ABI that impose such a
requirement (e.g. argument-passing in registers that previous ISA levels didn't
have), and we don't impose it. I believe there are people using musl on
pre-power8 powerpc64 systems, at least in BE mode and possibly also in LE mode.

[Bug fortran/92422] [Regression 9] Warning with character and optimisation flags

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P5
 CC||kargl at gcc dot gnu.org
  Known to work||10.0, 6.5.0, 7.4.1, 8.3.1
   Target Milestone|--- |9.4
Summary|Warning with character and  |[Regression 9] Warning with
   |optimisation flags  |character and optimisation
   ||flags
  Known to fail||9.2.1

[Bug target/91886] [10 regression] powerpc64 impossible constraint in asm

[segher at gcc dot gnu.org]

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

--- Comment #33 from Segher Boessenkool  ---
(In reply to nsz from comment #31)
> (In reply to Segher Boessenkool from comment #28)
> > [ "ws" needs at least a Power7, btw. ]
> 
> powerpc64le-* implies power8 and that's where this came up.

Does musl not support BE?  There is nothing about this that is LE-only
as far as I can see.

[Bug middle-end/92410] Invalid access to df->insns[] in regstat_bb_compute_calls_crossed (caught by hwasan)

[matmal01 at gcc dot gnu.org]

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

--- Comment #7 from Matthew Malcomson  ---
(In reply to Matthew Malcomson from comment #6)
> I'm not sure whether there's any pre-existing "should not use dataflow
> queries on notes" rule.  If there is, then the
> regstat_bb_compute_calls_crossed function should be modified to check for
> NONDEBUG_INSN_P and continue earlier on its loop.

I now see that `df_bb_refs_record` generates insn info for notes (but leaves it
mostly zeroed out).  I figure doing the same for the notes emitted by
`reemit_notes` seems reasonable.


Currently bootstrapping and regtesting (both with HWASAN and without) the
following patch.


diff --git a/gcc/haifa-sched.c b/gcc/haifa-sched.c
index 41cf1f3..2e1a84f 100644
--- a/gcc/haifa-sched.c
+++ b/gcc/haifa-sched.c
@@ -5433,6 +5433,7 @@ reemit_notes (rtx_insn *insn)

  last = emit_note_before (note_type, last);
  remove_note (insn, note);
+ df_insn_create_insn_record (last);
}
 }
 }
diff --git a/gcc/regstat.c b/gcc/regstat.c
index 4da9b7c..c6cefb11 100644
--- a/gcc/regstat.c
+++ b/gcc/regstat.c
@@ -324,6 +324,7 @@ regstat_bb_compute_calls_crossed (unsigned int bb_index,
bitmap live)

   FOR_BB_INSNS_REVERSE (bb, insn)
 {
+  gcc_assert (INSN_UID (insn) < DF_INSN_SIZE ());
   struct df_insn_info *insn_info = DF_INSN_INFO_GET (insn);
   unsigned int regno;

[Bug inline-asm/92352] ICE in force_constant_size

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #4 from Jakub Jelinek  ---
ice-on-invalid, not going to backport to release branches.

[Bug c++/92425] Incorrect logical AND on 64bit variable using 32bit register

[akobets at mail dot ru]

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

--- Comment #4 from Alexander Kobets  ---
Ok.

[Bug c++/92425] Incorrect logical AND on 64bit variable using 32bit register

[fw at gcc dot gnu.org]

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

Florian Weimer  changed:

   What|Removed |Added

 CC||fw at gcc dot gnu.org

--- Comment #3 from Florian Weimer  ---
In general, the 32-bit opcodes clear the upper 32 bits of the 64 bit registers.
They do not just operate on the lower 32 bits.

[Bug c++/90393] [9/10 Regression] ICE in return statement with a conditional operator, one of the second and third arguments is throw, and the other is a const variable of a class with a nontrivial co

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||tpg+gcc at mutabah dot net

--- Comment #14 from Jakub Jelinek  ---
*** Bug 92423 has been marked as a duplicate of this bug. ***

[Bug c++/92423] Reference assigned from a ternary results in destructor call

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||jakub at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #1 from Jakub Jelinek  ---
This used to be rejected before r260272 with:
pr92423.C: In function ‘int main()’:
pr92423.C:15:49: error: use of deleted function ‘Foo::Foo(const Foo&)’
   const auto& my_foo = (true ? base_foo : throw "");
 ^~
pr92423.C:4:3: note: declared here
   Foo (const Foo& x) = delete;
   ^~~
starting with that would call the dtor twice, and finally since r274550 aka
PR90393 calls dtor just once.
I think the g++.dg/expr/cond16.C testcase is sufficiently similar to this one
that it isn't worth adding another one.

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

[Bug c++/92425] Incorrect logical AND on 64bit variable using 32bit register

[akobets at mail dot ru]

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

--- Comment #2 from Alexander Kobets  ---
I think eax is 32-bit register. May be I do not understand, then I re-check the
result of that operation.

[Bug c++/92425] Incorrect logical AND on 64bit variable using 32bit register

[wilco at gcc dot gnu.org]

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

Wilco  changed:

   What|Removed |Added

 CC||wilco at gcc dot gnu.org

--- Comment #1 from Wilco  ---
Where do you see a problem? and eax, 4095 clears the top 32 bits of rax.

[Bug c++/92425] New: Incorrect logical AND on 64bit variable using 32bit register

[akobets at mail dot ru]

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

Bug ID: 92425
   Summary: Incorrect logical AND on 64bit variable using 32bit
register
   Product: gcc
   Version: 9.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: akobets at mail dot ru
  Target Milestone: ---

Created attachment 47200
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47200=edit
Assembly output

=== prog.cpp ===
unsigned long long a, b;

int start()
{
a = b & 0xFFF;
return 1;
}

Compiling
gcc -c -fno-PIC -Wall -Wextra -save-temps -fverbose-asm -masm=intel
-march=core2 -mtune=generic -O2 -fno-rtti -fno-default-inline --no-exceptions
-O2 prog.cpp
No errors
No warnings
Produces wrong assembly code
=== cut ===
_Z5startv:
.LFB0:
.cfi_startproc
endbr64 
# prog.cpp:5:   a = b & 0xFFF;
mov rax, QWORD PTR b[rip]   # tmp87, b
and eax, 4095   # tmp87,
# prog.cpp:5:   a = b & 0xFFF;
mov QWORD PTR a[rip], rax   # a, tmp87
# prog.cpp:7: }
mov eax, 1  #,
ret 
.cfi_endproc
=== cut ===
There is 'and' on 32bit register eax, while 'b' is 64bit variable. Bits 32...63
of 'b' stays unchanged, but must be zeroed.

[Bug middle-end/92410] Invalid access to df->insns[] in regstat_bb_compute_calls_crossed (caught by hwasan)

[matmal01 at gcc dot gnu.org]

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

--- Comment #6 from Matthew Malcomson  ---
I believe the problem is that `remove_notes` followed by `reemit_notes` can
generate these notes with a different UID.

When `reemit_notes` adds the new note, the dataflow information is not updated
automatically because `add_insn_before` only updates the information for
INSN_P(insn).

Hence the later lookup of this dataflow information is problematic.

I'm not sure whether there's any pre-existing "should not use dataflow queries
on notes" rule.  If there is, then the regstat_bb_compute_calls_crossed
function should be modified to check for NONDEBUG_INSN_P and continue earlier
on its loop.

If there isn't such a rule then I guess the best approach would be to ensure we
call `df_insn_create_insn_record` whenever calling `emit_note_before` or
`emit_note_after` once the dataflow information has been created.
(assuming that notes don't need the information to be populated since
`df_insn_rescan` seems to ignore notes).

I've tried both moving the check for NONDEBUG_INSN_P in
`regstat_bb_compute_calls_crossed` and adding a call to
`df_insn_create_insn_record` into `reemit_notes` on a cross-compiler and both
pass the testcase Martin found.

[Bug tree-optimization/92351] [10 Regression] Wrong code with -O3 -match=skylake since r277569

[avieira at gcc dot gnu.org]

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

avieira at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #4 from avieira at gcc dot gnu.org ---
I believe the committed patch fixes this.

[Bug target/92424] New: [aarch64] Broken code with -fpatchable-function-entry and BTI

[ktkachov at gcc dot gnu.org]

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

Bug ID: 92424
   Summary: [aarch64] Broken code with -fpatchable-function-entry
and BTI
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ktkachov at gcc dot gnu.org
  Target Milestone: ---

-fpatchable-function-entry seems to interact badly with
-mbranch-protection=standard (used to insert BTI markers)

void g(void);

void f(void)
{ g(); g(); }

aarch64-linux-gnu-gcc  -mbranch-protection=standard
-fpatchable-function-entry=2,1 -O3 -c foo.c -save-temps


Produces:
.arch armv8-a
.file   "foo.c"
.text
.align  2
.p2align 3,,7
.global f
.section__patchable_function_entries,"aw",@progbits
.8byte  .LPFE1
.text
.LPFE1:
nop
.type   f, %function
f:
nop  // <--- Function entry has NOP rather than PACIASP landing pad
.LFB0:
.cfi_startproc
hint25 // paciasp
.cfi_window_save
stp x29, x30, [sp, -16]!
.cfi_def_cfa_offset 16
.cfi_offset 29, -16
.cfi_offset 30, -8
mov x29, sp
bl  g
ldp x29, x30, [sp], 16
.cfi_restore 30
.cfi_restore 29
.cfi_def_cfa_offset 0
hint29 // autiasp
.cfi_window_save
b   g
.cfi_endproc
.LFE0:
.size   f, .-f


Could a possible solution be to emit ofr -mbranch-protection={standard or bti}
-fpatchable-function-entry=N,M:

f-4*M:
.rept M
nop
.endr
f:
bti c
.rept N-M
nop
.endr
// paciasp may be used from here on in

Unless we fix the codegen we should perhaps error out when the two options are
combined rather than producing silently wrong code?

[Bug target/91886] [10 regression] powerpc64 impossible constraint in asm

[wschmidt at gcc dot gnu.org]

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

--- Comment #32 from Bill Schmidt  ---
BTW, we are in close contact with the Clang folks for Power as well, so we're
going to get together with them about constraints consistency and a way forward
to ensure these problems don't recur.  I don't want anyone to get the idea that
we don't care about Clang; we care very much indeed about compatibility between
the compilers.  I've personally worked on both in the past to ensure the ABI
compatibility that you enjoy today.  We had an unexpected gotcha here, and
we'll get it resolved.

I do agree with Segher that this was a long-overdue cleanup that was causing us
a lot of misery, and the use of "ws" in the field was rather surprising to us. 
Long term we really want to get to "wa" and remove "ws", but aliases in the
meantime will be needed until supported versions of Clang and GCC have the
compatibility issue resolved.

[Bug c++/92421] [10 Regression] ice in inline_small_functions, at ipa-inline.c:2001

[dcb314 at hotmail dot com]

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

--- Comment #3 from David Binderman  ---
Reduced C++ code:

typedef long a;
void *b, *c;
template  class d {};
template  bool operator!=(d, d);
class g {
public:
  g(char *);
};
class j {
public:
  j();
  void h();
  void i();
  void aj();
};
class m {
public:
  m(bool);
};
class n {
public:
  operator a();
};
class o {
public:
  long am();
};
class H {
public:
  class p {};
  virtual bool accept(const char *, unsigned long, p *, bool);
};
class q : H {
public:
  class r {
  public:
enum at { au, av, aw };
  };
  enum { ax };
  virtual void ay(char *, int, const char *, r::at, char *);
  virtual bool az(const g &, unsigned = ax);
  virtual bool ba(const int &, p *, bool);
  void bb(char *bc, long bd, char *, long be) {
class bf : public p {
public:
  bf(long);
} bg(be);
accept(bc, bd, , true);
  }
};
class s {
  q *bi;
  bool bj();
};
template  class t : q {
  bool accept(const char *, unsigned long bd, p *bg, bool) {
bool k(bp || bq), cl = false, err = false;
if (br)
  ay("", 1, __func__, r::au, "");
if (bs)
  ay("", 6, __func__, r::av, "");
char bt[1], cd[1];
long bu = sizeof(int) + bd, ce = sizeof(L) + bd;
char *bw = bu > sizeof(bt) ? new char : bt,
 *cf = ce > sizeof(cd) ? new char : cd;
__builtin___memcpy_chk(b, c, bd, 0);
a by[1];
int bz = 0;
u cb = *cc((int *)bw, true, by, );
ay("", 1, __func__, r::aw, "");
if (bw != bt)
  delete bw;
__builtin___memcpy_chk(b, c, bd, 0);
cb.ch.i();
bool ci = cj((L *)cf, bg);
bool atran = bq && bp && cb.ck;
if (atran && !ci && cm())
  if (cn > co) {
int cp = cb.cq % 6;
v cs = *(ct + cp);
if (cu())
  cl = true;
  }
if (ci)
  if (k)
cv.aj();
cv.h();
b = cc((int *)bw, false, by, );
if (b)
  if (cw(, by, bz))
if (atran && bp && cx())
  cv.aj();
if (cl)
  if (k)
cv.aj();
cv.h();
int cp = cb.cq % 6;
v cs = *(ct + cp);
if (cy())
  err = true;
O da = *(db + cp);
if (da.dc->am() > cs.dc->am() + cs.dd->am() + 1 && de())
  cv.aj();
return !err;
  }
  bool ba(const int &, p *, bool) {
d kit, df;
while (kit != df)
  ;
cx();
  }
  bool az(const g &, unsigned) {
t dj;
int cur;
while (cur) {
  int dk, dl;
  char dbuf;
  dj.bb(, dl, , dk);
}
  }
  struct L {};
  struct u {
j ch;
a cq;
bool ck;
  };
  struct v {
o *dd;
o *dc;
  };
  struct O {
o *dc;
  };
  bool cy();
  bool cu(v *);
  bool cj(L *, p *);
  bool de(O *);
  u *cc(int *, bool, a *, int *);
  bool cw(u *, a *, int);
  bool cx() {
dm.dn();
bool err = false;
if (dm.l())
  err = true;
return !err;
  }
  bool cm(u *);
  j cv;
  int br;
  bool bs;
  bool bq;
  bk dm;
  a co;
  n cn;
  v ct[6];
  O db[6];
  bool bp;
};
class w : q {
public:
  void dn();
  bool l() {
m(true);
if (br)
  ay("", 1087, __func__, r::au, "");
return false;
  }
  int br;
};
bool s::bj() {
  bi->az("");
  new t;
}

[Bug target/91886] [10 regression] powerpc64 impossible constraint in asm

[nsz at gcc dot gnu.org]

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

--- Comment #31 from nsz at gcc dot gnu.org ---
(In reply to Segher Boessenkool from comment #28)
> [ "ws" needs at least a Power7, btw. ]

powerpc64le-* implies power8 and that's where this came up.

[Bug tree-optimization/92351] [10 Regression] Wrong code with -O3 -match=skylake since r277569

[avieira at gcc dot gnu.org]

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

--- Comment #3 from avieira at gcc dot gnu.org ---
Author: avieira
Date: Fri Nov  8 13:52:56 2019
New Revision: 277974

URL: https://gcc.gnu.org/viewcvs?rev=277974=gcc=rev
Log:
[vect] PR 92351: When peeling for alignment make alignment of epilogues unknown

gcc/ChangeLog:
2019-11-08  Andre Vieira  

PR tree-optimization/92351
* tree-vect-data-refs.c (vect_compute_data_ref_alignment): When we are
peeling the main loop for alignment, make sure to set the misalignment
of the epilogue's data references to DR_MISALIGNMENT_UNKNOWN.

gcc/testsuite/ChangeLog:
2019-11-08  Andre Vieira  

PR tree-optimization/92351
* gcc.dg/vect/vect-peel-2.c: Disable epilogue vectorization and
split the source of this test to...
* gcc.dg/vect/vect-peel-2-src.c: ... This.
* gcc.dg/vect/vect-peel-2-epilogues.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/vect/vect-peel-2-epilogues.c
trunk/gcc/testsuite/gcc.dg/vect/vect-peel-2-src.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/vect/vect-peel-2.c
trunk/gcc/tree-vect-data-refs.c

[Bug c++/92423] New: Reference assigned from a ternary results in destructor call

[tpg+gcc at mutabah dot net]

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

Bug ID: 92423
   Summary: Reference assigned from a ternary results in
destructor call
   Product: gcc
   Version: 9.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tpg+gcc at mutabah dot net
  Target Milestone: ---

The following code compiles with g++ 9.2.0, but calls `Foo`'s destructor twice.
```
#include 

struct Foo
{
Foo() {
printf("Foo()\n");
}
Foo(const Foo& x) = delete;
Foo(Foo&& x) = delete;
Foo& operator=(const Foo&) = delete;
Foo& operator=(Foo&&) = delete;
~Foo() {
printf("~Foo()\n");
}
};

int main() {
Foo base_foo;
const auto& my_foo = (true ? base_foo : throw "");
printf("Selected a foo\n");
return 0;
}
```

[Bug middle-end/92410] Invalid access to df->insns[] in regstat_bb_compute_calls_crossed (caught by hwasan)

[matmal01 at gcc dot gnu.org]

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

--- Comment #5 from Matthew Malcomson  ---
I've had a little look into it, and the below seems promising:

Based on a comment in haifa-sched.c, notes are removed before scheduling and
added back in.
Since the insn that is larger than the df buffer is a note, and I saw in gdb
that it's added during `reemit_notes`, I figure the root problem might be that
the notes are removed, then the df->insns array is calculated, then notes are
added back in.

I hence tested the below patch, and the testcase that Martin found no longer
crashes.

I have not yet looked into whether `df_recompute_luids` is the correct function
to call or if there's a better approach.  Just sharing an update.


diff --git a/gcc/haifa-sched.c b/gcc/haifa-sched.c
index 41cf1f3..564a358 100644
--- a/gcc/haifa-sched.c
+++ b/gcc/haifa-sched.c
@@ -6231,6 +6231,7 @@ commit_schedule (rtx_insn *prev_head, rtx_insn *tail,
basic_block *target_bb)
reemit_notes (insn);
   last_scheduled_insn = insn;
 }
+  df_recompute_luids(*target_bb);

   scheduled_insns.truncate (0);
 }
diff --git a/gcc/regstat.c b/gcc/regstat.c
index 4da9b7c..c6cefb11 100644
--- a/gcc/regstat.c
+++ b/gcc/regstat.c
@@ -324,6 +324,7 @@ regstat_bb_compute_calls_crossed (unsigned int bb_index,
bitmap live)

   FOR_BB_INSNS_REVERSE (bb, insn)
 {
+  gcc_assert (INSN_UID (insn) < DF_INSN_SIZE ());
   struct df_insn_info *insn_info = DF_INSN_INFO_GET (insn);
   unsigned int regno;

diff --git a/gcc/sel-sched-ir.c b/gcc/sel-sched-ir.c
index 8a1d414..5d8 100644
--- a/gcc/sel-sched-ir.c
+++ b/gcc/sel-sched-ir.c
@@ -4673,6 +4673,7 @@ sel_restore_notes (void)
if (NONDEBUG_INSN_P (insn))
  reemit_notes (insn);

+ df_recompute_luids (first);
   first = first->next_bb;
}
   while (first != last);

[Bug c++/80635] std::optional and bogus -Wmaybe-uninitialized warning

[lopezibanez at gmail dot com]

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

--- Comment #26 from Manuel López-Ibáñez  ---
Hi Martin,

Wouldn't it be better if the testcase tested that no warning is given for a
true case? Otherwise if the bug is fixed, no warning will be given, no
matter the option. Or have a testcase that the warning is given with the
option and not without .

On Fri, 8 Nov 2019, 12:42 jamborm at gcc dot gnu.org, <
gcc-bugzi...@gcc.gnu.org> wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80635
>
> --- Comment #25 from Martin Jambor  ---
> I have posted an RFC patch alleviating the situation somewhat to the
> mailing
> list:
>
> https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00614.html
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.

[Bug lto/92279] [10 Regression] ICE in error: non-trivial conversion in 'constructor' since r276416

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|RESOLVED|ASSIGNED
 Resolution|FIXED   |---
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org

--- Comment #2 from Martin Liška  ---
It's gone since r277616, I'm trying to reduce that, it's about FIELD_DECL and
I'm curious what it means..

[Bug testsuite/92391] gcc.dg/vect/bb-slp-40.c FAILs

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #4 from Joel Hutton  ---
> Hi Rainer
>
> I set up an account with cfarm, and tested on gcc202, the test fails because 
> on
> SPARC, no constructor is generated, the  for whatever reason (see below) 
> making
> the test not really applicable. I suggest making the test an xfail, so that if
> at some point in the future SPARC generates a constructor here the test will
> apply. The other option is to skip it for SPARC.

I've just checked gcc-testresults: the test also FAILs on
i586-unknown-freebsd11.2, i686-pc-linux-gnu, ia64-suse-linux-gnu,
powerpc-ibm-aix7.2.0.0, powerpc64-unknown-linux-gnu, and
s390x-ibm-linux-gnu.

Just adding an ever increasing list of xfail/skip's without really
understanding why the test fails or what is common between those targets
seems unmaintainable (and thus highly undesirable) to me.

[Bug ipa/92409] [10 regression] r277920 causes ICE in gcc.dg/cast-function-1.c

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug ipa/92409] [10 regression] r277920 causes ICE in gcc.dg/cast-function-1.c

[rguenth at gcc dot gnu.org]

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

--- Comment #13 from Richard Biener  ---
Author: rguenth
Date: Fri Nov  8 13:15:40 2019
New Revision: 277972

URL: https://gcc.gnu.org/viewcvs?rev=277972=gcc=rev
Log:
2019-11-08  Richard Biener  

PR ipa/92409
* tree-inline.c (declare_return_variable): Properly handle
type mismatches for the return slot.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-inline.c

[Bug tree-optimization/92283] [10 Regression] 454.calculix miscomparison since r276645 with -O2 -march=znver2

[rguenth at gcc dot gnu.org]

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

--- Comment #19 from Richard Biener  ---
(In reply to Alexander Monakov from comment #17)
> (In reply to Richard Biener from comment #16)
> > interestingly 66:66 and 67:67 generate exactly the same code and
> > 66:67 add a single loop.  That's totally odd but probably an
> > artifact of a bug in dbg_cnt_is_enabled which does
> > 
> > bool
> > dbg_cnt_is_enabled (enum debug_counter index)
> > {
> >   unsigned v = count[index];
> >   return v > limit_low[index] && v <= limit_high[index];
> > }
> > 
> > where it should be v >= limit_low[index].
> 
> This is intentionally like that, the idea is that a:b makes a half-open
> interval with the right bound (b) not included.  So 66:66 and 67:67 are both
> simply empty intervals.
> 
> dbg_cnt_is_enabled tests left bound with '>' and right bound with '<='
> because its caller (dbg_cnt) incremented the counter before the call.

How useful (not).  We then at least should reject -fdbg-cnt=foo:5:5

[Bug tree-optimization/92283] [10 Regression] 454.calculix miscomparison since r276645 with -O2 -march=znver2

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||amker at gcc dot gnu.org

--- Comment #18 from Richard Biener  ---
The fortran loop is

   real*8  vold(0:3,*),v(0:3,*)
...

if((iperturb.ne.0).and.(nmethod.eq.1)) then
   vmax=0.d0
   do i=1,nk
  do j=jmin,jmax
 vmax=max(vmax,dabs(v(j,i)))
c write(*,*) i,j,vold(j,i),v(j,i),vmax
 v(j,i)=v(j,i)+vold(j,i)
  enddo
   enddo
endif

and the .gimple diff

@@ -2536,21 +2970,29 @@
   vmax__lsm.757_3905 = [results.f:130:0] *vmax_2002(D);
   [results.f:130:0] _31 = (integer(kind=8)) i.120_4019;
   [results.f:130:0] _32 = _31 * 4;
+  ivtmp.773_566 = (sizetype) jmin_1722;

[local count: 4326176]:
-  # j.121_4017 = PHI <[results.f:129:0] jmin_1722(19), [results.f:129:0]
_39(670)>
+  # ivtmp.773_3273 = PHI 
   # vmax__lsm.757_1845 = PHI 
-  [results.f:130:0] _33 = (integer(kind=8)) j.121_4017;
-  [results.f:130:0] _34 = _32 + _33;
-  [results.f:130:0] _35 = _34 + -4;
-  [results.f:130:0] _36 = [results.f:130:0] [results.f:130:0]
(*v_2012(D))[_35];
+  _2429 = (sizetype) _32;
+  _565 = _2429 * 8;
+  _4606 = v_2012(D) + _565;
+  [results.f:130:0] _36 = MEM[base: _4606, index: ivtmp.773_3273, step: 8,
offset: -32B];
   [results.f:130:0] _2047 = ABS_EXPR <_36>;
   [results.f:130:0] M.64_2048 = MAX_EXPR ;
-  [results.f:132:0] _37 = [results.f:132:0] [results.f:132:0]
(*vold_2011(D))[_35];
+  _4529 = (sizetype) _32;
+  _558 = _4529 * 8;
+  _4481 = vold_2011(D) + _558;
+  [results.f:132:0] _37 = MEM[base: _4481, index: ivtmp.773_3273, step: 8,
offset: -32B];
   [results.f:132:0] _38 = _36 + _37;
-  [results.f:132:0] [results.f:132:0] [results.f:132:0] (*v_2012(D))[_35] =
_38;
-  [results.f:129:0] _39 = j.121_4017 + 1;
-  [results.f:129:0] if (_39 > jmax_1721)
+  _564 = (sizetype) _32;
+  _4573 = _564 * 8;
+  _560 = v_2012(D) + _4573;
+  [results.f:132:0] MEM[base: _560, index: ivtmp.773_3273, step: 8, offset:
-32B] = _38;
+  [results.f:129:0] ivtmp.773_1666 = ivtmp.773_3273 + 1;
+  _3693 = (integer(kind=4)) ivtmp.773_1666;
+  [results.f:129:0] if (_3693 > jmax_1721)
 goto ; [11.00%]
   else
 goto ; [89.00%]

but as far as I can see the IVOPTs transform is correct, assembly differences
are too large to swallow though (trying to disable scheduling).

[Bug tree-optimization/92283] [10 Regression] 454.calculix miscomparison since r276645 with -O2 -march=znver2

[amonakov at gcc dot gnu.org]

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

Alexander Monakov  changed:

   What|Removed |Added

 CC||amonakov at gcc dot gnu.org

--- Comment #17 from Alexander Monakov  ---
(In reply to Richard Biener from comment #16)
> interestingly 66:66 and 67:67 generate exactly the same code and
> 66:67 add a single loop.  That's totally odd but probably an
> artifact of a bug in dbg_cnt_is_enabled which does
> 
> bool
> dbg_cnt_is_enabled (enum debug_counter index)
> {
>   unsigned v = count[index];
>   return v > limit_low[index] && v <= limit_high[index];
> }
> 
> where it should be v >= limit_low[index].

This is intentionally like that, the idea is that a:b makes a half-open
interval with the right bound (b) not included.  So 66:66 and 67:67 are both
simply empty intervals.

dbg_cnt_is_enabled tests left bound with '>' and right bound with '<=' because
its caller (dbg_cnt) incremented the counter before the call.

[Bug target/91886] [10 regression] powerpc64 impossible constraint in asm

[nsz at gcc dot gnu.org]

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

--- Comment #30 from nsz at gcc dot gnu.org ---
i think it is not the end of the world if the asm constraint api
changes in this case: fixing musl is easy because it's not super
important to optimize fmin, fminf, fmax, fmaxf in libc (if it were
important then gcc should inline them instead of calling into libc,
currently it seems gcc is not able to do that without -ffast-math).

the change breaks the build of old musl releases with new gcc,
so as a general principle it makes more sense to me to keep
documented apis working (e.g. when glibc removed ustat, the gcc
devs asked for 5 years advance notice via deprecation warnings),
but it's up to the gcc maintainers to decide.

[Bug tree-optimization/92283] [10 Regression] 454.calculix miscomparison since r276645 with -O2 -march=znver2

[rguenth at gcc dot gnu.org]

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

--- Comment #16 from Richard Biener  ---
(In reply to Richard Biener from comment #12)
> Trying to bisect with IVOPTs debug-counter.
> 
> 65:69 FAIL
> 65:66 OK
> 67:69 OK
> 
> *sigh*

Back to this (ivopts_loop counter soon to be checked in).

66:68 FAIL
66:67 FAIL (66:66 OK 67:67 OK)

interestingly 66:66 and 67:67 generate exactly the same code and
66:67 add a single loop.  That's totally odd but probably an
artifact of a bug in dbg_cnt_is_enabled which does

bool
dbg_cnt_is_enabled (enum debug_counter index)
{
  unsigned v = count[index];
  return v > limit_low[index] && v <= limit_high[index];
}

where it should be v >= limit_low[index].  It's also nowhere documented
but zero is a value never in the set of tested values.

So it points to a single loops IVOPTs optimization.

[Bug target/92095] [8/9/10 regression] internal error with -O1 -mcpu=niagara2 -fPIE

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #8 from Eric Botcazou  ---
This should compile again.

[Bug c++/80635] std::optional and bogus -Wmaybe-uninitialized warning

[jamborm at gcc dot gnu.org]

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

--- Comment #25 from Martin Jambor  ---
I have posted an RFC patch alleviating the situation somewhat to the mailing
list:

https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00614.html

[Bug target/92095] [8/9/10 regression] internal error with -O1 -mcpu=niagara2 -fPIE

[ebotcazou at gcc dot gnu.org]

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

--- Comment #7 from Eric Botcazou  ---
Author: ebotcazou
Date: Fri Nov  8 12:38:03 2019
New Revision: 277968

URL: https://gcc.gnu.org/viewcvs?rev=277968=gcc=rev
Log:
PR target/92095
* config/sparc/sparc-protos.h (output_load_pcrel_sym): Declare.
* config/sparc/sparc.c (sparc_cannot_force_const_mem): Revert latest
change.
(got_helper_needed): New static variable.
(output_load_pcrel_sym): New function.
(get_pc_thunk_name): Remove after inlining...
(load_got_register): ...here.  Rework the initialization of the GOT
register and of the GOT helper.
(save_local_or_in_reg_p): Test the REGNO of the GOT register.
(sparc_file_end): Test got_helper_needed to decide whether the GOT
helper must be emitted.  Use output_asm_insn instead of fprintf.
(sparc_init_pic_reg): In PIC mode, always initialize the PIC register
if optimization is enabled.
* config/sparc/sparc.md (load_pcrel_sym): Emit the assembly
by calling output_load_pcrel_sym.

Added:
branches/gcc-8-branch/gcc/testsuite/gcc.c-torture/compile/20191108-1.c
  - copied unchanged from r277967,
trunk/gcc/testsuite/gcc.c-torture/compile/20191108-1.c
Modified:
branches/gcc-8-branch/gcc/ChangeLog
branches/gcc-8-branch/gcc/config/sparc/sparc-protos.h
branches/gcc-8-branch/gcc/config/sparc/sparc.c
branches/gcc-8-branch/gcc/config/sparc/sparc.md
branches/gcc-8-branch/gcc/testsuite/ChangeLog
branches/gcc-8-branch/gcc/testsuite/gcc.target/sparc/overflow-3.c
branches/gcc-8-branch/gcc/testsuite/gcc.target/sparc/overflow-4.c
branches/gcc-8-branch/gcc/testsuite/gcc.target/sparc/overflow-5.c

[Bug target/92095] [8/9/10 regression] internal error with -O1 -mcpu=niagara2 -fPIE

[ebotcazou at gcc dot gnu.org]

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

--- Comment #6 from Eric Botcazou  ---
Author: ebotcazou
Date: Fri Nov  8 12:33:48 2019
New Revision: 277967

URL: https://gcc.gnu.org/viewcvs?rev=277967=gcc=rev
Log:
PR target/92095
* config/sparc/sparc-protos.h (output_load_pcrel_sym): Declare.
* config/sparc/sparc.c (sparc_cannot_force_const_mem): Revert latest
change.
(got_helper_needed): New static variable.
(output_load_pcrel_sym): New function.
(get_pc_thunk_name): Remove after inlining...
(load_got_register): ...here.  Rework the initialization of the GOT
register and of the GOT helper.
(save_local_or_in_reg_p): Test the REGNO of the GOT register.
(sparc_file_end): Test got_helper_needed to decide whether the GOT
helper must be emitted.  Use output_asm_insn instead of fprintf.
(sparc_init_pic_reg): In PIC mode, always initialize the PIC register
if optimization is enabled.
* config/sparc/sparc.md (load_pcrel_sym): Emit the assembly
by calling output_load_pcrel_sym.

Added:
branches/gcc-9-branch/gcc/testsuite/gcc.c-torture/compile/20191108-1.c
  - copied unchanged from r277966,
trunk/gcc/testsuite/gcc.c-torture/compile/20191108-1.c
Modified:
branches/gcc-9-branch/gcc/ChangeLog
branches/gcc-9-branch/gcc/config/sparc/sparc-protos.h
branches/gcc-9-branch/gcc/config/sparc/sparc.c
branches/gcc-9-branch/gcc/config/sparc/sparc.md
branches/gcc-9-branch/gcc/testsuite/ChangeLog
branches/gcc-9-branch/gcc/testsuite/gcc.target/sparc/overflow-3.c
branches/gcc-9-branch/gcc/testsuite/gcc.target/sparc/overflow-4.c
branches/gcc-9-branch/gcc/testsuite/gcc.target/sparc/overflow-5.c

[Bug target/92095] [8/9/10 regression] internal error with -O1 -mcpu=niagara2 -fPIE

[ebotcazou at gcc dot gnu.org]

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

--- Comment #5 from Eric Botcazou  ---
Author: ebotcazou
Date: Fri Nov  8 12:30:47 2019
New Revision: 277966

URL: https://gcc.gnu.org/viewcvs?rev=277966=gcc=rev
Log:
PR target/92095
* config/sparc/sparc-protos.h (output_load_pcrel_sym): Declare.
* config/sparc/sparc.c (sparc_cannot_force_const_mem): Revert latest
change.
(got_helper_needed): New static variable.
(output_load_pcrel_sym): New function.
(get_pc_thunk_name): Remove after inlining...
(load_got_register): ...here.  Rework the initialization of the GOT
register and of the GOT helper.
(save_local_or_in_reg_p): Test the REGNO of the GOT register.
(sparc_file_end): Test got_helper_needed to decide whether the GOT
helper must be emitted.  Use output_asm_insn instead of fprintf.
(sparc_init_pic_reg): In PIC mode, always initialize the PIC register
if optimization is enabled.
* config/sparc/sparc.md (load_pcrel_sym): Emit the assembly
by calling output_load_pcrel_sym.

Added:
trunk/gcc/testsuite/gcc.c-torture/compile/20191108-1.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/sparc/sparc-protos.h
trunk/gcc/config/sparc/sparc.c
trunk/gcc/config/sparc/sparc.md
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/sparc/overflow-3.c
trunk/gcc/testsuite/gcc.target/sparc/overflow-4.c
trunk/gcc/testsuite/gcc.target/sparc/overflow-5.c

[Bug tree-optimization/92283] [10 Regression] 454.calculix miscomparison since r276645 with -O2 -march=znver2

[rguenther at suse dot de]

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

--- Comment #15 from rguenther at suse dot de  ---
On Fri, 8 Nov 2019, marxin at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92283
> 
> --- Comment #14 from Martin Liška  ---
> > 
> > more complex "ranges" for debug counters appreciated,
> 
> +1
> 
> > -fdbg-cnt=foo:{5-6,9,1-10} or some sorts of that (lists of ranges / values).
> > I'm definitely missing a all-but-N as well. ~6 and ~6-9 maybe.  Guess
> > {} don't work very well due to shell limitations so maybe
> > simply foo:5-6:9:1-10,bar:... with changing semantics of previous handling.
> 
> Note that the debug counter is mainly for us as developers, so I would not
> care much about backward compatibility.
> 
> > Implementation-wise we'd have instead of high/low arrays
> > an array of pair > which we only look at
> > the last element of the vec (sort it backwards), popping it whenever
> > we reach it's max and checking against the current min.  or some
> > other data structure mimicing this, that is, dbg_cnt () is still O(1)
> > just parsing the option might involve sorting.
> 
> Yes, one simple improvement can be:
> foo:5-6:9:10-100:1000 where we can enforce that ranges are in increasing
> order and not overlapping. Or we can sort the ranges and then dbg_cnt will
> be O(1) with the popping technique.

This simple improved format works for me.  For users sake I'd simply sort
the thing since we're going to need to reverse it anyways.  Then
-fdbg-cnt=foo:5 -fdbg-cnt=foo:1-3 would also be inclusive, effectively
setting 1-3:5?

[Bug tree-optimization/92283] [10 Regression] 454.calculix miscomparison since r276645 with -O2 -march=znver2

[marxin at gcc dot gnu.org]

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

--- Comment #14 from Martin Liška  ---
> 
> more complex "ranges" for debug counters appreciated,

+1

> -fdbg-cnt=foo:{5-6,9,1-10} or some sorts of that (lists of ranges / values).
> I'm definitely missing a all-but-N as well. ~6 and ~6-9 maybe.  Guess
> {} don't work very well due to shell limitations so maybe
> simply foo:5-6:9:1-10,bar:... with changing semantics of previous handling.

Note that the debug counter is mainly for us as developers, so I would not
care much about backward compatibility.

> Implementation-wise we'd have instead of high/low arrays
> an array of pair > which we only look at
> the last element of the vec (sort it backwards), popping it whenever
> we reach it's max and checking against the current min.  or some
> other data structure mimicing this, that is, dbg_cnt () is still O(1)
> just parsing the option might involve sorting.

Yes, one simple improvement can be:
foo:5-6:9:10-100:1000 where we can enforce that ranges are in increasing
order and not overlapping. Or we can sort the ranges and then dbg_cnt will
be O(1) with the popping technique.

I can work on that after we discuss the extended format.

[Bug tree-optimization/92283] [10 Regression] 454.calculix miscomparison since r276645 with -O2 -march=znver2

[rguenth at gcc dot gnu.org]

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

--- Comment #13 from Richard Biener  ---
(In reply to Richard Biener from comment #12)
> more complex "ranges" for debug counters appreciated,
> -fdbg-cnt=foo:{5-6,9,1-10} or some sorts of that (lists of ranges / values).
> I'm definitely missing a all-but-N as well. ~6 and ~6-9 maybe.  Guess
> {} don't work very well due to shell limitations so maybe
> simply foo:5-6:9:1-10,bar:... with changing semantics of previous handling.
> Implementation-wise we'd have instead of high/low arrays
> an array of pair > which we only look at
> the last element of the vec (sort it backwards), popping it whenever
> we reach it's max and checking against the current min.  or some
> other data structure mimicing this, that is, dbg_cnt () is still O(1)
> just parsing the option might involve sorting.

If we store the "inverse" in the vector then an empty vector would be
the natural default value [0,+INF] included.  So we could continue to
statically initialize it (or treat .exists () as special value as
opposed to empty).

[Bug tree-optimization/92283] [10 Regression] 454.calculix miscomparison since r276645 with -O2 -march=znver2

[rguenth at gcc dot gnu.org]

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

--- Comment #12 from Richard Biener  ---
Tackling from the tuning side, -mfma -mtune=znver2 miscompares,
-mtune=generic doesn't [checkme].

Using -mfma -mtune=generic
-mtune-ctrl=^fuse_alu_and_branch,^lcp_stall,use_incdec,^avoid_false_dep_for_bmi,^one_if_conv_insn,use_ffreep,^ext_80387_constants,sse_packed_single_insn_optimal,avoid_fma_chains,avoid_fma256_chains,256_unaligned_load_optimal,256_unaligned_store_optimal,^qimode_math
(all tunables to the znver2 variant) doesn't miscompare

on the gimple side IVOPTs and avoid_fma_chains makes a difference

-O2 -mfma -mtune=generic -fno-schedule-insns2 is OK
-O2 -mfma -mtune=znver2 -fno-schedule-insns2 -mtune-ctrl=^avoid_fma_chains
FAILs
-O2 -mfma -mtune=znver2 -fno-schedule-insns2 -mtune-ctrl=^avoid_fma_chains
-fno-ivopts is OK
-O2 -mfma -mtune=znver2 -fno-schedule-insns2 -fno-ivopts is OK
-O2 -mfma -mtune=znver2 -fno-ivopts is OK

Trying to bisect with IVOPTs debug-counter.

65:69 FAIL
65:66 OK
67:69 OK

*sigh*

more complex "ranges" for debug counters appreciated,
-fdbg-cnt=foo:{5-6,9,1-10} or some sorts of that (lists of ranges / values).
I'm definitely missing a all-but-N as well. ~6 and ~6-9 maybe.  Guess
{} don't work very well due to shell limitations so maybe
simply foo:5-6:9:1-10,bar:... with changing semantics of previous handling.
Implementation-wise we'd have instead of high/low arrays
an array of pair > which we only look at
the last element of the vec (sort it backwards), popping it whenever
we reach it's max and checking against the current min.  or some
other data structure mimicing this, that is, dbg_cnt () is still O(1)
just parsing the option might involve sorting.

[Bug testsuite/92415] new test case g++.dg/cpp2a/spaceship-scalar1-neg.C introduced in r277925 fails

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
I think r277934 should have fixed this already.

[Bug testsuite/92391] gcc.dg/vect/bb-slp-40.c FAILs

[joel.hutton at arm dot com]

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

--- Comment #4 from Joel Hutton  ---
Hi Rainer

I set up an account with cfarm, and tested on gcc202, the test fails because on
SPARC, no constructor is generated, the  for whatever reason (see below) making
the test not really applicable. I suggest making the test an xfail, so that if
at some point in the future SPARC generates a constructor here the test will
apply. The other option is to skip it for SPARC.

tree output on SPARC at the slp pass:
.
.
.
  MEM[(char *)d_202 + 25B] = _136;
  # .MEM_233 = VDEF <.MEM_232>
  MEM[(char *)d_202 + 26B] = _140;
  # .MEM_234 = VDEF <.MEM_233>
  MEM[(char *)d_202 + 27B] = _144;
  # .MEM_235 = VDEF <.MEM_234>
  MEM[(char *)d_202 + 28B] = _148;
  # .MEM_236 = VDEF <.MEM_235>
  MEM[(char *)d_202 + 29B] = _152;
  # .MEM_237 = VDEF <.MEM_236>
  MEM[(char *)d_202 + 30B] = _156;
  # .MEM_238 = VDEF <.MEM_237>
  MEM[(char *)d_202 + 31B] = _160;
  # PT = { D.1522 } (nonlocal, interposable)
  d_239 = d_202 + 32;

[Bug ipa/92409] [10 regression] r277920 causes ICE in gcc.dg/cast-function-1.c

[rguenther at suse dot de]

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

--- Comment #12 from rguenther at suse dot de  ---
On Fri, 8 Nov 2019, jamborm at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92409
> 
> --- Comment #11 from Martin Jambor  ---
> (In reply to Richard Biener from comment #8)
> > @@ -3634,6 +3636,10 @@ declare_return_variable (copy_body_data
> >   && !DECL_GIMPLE_REG_P (result)
> >   && DECL_P (var))
> > DECL_GIMPLE_REG_P (var) = 0;
> > +
> > +  if (!useless_type_conversion_p (callee_type, caller_type))
> > +   var = build1 (VIEW_CONVERT_EXPR, callee_type, var);
> > +
> >use = NULL;
> >goto done;
> >  }
> 
> OK, but please note that the callee_type and caller_type have
> different sizes here:
> 
> (gdb) pt callee_type
>   size  bitsizetype> constant 32>...
> 
> (gdb) pt caller_type
>   size  bitsizetype> constant 96>...
> 
> ...so you are creating a size-mismatched V_C_E.  Don't you want to use
> force_value_to_type instead?

No, I need an lvalue here.  Note V_C_Es like this are OK-ish (Ada
creates those as well).  In the end we're moving the mismatch handling
to RTL which eventually will simply push to a stack slot and do a bitfield
read (or ICE ...).

[Bug tree-optimization/92420] [7/8/9/10 Regression] Vectorization miscompilation with negative strides since r238039

[rsandifo at gcc dot gnu.org]

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

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  
---
Mine

[Bug middle-end/92384] [8/9 Regression] Empty class instances have different equal testing result among GCC versions

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[8/9/10 Regression] Empty   |[8/9 Regression] Empty
   |class instances have|class instances have
   |different equal testing |different equal testing
   |result among GCC versions   |result among GCC versions

--- Comment #6 from Jakub Jelinek  ---
Should be fixed on the trunk, will wait a little bit before backporting it to
release branches.

[Bug target/92038] Extremely inefficient x86_64 code for trivally copyable types passed in registers.

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek  ---
Author: jakub
Date: Fri Nov  8 10:53:50 2019
New Revision: 277963

URL: https://gcc.gnu.org/viewcvs?rev=277963=gcc=rev
Log:
PR target/92038
* gimple-ssa-store-merging.c (find_constituent_stores): For return
value only, return non-NULL if there is a single non-clobber
constituent store even if there are constituent clobbers and return
one of clobber constituent stores if all constituent stores are
clobbers.
(split_group): Handle clobbers.
(imm_store_chain_info::output_merged_store): When computing
bzero_first, look after all clobbers at the start.  Don't count
clobber stmts in orig_num_stmts, except if the first orig store is
a clobber covering the whole area and split_stores cover the whole
area, consider equal number of stmts ok.  Punt if split_stores
contains only ->orig stores and their number plus number of original
clobbers is equal to original number of stmts.  For ->orig, look past
clobbers in the constituent stores.
(imm_store_chain_info::output_merged_stores): Don't remove clobber
stmts.
(rhs_valid_for_store_merging_p): Don't return false for clobber stmt
rhs.
(store_valid_for_store_merging_p): Allow clobber stmts.
(verify_clear_bit_region_be): Fix up a thinko in function comment.

* g++.dg/opt/store-merging-1.C: New test.
* g++.dg/opt/store-merging-2.C: New test.
* g++.dg/opt/store-merging-3.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/opt/store-merging-1.C
trunk/gcc/testsuite/g++.dg/opt/store-merging-2.C
trunk/gcc/testsuite/g++.dg/opt/store-merging-3.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple-ssa-store-merging.c
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/92384] [8/9/10 Regression] Empty class instances have different equal testing result among GCC versions

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Fri Nov  8 10:52:50 2019
New Revision: 277962

URL: https://gcc.gnu.org/viewcvs?rev=277962=gcc=rev
Log:
PR c++/92384
* function.c (assign_parm_setup_block, assign_parm_setup_stack): Don't
copy TYPE_EMPTY_P arguments from data->entry_parm to data->stack_parm
slot.
(assign_parms): For TREE_ADDRESSABLE parms with TYPE_EMPTY_P type
force creation of a unique data.stack_parm slot.

* g++.dg/torture/pr92384.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/torture/pr92384.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/function.c
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/92419] const variable aliases lead to folding non-const initializers

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
bool 
varpool_node::ctor_useable_for_folding_p (void)
{
...
  /* Alias of readonly variable is also readonly, since the variable is stored
 in readonly memory.  We also accept readonly aliases of non-readonly
 locations assuming that user knows what he is asking for.  */
  if (!TREE_READONLY (decl) && !TREE_READONLY (real_node->decl))
return false;

so looks like this is done on purpose?  Shouldn't we then diagnose
those aliases?  I'd have done

  if (!TREE_READONLY (real_node->decl))
return false;

since as the comment says whether the variable may be stored in readonly
memory or not is what matters.  Was there a real reason to be this
forgiving for the testcase at hand?  Just to avoid the "asymmetry"
with the non-const alias of a const var?

Better testcase w/o unused 'tem':

int var = 3;
extern const int const_var __attribute__((alias("var")));

void bar()
{
  var = 5;
}
int foo()
{
  int tem = const_var;
  bar ();
  return const_var - tem;
}
int main()
{
  if (foo() != 2)
__builtin_abort ();
  return 0;
}

[Bug ipa/92409] [10 regression] r277920 causes ICE in gcc.dg/cast-function-1.c

[jamborm at gcc dot gnu.org]

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

--- Comment #11 from Martin Jambor  ---
(In reply to Richard Biener from comment #8)
> @@ -3634,6 +3636,10 @@ declare_return_variable (copy_body_data
>   && !DECL_GIMPLE_REG_P (result)
>   && DECL_P (var))
> DECL_GIMPLE_REG_P (var) = 0;
> +
> +  if (!useless_type_conversion_p (callee_type, caller_type))
> +   var = build1 (VIEW_CONVERT_EXPR, callee_type, var);
> +
>use = NULL;
>goto done;
>  }

OK, but please note that the callee_type and caller_type have
different sizes here:

(gdb) pt callee_type
  constant 32>...

(gdb) pt caller_type
  constant 96>...

...so you are creating a size-mismatched V_C_E.  Don't you want to use
force_value_to_type instead?

[Bug c++/92421] [10 Regression] ice in inline_small_functions, at ipa-inline.c:2001

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||needs-reduction
 CC||hubicka at gcc dot gnu.org
   Target Milestone|--- |10.0
Summary|ice in  |[10 Regression] ice in
   |inline_small_functions, at  |inline_small_functions, at
   |ipa-inline.c:2001   |ipa-inline.c:2001

--- Comment #2 from Richard Biener  ---
Those asserts again...

[Bug c++/92421] ice in inline_small_functions, at ipa-inline.c:2001

[dcb314 at hotmail dot com]

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

--- Comment #1 from David Binderman  ---
gcc trunk first seems to go wrong sometime between revision
277750 and 277800.

[Bug ipa/92409] [10 regression] r277920 causes ICE in gcc.dg/cast-function-1.c

[rguenth at gcc dot gnu.org]

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

--- Comment #10 from Richard Biener  ---
(In reply to Martin Jambor from comment #9)
> Created attachment 47199 [details]
> Fixed fix
> 
> Uh, the conversion must be on the RHS, not the LHS.  I'm testing this patch,
> it should be the right one now :-)

I'm testing the other patch which IMHO is better (more testing coverage
would be nice though).

[Bug fortran/92422] New: Warning with character and optimisation flags

[moad212 at hotmail dot com]

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

Bug ID: 92422
   Summary: Warning with character and optimisation flags
   Product: gcc
   Version: 9.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: moad212 at hotmail dot com
  Target Milestone: ---

When I compile the Fortran test program:

***

PROGRAM character_warning

  CHARACTER(len=16) :: word

  word = 'hi'
  WRITE(*,*) word

END PROGRAM character_warning

***

with 'gfortran -Warray-bounds -O2 character_warning.f90', I get a warning:

***

character_warning.f90:5:0:

5 |   word = 'hi'
  | 
Warning: array subscript 0 is outside array bounds of 'character(kind=1)[1:16]'
[-Warray-bounds]
character_warning.f90:3:0:

3 |   CHARACTER(len=16) :: word
  | 
note: while referencing 'word'

***

This only started to happened when I upgraded to gfortran9 from gfortran8. I
don't understand why the warning is being thrown and would like to remove it so
that my compilation is clean. The warning goes away if I lower the optimisation
to -O1 or if I remove the -Warray-bounds flag (maybe obviously).

I posted about this on stackoverflow here:
https://stackoverflow.com/questions/58752319/array-bounds-warning-with-character-in-gfortran

[Bug ipa/92409] [10 regression] r277920 causes ICE in gcc.dg/cast-function-1.c

[jamborm at gcc dot gnu.org]

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

Martin Jambor  changed:

   What|Removed |Added

  Attachment #47195|0   |1
is obsolete||

--- Comment #9 from Martin Jambor  ---
Created attachment 47199
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47199=edit
Fixed fix

Uh, the conversion must be on the RHS, not the LHS.  I'm testing this patch, it
should be the right one now :-)

[Bug c/92088] aggregates with VLAs and nested functions are broken

[ebotcazou at gcc dot gnu.org]

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

--- Comment #10 from Eric Botcazou  ---
> VLAs are always passed by reference in Ada.

And, more generally, any type with variable size is too.

[Bug c/92088] aggregates with VLAs and nested functions are broken

[ebotcazou at gcc dot gnu.org]

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

--- Comment #9 from Eric Botcazou  ---
> I don't think the inliner should work around this - this hasn't been
> necessary for Ada which is a good sign here.  Eric - how does GiGi handle 
> this 
> case?

VLAs are always passed by reference in Ada.

[Bug ipa/92409] [10 regression] r277920 causes ICE in gcc.dg/cast-function-1.c

[rguenth at gcc dot gnu.org]

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

--- Comment #8 from Richard Biener  ---
I think the fix is more like the following to make declare_return_variable
notice the mismatch.  That alone might not be enough but the fix should be
there.  I assume that we use a return slot only for non-registers
because those are the only valid uses of VIEW_CONVERT_EXPRs on lvalues.

Index: gcc/tree-inline.c
===
--- gcc/tree-inline.c   (revision 277955)
+++ gcc/tree-inline.c   (working copy)
@@ -3593,7 +3593,9 @@ declare_return_variable (copy_body_data
  vs. the call expression.  */
   if (modify_dest)
 caller_type = TREE_TYPE (modify_dest);
-  else
+  else if (return_slot)
+caller_type = TREE_TYPE (return_slot);
+  else /* No LHS on the call.  */
 caller_type = TREE_TYPE (TREE_TYPE (callee));

   /* We don't need to do anything for functions that don't return anything. 
*/
@@ -3634,6 +3636,10 @@ declare_return_variable (copy_body_data
  && !DECL_GIMPLE_REG_P (result)
  && DECL_P (var))
DECL_GIMPLE_REG_P (var) = 0;
+
+  if (!useless_type_conversion_p (callee_type, caller_type))
+   var = build1 (VIEW_CONVERT_EXPR, callee_type, var);
+
   use = NULL;
   goto done;
 }

[Bug ipa/92409] [10 regression] r277920 causes ICE in gcc.dg/cast-function-1.c

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Assignee|jamborm at gcc dot gnu.org |rguenth at gcc dot 
gnu.org
   Target Milestone|--- |10.0

[Bug ipa/92409] [10 regression] r277920 causes ICE in gcc.dg/cast-function-1.c

[jamborm at gcc dot gnu.org]

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

--- Comment #7 from Martin Jambor  ---
Ah sorry, looking at my bash history, yesterday I somehow lost the -m32 on my
command line :-(  Will try again.

[Bug tree-optimization/92420] [7/8/9/10 Regression] Vectorization miscompilation with negative strides since r238039

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Keywords||wrong-code
   Priority|P3  |P2
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-11-08
 CC||rsandifo at gcc dot gnu.org
   Target Milestone|--- |7.5
 Ever confirmed|0   |1

[Bug c++/92421] New: ice in inline_small_functions, at ipa-inline.c:2001

[dcb314 at hotmail dot com]

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

Bug ID: 92421
   Summary: ice in inline_small_functions, at ipa-inline.c:2001
   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 47198
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47198=edit
gzipped C++ source code

For the attached C++ code with recent gcc trunk and compiler flag -O3,
does this:

$ /home/dcb/gcc/results/bin/gcc -c -O3 /tmp/q.ii
during IPA pass: inline
chewing_large_table2_kyotodb.cpp:426:2: internal compiler error: in
inline_small_functions, at ipa-inline.c:2001
0x8b15f7 inline_small_functions
../../trunk/gcc/ipa-inline.c:2001
0x8b15f7 ipa_inline
../../trunk/gcc/ipa-inline.c:2616
0x8b15f7 execute
../../trunk/gcc/ipa-inline.c:3024

I'll have my usual go at reducing the code and finding a revision range.