[Bug fortran/99840] [9/10/11 Regression] ICE in gfc_simplify_matmul, at fortran/simplify.c:4777

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

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

--- Comment #9 from CVS Commits  ---
The master branch has been updated by Harald Anlauf :

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

commit r11-7943-gd7cef070bf43bfb3f3d77bac42eadea06c4b0281
Author: Harald Anlauf 
Date:   Thu Apr 1 07:49:32 2021 +0200

PR fortran/99840 - ICE in gfc_simplify_matmul, at fortran/simplify.c:4777

The simplification of the transposition of a constant array shall properly
initialize and set the shape of the result.

gcc/fortran/ChangeLog:

PR fortran/99840
* simplify.c (gfc_simplify_transpose): Properly initialize
resulting shape.

gcc/testsuite/ChangeLog:

PR fortran/99840
* gfortran.dg/transpose_5.f90: New test.

[Bug c++/99737] [modules] malloc(): smallbin double linked list corrupted

[alexander.lelyakin at googlemail dot com via Gcc-bugs]

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

--- Comment #4 from Alexander Lelyakin  ---
Today's sequence is:

/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header tuple
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header set
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header cmath
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header locale
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header filesystem

Repeatedly running this sequence i have found that it produces little different
error messages every time. 
1
corrupted double-linked list
In file included from /usr/local/include/c++/11.0.1/bits/shared_ptr.h:53,
 from /usr/local/include/c++/11.0.1/bits/fs_path.h:46,
 from /usr/local/include/c++/11.0.1/filesystem:45:
/usr/local/include/c++/11.0.1/bits/shared_ptr_base.h:1851:34: internal compiler
error: Aborted
 1851 | : public __hash_base>
  |  ^
0x110a6ff crash_signal
../../gcc/gcc/toplev.c:327
0x1d549f4 xcalloc
../../gcc/libiberty/xmalloc.c:162
0xae35f6 xcallocator::data_alloc(unsigned long)
../../gcc/gcc/hash-table.h:275
0xae35f6 hash_table, false,
xcallocator>::alloc_entries(unsigned long) const
../../gcc/gcc/hash-table.h:711
0xae35f6 hash_table, false,
xcallocator>::hash_table(unsigned long, bool, bool, bool, mem_alloc_origin)
../../gcc/gcc/hash-table.h:628
0xae3d50 hash_set
>::hash_set(unsigned long, bool)
../../gcc/gcc/hash-set.h:41
0xae3d50 for_each_template_parm
../../gcc/gcc/cp/pt.c:10564
0xac06cc cp_parser_type_id_1
../../gcc/gcc/cp/parser.c:23221
0xac2be3 cp_parser_template_type_arg
../../gcc/gcc/cp/parser.c:23275
0xac2d0f cp_parser_template_argument
../../gcc/gcc/cp/parser.c:17915
0xac2d0f cp_parser_template_argument_list
../../gcc/gcc/cp/parser.c:17826
0xac2d0f cp_parser_enclosed_template_argument_list
../../gcc/gcc/cp/parser.c:30799
0xac4066 cp_parser_template_id
../../gcc/gcc/cp/parser.c:17398
0xac47fb cp_parser_class_name
../../gcc/gcc/cp/parser.c:24692
0xabbcaa cp_parser_qualifying_entity
../../gcc/gcc/cp/parser.c:7002
0xabbcaa cp_parser_nested_name_specifier_opt
../../gcc/gcc/cp/parser.c:6684
0xaaf80c cp_parser_base_specifier
../../gcc/gcc/cp/parser.c:26711
0xaaf80c cp_parser_base_clause
../../gcc/gcc/cp/parser.c:26564
0xaaf80c cp_parser_class_head
../../gcc/gcc/cp/parser.c:25651
0xaaf80c cp_parser_class_specifier_1
../../gcc/gcc/cp/parser.c:24814
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

2
corrupted double-linked list
In file included from /usr/local/include/c++/11.0.1/bits/shared_ptr.h:53,
 from /usr/local/include/c++/11.0.1/bits/fs_path.h:46,
 from /usr/local/include/c++/11.0.1/filesystem:45:
/usr/local/include/c++/11.0.1/bits/shared_ptr_base.h:1851:52: internal compiler
error: Aborted
 1851 | : public __hash_base>
  |^~~
0x110a6ff crash_signal
../../gcc/gcc/toplev.c:327
0x1d549f4 xcalloc
../../gcc/libiberty/xmalloc.c:162
0x13f3fd9 xcallocator::data_alloc(unsigned long)
../../gcc/gcc/hash-table.h:275
0x13f3fd9 hash_table, false,
xcallocator>::alloc_entries(unsigned long) const
../../gcc/gcc/hash-table.h:711
0x13f3fd9 hash_table, false,
xcallocator>::hash_table(unsigned long, bool, bool, bool, mem_alloc_origin)
../../gcc/gcc/hash-table.h:628
0x13f3fd9 hash_set
>::hash_set(unsigned long, bool)
../../gcc/gcc/hash-set.h:41
0x13f3fd9 walk_tree_without_duplicates_1(tree_node**, tree_node*
(*)(tree_node**, int*, void*), void*, tree_node* (*)(tree_node**, int*,
tree_node* (*)(tree_node**, int*, void*), void*, hash_set >*))
../../gcc/gcc/tree.c:12474
0xaf4b99 instantiation_dependent_uneval_expression_p(tree_node*)
../../gcc/gcc/cp/pt.c:27494
0xaf4b99 instantiation_dependent_expression_p(tree_node*)
../../gcc/gcc/cp/pt.c:27504
0x982285 is_nondependent_constant_expression(tree_node*)
../../gcc/gcc/cp/constexpr.c:8960
0x982285 is_nondependent_constant_expression(tree_node*)
../../gcc/gcc/cp/constexpr.c:8956
0x98308f maybe_constant_value(tree_node*, tree_node*, bool)
../../gcc/gcc/cp/constexpr.c:7432
0xb23c0c convert_nontype_argument
../../gcc/gcc/cp/pt.c:7274
0xb23c0c convert_template_argument
../../gcc/gcc/cp/pt.c:8508
0xb259c3 coerce_template_parms
../../gcc/gcc/cp/pt.c:8987
0xb286d9 lookup_template_class_1
../../gcc/gcc/cp/pt.c:9825
0xb2a47c lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*,
int, int)
../../gcc/gcc/cp/pt.c:10211
0xb5285b finish_template_type(tree_node*, tree_node*, 

[Bug c++/99861] New: [modules] ICE in hashtab_chk_error

[alexander.lelyakin at googlemail dot com via Gcc-bugs]

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

Bug ID: 99861
   Summary: [modules] ICE in hashtab_chk_error
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: alexander.lelyakin at googlemail dot com
  Target Milestone: ---

/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header latch
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header cfenv
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header clocale
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header cmath
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header ciso646
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header unordered_map
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header algorithm

hash table checking failed: equal operator returns true for a pair of values
with a different hash value
In file included from /usr/local/include/c++/11.0.1/vector:66,
 from /usr/local/include/c++/11.0.1/functional:62,
 from
/usr/local/include/c++/11.0.1/pstl/glue_algorithm_defs.h:13,
 from /usr/local/include/c++/11.0.1/algorithm:74:
/usr/local/include/c++/11.0.1/bits/stl_uninitialized.h: In static member
function ‘static _ForwardIterator
std::__uninitialized_copy::__uninit_copy(_InputIterator, _InputIterator,
_ForwardIterator)’:
/usr/local/include/c++/11.0.1/bits/stl_uninitialized.h:110:23: internal
compiler error: in hashtab_chk_error, at hash-table.c:137
  110 | { return std::copy(__first, __last, __result); }
  |   ^~~~
0x92894b hashtab_chk_error()
../../gcc/gcc/hash-table.c:137
0xb35fa5 hash_table::verify(spec_entry*
const&, unsigned int)
../../gcc/gcc/hash-table.h:1033
0xb3652e hash_table::find_slot_with_hash(spec_entry* const&, unsigned int,
insert_option)
../../gcc/gcc/hash-table.h:968
0xaf315b match_mergeable_specialization(bool, spec_entry*)
../../gcc/gcc/cp/pt.c:29942
0xa6cf43 trees_in::key_mergeable(int, merge_kind, tree_node*, tree_node*,
tree_node*, tree_node*, bool)
../../gcc/gcc/cp/module.cc:10667
0xa70564 trees_in::decl_value()
../../gcc/gcc/cp/module.cc:7899
0xa693c7 trees_in::tree_node(bool)
../../gcc/gcc/cp/module.cc:9150
0xa6f9eb module_state::read_cluster(unsigned int)
../../gcc/gcc/cp/module.cc:14797
0xa6feed module_state::load_section(unsigned int, binding_slot*)
../../gcc/gcc/cp/module.cc:18068
0xa6ffaf module_state::lazy_load(unsigned int, binding_slot*)
../../gcc/gcc/cp/module.cc:18726
0xa6a230 trees_in::tree_node(bool)
../../gcc/gcc/cp/module.cc:9661
0xa6b046 trees_in::core_vals(tree_node*)
../../gcc/gcc/cp/module.cc:6662
0xa68a97 trees_in::tree_node_vals(tree_node*)
../../gcc/gcc/cp/module.cc:7057
0xa68a97 trees_in::tree_value()
../../gcc/gcc/cp/module.cc:8927
0xa68ecf trees_in::tree_node(bool)
../../gcc/gcc/cp/module.cc:9145
0xa6acd1 trees_in::core_vals(tree_node*)
../../gcc/gcc/cp/module.cc:6413
0xa68a97 trees_in::tree_node_vals(tree_node*)
../../gcc/gcc/cp/module.cc:7057
0xa68a97 trees_in::tree_value()
../../gcc/gcc/cp/module.cc:8927
0xa68ecf trees_in::tree_node(bool)
../../gcc/gcc/cp/module.cc:9145
0xa6acd1 trees_in::core_vals(tree_node*)
../../gcc/gcc/cp/module.cc:6413
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

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

[Bug middle-end/99857] [11 Regression] FAIL: libgomp.c/declare-variant-1.c (test for excess errors) by r11-7926

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

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

Martin Liška  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED
 CC||marxin at gcc dot gnu.org

--- Comment #1 from Martin Liška  ---
Fixed with g:23ce9945d5efa77c96161443f68e03664705ada3.

[Bug tree-optimization/99856] [9/10/11 Regression] Alpha Compositing auto vectorization regression

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

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

Martin Liška  changed:

   What|Removed |Added

   Last reconfirmed||2021-04-01
  Component|c   |tree-optimization
 Ever confirmed|0   |1
  Known to work||8.4.0
 Status|UNCONFIRMED |NEW
Summary|Alpha Compositing auto  |[9/10/11 Regression] Alpha
   |vectorization regression:   |Compositing auto
   |8.3 -> 9.1  |vectorization regression
  Known to fail||9.3.0
 CC||marxin at gcc dot gnu.org,
   ||rsandifo at gcc dot gnu.org

--- Comment #1 from Martin Liška  ---
Confirmed, started with r9-1590-g370c2ebe8fa20e08.

[Bug c++/78391] g++ (any version) at O0 (for O1, O2, O3 is ok) doesn't warn when class members are used uninitialized.

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

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

Martin Sebor  changed:

   What|Removed |Added

  Component|middle-end  |c++
   Severity|enhancement |normal

--- Comment #5 from Martin Sebor  ---
So the missing warning seems like it might be due to a bug in the C++ front
end.

[Bug middle-end/78391] g++ (any version) at O0 (for O1, O2, O3 is ok) doesn't warn when class members are used uninitialized.

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

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

Martin Sebor  changed:

   What|Removed |Added

  Known to fail||10.2.0, 11.0, 7.3.0, 8.3.0,
   ||9.2.0
 CC||msebor at gcc dot gnu.org
   Last reconfirmed|2016-11-17 00:00:00 |2021-3-31

--- Comment #4 from Martin Sebor  ---
Reconfirmed with GCC 11.

GCC does issue -Wuninitialized without optimization on an equivalent test case
with an explicit ctor.  The difference between the two ctors is that B's has a
clobber:

$ cat pr78391.C && PRED_DUMP=euninit gcc -S -Wall pr78391.C
struct A { int x = w; int w = 10; };

int f ()
{
  A a;
  return a.x;
}

struct B { int x, w; B (): x(w), w (10) { } };

int g ()
{
  B b;
  return b.x;
}

void A::A (struct A * const this)
{
  int _1;

   :
  # VUSE <.MEM_2(D)>   <<< no clobber
  _1 = this_3(D)->w;   <<< -Wuninitialized
  # .MEM_4 = VDEF <.MEM_2(D)>
  this_3(D)->x = _1;
  # .MEM_5 = VDEF <.MEM_4>
  this_3(D)->w = 10;
  # VUSE <.MEM_5>
  return;

}


int f ()
{
  struct A a;
  int D.2439;
  int _3;

   :
  # .MEM_2 = VDEF <.MEM_1(D)>
  A::A ();
  # VUSE <.MEM_2>
  _3 = a.x;
  # .MEM_4 = VDEF <.MEM_2>
  a ={v} {CLOBBER};

   :
:
  # VUSE <.MEM_4>
  return _3;

}


void B::B (struct B * const this)
{
  int _1;

   :
  # .MEM_4 = VDEF <.MEM_2(D)>
  *this_3(D) ={v} {CLOBBER};   <<< clobber here
  # VUSE <.MEM_4>
  _1 = this_3(D)->w;   <<< -Wuninitialized
  # .MEM_5 = VDEF <.MEM_4>
  this_3(D)->x = _1;
  # .MEM_6 = VDEF <.MEM_5>
  this_3(D)->w = 10;
  # VUSE <.MEM_6>
  return;

}


pr78391.C: In constructor ‘B::B()’:
pr78391.C:9:30: warning: ‘*this.B::w’ is used uninitialized [-Wuninitialized]
9 | struct B { int x, w; B (): x(w), w (10) { } };
  |  ^
int g ()
{
  struct B b;
  int D.2442;
  int _3;

   :
  # .MEM_2 = VDEF <.MEM_1(D)>
  B::B ();
  # VUSE <.MEM_2>
  _3 = b.x;
  # .MEM_4 = VDEF <.MEM_2>
  b ={v} {CLOBBER};

   :
:
  # VUSE <.MEM_4>
  return _3;

}

[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues

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

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

Bug 78370 Summary: taking address of a var causes missing uninitialized warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78370

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

[Bug middle-end/19430] taking address of a var causes missing uninitialized warning (virtual PHI with MEM)

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

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

Martin Sebor  changed:

   What|Removed |Added

 CC||scott.d.phillips at intel dot 
com

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

[Bug middle-end/78370] taking address of a var causes missing uninitialized warning

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

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

Martin Sebor  changed:

   What|Removed |Added

  Known to fail||10.2.0, 11.0, 6.3.0, 7.0.1,
   ||8.3.0, 9.3.0
 Status|NEW |RESOLVED
   Last reconfirmed|2016-11-16 00:00:00 |2021-3-31
 Resolution|--- |DUPLICATE
 CC||msebor at gcc dot gnu.org

--- Comment #4 from Martin Sebor  ---
No improvement in GCC 11 but I agree this is a duplicate of the ancient
pr19430.

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

[Bug middle-end/78081] -Wmaybe-initialized false-alarm regression for Emacs regex.c (jump threading fallout)

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

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

--- Comment #5 from Martin Sebor  ---
But... the reduced test case started triggering -Wmaybe-uninitialized in
r11-3685 while the original test case always has, so maybe I went too far with
the reduction and there are actually two bugs going on here.

[Bug middle-end/78081] -Wmaybe-initialized false-alarm regression for Emacs regex.c (jump threading fallout)

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

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org
  Known to fail|5.4.0, 6.3.0, 7.0.1, 8.0|10.2.0, 11.0, 5.5.0, 6.4.0,
   ||7.2.0, 8.3.0, 9.1.0

--- Comment #4 from Martin Sebor  ---
Reconfirmed with GCC 11 and both the original test case as well as the reduced
test case below.  The warning is augmented to print a couple of notes, the
first showing the condition under which the variable is determined to be
uninitialized, and the second the condition under which it's used.  The
expressions printed in the notes: (s == 0) and (s != 0 && (f (s_23) != 1), are
clearly mutually exclusive but the warning has recorded '(.NOT.) _1 == 1
(.AND.) s_23 != 0B' as the used condition and doesn't have the smarts to figure
out that the s_23 PHI   is equal to s_3(5) in bb 8.

$ cat pr78081.c && gcc -O2 -S -Wall -fdump-tree-uninit=/dev/stdout pr78081.c
extern int f (const char *);

int g (const char *s0, const char *s1)
{
  for (const char *s = s1; ; )
{
  long i;

  if (s)
i = s - s0;

  if (f (s) == 1)
break;

  if (s)
s = i + s0;
}

  return -1;
}

;; Function g (g, funcdef_no=0, decl_uid=1946, cgraph_uid=1, symbol_order=0)
...
Testing if this predicate:  (.NOT.) s_3 != 0B 
<<< s != 0
...can be invalidated by a USE guard of:  (.NOT.) _1 == 1 (.AND.) s_23 != 0B  
<<< s != 0
[BEFORE SIMPLICATION -- [USE]:
i.0_2 = (sizetype) i_22;
is guarded by :

 (.NOT.) _1 == 1 (.AND.) s_23 != 0B


[BEFORE NORMALIZATION --[USE]:
i.0_2 = (sizetype) i_22;
is guarded by :

 (.NOT.) _1 == 1 (.AND.) s_23 != 0B


[AFTER NORMALIZATION -- [USE]:
i.0_2 = (sizetype) i_22;
is guarded by :

s_23 != 0B (.AND.)  (.NOT.) _1 == 1


[CHECK]: Found unguarded use: i.0_2 = (sizetype) i_22;

pr78081.c: In function ‘g’:
pr78081.c:16:15: warning: ‘i’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
   16 | s = i + s0;
  | ~~^~~~
pr78081.c:7:12: note: when ‘s == 0’
7 |   long i;
  |^
pr78081.c:7:12: note: used when ‘s != 0 && f (s_23) != 1’
pr78081.c:7:12: note: ‘i’ was declared here


int g (const char * s0, const char * s1)
{
  long int i;
  const char * s;
  int _1;
  sizetype i.0_2;

   [local count: 118111598]:

   [local count: 787052758]:
  # s_3 = PHI 
  # i_4 = PHI<<< i_8(D) is uninitialized
  if (s_3 != 0B)
goto ; [90.32%]
  else
goto ; [9.68%]

   [local count: 76166394]:
  goto ; [100.00%]

   [local count: 751619280]:
  i_11 = s_3 - s0_10(D);

   [local count: 827785674]: <<< s_3 != 0
  # i_22 = PHI   <<< (2)

   [local count: 1073741824]:
  # s_23 = PHI <<< s_23
  _1 = f (s_23);
  if (_1 == 1)
goto ; [11.00%]
  else
goto ; [89.00%]

   [local count: 955630225]:
  if (s_23 != 0B)  <<< s_23 != 0
goto ; [70.00%]
  else
goto ; [30.00%]

   [local count: 286689065]:
  goto ; [100.00%]

   [local count: 668941161]: <<< s_23 != 0
  i.0_2 = (sizetype) i_22; <<< (1)
  s_13 = s0_10(D) + i.0_2; <<< use: -Wmaybe-uninitialized
  goto ; [100.00%]

   [local count: 118111600]:
  return -1;

}

[Bug analyzer/99771] Analyzer diagnostics should not say ""

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

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

--- Comment #3 from David Malcolm  ---
The above patch fixes some of the occurrences of the bug (due to (b)), but not
those due to (a), so keeping this bug open.

[Bug analyzer/99771] Analyzer diagnostics should not say ""

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

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by David Malcolm :

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

commit r11-7941-ge4bb1bd60a9fd1bed36092a990aa5fed5d45bfa6
Author: David Malcolm 
Date:   Mon Mar 29 16:13:32 2021 -0400

analyzer: avoid printing '' for SSA names [PR99771]

We don't want to print '' in our diagnostics, but
PR analyzer/99771 lists various cases where -fanalyzer does, due to
using the SSA_NAME for a temporary when determining the best tree to
use.

This can happen in two ways:

(a) ...when a better expression than the SSA_NAME could be built, but
finding it requires traversing the relationships in the region_model
in a graph-like way, rather than by considering individual svalues and
regions.

(b) ...when the only remaining user of the underlying svalue is the
SSA_NAME, typically due to the diagnostic referring to a temporary.

I've been experimenting with fixing (a), but don't have a good fix yet.
In the meantime, this patch addresses (b) by detecting if we have
the SSA_NAME for a temporary, and, for the cases where it's possible,
reconstructing a tree by walking the def-stmts.  This fixes various
cases of (b) and ameliorates some cases of (a).

gcc/analyzer/ChangeLog:
PR analyzer/99771
* analyzer.cc (maybe_reconstruct_from_def_stmt): New.
(fixup_tree_for_diagnostic_1): New.
(fixup_tree_for_diagnostic): New.
* analyzer.h (fixup_tree_for_diagnostic): New decl.
* checker-path.cc (call_event::get_desc): Call
fixup_tree_for_diagnostic and use it for the call_with_state call.
(warning_event::get_desc): Likewise for the final_event and
make_label_text calls.
* engine.cc (impl_region_model_context::on_state_leak): Likewise
for the on_leak and add_diagnostic calls.
* region-model.cc (region_model::get_representative_tree):
Likewise for the result.

gcc/testsuite/ChangeLog:
PR analyzer/99771
* gcc.dg/analyzer/data-model-10.c: Update expected output.
* gcc.dg/analyzer/malloc-ipa-13.c: Likewise.
* gcc.dg/analyzer/malloc-ipa-13a.c: New test.
* gcc.dg/analyzer/pr99771-1.c: New test.

[Bug c++/99859] constexpr evaluation with member function is incorrect

[ldalessandro at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Luke Dalessandro  ---
It was pointed out that it _also_ works if I change

> static_assert(foo());

to 

> constexpr bool b = foo();
> static_assert(b);

static_assert(foo());

[Bug analyzer/99860] New: RFE: analyzer does not respect "restrict"

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

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

Bug ID: 99860
   Summary: RFE: analyzer does not respect "restrict"
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: dmalcolm at gcc dot gnu.org
  Target Milestone: ---

The analyzer currently is very conservative about aliasing, and assumes that
anything that could be aliased by a pointer gets clobbered when a write occurs
through that pointer.

Am filing this bug to remind me to better support pointers marked with
"restrict".

Probably should also warn about places where the analyzer detects that restrict
isn't being honored.

[Bug c++/99859] New: constexpr evaluation with member function is incorrect

[ldalessandro at gmail dot com via Gcc-bugs]

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

Bug ID: 99859
   Summary: constexpr evaluation with member function is incorrect
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ldalessandro at gmail dot com
  Target Milestone: ---

I'm at a loss for how to describe this.

I have an intrusive reference counting smart pointer that manipulates the
pointed-to object's `count_` member either explicitly or via a member function.
The explicit version works fine, the member function does not (both are fine in
clang).

See the difference with -DUSE_DEC in https://godbolt.org/z/rhb7e6rjr.

[Bug fortran/77504] [8/9/10/11 Regression] "is used uninitialized" with allocatable string and array constructors

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

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org
 Blocks|24639   |

--- Comment #24 from Martin Sebor  ---
Since this is a true positive removing the -Wuninitilized dependency based on
comment #14.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
[Bug 24639] [meta-bug] bug to track all Wuninitialized issues

[Bug middle-end/73550] Another wrong -Wmaybe-uninitialized warning in switch statement

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

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org
  Known to fail||10.2.0, 11.0, 7.3.0, 8.3.0,
   ||9.2.0
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2021-03-31

--- Comment #6 from Martin Sebor  ---
Confirmed with GCC 11.

[Bug middle-end/72826] bad pretty-printing of decl *((void*)& x +offset) for uninitialized structure field (ESRA)

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

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org
   Severity|normal  |enhancement

--- Comment #6 from Martin Sebor  ---
This has changed in GCC 11 to print the following:

$ gcc -O2 -S -Wall pr72826.C
pr72826.C: In function ‘int main()’:
pr72826.C:8:13: warning: ‘*(unsigned char*)((char*) +
offsetof(countdownTimer, countdownTimer::started))’ is used uninitialized
[-Wuninitialized]
8 | if (started) return;
  | ^~~
pr72826.C:20:20: note: ‘*(unsigned char*)((char*) +
offsetof(countdownTimer, countdownTimer::started))’ was declared here
   20 | countdownTimer timer;
  |^

So the internal details aren't leaking out into the message as much anymore. 
At the same time, there's quite a bit of unnecessary noise there that could be
further reduced.  The IL below doesn't show that there is enough information to
recover the original ‘countdownTimer::countdownTimer’ from the MEM_REF in the
read of timer$33:

int main ()
{
  unsigned char timer$33;
  bool _3;

   [local count: 1073741824]:
  _3 = VIEW_CONVERT_EXPR(timer$33_2(D));
  if (_3 != 0)
goto ; [51.12%]
  else
goto ; [48.88%]

The MEM_REF comes from the DECL_DEBUG_EXPR () for timer$33_2:

 
unit-size 
align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7fffea979c78 precision:8 min  max >

arg:0 
public unsigned DI
size 
unit-size 
align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7fffea96a498>

arg:0 
used tree_1 tree_6 read decl_5 BLK /build/tmp/pr72826.C:20:20
size 
unit-size 
align:8 warn_if_not_align:0 context >>
arg:1 
constant 33>>

This could be done by determining the member of the MEM_REF type at the offset.

But this would be just a minor cosmetic improvement.

[Bug c++/99851] Warn about operator new that takes std::nothrow_t but is potentially-throwing

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

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

--- Comment #3 from Jonathan Wakely  ---
And just to be clear, this should apply to operator new and operator new[]. The
examples above both use the array form, but there's no reason this shouldn't
apply to the single object form too.

[Bug c++/99851] Warn about operator new that takes std::nothrow_t but is potentially-throwing

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

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

--- Comment #2 from Jonathan Wakely  ---
(In reply to Martin Sebor from comment #1)
> Confirmed, thanks!  Just to make sure I understand: we want a warning for
> the operator new declaration (irrespective of its definition) because the
> nothrow_t argument suggests it doesn't throw but the absence of noexcept
> implies it might.  I.e., the warning can be emitted as early as in the C++
> front end.

Yes, you understood exactly.

Additionally, we should not warn if the function has an explicit
noexcept(false).

I think it's reasonable to add this to -Wall. In the unlikely event that the
user really does want a throwing operator new that takes a std::nothrow_t
parameter, I think requiring noexcept(false) to suppress the warning is
reasonable. It's confusing/misleading otherwise.

[Bug c++/99445] [11 Regression] ICE in hashtab_chk_error, at hash-table.c:137 since r11-7011-g6e0a231a4aa2407b

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

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

Jason Merrill  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/97009] [9/10/11 Regression] Inlining with non-standard selected_int_kind leads to errors

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

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

--- Comment #8 from Martin Jambor  ---
I have proposed the patch on the mailing list:
https://gcc.gnu.org/pipermail/gcc-patches/2021-March/567553.html

[Bug tree-optimization/83336] [meta-bug] Issues with displaying inlining chain for middle-end warnings

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

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

Bug 71701 Summary: bogus token in -Wmaybe-uninitialized warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71701

   What|Removed |Added

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

[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues

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

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

Bug 71701 Summary: bogus token in -Wmaybe-uninitialized warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71701

   What|Removed |Added

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

[Bug middle-end/71701] bogus token in -Wmaybe-uninitialized warning

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

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

Martin Sebor  changed:

   What|Removed |Added

  Known to fail||9.3.0
Version|7.0 |9.0
   Target Milestone|--- |9.0
 Resolution|--- |FIXED
 CC||msebor at gcc dot gnu.org
 Status|UNCONFIRMED |RESOLVED

--- Comment #6 from Martin Sebor  ---
The warning has disappeared with r263660 (9.0.0 20180820): PR c++/78655 (gcc
doesn't exploit the fact that the result of pointer addition can not be
nullptr)

I could only reproduce it with the preprocessed test case from attachment
38791.  Since it depends on the contents of Glibc headers I'm going to resolve
it as fixed without adding a test case.

[Bug c++/99858] New: Wrong throw-expression behaviour with reference to pointer

[ibrbulat at yandex dot ru via Gcc-bugs]

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

Bug ID: 99858
   Summary: Wrong throw-expression behaviour with reference to
pointer
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ibrbulat at yandex dot ru
  Target Milestone: ---

If you catch an exception of pointer type by reference to pointer, change the
value of the pointer inside this catch block and then rethrow it via *throw*
with no operand, compiler will create a copy of initial exception(!) and no
changes will be seen in the next handler.
Minimal example is here https://godbolt.org/z/T11939EYM

This behavior is contrary to the C ++ language standard (e.g. C++17):
[expr.throw]: "... 3. A throw-expression with no operand rethrows the currently
handled exception (18.3). The exception is reactivated with the existing
exception object; no new exception object is created. ..."
[except.throw]: "... If a handler exits by rethrowing, control is passed to
another handler for the same exception object.  ..."

However it works well with other (non-pointer) types - no additional copy is
created, all handlers work with the same object and see each other changes
(example: https://godbolt.org/z/Ea6r1z7rE)

[Bug fortran/99840] [9/10/11 Regression] ICE in gfc_simplify_matmul, at fortran/simplify.c:4777

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

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

--- Comment #8 from anlauf at gcc dot gnu.org ---
Patch: https://gcc.gnu.org/pipermail/fortran/2021-March/055897.html

[Bug target/99847] Optimization breaks alignment on CPU32

[m.frohiky at gmail dot com via Gcc-bugs]

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

--- Comment #4 from ⎓  ---
Hmm... I was hoping to get away with the readily available compiler, and I
thought that it's actually used for CPU32. Ok, I'll try then with a specific
one tomorrow.

But still, ABI can't request that all bytes in a uint8_t array are aligned. I
mean, you can never expect uint8_t pointer to be aligned, regardless of the
used ABI.

On the other hand, according to Wiki:
 > The 68020 had no alignment restrictions on data access.

So that could explain it.

If it really is the wrong compiler kind, then I've gotta admit, this is the
second time something like that happened to me because of my laziness to build
a compiler. Shouldn't the old and new m68k be separated or something, so a
problem like this can't happen? Maybe another issue for that?

[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues

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

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

Bug 71699 Summary: bogus -Wmaybe-uninitialized warning: gcc misses that 
non-NULL pointer + offset can never be NULL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71699

   What|Removed |Added

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

[Bug middle-end/71699] bogus -Wmaybe-uninitialized warning: gcc misses that non-NULL pointer + offset can never be NULL

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

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

Martin Sebor  changed:

   What|Removed |Added

   Target Milestone|--- |9.0
 Status|NEW |RESOLVED
 Resolution|--- |FIXED
 CC||msebor at gcc dot gnu.org
  Known to work||9.3.0
  Known to fail||7.3.0, 8.3.0

--- Comment #13 from Martin Sebor  ---
At -O1 and above the warning has disappeared with r263662 (GCC 9.0.0 20180820).

It's still on trunk with -O0 (and with -Og) not with higher optimization
levels.  But I'm not sure I see this as a problem.  The test case assigns an
uninitialized variable for no apparent reason and expects the assignment to be
eliminated.  That does happen but only with optimization.  The warning could
probably be enhanced to figure this out by essentially implementing the same
logic as the optimization does but that seems like going too far.  With so many
open bugs against -Wuninitialized of higher priority with no progress for a
decade or more I'm going to resolve this one as fixed.

[Bug fortran/99840] [9/10/11 Regression] ICE in gfc_simplify_matmul, at fortran/simplify.c:4777

[anlauf at gmx dot de via Gcc-bugs]

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

--- Comment #7 from Harald Anlauf  ---
> The simple patch in comment #2 also works.

I know.  But it only covers the issue in gfc_simplify_transpose.

[Bug fortran/99840] [9/10/11 Regression] ICE in gfc_simplify_matmul, at fortran/simplify.c:4777

[sgk at troutmask dot apl.washington.edu via Gcc-bugs]

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

--- Comment #6 from Steve Kargl  ---
On Wed, Mar 31, 2021 at 08:51:57PM +, anlauf at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99840
> 
> --- Comment #5 from anlauf at gcc dot gnu.org ---
> OK, now I see it.  gfc_get_shape does not init the resulting shape.
> The following simpler patch does the job:
> 
> diff --git a/gcc/fortran/simplify.c b/gcc/fortran/simplify.c
> index 388aca7c38c..c27b47aa98f 100644
> --- a/gcc/fortran/simplify.c
> +++ b/gcc/fortran/simplify.c
> @@ -8123,8 +8123,8 @@ gfc_simplify_transpose (gfc_expr *matrix)
>>where);
>result->rank = 2;
>result->shape = gfc_get_shape (result->rank);
> -  mpz_set (result->shape[0], matrix->shape[1]);
> -  mpz_set (result->shape[1], matrix->shape[0]);
> +  mpz_init_set (result->shape[0], matrix->shape[1]);
> +  mpz_init_set (result->shape[1], matrix->shape[0]);
> 
>if (matrix->ts.type == BT_CHARACTER)
>  result->ts.u.cl = matrix->ts.u.cl;
> 

The simple patch in comment #2 also works.

[Bug middle-end/99857] New: [11 Regression] FAIL: libgomp.c/declare-variant-1.c (test for excess errors) by r11-7926

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

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

Bug ID: 99857
   Summary: [11 Regression] FAIL: libgomp.c/declare-variant-1.c
(test for excess errors) by r11-7926
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: jh at suse dot cz
  Target Milestone: ---

r11-7926 caused:

lto1: fatal error: bytecode stream: trying to read 0 bytes after the end of the
input buffer^M
compilation terminated.^M
lto-wrapper: fatal error:
/export/users/hjl/build/gnu/tools-build/gcc-32bit-gitlab-native/build-i686-linux/./gcc/xgcc
returned 1 exit status^M
compilation terminated.^M
/usr/local32/bin/ld: error: lto-wrapper failed^M
collect2: error: ld returned 1 exit status^M
See ":er exited with status 1.
FAIL: libgomp.c/declare-variant-1.c (test for excess errors)fter the end of the
Excess errors:

[Bug middle-end/71011] Wrong decl in a "may be uninitialized" warning

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

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

Martin Sebor  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
 CC||msebor at gcc dot gnu.org

--- Comment #5 from Martin Sebor  ---
GCC 11 adds a note pointing to the declaration of the uninitialized variable
and prints something like:

allocate.C: In member function ‘void allocate_c::run_a_cycle()’:
allocate.C:44117:19: warning: ‘data’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
44117 | else if (uop->m_uop_type == UOP_IADD ||
  |  ~^~
allocate.C:38515:9: note: ‘data’ was declared here
38515 |   T data;
  | ^~~~

It might be possible to improve the output further (and I expect to) but given
that this is likely a true positive and with so many more serious
-Wuninitialized bugs I think it's good enough to resolve this report.

[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues

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

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

Bug 71011 Summary: Wrong decl in a "may be uninitialized" warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71011

   What|Removed |Added

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

[Bug fortran/99840] [9/10/11 Regression] ICE in gfc_simplify_matmul, at fortran/simplify.c:4777

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

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

--- Comment #5 from anlauf at gcc dot gnu.org ---
OK, now I see it.  gfc_get_shape does not init the resulting shape.
The following simpler patch does the job:

diff --git a/gcc/fortran/simplify.c b/gcc/fortran/simplify.c
index 388aca7c38c..c27b47aa98f 100644
--- a/gcc/fortran/simplify.c
+++ b/gcc/fortran/simplify.c
@@ -8123,8 +8123,8 @@ gfc_simplify_transpose (gfc_expr *matrix)
   >where);
   result->rank = 2;
   result->shape = gfc_get_shape (result->rank);
-  mpz_set (result->shape[0], matrix->shape[1]);
-  mpz_set (result->shape[1], matrix->shape[0]);
+  mpz_init_set (result->shape[0], matrix->shape[1]);
+  mpz_init_set (result->shape[1], matrix->shape[0]);

   if (matrix->ts.type == BT_CHARACTER)
 result->ts.u.cl = matrix->ts.u.cl;

[Bug ipa/98265] [10/11 Regression] gcc-10 has significantly worse code generated with -O2 compared to -O1 (or gcc-9 -O2) when using the Eigen C++ library

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

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

--- Comment #8 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Jan Hubicka
:

https://gcc.gnu.org/g:42c22a4d724b4a4b0183f4412c3d42c9cca29d30

commit r10-9646-g42c22a4d724b4a4b0183f4412c3d42c9cca29d30
Author: Jan Hubicka 
Date:   Wed Mar 31 22:44:20 2021 +0200

Make USES_COMDAT_LOCAL CIF_FINAL_NORMAL

USES_COMDAT_LOCAL is incorrectly defined as CIF_FINAL_ERROR which makes
inliner
to mis some inlines of functions in comdat section that was previously
split.

2021-03-31  Jan Hubicka  

PR ipa/98265
* cif-code.def (USES_COMDAT_LOCAL): Make CIF_FINAL_NORMAL.

(cherry picked from commit e7fd3b783238d034018443e43a58ff87908b4db6)

[Bug ipa/98265] [10/11 Regression] gcc-10 has significantly worse code generated with -O2 compared to -O1 (or gcc-9 -O2) when using the Eigen C++ library

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

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

--- Comment #7 from CVS Commits  ---
The master branch has been updated by Jan Hubicka :

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

commit r11-7940-ge7fd3b783238d034018443e43a58ff87908b4db6
Author: Jan Hubicka 
Date:   Wed Mar 31 22:44:20 2021 +0200

Make USES_COMDAT_LOCAL CIF_FINAL_NORMAL

USES_COMDAT_LOCAL is incorrectly defined as CIF_FINAL_ERROR which makes
inliner
to mis some inlines of functions in comdat section that was previously
split.

2021-03-31  Jan Hubicka  

PR ipa/98265
* cif-code.def (USES_COMDAT_LOCAL): Make CIF_FINAL_NORMAL.

[Bug target/98119] [10 Regression] SVE: Wrong code with -O1 -ftree-vectorize -msve-vector-bits=512 -mtune=thunderx

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

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

Summary|[10/11 Regression] SVE: |[10 Regression] SVE: Wrong
   |Wrong code with -O1 |code with -O1
   |-ftree-vectorize|-ftree-vectorize
   |-msve-vector-bits=512   |-msve-vector-bits=512
   |-mtune=thunderx |-mtune=thunderx

--- Comment #5 from rsandifo at gcc dot gnu.org  
---
Fixed on trunk so far.

[Bug fortran/99840] [9/10/11 Regression] ICE in gfc_simplify_matmul, at fortran/simplify.c:4777

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

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

--- Comment #4 from anlauf at gcc dot gnu.org ---
For reasons I do not understand,

Breakpoint 1, gfc_simplify_matmul (matrix_a=0x292bbf0, matrix_b=0x292c550)
at ../../gcc-trunk/gcc/fortran/simplify.c:4777
4777  result_columns = mpz_get_si (matrix_b->shape[1]);
(gdb) p matrix_b->shape[1] 
$64 = {{_mp_alloc = 0, _mp_size = 0, _mp_d = 0x0}}
(gdb) p matrix_b->shape[0]
$65 = {{_mp_alloc = 0, _mp_size = 0, _mp_d = 0x0}}

This is a result from the mpz_set in gfc_simplify_transpose.
Isn't this a representation of zero?

Alternative patch, which passes the relevant regtesting:

diff --git a/gcc/fortran/simplify.c b/gcc/fortran/simplify.c
index 388aca7c38c..b884a81fce0 100644
--- a/gcc/fortran/simplify.c
+++ b/gcc/fortran/simplify.c
@@ -8123,16 +8123,16 @@ gfc_simplify_transpose (gfc_expr *matrix)
   >where);
   result->rank = 2;
   result->shape = gfc_get_shape (result->rank);
-  mpz_set (result->shape[0], matrix->shape[1]);
-  mpz_set (result->shape[1], matrix->shape[0]);
+  matrix_rows = mpz_get_si (matrix->shape[0]);
+  matrix_cols = mpz_get_si (matrix->shape[1]);
+  mpz_init_set_si (result->shape[0], matrix_cols);
+  mpz_init_set_si (result->shape[1], matrix_rows);

   if (matrix->ts.type == BT_CHARACTER)
 result->ts.u.cl = matrix->ts.u.cl;
   else if (matrix->ts.type == BT_DERIVED)
 result->ts.u.derived = matrix->ts.u.derived;

-  matrix_rows = mpz_get_si (matrix->shape[0]);
-  matrix_cols = mpz_get_si (matrix->shape[1]);
   for (row = 0; row < matrix_rows; ++row)
 for (col = 0; col < matrix_cols; ++col)
   {

[Bug target/97141] [10 Regression] aarch64, SVE: ICE in decompose, at rtl.h (during expand) since r10-4676-g9c437a108a

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

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

--- Comment #6 from rsandifo at gcc dot gnu.org  
---
*** Bug 98726 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/98726] [10/11 Regression] SVE: tree check: expected integer_cst, have poly_int_cst in to_wide, at tree.h:5984

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

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|ASSIGNED|RESOLVED

--- Comment #12 from rsandifo at gcc dot gnu.org  
---
Fixed on trunk.  Treating as a dup for backports.

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

[Bug target/97141] [10 Regression] aarch64, SVE: ICE in decompose, at rtl.h (during expand) since r10-4676-g9c437a108a

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

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

Summary|[10/11 Regression] aarch64, |[10 Regression] aarch64,
   |SVE: ICE in decompose, at   |SVE: ICE in decompose, at
   |rtl.h (during expand) since |rtl.h (during expand) since
   |r10-4676-g9c437a108a|r10-4676-g9c437a108a

--- Comment #5 from rsandifo at gcc dot gnu.org  
---
Fixed on trunk so far.

[Bug tree-optimization/68548] bogus "may be used uninitialized" (predicate analysis)

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

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org
  Known to fail|4.9.3, 5.2.0|10.2.0, 11.0, 4.9.4, 5.5.0,
   ||6.4.0, 7.2.0, 8.3.0, 9.1.0

--- Comment #3 from Martin Sebor  ---
Reconfirmed with GCC 11.  It's not a regression.  With a patch I'm working with
GCC issues the following warning and notes confirming the analysis from comment
#1 and #2.

pr68548.c: In function ‘foo’:
pr68548.c:14:17: warning: ‘data0’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
   14 | bar(data0);
  | ^~
pr68548.c:7:18: note: when ‘(writemask & 1) == 0’
7 | unsigned data0;
  |  ^
pr68548.c:7:18: note: used when ‘(writemask & 1) == 0’
pr68548.c:7:18: note: ‘data0’ was declared here

EVRP knows to fold the test for data0 != data to false but nothing substitutes
data for data0 when the value is passed to another function or returned.  So
the following, for instance, doesn't trigger a warning because the data0 - data
subtraction is folded into zero.

int x;

void baz (unsigned writemask, unsigned data) {
unsigned remaining = X;
unsigned data0;

if (writemask & X) data0 = data;

remaining &= ~writemask;
if (remaining == 0)
  x = data0 - data;
}

[Bug tree-optimization/99726] [10 Regression] ICE in create_intersect_range_checks_index, at tree-data-ref.c:1855 since r10-4762-gf9d6338bd15ce1fae36bf25d3a0545e9678ddc58

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

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

Summary|[10/11 Regression] ICE in   |[10 Regression] ICE in
   |create_intersect_range_chec |create_intersect_range_chec
   |ks_index, at|ks_index, at
   |tree-data-ref.c:1855 since  |tree-data-ref.c:1855 since
   |r10-4762-gf9d6338bd15ce1fae |r10-4762-gf9d6338bd15ce1fae
   |36bf25d3a0545e9678ddc58 |36bf25d3a0545e9678ddc58

--- Comment #5 from rsandifo at gcc dot gnu.org  
---
Fixed on trunk so far.

[Bug tree-optimization/98268] [10 Regression] ICE: verify_gimple failed with LTO and SVE

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

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

Summary|[10/11 Regression] ICE: |[10 Regression] ICE:
   |verify_gimple failed with   |verify_gimple failed with
   |LTO and SVE |LTO and SVE

--- Comment #9 from rsandifo at gcc dot gnu.org  
---
Fixed on trunk so far.

[Bug middle-end/63943] wrong location for -Wmaybe-uninitialized in inlined function

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

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

Eric Gallager  changed:

   What|Removed |Added

 CC||dmalcolm at gcc dot gnu.org,
   ||egallager at gcc dot gnu.org

--- Comment #5 from Eric Gallager  ---
(In reply to Manuel López-Ibáñez from comment #4)
> (In reply to Martin Sebor from comment #3)
> > As for using %K, I mostly agree.  I actually have %G in my tree, but my goal
> > is to get rid of both and replace them with a new warning function like so:
> >   https://gcc.gnu.org/pipermail/gcc-patches/2021-January/563862.html
> > and replace calls to warning() and warning_at() in the middle end with those
> > to the new function.  This makes it possible to control warnings at any
> > point in the lining stack and resolves bug like pr98871.
> 
> That is great. It may be worth CCing David Malcolm, since he is the
> diagnostics maintainer.

OK, done

[Bug tree-optimization/97009] [9/10/11 Regression] Inlining with non-standard selected_int_kind leads to errors

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

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

--- Comment #7 from Martin Jambor  ---
I am about to test this patch.  I think this should be P1 and I would really
like to get this fix to GCC 10.3.  Sorry for getting to this so late.

diff --git a/gcc/tree-sra.c b/gcc/tree-sra.c
index d177f1ba11c..8dfc923ed7e 100644
--- a/gcc/tree-sra.c
+++ b/gcc/tree-sra.c
@@ -2723,6 +2723,19 @@ budget_for_propagation_access (tree decl)
   return true;
 }

+/* Return true if ACC or any of its subaccesses has grp_child set.  */
+
+static bool
+access_or_its_child_written (struct access *acc)
+{
+  if (acc->grp_write)
+return true;
+  for (struct access *sub = acc->first_child; sub; sub = sub->next_sibling)
+if (access_or_its_child_written (sub))
+  return true;
+  return false;
+}
+
 /* Propagate subaccesses and grp_write flags of RACC across an assignment link
to LACC.  Enqueue sub-accesses as necessary so that the write flag is
propagated transitively.  Return true if anything changed.  Additionally,
if
@@ -2836,7 +2849,7 @@ propagate_subaccesses_from_rhs (struct access *lacc,
struct access *racc)
   if (rchild->grp_unscalarizable_region
  || !budget_for_propagation_access (lacc->base))
{
- if (rchild->grp_write && !lacc->grp_write)
+ if (!lacc->grp_write && access_or_its_child_written (rchild))
{
  ret = true;
  subtree_mark_written_and_rhs_enqueue (lacc);

[Bug tree-optimization/97009] [9/10/11 Regression] Inlining with non-standard selected_int_kind leads to errors

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

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

--- Comment #6 from Martin Jambor  ---
Created attachment 50492
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50492=edit
C testcase

C testcase.

[Bug c/99856] New: Alpha Compositing auto vectorization regression: 8.3 -> 9.1

[dushistov at mail dot ru via Gcc-bugs]

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

Bug ID: 99856
   Summary: Alpha Compositing auto vectorization regression: 8.3
-> 9.1
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dushistov at mail dot ru
  Target Milestone: ---

Such code vectorized with gcc 8.3, but failed to vectorized with 9.1.
Last version of clang works just fine.

```
#include 
#include 

#define SHIFTFORDIV255(a)\
a) >> 8) + a) >> 8)

#define DIV255(a)\
SHIFTFORDIV255(a + 0x80)

void
opSourceOver_premul(uint8_t* restrict Rrgba,
const uint8_t* restrict Srgba,
const uint8_t* restrict Drgba, size_t len)
{
size_t i = 0;
for (; i < len*4; i += 4) {
uint8_t Sa = Srgba[i + 3];
Rrgba[i + 0] = DIV255(Srgba[i + 0] * 255 + Drgba[i + 0] * (255 - Sa));
Rrgba[i + 1] = DIV255(Srgba[i + 1] * 255 + Drgba[i + 1] * (255 - Sa));
Rrgba[i + 2] = DIV255(Srgba[i + 2] * 255 + Drgba[i + 2] * (255 - Sa));
Rrgba[i + 3] = DIV255(Srgba[i + 3] * 255 + Drgba[i + 3] * (255 - Sa));
}
}
```

see https://godbolt.org/z/PW65xzb4h
with assembler output for 8.3 and 9.1

[Bug rtl-optimization/96264] [10 Regression] wrong code with -Os -fno-forward-propagate -fschedule-insns -fno-tree-ter

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

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

seurer at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #23 from seurer at gcc dot gnu.org ---
It works now on gcc 10

[Bug target/99133] Power10 xxspltiw, xxspltidp, xxsplti32dx instructions need to be marked as prefixed

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

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

pthaugen at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #4 from pthaugen at gcc dot gnu.org ---
Fixed.

[Bug c++/99850] [P1102R2] reject valid lambda syntax in C++23

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
Ah, but in lambda-expression: non-terminal there is another
requires-clause[opt] after the < template-parameter-list >.
So we need to handle
auto l = [] requires true (T t, int n) { };
But during parsing we have parsing of requires clause at that spot after >,
and when ()s are omitted, there is code to handle -> at that spot.

[Bug tree-optimization/67196] [9/10/11 Regression] loop-induced false positive from -Wmaybe-uninitialized

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

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

Martin Sebor  changed:

   What|Removed |Added

   Last reconfirmed|2015-08-12 00:00:00 |2021-3-31
  Known to fail||10.2.0, 11.0, 5.5.0, 6.4.0,
   ||7.2.0, 8.3.0, 9.1.0
 CC||msebor at gcc dot gnu.org
Summary|Another false positive from |[9/10/11 Regression]
   |-Wmaybe-uninitialized   |loop-induced false positive
   ||from -Wmaybe-uninitialized
   Keywords||diagnostic

--- Comment #3 from Martin Sebor  ---
Reconfirmed with GCC 11 as a regression introduced in r185913 (4.8.0 20120328).

Nothing in the IL jumps out at me that could be used by the predicate analysis
to rule out the false positive: the use in the return statement in bb 8 looks
unconditional.

pr67196.c: In function ‘test’:
pr67196.c:7:7: warning: ‘first_caption_idx’ may be used uninitialized in this
function [-Wmaybe-uninitialized]
7 |   int first_caption_idx;
  |   ^
int test (int n)
{
  int i;
  int first_caption_idx;
  int first_caption;
  int num_captions_in_row;
  int _1;
  _Bool _2;
  _Bool _3;
  _Bool _4;
  int _12;

   [local count: 118111600]:
  if (n_16(D) > 0)
goto ; [89.00%]
  else
goto ; [11.00%]

   [local count: 12992276]:
  goto ; [100.00%]

   [local count: 105119324]:

   [local count: 955630225]:
  # num_captions_in_row_25 = PHI 
  # first_caption_27 = PHI 
  # first_caption_idx_29 = PHI   <<< (3)
first_caption_idx_14(D) is uninitialized
  # i_31 = PHI 
  _1 = some_test (i_31);
  if (_1 != 0)
goto ; [50.00%]
  else
goto ; [50.00%]

   [local count: 477815113]:
  goto ; [100.00%]

   [local count: 477815112]:
  num_captions_in_row_18 = num_captions_in_row_25 + 1;

   [local count: 955630225]:
  # num_captions_in_row_5 = PHI 
  # first_caption_7 = PHI 
  # first_caption_idx_9 = PHI<<< (2)
  i_19 = i_31 + 1;
  if (n_16(D) != i_19)
goto ; [89.00%]
  else
goto ; [11.00%]

   [local count: 850510901]:
  goto ; [100.00%]

   [local count: 105119324]:
  _2 = first_caption_7 != 0;
  _3 = num_captions_in_row_5 == 1;
  _4 = _2 & _3;
  if (_4 != 0)
goto ; [38.20%]
  else
goto ; [61.80%]

   [local count: 40157944]:
  goto ; [100.00%]

   [local count: 64961380]:

   [local count: 118111600]:
  # _12 = PHI <<< (1)
  return _12;   <<< use

}

[Bug c++/99850] [P1102R2] reject valid lambda syntax in C++23

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

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

--- Comment #2 from Jakub Jelinek  ---
Are you sure it is incorrectly rejected?
http://eel.is/c++draft/expr.prim.lambda.general
says:
 lambda-declarator:
   lambda-specifiers
   ( parameter-declaration-clause ) lambda-specifiers requires-clause[opt]
So in my reading, if requires-clause is present, the ()s are not optional.
Otherwise requires-clause[opt] would need to be in the lambda-specifiers
non-terminal or present also after the first lambda-specifiers.

[Bug debug/99490] [11 Regression] -gdwarf-5 -gsplit-dwarf puts .debug_rnglists to main file, not .dwo file

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug target/99133] Power10 xxspltiw, xxspltidp, xxsplti32dx instructions need to be marked as prefixed

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

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Pat Haugen :

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

commit r11-7939-gea9a39e63eba1ba72aa3608317d1c40ae6bcef55
Author: Pat Haugen 
Date:   Wed Mar 31 14:37:24 2021 -0500

Update prefixed attribute for Power10.

This patch creates a new attribute, "maybe_prefixed", which is used to mark
those instructions that may have a prefixed form. The existing "prefixed"
attribute is now used to mark all instructions that are prefixed form.

2021-03-31  Pat Haugen  

gcc/
PR target/99133
* config/rs6000/altivec.md (xxspltiw_v4si, xxspltiw_v4sf_inst,
xxspltidp_v2df_inst, xxsplti32dx_v4si_inst, xxsplti32dx_v4sf_inst,
xxblend_, xxpermx_inst, xxeval): Mark prefixed.
* config/rs6000/mma.md (mma_, mma_,
mma_, mma_, mma_, mma_,
mma_, mma_, mma_, mma_):
Likewise.
* config/rs6000/rs6000.c (rs6000_final_prescan_insn): Adjust test.
* config/rs6000/rs6000.md (define_attr "maybe_prefixed"): New.
(define_attr "prefixed"): Update initializer.

[Bug debug/99490] [11 Regression] -gdwarf-5 -gsplit-dwarf puts .debug_rnglists to main file, not .dwo file

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

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

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

https://gcc.gnu.org/g:4b33c5aaab9e863da162942ab8bcd54070b705af

commit r11-7938-g4b33c5aaab9e863da162942ab8bcd54070b705af
Author: Jakub Jelinek 
Date:   Wed Mar 31 21:25:58 2021 +0200

dwarf2out: Fix up ranges for -gdwarf-5 -gsplit-dwarf [PR99490]

For -gdwarf-4 -gsplit-dwarf we used to emit .debug_ranges section
(so in the binaries/shared libraries) with DW_AT_ranges from skeleton
units as well as .debug_info.dwo pointing to it through DW_FORM_sec_offset
(and DW_AT_GNU_ranges_base pointing into section, not sure for what
reason exactly).
When DWARF5 support was being added, we've started using .debug_rnglists
section, added DW_AT_rnglists_base to the DW_TAG_skeleton_unit, kept
DW_AT_ranges with DW_FORM_sec_offset in the skeleton and switched
over to DW_FORM_rnglistx for DW_AT_ranges in .debug_info.dwo.
But the DWARF5 spec actually means for the ranges section (at least
everything for those DW_AT_ranges in .debug_info.dwo) to sit
in .debug_rnglists.dwo section next to the .debug_info.dwo, rather than
having consumers look it up in the binary/shared library instead.
Based on some discussions in the DWARF discuss mailing list:
   
http://lists.dwarfstd.org/pipermail/dwarf-discuss-dwarfstd.org/2021-March/thread.html#4765
this patch mostly follows what LLVM emits for that right now:
1) small .debug_rnglists section (when needed) just to cover the
   skeleton DW_AT_ranges (if present); the content of the section
   uses the Split DWARFy DW_RLE_* codes with addrx encodings where
   possible
2) DW_AT_ranges in the skeleton uses DW_FORM_sec_offset (difference
   from LLVM which uses DW_FORM_rnglistx, which makes it larger
   and ambiguous)
3) DW_AT_rnglists_base attribute is gone from the skeleton (again,
   unlike LLVM where it is just confusing what exactly it means because
   it is inherited; it would make sense if we emitted DW_FORM_rnglistx
   in non-split DWARF, but unless ranges are shared, I'm afraid we'd
   make DWARF larger with fewer relocations by that)
4) usually big .debug_rnglists.dwo section again with using DW_RLE_*x*
   where possible
5) DW_AT_ranges with DW_FORM_rnglistx from .debug_info.dwo referring to
   that .debug_rnglists.dwo ranges

2021-03-31  Jakub Jelinek  

PR debug/99490
* dwarf2out.c (debug_ranges_dwo_section): New variable.
(DW_RANGES_IDX_SKELETON): Define.
(struct dw_ranges): Add begin_entry and end_entry members.
(DEBUG_DWO_RNGLISTS_SECTION): Define.
(add_ranges_num): Adjust r initializer for addition of *_entry
members.
(add_ranges_by_labels): For -gsplit-dwarf and force_direct,
set idx to DW_RANGES_IDX_SKELETON.
(use_distinct_base_address_for_range): New function.
(index_rnglists): Don't set r->idx if it is equal to
DW_RANGES_IDX_SKELETON.  Initialize r->begin_entry and
r->end_entry for -gsplit-dwarf if those will be needed by
output_rnglists.
(output_rnglists): Add DWO argument.  If true, switch to
debug_ranges_dwo_section rather than debug_ranges_section.
Adjust l1/l2 label indexes.  Only output the offset table when
dwo is true and don't include in there the skeleton range
entry if present.  For -gsplit-dwarf, skip ranges that belong
to the other rnglists section.  Change return type from void
to bool and return true if there are any range entries for
the other section.  For dwarf_split_debug_info use
DW_RLE_startx_endx, DW_RLE_startx_length and DW_RLE_base_addressx
entries instead of DW_RLE_start_end, DW_RLE_start_length and
DW_RLE_base_address.  Use use_distinct_base_address_for_range.
(init_sections_and_labels): Initialize debug_ranges_dwo_section
if -gsplit-dwarf and DWARF >= 5.  Adjust ranges_section_label
and range_base_label indexes.
(dwarf2out_finish): Call index_rnglists earlier before finalizing
.debug_addr.  Never emit DW_AT_rnglists_base attribute.  For
-gsplit-dwarf and DWARF >= 5 call output_rnglists up to twice
with different dwo arguments.
(dwarf2out_c_finalize): Clear debug_ranges_dwo_section.

[Bug c++/99855] [modules] ICE Error reporting routines re-entered.

[alexander.lelyakin at googlemail dot com via Gcc-bugs]

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

--- Comment #5 from Alexander Lelyakin  ---
I have seen all that stuff with compiler at 
commit d7145b4bb6c8729a1e782373cb6256c06ed60465

Let's see what will be tomorrow.

[Bug middle-end/67194] [9/10/11 Regression] Missed jump thread and false positive from -Wuninitialized

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

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

Martin Sebor  changed:

   What|Removed |Added

Version|unknown |4.8.0
Summary|Missed jump thread and  |[9/10/11 Regression] Missed
   |false positive from |jump thread and false
   |-Wuninitialized |positive from
   ||-Wuninitialized
 CC||msebor at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2021-03-31
  Known to fail||10.2.0, 11.0, 4.8.4, 4.9.4,
   ||5.5.0, 6.4.0, 7.2.0, 8.3.0,
   ||9.1.0

--- Comment #1 from Martin Sebor  ---
Confirmed with GCC 11 as a regression introduced in r192537 (4.8.0 20121017):

$ gcc -O2 -S -Wall -xc++ pr67194.c
pr67194.c: In function ‘void elimination_costs_in_insn(rtx_insn*)’:
pr67194.c:53:28: warning: ‘orig_dup[0]’ may be used uninitialized in this
function [-Wmaybe-uninitialized]
   53 | *recog_data.dup_loc[i] = orig_dup[i];
  | ~~~^
pr67194.c:34:7: note: ‘orig_dup[0]’ was declared here
   34 |   rtx orig_dup[30];
  |   ^~~~

[Bug c++/99855] [modules] ICE Error reporting routines re-entered.

[alexander.lelyakin at googlemail dot com via Gcc-bugs]

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

--- Comment #4 from Alexander Lelyakin  ---
And next time same sequence run without error! 
All that with the same compiler, in empty dir.

[Bug middle-end/65244] Bogus -Wmaybe-uninitialized warning with posix_memalign() and -Og

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

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

Martin Sebor  changed:

   What|Removed |Added

   Last reconfirmed|2015-02-27 00:00:00 |2021-3-31
  Known to fail||10.2.0, 11.0, 4.9.4, 5.5.0,
   ||6.4.0, 7.2.0, 8.3.0, 9.1.0
  Known to work|4.8.2, 5.0  |
 CC||msebor at gcc dot gnu.org

--- Comment #15 from Martin Sebor  ---
The warning with -Og disappeared with r212559 but still comes back on trunk
with -Og -ftree-bit-ccp.  With that, as the comment in gimple-low.c says, a
call to posix_memalign() is lowered into:

void *tem;
 res = posix_memalign (, align, size);
 if (res == 0)
   ptr = __builtin_assume_aligned (tem, align);

and at -Og it looks like the two conditionals don't get cleaned up as nicely as
at -O1 and lead to an IL that the warning is designed to trigger on.  This
could be handled by the warning but unless this can come up with other
(especially non-builtin) functions it may not be worth the trouble.

$ cat pr65244.c && gcc -Og -S -Wall -ftree-bit-ccp
-fdump-tree-uninit=/dev/stdout pr65244.c
void exit(int __status) __attribute__ ((__noreturn__));
int posix_memalign(void **__memptr, __SIZE_TYPE__ __alignment, __SIZE_TYPE__
__size);

void *f(void) {
void *ptr;

if (posix_memalign(, 16, 256) != 0)
exit(1);

return ptr;
}

;; Function f (f, funcdef_no=0, decl_uid=1949, cgraph_uid=1, symbol_order=0)

pr65244.c: In function ‘f’:
pr65244.c:10:12: warning: ‘ptr’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
   10 | return ptr;
  |^~~
pr65244.c:5:11: note: ‘ptr’ was declared here
5 | void *ptr;
  |   ^~~
void * f ()
{
  void * D.1957;
  void * ptr;
  int _1;
  void * _6;

   [local count: 1073741824]:
  _1 = posix_memalign (, 16, 256);
  if (_1 == 0)
goto ; [50.00%]
  else
goto ; [50.00%]

   [local count: 536870912]:
  goto ; [100.00%]

   [local count: 536870913]:
  _6 = D.1957;

   [local count: 1073741824]:
  # ptr_2 = PHI 
  if (_1 != 0)
goto ; [0.04%]
  else
goto ; [99.96%]

   [local count: 429496]:
  exit (1);

   [local count: 1073312329]:
  return ptr_2;

}

[Bug c++/99855] [modules] ICE Error reporting routines re-entered.

[alexander.lelyakin at googlemail dot com via Gcc-bugs]

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

--- Comment #3 from Alexander Lelyakin  ---
malloc(): smallbin double linked list corrupted
In file included from /usr/local/include/c++/11.0.1/filesystem:45:
/usr/local/include/c++/11.0.1/bits/fs_path.h:94:62: internal compiler error:
Aborted
   94 | using __safe_iterator_traits = std::iterator_traits<_Iter>;
  |  ^
0x11016bf crash_signal
../../gcc/gcc/toplev.c:327
0x1d47750 xrealloc
../../gcc/libiberty/xmalloc.c:179
0xa6d663 void va_heap::reserve(vec*&, unsigned int, bool)
../../gcc/gcc/vec.h:290
0xa6d663 vec::reserve(unsigned int, bool)
../../gcc/gcc/vec.h:1778
0xa6d663 vec::safe_push(tree_node* const&)
../../gcc/gcc/vec.h:1887
0xa6d663 trees_in::post_process(tree_node*)
../../gcc/gcc/cp/module.cc:2956
0xa6d663 trees_in::read_function_def(tree_node*, tree_node*)
../../gcc/gcc/cp/module.cc:11456
0xa6f7f1 module_state::read_cluster(unsigned int)
../../gcc/gcc/cp/module.cc:14806
0xa6fe6d module_state::load_section(unsigned int, binding_slot*)
../../gcc/gcc/cp/module.cc:18068
0xa6ff2f module_state::lazy_load(unsigned int, binding_slot*)
../../gcc/gcc/cp/module.cc:18726
0xa6a1b0 trees_in::tree_node(bool)
../../gcc/gcc/cp/module.cc:9661
0xa7047a trees_in::decl_container()
../../gcc/gcc/cp/module.cc:10271
0xa7047a trees_in::decl_value()
../../gcc/gcc/cp/module.cc:7887
0xa69347 trees_in::tree_node(bool)
../../gcc/gcc/cp/module.cc:9150
0xa6f96b module_state::read_cluster(unsigned int)
../../gcc/gcc/cp/module.cc:14797
0xa6fe6d module_state::load_section(unsigned int, binding_slot*)
../../gcc/gcc/cp/module.cc:18068
0xa6ff2f module_state::lazy_load(unsigned int, binding_slot*)
../../gcc/gcc/cp/module.cc:18726
0xa6a1b0 trees_in::tree_node(bool)
../../gcc/gcc/cp/module.cc:9661
0xa692b9 trees_in::tree_node(bool)
../../gcc/gcc/cp/module.cc:9200
0xa6b6c5 trees_in::core_vals(tree_node*)
../../gcc/gcc/cp/module.cc:6627
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++/99855] [modules] ICE Error reporting routines re-entered.

[alexander.lelyakin at googlemail dot com via Gcc-bugs]

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

--- Comment #2 from Alexander Lelyakin  ---
Yes, attempting to repeat gives different message, but not same as by you:

malloc(): smallbin double linked list corrupted
In file included from /usr/local/include/c++/11.0.1/bits/fs_path.h:46,
 from /usr/local/include/c++/11.0.1/filesystem:45:
/usr/local/include/c++/11.0.1/bits/shared_ptr.h:330:32: internal compiler
error: Aborted
  330 | #pragma GCC diagnostic ignored "-Wdeprecated-declarations"
  |^~~
0x11016bf crash_signal
../../gcc/gcc/toplev.c:327
0x1d47750 xrealloc
../../gcc/libiberty/xmalloc.c:179
0x1cb82a7 diagnostic_classify_diagnostic(diagnostic_context*, int,
diagnostic_t, unsigned int)
../../gcc/gcc/diagnostic.c:864
0x1ca85ca control_warning_option(unsigned int, int, char const*, bool, unsigned
int, unsigned int, cl_option_handlers const*, gcc_options*, gcc_options*,
diagnostic_context*)
../../gcc/gcc/opts-common.c:1722
0xc00249 handle_pragma_diagnostic
../../gcc/gcc/c-family/c-pragma.c:849
0xaa63ab cp_parser_pragma
../../gcc/gcc/cp/parser.c:45198
0xaa7f4e cp_parser_member_specification_opt
../../gcc/gcc/cp/parser.c:25793
0xaa7f4e cp_parser_class_specifier_1
../../gcc/gcc/cp/parser.c:24877
0xaaa0a3 cp_parser_class_specifier
../../gcc/gcc/cp/parser.c:25193
0xaaa0a3 cp_parser_type_specifier
../../gcc/gcc/cp/parser.c:18440
0xaab039 cp_parser_decl_specifier_seq
../../gcc/gcc/cp/parser.c:15062
0xad5c46 cp_parser_single_declaration
../../gcc/gcc/cp/parser.c:30426
0xad5fc6 cp_parser_template_declaration_after_parameters
../../gcc/gcc/cp/parser.c:30089
0xad6770 cp_parser_explicit_template_declaration
../../gcc/gcc/cp/parser.c:30355
0xad8e99 cp_parser_declaration
../../gcc/gcc/cp/parser.c:14068
0xad8469 cp_parser_toplevel_declaration
../../gcc/gcc/cp/parser.c:14166
0xad8469 cp_parser_declaration_seq_opt
../../gcc/gcc/cp/parser.c:13954
0xad8902 cp_parser_namespace_body
../../gcc/gcc/cp/parser.c:20454
0xad8902 cp_parser_namespace_definition
../../gcc/gcc/cp/parser.c:20432
0xad9058 cp_parser_declaration
../../gcc/gcc/cp/parser.c:14117
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++/99855] [modules] ICE Error reporting routines re-entered.

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

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #1 from Marek Polacek  ---
Hmm, I see a different ICE:

malloc(): smallbin double linked list corrupted
In file included from
/home/mpolacek/x/trunk/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/fs_path.h:46,
 from
/home/mpolacek/x/trunk/x86_64-pc-linux-gnu/libstdc++-v3/include/filesystem:45:
/home/mpolacek/x/trunk/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/shared_ptr.h:330:32:
internal compiler error: Aborted
  330 | #pragma GCC diagnostic ignored "-Wdeprecated-declarations"
  |^~~
0x160dffc crash_signal
/home/mpolacek/src/gcc/gcc/toplev.c:327
0x7f965b906a5f ???
   
/usr/src/debug/glibc-2.32-37-g760e1d2878/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0
0x7f965b9069d5 __GI_raise
../sysdeps/unix/sysv/linux/raise.c:50
0x7f965b8ef8a3 __GI_abort
/usr/src/debug/glibc-2.32-37-g760e1d2878/stdlib/abort.c:79
0x7f965b949176 __libc_message
../sysdeps/posix/libc_fatal.c:155
0x7f965b950e6b malloc_printerr
/usr/src/debug/glibc-2.32-37-g760e1d2878/malloc/malloc.c:5389
0x7f965b954713 _int_malloc
/usr/src/debug/glibc-2.32-37-g760e1d2878/malloc/malloc.c:3672
0x7f965b954fcd _int_realloc
/usr/src/debug/glibc-2.32-37-g760e1d2878/malloc/malloc.c:4637
0x7f965b9562a5 __GI___libc_realloc
/usr/src/debug/glibc-2.32-37-g760e1d2878/malloc/malloc.c:3246
0x282079d xrealloc
/home/mpolacek/src/gcc/libiberty/xmalloc.c:179
0x276bd40 diagnostic_classify_diagnostic(diagnostic_context*, int,
diagnostic_t, unsigned int)
/home/mpolacek/src/gcc/gcc/diagnostic.c:864
0x27548ab control_warning_option(unsigned int, int, char const*, bool, unsigned
int, unsigned int, cl_option_handlers const*, gcc_options*, gcc_options*,
diagnostic_context*)
/home/mpolacek/src/gcc/gcc/opts-common.c:1722
0xea6c6f handle_pragma_diagnostic
/home/mpolacek/src/gcc/gcc/c-family/c-pragma.c:849
0xea7bdd c_invoke_pragma_handler(unsigned int)
/home/mpolacek/src/gcc/gcc/c-family/c-pragma.c:1515
0xcde6f5 cp_parser_pragma
/home/mpolacek/src/gcc/gcc/cp/parser.c:45200
0xca70c8 cp_parser_member_specification_opt
/home/mpolacek/src/gcc/gcc/cp/parser.c:25793
0xca4d3a cp_parser_class_specifier_1
/home/mpolacek/src/gcc/gcc/cp/parser.c:24877
0xca5ea0 cp_parser_class_specifier
/home/mpolacek/src/gcc/gcc/cp/parser.c:25193
0xc9742c cp_parser_type_specifier
/home/mpolacek/src/gcc/gcc/cp/parser.c:18440
0xc91ac9 cp_parser_decl_specifier_seq
/home/mpolacek/src/gcc/gcc/cp/parser.c:15062

[Bug ipa/99309] [10/11 Regression] Segmentation fault with __builtin_constant_p usage at -O2

[hubicka at ucw dot cz via Gcc-bugs]

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

--- Comment #7 from Jan Hubicka  ---
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99309
> 
> --- Comment #6 from Jakub Jelinek  ---
> (In reply to Jan Hubicka from comment #5)
> > As discussed, I can prepare patch to make inliner to redirect
> > __builtin_constant_p to __builtin_true whenever inliner detect that the
> > expression is compile time ocnstant.  This will avoid us eventually hitting
> > unreachable when late optimizations forget to make the transformation.
> 
> I'm quite worried about that, the point of guarding something with
> __builtin_constant_p is about the hope that the argument of that builtin will
> evaluate to constant in the conditional block guarded by it.
> By folding __builtin_constant_p to true if it sees it as constant but not
> actually propagating that constant to all uses of that expression we could 
> have
> the condition folded to true, but if SRA or FRE etc. is disabled or isn't able
> to optimize it, we wouldn't have it constant.
Yes, it is not good (this is why I did not implement it earlier).
However you can trigger same problem without inline.  Just put enough
statements between the conditional and use so AO walk oracles gives
up...

Honza

[Bug c++/99855] New: [modules] ICE Error reporting routines re-entered.

[alexander.lelyakin at googlemail dot com via Gcc-bugs]

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

Bug ID: 99855
   Summary: [modules] ICE Error reporting routines re-entered.
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: alexander.lelyakin at googlemail dot com
  Target Milestone: ---

/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header algorithm
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header memory
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header thread
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header
condition_variable
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header istream
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header variant
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header functional
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header cassert
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header cinttypes
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header shared_mutex
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header locale
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header fstream
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header cwctype
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header exception
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header cstdlib
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header string
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header vector
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header cstdio
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header filesystem

In file included from /usr/local/include/c++/11.0.1/bits/shared_ptr_base.h:53,
 from /usr/local/include/c++/11.0.1/bits/shared_ptr.h:53,
 from /usr/local/include/c++/11.0.1/bits/fs_path.h:46,
 from /usr/local/include/c++/11.0.1/filesystem:45:


Internal compiler error: Error reporting routines re-entered.
0x877d94 tree_check_failed(tree_node const*, char const*, int, char const*,
...)
../../gcc/gcc/tree.c:9816
0x6c7098 tree_check(tree_node*, char const*, int, char const*, tree_code)
../../gcc/gcc/tree.h:3353
0x6c7098 dump_decl
../../gcc/gcc/cp/error.c:1259
0xa06c40 dump_scope
../../gcc/gcc/cp/error.c:234
0x9ff580 dump_aggr_type
../../gcc/gcc/cp/error.c:770
0xa00d85 dump_function_decl
../../gcc/gcc/cp/error.c:1715
0xa086d2 decl_as_string(tree_node*, int)
../../gcc/gcc/cp/error.c:3079
0xa086d2 lang_decl_name(tree_node*, int, bool)
../../gcc/gcc/cp/error.c:3114
0xb66217 cxx_printable_name_internal
../../gcc/gcc/cp/tree.c:2632
0xa09ddc cp_print_error_function
../../gcc/gcc/cp/error.c:3472
0xa09ddc cp_diagnostic_starter
../../gcc/gcc/cp/error.c:3426
0x1cb8972 diagnostic_report_diagnostic(diagnostic_context*, diagnostic_info*)
../../gcc/gcc/diagnostic.c:1245
0x1cb8ede diagnostic_impl
../../gcc/gcc/diagnostic.c:1406
0x1cb9227 internal_error(char const*, ...)
../../gcc/gcc/diagnostic.c:1808
0x877d94 tree_check_failed(tree_node const*, char const*, int, char const*,
...)
../../gcc/gcc/tree.c:9816
0x6c7098 tree_check(tree_node*, char const*, int, char const*, tree_code)
../../gcc/gcc/tree.h:3353
0x6c7098 dump_decl
../../gcc/gcc/cp/error.c:1259
0xa06c40 dump_scope
../../gcc/gcc/cp/error.c:234
0x9ff580 dump_aggr_type
../../gcc/gcc/cp/error.c:770
0xa00d85 dump_function_decl
../../gcc/gcc/cp/error.c:1715
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

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

[Bug analyzer/99854] gcc 11 snapshot 20210328: "lto1: fatal error: Cgraph edge statement index out of range" when building Valgrind with LTO and -fanalyzer

[jseward at acm dot org via Gcc-bugs]

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

jseward at acm dot org changed:

   What|Removed |Added

 Resolution|DUPLICATE   |FIXED

--- Comment #2 from jseward at acm dot org ---
Thanks for the analyzer!  I would add (not that it's relevant to this report)
that anecdotally, it seems to use way less memory than when I tested it some
months back.  Maybe only 1/4 as much.  A big improvement.

[Bug tree-optimization/98268] [10/11 Regression] ICE: verify_gimple failed with LTO and SVE

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

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

--- Comment #8 from CVS Commits  ---
The master branch has been updated by Richard Sandiford :

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

commit r11-7936-gc778968339afd140380a46edbade054667c7dce2
Author: Richard Sandiford 
Date:   Wed Mar 31 19:34:01 2021 +0100

gimple-fold: Recompute ADDR_EXPR flags after folding a TMR [PR98268]

The gimple verifier picked up that an ADDR_EXPR of a MEM_REF was not
marked TREE_CONSTANT even though the address was in fact invariant.
This came from folding a _MEM_REF with constant operands to
a _REF; _MEM_REF is never treated as TREE_CONSTANT
but _REF can be.

gcc/
PR tree-optimization/98268
* gimple-fold.c (maybe_canonicalize_mem_ref_addr): Call
recompute_tree_invariant_for_addr_expr after successfully
folding a TARGET_MEM_REF that occurs inside an ADDR_EXPR.

gcc/testsuite/
PR tree-optimization/98268
* gcc.target/aarch64/sve/pr98268-1.c: New test.
* gcc.target/aarch64/sve/pr98268-2.c: Likewise.

[Bug tree-optimization/99726] [10/11 Regression] ICE in create_intersect_range_checks_index, at tree-data-ref.c:1855 since r10-4762-gf9d6338bd15ce1fae36bf25d3a0545e9678ddc58

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

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Richard Sandiford :

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

commit r11-7935-gb5c7accfb56a7347008f629be4c7344dd849b1b1
Author: Richard Sandiford 
Date:   Wed Mar 31 19:34:01 2021 +0100

data-ref: Tighten index-based alias checks [PR99726]

create_intersect_range_checks_index tries to create a runtime
alias check based on index comparisons.  It looks through the
access functions for the two DRs to find a SCEV for the loop
that is being versioned and converts a DR_STEP-based check
into an index-based check.

However, there isn't any reliable sign information in the types,
so the code expects the value of the IV step (when interpreted as
signed) to be negative iff the DR_STEP (when interpreted as signed)
is negative.

r10-4762 added another assert related to this assumption and the
assert fired for the testcase in the PR.  The sign of the IV step
didn't match the sign of the DR_STEP.

I think this is actually showing what was previously a wrong-code bug.
The signs didn't match because the DRs contained *two* access function
SCEVs for the loop being versioned.  It doesn't look like the code
is set up to deal with this, since it checks each access function
independently and treats it as the sole source of DR_STEP.

The patch therefore moves the main condition out of the loop.
This also has the advantage of not building a tree for one access
function only to throw it away if we find an inner function that
makes the comparison invalid.

gcc/
PR tree-optimization/99726
* tree-data-ref.c (create_intersect_range_checks_index): Bail
out if there is more than one access function SCEV for the loop
being versioned.

gcc/testsuite/
PR tree-optimization/99726
* gcc.target/i386/pr99726.c: New test.

[Bug c++/99851] Warn about operator new that takes std::nothrow_t but is potentially-throwing

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

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

Martin Sebor  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
 CC||msebor at gcc dot gnu.org
   Last reconfirmed||2021-03-31

--- Comment #1 from Martin Sebor  ---
Confirmed, thanks!  Just to make sure I understand: we want a warning for the
operator new declaration (irrespective of its definition) because the nothrow_t
argument suggests it doesn't throw but the absence of noexcept implies it
might.  I.e., the warning can be emitted as early as in the C++ front end.

The following modified test case shows that the the null test in main() is
eliminated on the basis of the missing noexcept:

$ cat pr99851.C && g++ -O1 -S -Wall -fdump-tree-optimized=/dev/stdout pr99851.C
namespace std {
  typedef __SIZE_TYPE__ size_t;
  const struct nothrow_t { } nothrow;
}

struct X
{
  void* operator new[](std::size_t n, const std::nothrow_t&) {
return __builtin_malloc (n);
  }

  unsigned data = 0;
};

int main()
{
  void *p = new (std::nothrow) X[2];
  if (!p)
__builtin_abort ();
  __builtin_printf ("%p\n", p);
}

;; Function main (main, funcdef_no=1, decl_uid=2393, cgraph_uid=5,
symbol_order=5) (executed once)

int main ()
{
  void * _9;

   [local count: 357878154]:
  _9 = __builtin_malloc (8);
  MEM[(struct X *)_9].data = 0;
  MEM[(struct X *)_9 + 4B].data = 0;
  __builtin_printf ("%p\n", _9);
  return 0;

}

[Bug target/97141] [10/11 Regression] aarch64, SVE: ICE in decompose, at rtl.h (during expand) since r10-4676-g9c437a108a

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

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Richard Sandiford :

https://gcc.gnu.org/g:1b5f74e8be4dd7abe5624ff60adceff19ca71bda

commit r11-7934-g1b5f74e8be4dd7abe5624ff60adceff19ca71bda
Author: Richard Sandiford 
Date:   Wed Mar 31 19:34:00 2021 +0100

Handle CONST_POLY_INTs in CONST_VECTORs [PR97141, PR98726]

This PR is caused by POLY_INT_CSTs being (necessarily) valid
in tree-level VECTOR_CSTs but CONST_POLY_INTs not being valid
in RTL CONST_VECTORs.  I can't tell/remember how deliberate
that was, but I'm guessing not very.  In particular,
valid_for_const_vector_p was added to guard against symbolic
constants rather than CONST_POLY_INTs.

I did briefly consider whether we should maintain the current
status anyway.  However, that would then require a way of
constructing variable-length vectors from individiual elements
if, say, we have:

   { [2, 2], [3, 2], [4, 2], ⦠}

So I'm chalking this up to an oversight.  I think the intention
(and certainly the natural thing) is to have the same rules for
both trees and RTL.

The SVE CONST_VECTOR code should already be set up to handle
CONST_POLY_INTs.  However, we need to add support for Advanced SIMD
CONST_VECTORs that happen to contain SVE-based values.  The patch does
that by expanding such CONST_VECTORs in the same way as variable vectors.

gcc/
PR rtl-optimization/97141
PR rtl-optimization/98726
* emit-rtl.c (valid_for_const_vector_p): Return true for
CONST_POLY_INT_P.
* rtx-vector-builder.h (rtx_vector_builder::step): Return a
poly_wide_int instead of a wide_int.
(rtx_vector_builder::apply_set): Take a poly_wide_int instead
of a wide_int.
* rtx-vector-builder.c (rtx_vector_builder::apply_set): Likewise.
* config/aarch64/aarch64.c (aarch64_legitimate_constant_p): Return
false for CONST_VECTORs that cannot be forced to memory.
* config/aarch64/aarch64-simd.md (mov): If a CONST_VECTOR
is too complex to force to memory, build it up from individual
elements instead.

gcc/testsuite/
PR rtl-optimization/97141
PR rtl-optimization/98726
* gcc.c-torture/compile/pr97141.c: New test.
* gcc.c-torture/compile/pr98726.c: Likewise.
* gcc.target/aarch64/sve/pr97141.c: Likewise.
* gcc.target/aarch64/sve/pr98726.c: Likewise.

[Bug tree-optimization/98726] [10/11 Regression] SVE: tree check: expected integer_cst, have poly_int_cst in to_wide, at tree.h:5984

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

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

--- Comment #11 from CVS Commits  ---
The master branch has been updated by Richard Sandiford :

https://gcc.gnu.org/g:1b5f74e8be4dd7abe5624ff60adceff19ca71bda

commit r11-7934-g1b5f74e8be4dd7abe5624ff60adceff19ca71bda
Author: Richard Sandiford 
Date:   Wed Mar 31 19:34:00 2021 +0100

Handle CONST_POLY_INTs in CONST_VECTORs [PR97141, PR98726]

This PR is caused by POLY_INT_CSTs being (necessarily) valid
in tree-level VECTOR_CSTs but CONST_POLY_INTs not being valid
in RTL CONST_VECTORs.  I can't tell/remember how deliberate
that was, but I'm guessing not very.  In particular,
valid_for_const_vector_p was added to guard against symbolic
constants rather than CONST_POLY_INTs.

I did briefly consider whether we should maintain the current
status anyway.  However, that would then require a way of
constructing variable-length vectors from individiual elements
if, say, we have:

   { [2, 2], [3, 2], [4, 2], ⦠}

So I'm chalking this up to an oversight.  I think the intention
(and certainly the natural thing) is to have the same rules for
both trees and RTL.

The SVE CONST_VECTOR code should already be set up to handle
CONST_POLY_INTs.  However, we need to add support for Advanced SIMD
CONST_VECTORs that happen to contain SVE-based values.  The patch does
that by expanding such CONST_VECTORs in the same way as variable vectors.

gcc/
PR rtl-optimization/97141
PR rtl-optimization/98726
* emit-rtl.c (valid_for_const_vector_p): Return true for
CONST_POLY_INT_P.
* rtx-vector-builder.h (rtx_vector_builder::step): Return a
poly_wide_int instead of a wide_int.
(rtx_vector_builder::apply_set): Take a poly_wide_int instead
of a wide_int.
* rtx-vector-builder.c (rtx_vector_builder::apply_set): Likewise.
* config/aarch64/aarch64.c (aarch64_legitimate_constant_p): Return
false for CONST_VECTORs that cannot be forced to memory.
* config/aarch64/aarch64-simd.md (mov): If a CONST_VECTOR
is too complex to force to memory, build it up from individual
elements instead.

gcc/testsuite/
PR rtl-optimization/97141
PR rtl-optimization/98726
* gcc.c-torture/compile/pr97141.c: New test.
* gcc.c-torture/compile/pr98726.c: Likewise.
* gcc.target/aarch64/sve/pr97141.c: Likewise.
* gcc.target/aarch64/sve/pr98726.c: Likewise.

[Bug ipa/99309] [10/11 Regression] Segmentation fault with __builtin_constant_p usage at -O2

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

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

--- Comment #6 from Jakub Jelinek  ---
(In reply to Jan Hubicka from comment #5)
> As discussed, I can prepare patch to make inliner to redirect
> __builtin_constant_p to __builtin_true whenever inliner detect that the
> expression is compile time ocnstant.  This will avoid us eventually hitting
> unreachable when late optimizations forget to make the transformation.

I'm quite worried about that, the point of guarding something with
__builtin_constant_p is about the hope that the argument of that builtin will
evaluate to constant in the conditional block guarded by it.
By folding __builtin_constant_p to true if it sees it as constant but not
actually propagating that constant to all uses of that expression we could have
the condition folded to true, but if SRA or FRE etc. is disabled or isn't able
to optimize it, we wouldn't have it constant.

[Bug analyzer/98599] fatal error: Cgraph edge statement index out of range with -Os -flto -fanalyzer

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

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

David Malcolm  changed:

   What|Removed |Added

 CC||jseward at acm dot org

--- Comment #11 from David Malcolm  ---
*** Bug 99854 has been marked as a duplicate of this bug. ***

[Bug analyzer/99854] gcc 11 snapshot 20210328: "lto1: fatal error: Cgraph edge statement index out of range" when building Valgrind with LTO and -fanalyzer

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

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #1 from David Malcolm  ---
Thanks for filing this (and for valgrind!)

Looks like a dup of bug 98599.

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

[Bug target/99847] Optimization breaks alignment on CPU32

[mikpelinux at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Mikael Pettersson  ---
I am almost certain that you need to use an m68k-elf toolchain rather than an
m68k-linux-gnu one for the CPU32. The linux toolchain targets the classic '020
CPU or above (030, 040, or 060) and mandates the Linux ABI, which affects
alignment among other things.

[Bug ipa/99309] [10/11 Regression] Segmentation fault with __builtin_constant_p usage at -O2

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

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

--- Comment #5 from Jan Hubicka  ---
As discussed, I can prepare patch to make inliner to redirect
__builtin_constant_p to __builtin_true whenever inliner detect that the
expression is compile time ocnstant.  This will avoid us eventually hitting
unreachable when late optimizations forget to make the transformation.

I was worried about this idea since this will still lead to some inconsistency
since uses guarded by the __builtin_constnat_p may or may not be constant
propagated and it seems logical to assume that in the block guarded by
builtin_constnat_p the expression will indeed evaluate to compile time
constant.

However we can get similar inconsistencies with alias oracle walking limits as
well, so these constructions are generally fragile (but seems increasingly
common in C++ codebases).

It would be still nice to have fre5 to constant propagate this. IPA analysis
are very simplistics.
Richi, any idea on this?

[Bug ipa/99447] [11 Regression] ICE (segfault) in lookup_page_table_entry

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

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

Jan Hubicka  changed:

   What|Removed |Added

 Status|NEW |WAITING

--- Comment #27 from Jan Hubicka  ---
Even with pie and fat LTO the compilation works well. In addition I committed
patch that should make it clear that we to not stale pointers.

Without a reproducer I am not sure what we can do more, so perhaps we can
resolve it as WORKSFORME.

[Bug ipa/99447] [11 Regression] ICE (segfault) in lookup_page_table_entry

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

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

--- Comment #26 from CVS Commits  ---
The master branch has been updated by Jan Hubicka :

https://gcc.gnu.org/g:23ce9945d5efa77c96161443f68e03664705ada3

commit r11-7933-g23ce9945d5efa77c96161443f68e03664705ada3
Author: Jan Hubicka 
Date:   Wed Mar 31 20:10:31 2021 +0200

Fix overvactive check in cgraph_node::release_body

gcc/ChangeLog:

PR lto/99447
* cgraph.c (cgraph_node::release_body): Fix overactive check.

[Bug fortran/99853] ICE: Cannot convert 'LOGICAL(4)' to 'INTEGER(8)' (etc.)

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

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4
   Last reconfirmed||2021-03-31
 CC||kargl at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #2 from kargl at gcc dot gnu.org ---
Patch.  No need to ICE here.

diff --git a/gcc/fortran/resolve.c b/gcc/fortran/resolve.c
index b936c98a211..425150126fd 100644
--- a/gcc/fortran/resolve.c
+++ b/gcc/fortran/resolve.c
@@ -8711,11 +8711,11 @@ resolve_select (gfc_code *code, bool select_type)

  if (cp->low != NULL
  && case_expr->ts.kind != gfc_kind_max(case_expr, cp->low))
-   gfc_convert_type_warn (case_expr, >low->ts, 2, 0);
+   gfc_convert_type_warn (case_expr, >low->ts, 1, 0);

  if (cp->high != NULL
  && case_expr->ts.kind != gfc_kind_max(case_expr, cp->high))
-   gfc_convert_type_warn (case_expr, >high->ts, 2, 0);
+   gfc_convert_type_warn (case_expr, >high->ts, 1, 0);
}
 }
 }

[Bug analyzer/99854] New: gcc 11 snapshot 20210328: "lto1: fatal error: Cgraph edge statement index out of range" when building Valgrind with LTO and -fanalyzer

[jseward at acm dot org via Gcc-bugs]

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

Bug ID: 99854
   Summary: gcc 11 snapshot 20210328: "lto1: fatal error: Cgraph
edge statement index out of range" when building
Valgrind with LTO and -fanalyzer
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: jseward at acm dot org
  Target Milestone: ---

Building Valgrind trunk on x86_64-linux with gcc (GCC) 11.0.1 20210328
(experimental) fails with

  In function ‘setregs’:
  lto1: fatal error: Cgraph edge statement index out of range

This requires both LTO and -fanalyzer to fail.  Either by itself does not fail.

STR on x86_64-linux, Fedora 33:

  git clone git://sourceware.org/git/valgrind.git
  cd valgrind
  # apply one-line config patch below, so as to build with -fanalyzer
  ./autogen.sh && ./configure --prefix=`pwd`/Inst --enable-only64bit
--enable-lto
  make -j8

Fails thusly:

  In function ‘myvprintf_str_XML_simplistic’:
  lto1: fatal error: Cgraph edge statement index out of range

and

  In function ‘setregs’:
  lto1: fatal error: Cgraph edge statement index out of range

(takes about 25 seconds).

Sorry not to have minimised.  Am willing to try out patches.

Config patch as referred to above:

diff --git a/Makefile.all.am b/Makefile.all.am
index bcd29165d..c339b95c7 100644
--- a/Makefile.all.am
+++ b/Makefile.all.am
@@ -96,7 +96,7 @@ clean-noinst_DSYMS:
 # performance and get whatever useful warnings we can out of gcc.
 # -fno-builtin is important for defeating LLVM's idiom recognition
 # that somehow causes VG_(memset) to get into infinite recursion.
-AM_CFLAGS_BASE = \
+AM_CFLAGS_BASE = -fanalyzer \
-O2 -g \
-Wall \
-Wmissing-prototypes \

[Bug c++/99850] [P1102R2] reject valid lambda syntax in C++23

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

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

Marek Polacek  changed:

   What|Removed |Added

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

[Bug middle-end/63943] wrong location for -Wmaybe-uninitialized in inlined function

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

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

--- Comment #4 from Manuel López-Ibáñez  ---
(In reply to Martin Sebor from comment #3)
> As for using %K, I mostly agree.  I actually have %G in my tree, but my goal
> is to get rid of both and replace them with a new warning function like so:
>   https://gcc.gnu.org/pipermail/gcc-patches/2021-January/563862.html
> and replace calls to warning() and warning_at() in the middle end with those
> to the new function.  This makes it possible to control warnings at any
> point in the lining stack and resolves bug like pr98871.

That is great. It may be worth CCing David Malcolm, since he is the diagnostics
maintainer. A couple of comments:

* #include "tree.h" in diagnostic.c is not great. Ideally, diagnostic.c should
be independent of trees so that other front-ends can use it without having to
use tree. We went through a lot of work to make the core diagnostics
independent of any FE or Middle-end and only depend on line-map and options
handling. The original plan is to move it to its own library/module, but I
guess there has been little progress in the modular GCC.

* There is a tree-diagnostic.c. Everything that depends on tree.h should be
moved there. (again, if there was a modular GCC, this would be obvious but
alas...)

* Although it is more work, I think Richard and other middle-end reviewers
would be more motivated to accept this if it removed completely
percent_K_format. That is, rather than add yet-another-way, completely replaces
the old %K with something better.

* I don't contribute to GCC anymore, but rather than doing:

diag_inlining_context dic (exp);
warning (dic, opt, "%qD specified size %E may exceed maximum object size %E",
func, bndrng[0], maxobjsize);

I'd prefer:

warning_at_inlined_context(exp, opt, "%qD specified size %E may exceed maximum
object size %E", func, bndrng[0], maxobjsize);

This way, I don't need to know about class diag_inlining_context nor about
another variable (dic). I just need to know about an alternative warning
function and the magic is hidden from me. This function can live in
tree-diagnostic.c which contains the tree-specific functions for diagnostics.

[Bug fortran/99853] ICE: Cannot convert 'LOGICAL(4)' to 'INTEGER(8)' (etc.)

[gscfq--- via Gcc-bugs]

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

G. Steinmetz  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code

--- Comment #1 from G. Steinmetz  ---

More test cases :


$ cat z2.f90
program p
   select case (.true.)
   case (1_16)
   end select
end


$ cat z3.f90
program p
   select case (.true._1)
   case (1_2)
   end select
end


$ cat z4.f90
program p
   select case (.true._8)
   case (1_16)
   end select
end


$ cat z5.f90
program p
   select case (1_2)
   case (.true.)
   end select
end


$ cat z6.f90
program p
   select case (1_4)
   case (.true._8)
   end select
end


---


While cases like the following give :


$ cat z0.f90
program p
   select case (.true.)
   case (1)
   end select
end


$ cat z0b.f90
program p
   select case (.true.)
   case (1_1)
   end select
end


$ cat z0c.f90
program p
   select case (.true._16)
   case (1_8)
   end select
end


$ gfortran-11-20210328 -c z0.f90 -std=f2008
z0.f90:3:9:

3 |case (1)
  | 1
Error: Expression in CASE statement at (1) must be of type LOGICAL

[Bug fortran/99853] New: ICE: Cannot convert 'LOGICAL(4)' to 'INTEGER(8)' (etc.)

[gscfq--- via Gcc-bugs]

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

Bug ID: 99853
   Summary: ICE: Cannot convert 'LOGICAL(4)' to 'INTEGER(8)'
(etc.)
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

With option -std=f95, -std=f2003, -std=f2008 or -std=f2018 :
(affects versions down to at least r5)


$ cat z1.f90
program p
   select case (.true.)
   case (1_8)
   end select
end


$ gfortran-11-20210328 -c z1.f90
z1.f90:2:16:

2 |select case (.true.)
  |1
Warning: Extension: Conversion from LOGICAL(4) to INTEGER(8) at (1)


$ gfortran-11-20210328 -c z1.f90 -std=f2008
z1.f90:2:16:

2 |select case (.true.)
  |1
internal compiler error: Cannot convert 'LOGICAL(4)' to 'INTEGER(8)' at (1)
0x6c38d9 gfc_report_diagnostic
../../gcc/fortran/error.c:782
0x6c4ffa gfc_internal_error(char const*, ...)
../../gcc/fortran/error.c:1402
0x6e4808 gfc_convert_type_warn(gfc_expr*, gfc_typespec*, int, int, bool)
../../gcc/fortran/intrinsic.c:5397
0x72f277 resolve_select
../../gcc/fortran/resolve.c:8714
0x738b97 gfc_resolve_code(gfc_code*, gfc_namespace*)
../../gcc/fortran/resolve.c:12055
0x73a9f7 resolve_codes
../../gcc/fortran/resolve.c:17395
0x73aabe gfc_resolve(gfc_namespace*)
../../gcc/fortran/resolve.c:17430
0x723024 resolve_all_program_units
../../gcc/fortran/parse.c:6290
0x723024 gfc_parse_file()
../../gcc/fortran/parse.c:6542
0x7705ff gfc_be_parse_file
../../gcc/fortran/f95-lang.c:212

[Bug fortran/99852] Missing error "Arithmetic overflow" for some cases

[gscfq--- via Gcc-bugs]

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

--- Comment #1 from G. Steinmetz  ---

In addition a side mark, the following gives for all a-d :


$ cat z3.f90
program p
   implicit none
   integer, parameter :: wik = 1
   integer(wik), parameter :: a = -huge(1_wik) - 1_wik
   integer(wik) :: b = -huge(1_wik) - 1_wik
   integer(wik) :: c
   c = -huge(1_wik) - 1_wik
   associate (d => -huge(1_wik) - 1_wik)
  print *, a, b, c, d
   end associate
end


$ gfortran-11-20210328 -c z3.f90 -pedantic
z3.f90:4:33:

4 |integer(wik), parameter :: a = -huge(1_wik) - 1_wik
  | 1
Warning: Integer outside symmetric range implied by Standard Fortran at (1)
z3.f90:5:22:

5 |integer(wik) :: b = -huge(1_wik) - 1_wik
  |  1
Warning: Integer outside symmetric range implied by Standard Fortran at (1)
z3.f90:7:7:

7 |c = -huge(1_wik) - 1_wik
  |   1
Warning: Integer outside symmetric range implied by Standard Fortran at (1)
z3.f90:8:19:

8 |associate (d => -huge(1_wik) - 1_wik)
  |   1
Warning: Integer outside symmetric range implied by Standard Fortran at (1)

[Bug fortran/99852] New: Missing error "Arithmetic overflow" for some cases

[gscfq--- via Gcc-bugs]

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

Bug ID: 99852
   Summary: Missing error "Arithmetic overflow" for some cases
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Following examples produce an error for c and d, but not for a and b :
(similar for wik=2,4,8,16)


$ cat z1.f90
program p
   implicit none
   integer, parameter :: wik = 1
   integer(wik), parameter :: a = huge(1_wik) + 1_wik
   integer(wik) :: b = huge(1_wik) + 1_wik
   integer(wik) :: c
   c = huge(1_wik) + 1_wik
   associate (d => huge(1_wik) + 1_wik)
  print *, a, b, c, d
   end associate
end


$ cat z2.f90
program p
   implicit none
   integer, parameter :: wik = 1
   integer(wik), parameter :: a = -huge(1_wik) - 2_wik
   integer(wik) :: b = -huge(1_wik) - 2_wik
   integer(wik) :: c
   c = -huge(1_wik) - 2_wik
   associate (d => -huge(1_wik) - 2_wik)
  print *, a, b, c, d
   end associate
end


$ gfortran-11-20210328 -c z1.f90
z1.f90:7:7:

7 |c = huge(1_wik) + 1_wik
  |   1
Error: Arithmetic overflow at (1)
z1.f90:8:19:

8 |associate (d => huge(1_wik) + 1_wik)
  |   1
Error: Arithmetic overflow at (1)

[Bug fortran/97455] ICE on invalid code (wrong pointer assignment) in SELECT TYPE construct

[gscfq--- via Gcc-bugs]

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

G. Steinmetz  changed:

   What|Removed |Added

 CC||gs...@t-online.de

--- Comment #2 from G. Steinmetz  ---

Update, backtrace and a variation :


$ cat z1.f90
subroutine s
   select type (x => x(:))
   end select
end


$ cat z2.f90
subroutine s
   select type (x ==> x)
   end select
end


$ gfortran-11-20210328 -c z1.f90
f951: internal compiler error: Segmentation fault
0xc09d4f crash_signal
../../gcc/toplev.c:327
0x6576ba delete_root
../../gcc/fortran/bbt.c:150
0x65787e gfc_delete_bbt(void*, void*, int (*)(void*, void*))
../../gcc/fortran/bbt.c:197
0x7224d8 gfc_delete_symtree(gfc_symtree**, char const*)
../../gcc/fortran/symbol.c:2962
0x723bd6 gfc_restore_last_undo_checkpoint()
../../gcc/fortran/symbol.c:3706
0x6dab47 reject_statement
../../gcc/fortran/parse.c:2678
0x6de324 match_word
../../gcc/fortran/parse.c:70
0x6de324 decode_statement
../../gcc/fortran/parse.c:428
0x6dfb3c next_free
../../gcc/fortran/parse.c:1316
0x6dfb3c next_statement
../../gcc/fortran/parse.c:1548
0x6e1f04 parse_spec
../../gcc/fortran/parse.c:3783
0x6e3f7c parse_progunit
../../gcc/fortran/parse.c:5896
0x6e5a20 gfc_parse_file()
../../gcc/fortran/parse.c:6444
0x7320ef gfc_be_parse_file
../../gcc/fortran/f95-lang.c:212

[Bug c++/99833] [8/9/10/11 Regression] structured binding + if init + generic lambda = internal compiler error

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

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

--- Comment #5 from Patrick Palka  ---
It looks like GCC 10.1 accepts this testcase, and 10.2, 10.3 and 11 reject.

The requires-expression is a red herring, we can trigger the ICE without it:

#include 
template void f() {
  [] (auto x) {
if constexpr (auto [a, b] = std::tuple{x, x}; sizeof(a) > 1)
  ;
  }(0);
}

template void f();

The ICE for this one isn't a regression it seems.

[Bug c++/99845] gcc8: Overloaded operator new[](size_t, const std::nothrow_t&) is seg faulting when the allocation fails

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #10 from Jonathan Wakely  ---
(In reply to Martin Sebor from comment #9)
> This seems like it might be worth warning about.

Requested as PR 99851

[Bug c++/99851] New: Warn about operator new that takes std::nothrow_t but is potentially-throwing

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

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

Bug ID: 99851
   Summary: Warn about operator new that takes std::nothrow_t but
is potentially-throwing
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: enhancement
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
Blocks: 87403
  Target Milestone: ---

This program crashes with a segfault:

#include 

void* null() { return nullptr; }

struct X
{
  void* operator new[](std::size_t, const std::nothrow_t&) {
return null();
  }

  unsigned data = 0;
};

int main()
{
  new(std::nothrow) X[2];
}

The problem is that the new overload is not noexcept, so the compiler assumes
it can't return null. The user probably intended it to be a non-throwing form
of operator new (as implied by the nothrow_t parameter), so we should warn that
it isn't noexcept.

N.B. if the function return nullptr directly then we warn:

new.C: In static member function ‘static void* X::operator new [](std::size_t,
const std::nothrow_t&)’:
new.C:6:12: warning: ‘operator new’ must not return NULL unless it is declared
‘throw()’ (or ‘-fcheck-new’ is in effect)
6 | return nullptr;
  |^~~

That should be updated to say 'noexcept' not 'throw()' and we might want the
two warnigns to use similar phrasing. That warning should also say "a null
pointer" not NULL.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87403
[Bug 87403] [Meta-bug] Issues that suggest a new warning

[Bug rtl-optimization/96264] [10 Regression] wrong code with -Os -fno-forward-propagate -fschedule-insns -fno-tree-ter

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

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

--- Comment #22 from Vladimir Makarov  ---
I've committed the patch to gcc-10 branch.

I also committed patch modifying the test -- see PR99233.

[Bug testsuite/99233] [11 regression] new test case gcc.target/powerpc/pr96264.c in r11-7285 fails

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

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

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

https://gcc.gnu.org/g:395dac0ab6dad8aaef1180e961a5cd51da649f23

commit r10-9645-g395dac0ab6dad8aaef1180e961a5cd51da649f23
Author: Vladimir N. Makarov 
Date:   Thu Feb 25 11:20:32 2021 -0500

[PR99233] tesstsuite: Run test pr96264.c only for little endian

The test in question is assumed to work only for little endian target.

gcc/testsuite/ChangeLog:

PR testsuite/99233
* gcc.target/powerpc/pr96264.c: Run it only for powerpc64le.

[Bug rtl-optimization/96264] [10 Regression] wrong code with -Os -fno-forward-propagate -fschedule-insns -fno-tree-ter

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

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

--- Comment #21 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Vladimir Makarov
:

https://gcc.gnu.org/g:1b7c97f25b271f826958873bda4fafc4cfc5b60d

commit r10-9644-g1b7c97f25b271f826958873bda4fafc4cfc5b60d
Author: Vladimir N. Makarov 
Date:   Thu Feb 18 17:49:26 2021 -0500

[PR96264] LRA: Check output insn hard regs when updating available
rematerialization after the insn

 Insn for rematerialization can contain a clobbered hard register.  We
can not move such insn through another insn setting up the same hard
register.  The patch adds such check.

gcc/ChangeLog:

PR rtl-optimization/96264
* lra-remat.c (reg_overlap_for_remat_p): Check also output insn
hard regs.

gcc/testsuite/ChangeLog:

PR rtl-optimization/96264
* gcc.target/powerpc/pr96264.c: New.

[Bug c++/99850] [P1102R2] reject valid lambda syntax in C++23

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

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #1 from Marek Polacek  ---
Confirmed.  I could take a look, unless Jakub wants it.

[Bug middle-end/65182] -Wuninitialized fails when pointer to variable later passed to function (fixed? add testcase?)

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

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

--- Comment #8 from CVS Commits  ---
The master branch has been updated by Martin Sebor :

https://gcc.gnu.org/g:31199d95de1304e200554bbf98b2d8a6a7298bec

commit r11-7932-g31199d95de1304e200554bbf98b2d8a6a7298bec
Author: Martin Sebor 
Date:   Wed Mar 31 10:39:24 2021 -0600

PR middle-end/65182 - -Wuninitialized fails when pointer to variable later
passed to function

gcc/testsuite:
PR middle-end/65182
* gcc.dg/uninit-pr65182.c: New test.

[Bug c++/99850] New: [P1102R2] reject valid lambda syntax in C++23

[hewillk at gmail dot com via Gcc-bugs]

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

Bug ID: 99850
   Summary: [P1102R2] reject valid lambda syntax in C++23
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hewillk at gmail dot com
  Target Milestone: ---

https://godbolt.org/z/x5E5cGPTb

auto l = [] requires true -> void {};

gcc incorrectly rejects this valid lambda, you can see more details in
https://stackoverflow.com/questions/6684/the-validity-of-lambda-expression-with-omitted-parameter-list-in-c23