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

[i at maskray dot me]

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

Bug ID: 96092
   Summary: Should --coverage respect -ffile-prefix-map?
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: gcov-profile
  Assignee: unassigned at gcc dot gnu.org
  Reporter: i at maskray dot me
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

% gcc-10 -ffile-prefix-map=/tmp/c=/src --coverage -c -g /tmp/c/a.c

# -ffile-prefix-map implies -fdebug-prefix-map
% llvm-dwarfdump -debug-info a.o | grep /src
  DW_AT_name("/src/a.c")
  DW_AT_comp_dir("/src")
DW_AT_decl_file ("/src/a.c")

# --coverage is not affected
% r2 -qc 'pxw `?v $s`' a.gcno
0x  0x67636e6f 0x42303065 0x27b4c272 0x0002  oncge00Br..'
0x0010  0x706d742f 0x632f 0x0001 0x0100  /tmp/c..
0x0020  0x000f 0x067072eb 0x40058857 0xdb5de9e8  .rp.W..@..].
0x0030  0x0002 0x6e69616d 0x 0x  main
0x0040  0x0003 0x706d742f 0x612f632f 0x632e  /tmp/c/a.c..
0x0050  0x0001 0x0005 0x0001 0x000c  
0x0060  0x0141 0x0001 0x0004 0x0143  ..A...C.
0x0070  0x0003 0x 0x0002 0x0004  
0x0080  0x0143 0x0003 0x0002 0x0003  ..C.
0x0090  0x0005 0x0143 0x0003 0x0003  ..C.
0x00a0  0x0001 0x0001 0x0145 0x0009  ..E.
0x00b0  0x0002 0x 0x0003 0x706d742f  /tmp
0x00c0  0x612f632f 0x632e 0x0001 0x  /c/a.c..
0x00d0  0x


I created this issue because I saw a clang-side proposal
https://reviews.llvm.org/D83154 (add -fcoverage-prefix-map) today.

[Bug tree-optimization/96091] ICE during dom: tree check: expected integer_cst, have poly_int_cst in to_wide, at tree.h:5911

[qianchao9 at huawei dot com]

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

--- Comment #1 from Qian Chao  ---
Bootstrap and tested on aarch64 platform. No new regression witnessed.

Any suggestions?

[Bug tree-optimization/96091] New: ICE during dom: tree check: expected integer_cst, have poly_int_cst in to_wide, at tree.h:5911

[qianchao9 at huawei dot com]

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

Bug ID: 96091
   Summary: ICE during dom: tree check: expected integer_cst, have
poly_int_cst in to_wide, at tree.h:5911
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: qianchao9 at huawei dot com
  Target Milestone: ---

Created attachment 48840
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48840=edit
fix-gimple-fold

Compiling this with -S -ftree-vectorize -march=armv8.5-a+sve -O2
-mno-strict-align -ftracer:

void foo(short a[], short m)
{
  int i, j;
  int f1[10];
  short nc;

  nc = m + 1;
  for (i = 0, j = m; i < nc; i++, j--)
{
  a[i] = f1[i];
  a[j] = i;
}
  return;
}

gives:

during GIMPLE pass: dom
testcase.c: In function ‘foo’:
testcase.c:1:6: internal compiler error: tree check: expected integer_cst, have
poly_int_cst in to_wide, at tree.h:5911
1 | void foo(short a[], short m)
  |  ^~~
0x17714fb tree_check_failed(tree_node const*, char const*, int, char const*,
...)
../../gcc/tree.c:9685
0x9ebf7f tree_int_cst_elt_check(tree_node const*, int, char const*, int, char
const*)
../../gcc/tree.h:3491
0xa3d5bf wi::to_wide(tree_node const*)
../../gcc/tree.h:5911
0x17787ff vector_cst_int_elt(tree_node const*, unsigned int)
../../gcc/tree.c:10964
0x1778a33 vector_cst_elt(tree_node const*, unsigned int)
../../gcc/tree.c:10991
0xdfa553 vec_cst_ctor_to_array
../../gcc/fold-const.c:9795
0xdfa9d7 fold_vec_perm(tree_node*, tree_node*, tree_node*, vec_perm_indices
const&)
../../gcc/fold-const.c:9836
0x1c85c27 generic_simplify_VEC_PERM_EXPR
/home/qianchao/opt/gccRepo/gcc/build/gcc/generic-match.c:75993
0x1c86c37 generic_simplify(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*, tree_node*)
/home/qianchao/opt/gccRepo/gcc/build/gcc/generic-match.c:76143
0xe0703f fold_ternary_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*, tree_node*)
../../gcc/fold-const.c:12116
0x190eb43 gimple_resimplify3
../../gcc/gimple-match-head.c:354
0x1910bfb gimple_simplify(gimple*, gimple_match_op*, gimple**, tree_node*
(*)(tree_node*), tree_node* (*)(tree_node*))
../../gcc/gimple-match-head.c:1001
0xe86493 gimple_fold_stmt_to_constant_1(gimple*, tree_node* (*)(tree_node*),
tree_node* (*)(tree_node*))
../../gcc/gimple-fold.c:6329
0x1658c1f record_temporary_equivalences_from_stmts_at_dest
../../gcc/tree-ssa-threadedge.c:362
0x165a8db thread_through_normal_block
../../gcc/tree-ssa-threadedge.c:1064
0x165b363 thread_across_edge
../../gcc/tree-ssa-threadedge.c:1372
0x165b537 thread_outgoing_edges(basic_block_def*, gcond*, const_and_copies*,
avail_exprs_stack*, evrp_range_analyzer*, tree_node* (*)(gimple*, gimple*,
avail_exprs_stack*,   basic_block_def*))
../../gcc/tree-ssa-threadedge.c:1440
0x14f53bb dom_opt_dom_walker::after_dom_children(basic_block_def*)
../../gcc/tree-ssa-dom.c:1548
0x21663b7 dom_walker::walk(basic_block_def*)
../../gcc/domwalk.c:352
0x14f2df7 execute
../../gcc/tree-ssa-dom.c:724
...

The testcase failed to get unencoded elts in vector_cst during dom3, as the
vector_cst needs integer_cst elements. Howerver, the reason for ICE is that we
should not fold vector constructor that contains poly_int_cst elements to
vector_cst.

the following fixes the latent bug - we faild to limit folding poly_int_cst
constructor

diff --git a/gcc/gimple-fold.c b/gcc/gimple-fold.c
index 4e3de95d2d2..679a6770676 100644
--- a/gcc/gimple-fold.c
+++ b/gcc/gimple-fold.c
@@ -438,7 +438,7 @@ fold_gimple_assign (gimple_stmt_iterator *si)
tree val;

FOR_EACH_CONSTRUCTOR_VALUE (CONSTRUCTOR_ELTS (rhs), i, val)
- if (! CONSTANT_CLASS_P (val))
+ if (! CONSTANT_CLASS_P (val) || POLY_INT_CST_P (val))
return NULL_TREE;

return build_vector_from_ctor (TREE_TYPE (rhs),

[Bug libstdc++/96042] Reference type of std::ranges::iota is __int128 with -std=c++2a?!

[rs2740 at gmail dot com]

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

TC  changed:

   What|Removed |Added

 CC||rs2740 at gmail dot com

--- Comment #4 from TC  ---
Note that https://wg21.link/iterator.concept.winc#10 requires numeric_limits
specializations for integer-class types.

[Bug c++/96090] New: Inconsistent querying of differring exception specifications of explicitly defaulted functions

[johelegp at gmail dot com]

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

Bug ID: 96090
   Summary: Inconsistent querying of differring exception
specifications of explicitly defaulted functions
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: johelegp at gmail dot com
  Target Milestone: ---

See https://godbolt.org/z/SiGMyX.
```C++
#include 
using namespace std;
struct yesthrow_t
{
yesthrow_t()  noexcept(false) = default;
yesthrow_t(const yesthrow_t&) noexcept(false) = default;
yesthrow_t(  yesthrow_t&&)noexcept(false) = default;
yesthrow_t& operator=(const yesthrow_t&)  noexcept(false) = default;
yesthrow_t& operator=(  yesthrow_t&&) noexcept(false) = default;
};
static_assert(!is_nothrow_default_constructible_v);
static_assert(!is_nothrow_copy_constructible_v<   yesthrow_t>);
static_assert(!is_nothrow_copy_assignable_v<  yesthrow_t>);
static_assert(!is_nothrow_move_constructible_v<   yesthrow_t>);
static_assert(!is_nothrow_move_assignable_v<  yesthrow_t>);
```
https://gcc.gnu.org/ml/gcc-patches/2019-09/msg00311.html calls out a single
case, but not this inconsistency.

[Bug jit/96089] New: Support initializers for global variables.

[bouanto at zoho dot com]

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

Bug ID: 96089
   Summary: Support initializers for global variables.
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: jit
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: bouanto at zoho dot com
  Target Milestone: ---

Hi.
It would be nice to be able to set an initializer for global variables.
There were some discussion about it there:
https://gcc.gnu.org/pipermail/jit/2020q2/001215.html

Thanks.

[Bug fortran/95980] ICE in get_unique_type_string, at fortran/class.c:485

[dominiq at lps dot ens.fr]

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

--- Comment #10 from Dominique d'Humieres  ---
> Confirmed on preliminary tests (pr86551), full tests in progress: results 
> tomorrow).

Regtested without regression.

[Bug target/94954] Wrong code generation for vec_pack_to_short_fp32 builtin for Power

[cvs-commit at gcc dot gnu.org]

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

--- Comment #5 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Will Schmidt
:

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

commit r10-8430-g2d980dd19d11d7e530922bea6eafad8ff6641df7
Author: Will Schmidt 
Date:   Mon Jun 8 10:39:18 2020 -0500

Backport to gcc-10

[PATCH, PR target/94954] Fix wrong codegen for vec_pack_to_short_fp32()
builtin

Hi,
  Fix codegen for builtin vec_pack_to_short_fp32.  This includes adding
  a define_insn for xvcvsphp, and adding a new define_expand for
  convert_4f32_8f16.

[v2]
  Comment on altivec.md "convert_4f32_8f16" enhanced.
  Testsuite builtins-1-p9-runnable.c updated.

  OK for trunk and backports?

  Thanks
  -Will

PR target/94954

gcc/Changelog:

* config/rs6000/altivec.h (vec_pack_to_short_fp32): Update.
* config/rs6000/altivec.md (UNSPEC_CONVERT_4F32_8F16): New unspec.
(convert_4f32_8f16): New define_expand
* config/rs6000/rs6000-builtin.def (convert_4f32_8f16): New builtin
define
and overload.
* config/rs6000/rs6000-call.c (P9V_BUILTIN_VEC_CONVERT_4F32_8F16):
New
overloaded builtin entry.
* config/rs6000/vsx.md (UNSPEC_VSX_XVCVSPHP): New unspec.
(vsx_xvcvsphp): New define_insn.

gcc/testsuite/ChangeLog:
* gcc.target/powerpc/builtins-1-p9-runnable.c: Update.

[Bug target/94954] Wrong code generation for vec_pack_to_short_fp32 builtin for Power

[cvs-commit at gcc dot gnu.org]

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

--- Comment #4 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Will Schmidt
:

https://gcc.gnu.org/g:972c78d3f65354aa9ea23d5e503835d68881f494

commit r9-8722-g972c78d3f65354aa9ea23d5e503835d68881f494
Author: Will Schmidt 
Date:   Wed Jun 24 13:59:34 2020 -0500

Backport to gcc-9

[PATCH, PR target/94954] Fix wrong codegen for
vec_pack_to_short_fp32() builtin

Hi,
  Fix codegen for builtin vec_pack_to_short_fp32.  This includes adding
a define_insn for xvcvsphp, and adding a new define_expand for
convert_4f32_8f16.

[v2]
   Comment on altivec.md "convert_4f32_8f16" enhanced.
   Testsuite builtins-1-p9-runnable.c updated.

OK for trunk and backports?

Thanks
-Will

PR target/94954

2020-07-06  Will Schmidt  

gcc/ChangeLog:

* config/rs6000/altivec.h (vec_pack_to_short_fp32): Update.
* config/rs6000/altivec.md (UNSPEC_CONVERT_4F32_8F16): New unspec.
(convert_4f32_8f16): New define_expand
* config/rs6000/rs6000-builtin.def (convert_4f32_8f16): New builtin
define
and overload.
* config/rs6000/rs6000-c.c (P9V_BUILTIN_VEC_CONVERT_4F32_8F16): New
overloaded builtin entry.
* config/rs6000/vsx.md (UNSPEC_VSX_XVCVSPHP): New unspec.
(vsx_xvcvsphp): New define_insn.

gcc/testsuite/ChangeLog:

* gcc.target/powerpc/builtins-1-p9-runnable.c: Update.

[Bug fortran/95980] ICE in get_unique_type_string, at fortran/class.c:485

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #9 from Steve Kargl  ---
On Mon, Jul 06, 2020 at 08:29:24PM +, anlauf at gcc dot gnu.org wrote:
> I have the impression that there's a lot of bad things happening with
> invalid input that is not always caught on x86_64.

This has been true since I started working on gfortran some
15+ years ago.  Much of the code is written assuming a correctly
written Fortran program.  Invalid input, particularly corner
cases and with newer features, tend to blow up.

Gerhard seems to delight in finding these issues. :-)

[Bug target/94954] Wrong code generation for vec_pack_to_short_fp32 builtin for Power

[cvs-commit at gcc dot gnu.org]

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

--- Comment #3 from CVS Commits  ---
The releases/gcc-8 branch has been updated by Will Schmidt
:

https://gcc.gnu.org/g:5131f42d776eda08b3309c6596df9104b69987e9

commit r8-10346-g5131f42d776eda08b3309c6596df9104b69987e9
Author: Will Schmidt 
Date:   Wed Jul 1 15:04:13 2020 -0500

[PATCH v2, PR target/94954] Fix wrong codegen for vec_pack_to_short_fp32()
builtin

PR TARGET/94954

2020-07-06  Will Schmidt  

gcc/ChangeLog:
* config/rs6000/altivec.h (vec_pack_to_short_fp32): Update.
* config/rs6000/altivec.md (UNSPEC_CONVERT_4F32_8F16): New unspec.
(convert_4f32_8f16): New define_expand
* config/rs6000/rs6000-builtin.def (convert_4f32_8f16): New builtin
define
and overload.
* config/rs6000/rs6000-c.c (P9V_BUILTIN_VEC_CONVERT_4F32_8F16): New
overloaded builtin entry.
* config/rs6000/vsx.md (UNSPEC_VSX_XVCVSPHP): New unspec.
(vsx_xvcvsphp): New define_insn.

gcc/testsuite/ChangeLog:

* gcc.target/powerpc/builtins-1-p9-runnable.c: Update.

[Bug tree-optimization/95396] [8/9/10/11 Regression] GCC produces incorrect code with -O3 for loops since r8-6511-g3ae129323d150621

[babokin at gmail dot com]

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

--- Comment #4 from Dmitry Babokin  ---
Richard Sandiford, could you please have a look as author of the commit, which
brought the regression?

We have a bunch of other fails, which might be or might be not the same as this
one. We'd like to avoid spamming developers with duplicates, so waiting for
this bug to be fixed.

Also, if there's a way how we can help investigating this bug, we would
appreciate your guidance.

[Bug fortran/92967] ICE in matching_typebound_op, at fortran/interface.c:4214

[dominiq at lps dot ens.fr]

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

--- Comment #2 from Dominique d'Humieres  ---
*** Bug 96071 has been marked as a duplicate of this bug. ***

[Bug fortran/96071] ICE in matching_typebound_op, at fortran/interface.c:4233

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #3 from Dominique d'Humieres  ---
> Isn't that almost exactly a dup of PR92967?  (Except for integer <-> real)

Agreed! ICE in the same place.

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

[Bug middle-end/95507] [meta-bug] bogus/missing -Wnonnull

[msebor at gcc dot gnu.org]

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

Bug 96021 Summary: missing -Wnonnull passing nullptr to a nonnull variadic 
lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96021

   What|Removed |Added

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

[Bug c++/96021] missing -Wnonnull passing nullptr to a nonnull variadic lambda

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Resolution|--- |FIXED
   Target Milestone|--- |11.0
 Status|ASSIGNED|RESOLVED

--- Comment #4 from Martin Sebor  ---
Implemented for GCC 11 in r11-1860.

[Bug c++/95984] [11 Regression] Internal compiler error: Error reporting routines re-entered. since r11-1697-g75ff24e1920ea6b1

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #5 from Martin Sebor  ---
Fixed by r11-1860.

[Bug c++/95984] [11 Regression] Internal compiler error: Error reporting routines re-entered. since r11-1697-g75ff24e1920ea6b1

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:67a493a0b9e7ce6caba4b8bedf1f3295e477ec00

commit r11-1860-g67a493a0b9e7ce6caba4b8bedf1f3295e477ec00
Author: Martin Sebor 
Date:   Mon Jul 6 15:23:37 2020 -0600

Exclude calls to variadic lambda stubs from -Wnonnull checking (PR
c++/95984).

Resolves:
PR c++/95984 - Internal compiler error: Error reporting routines re-entered
in -Wnonnull on a variadic lamnda
PR c++/96021 - missing -Wnonnull passing nullptr to a nonnull variadic
lambda

gcc/c-family/ChangeLog:

PR c++/95984
* c-common.c (check_function_nonnull): Avoid checking syntesized
calls
to stub lambda objects with null this pointer.
(check_nonnull_arg): Handle C++ nullptr.

gcc/cp/ChangeLog:

PR c++/95984
* call.c (build_over_call): Check calls only when tf_warning is
set.

gcc/testsuite/ChangeLog:

PR c++/95984
* g++.dg/warn/Wnonnull6.C: New test.

[Bug fortran/95980] ICE in get_unique_type_string, at fortran/class.c:485

[dominiq at lps dot ens.fr]

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

--- Comment #8 from Dominique d'Humieres  ---
> I attached a brute-force patch that makes gfortran reject z1.f90
> without ICEing.
>
> Can you confirm this, or is there possibly something left to handle?

Confirmed on preliminary tests (pr86551), full tests in progress: results
tomorrow).

[Bug c++/96021] missing -Wnonnull passing nullptr to a nonnull variadic lambda

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:67a493a0b9e7ce6caba4b8bedf1f3295e477ec00

commit r11-1860-g67a493a0b9e7ce6caba4b8bedf1f3295e477ec00
Author: Martin Sebor 
Date:   Mon Jul 6 15:23:37 2020 -0600

Exclude calls to variadic lambda stubs from -Wnonnull checking (PR
c++/95984).

Resolves:
PR c++/95984 - Internal compiler error: Error reporting routines re-entered
in -Wnonnull on a variadic lamnda
PR c++/96021 - missing -Wnonnull passing nullptr to a nonnull variadic
lambda

gcc/c-family/ChangeLog:

PR c++/95984
* c-common.c (check_function_nonnull): Avoid checking syntesized
calls
to stub lambda objects with null this pointer.
(check_nonnull_arg): Handle C++ nullptr.

gcc/cp/ChangeLog:

PR c++/95984
* call.c (build_over_call): Check calls only when tf_warning is
set.

gcc/testsuite/ChangeLog:

PR c++/95984
* g++.dg/warn/Wnonnull6.C: New test.

[Bug fortran/96071] ICE in matching_typebound_op, at fortran/interface.c:4233

[anlauf at gcc dot gnu.org]

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

--- Comment #2 from anlauf at gcc dot gnu.org ---
Isn't that almost exactly a dup of PR92967?  (Except for integer <-> real)

[Bug fortran/93337] [9/10/11 Regression] ICE in gfc_dt_upper_string, at fortran/module.c:441

[cvs-commit at gcc dot gnu.org]

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

--- Comment #6 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Harald Anlauf
:

https://gcc.gnu.org/g:0e66f1ddf7a7166f7a140c03e5d55286c7ef582b

commit r10-8429-g0e66f1ddf7a7166f7a140c03e5d55286c7ef582b
Author: Harald Anlauf 
Date:   Thu Jul 2 20:41:51 2020 +0200

PR fortran/93337 - ICE in gfc_dt_upper_string, at fortran/module.c:441

When declaring a polymorphic variable that is not a dummy, allocatable or
pointer, an ICE occurred due to a NULL pointer dereference.  Check for
that situation and punt.

gcc/fortran/
PR fortran/93337
* class.c (gfc_find_derived_vtab): Punt if name is not set.

(cherry picked from commit d9fb6f2b4f1321b059807ff6073156f07d9d376b)

[Bug libstdc++/96036] Please make std::optinal noexcept constructible when possible

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #2 from Jonathan Wakely  ---
Fixed on trunk

[Bug libstdc++/96036] Please make std::optinal noexcept constructible when possible

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:8992cd1892df1adb352cf5d5b279a00686d1e88a

commit r11-1857-g8992cd1892df1adb352cf5d5b279a00686d1e88a
Author: Jonathan Wakely 
Date:   Mon Jul 6 21:54:12 2020 +0100

libstdc++: Add noexcept to std::optional initialization (PR 96036)

libstdc++-v3/ChangeLog:

PR libstdc++/96036
* include/std/optional (optional): Add noexcept-specifier to
every constructor, assignment operator, emplace function and
dereference operator.
* testsuite/20_util/optional/assignment/noexcept.cc: New test.
* testsuite/20_util/optional/cons/noexcept.cc: New test.

[Bug c++/95303] [concepts] Member type of class template is incorrectly printed in diagnostics when it fails to satisfy a concept

[ppalka at gcc dot gnu.org]

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

Patrick Palka  changed:

   What|Removed |Added

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

[Bug c++/70275] -w disables all -Werror flags

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-07-06
   Keywords||diagnostic
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #5 from Martin Sebor  ---
Let me confirm this bug report, in part because -w is documented to "Inhibit
all warning messages" but it does more than that, and also behaves differently
than Clang, and in my view not intuitively.  For example, the following
produces no output with GCC 10:

$ cat q.c && gcc -S -w -Wall -Werror -Wimplicit-int q.c
#pragma GCC diagnostic error "-Wimplicit-int"
f () { }

but reports an error with Clang:

$ clang -S -w -Wall -Werror -Wimplicit-int q.c
q.c:2:1: error: type specifier missing, defaults to 'int'
  [-Werror,-Wimplicit-int]
f () { }
^
1 error generated.

The Clang behavior makes more sense to me (it suppresses warnings but not
errors) but if there's some deeper logic in what GCC does it would be helpful
to mention it in the manual.

[Bug rtl-optimization/96015] [10/11 Regression] gcc-10.1.0 miscompiles Python on hppa

[law at redhat dot com]

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

--- Comment #33 from Jeffrey A. Law  ---
Have I mentioned before that I think __builtin_unreachable is fundamentally
broken/wrong :-)


I could argue that the BARRIER in the IL is wrong because it doesn't actually
line up with the semantics of the instruction stream.  But that's probably a
losing battle with those who think that __builtin_unreachable's current
behavior is sensible.

One thought would be to turn a conditional jump followed by a barrier into an
unconditional jump in jump.c.  But I fear that just papers over the problem and
that we'd see the same issue raise its head again in a slightly perturbed form
that wasn't recognized by jump.c, but tripped the same code as we have now in
reorg.c.

Another thought would be to detect this in relax_delay_slots and twiddle the
transformation to avoid the problematic behavior.  I think we could detect just
by seeing if there's a barrier after INSN in the same hunk of code that Eric
quoted and changing the behavior slightly when that's detected.

I hate special casing things like that and there's a reasonable chance other
parts of GCC are affected by the same problem.  That may argue for implementing
both approaches.

But I'd really just like to change how __builtin_unreachable works.

Eric, thoughts?

jeff

[Bug fortran/95980] ICE in get_unique_type_string, at fortran/class.c:485

[anlauf at gcc dot gnu.org]

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

--- Comment #7 from anlauf at gcc dot gnu.org ---
(In reply to Dominique d'Humieres from comment #5)
> AFAICT the patch fixes the ICE for z2.f90, but not for z1.f90.

You're right.  I got lost in trying to work on too many PRs.

I attached a brute-force patch that makes gfortran reject z1.f90
without ICEing.

Can you confirm this, or is there possibly something left to handle?
I have the impression that there's a lot of bad things happening with
invalid input that is not always caught on x86_64.

[Bug fortran/95980] ICE in get_unique_type_string, at fortran/class.c:485

[anlauf at gcc dot gnu.org]

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

--- Comment #6 from anlauf at gcc dot gnu.org ---
Created attachment 48839
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48839=edit
Patch, part 2

[Bug fortran/96086] ICE in gfc_match_select_rank, at fortran/match.c:6645

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #2 from anlauf at gcc dot gnu.org ---
Patch: https://gcc.gnu.org/pipermail/fortran/2020-July/054703.html

[Bug c++/95497] [11 Regression] ICE: concepts with a fully known / complete type in requires

[ppalka at gcc dot gnu.org]

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

Patrick Palka  changed:

   What|Removed |Added

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

[Bug c++/96063] [10/11 Regression] mismatched-tags warnings in stdlib headers

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
 Status|REOPENED|ASSIGNED

--- Comment #9 from Martin Sebor  ---
The warning routine checks the warning state and returns without doing anything
when it's set:

  if (!warn_mismatched_tags)
return;

It then calls warning_at() assuming the calls necessarily succeed, and doesn't
check their return value before calling inform().  That only works for global
settings of the warnings but not for local overrides via #pragmas.  Let me fix
it.  Longer term, we need a functional API to query whether warnings are
enabled, one that takes their context into consideration.  Checking the global
variable is almost never right.

[Bug fortran/96086] ICE in gfc_match_select_rank, at fortran/match.c:6645

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #1 from anlauf at gcc dot gnu.org ---
The ICE is fixed by:

diff --git a/gcc/fortran/match.c b/gcc/fortran/match.c
index 7d3711c55f9..cb09c5f8ec5 100644
--- a/gcc/fortran/match.c
+++ b/gcc/fortran/match.c
@@ -6647,7 +6647,8 @@ gfc_match_select_rank (void)
   if (expr2->symtree)
{
  sym2 = expr2->symtree->n.sym;
- as = sym2->ts.type == BT_CLASS ? CLASS_DATA (sym2)->as : sym2->as;
+ as = (sym2->ts.type == BT_CLASS
+   && CLASS_DATA (sym2)) ? CLASS_DATA (sym2)->as : sym2->as;
}

   if (expr2->expr_type != EXPR_VARIABLE
@@ -6659,7 +6660,7 @@ gfc_match_select_rank (void)
  goto cleanup;
}

-  if (expr2->ts.type == BT_CLASS)
+  if (expr2->ts.type == BT_CLASS && CLASS_DATA (sym2))
{
  copy_ts_from_selector_to_associate (expr1, expr2);

diff --git a/gcc/fortran/resolve.c b/gcc/fortran/resolve.c
index 223de91..ef251dc142d 100644
--- a/gcc/fortran/resolve.c
+++ b/gcc/fortran/resolve.c
@@ -9012,7 +9012,9 @@ resolve_assoc_var (gfc_symbol* sym, bool resolve_target)
  if (as->corank != 0)
sym->attr.codimension = 1;
}
-  else if (sym->ts.type == BT_CLASS && (!CLASS_DATA (sym)->as ||
sym->assoc->rankguessed))
+  else if (sym->ts.type == BT_CLASS
+  && CLASS_DATA (sym)
+  && (!CLASS_DATA (sym)->as || sym->assoc->rankguessed))
{
  if (!CLASS_DATA (sym)->as)
CLASS_DATA (sym)->as = gfc_get_array_spec ();

[Bug libstdc++/96088] New: Range insertion into unordered_map is less effective than a loop with insertion

[antoshkka at gmail dot com]

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

Bug ID: 96088
   Summary: Range insertion into unordered_map is less effective
than a loop with insertion
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: antoshkka at gmail dot com
  Target Milestone: ---

Consider the function f1:

static constexpr std::initializer_list> lst = {
{"long_str_for_dynamic_allocating", 1}};

void f1() {
std::unordered_map m(1);
m.insert(lst.begin(), lst.end());
}


It creates a temporary and as a result makes 4 allocations. Meanwhile f2 does
not create a temporary and does aonly 3 allocations:

void f2() {
std::unordered_map m(1);
for (const auto& x : lst) {
m.insert(x);
}
}


Godbolt playground: https://godbolt.org/z/VapmBU

[Bug fortran/96041] [11 regression] ICE in gfortran.dg/pr93423.f90 after r11-1792

[anlauf at gcc dot gnu.org]

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

--- Comment #6 from anlauf at gcc dot gnu.org ---
On x86_64 I never reach symbol.c:2662, since the code returns from line 2659.
This the closest I get to your backtrace:

Breakpoint 2, free_st_labels (label=0x0) at
../../gcc-trunk/gcc/fortran/symbol.c:2659
2659  if (label == NULL)
(gdb) bt
#0  free_st_labels (label=0x0) at ../../gcc-trunk/gcc/fortran/symbol.c:2659
#1  0x0073ad9a in gfc_free_namespace (ns=0x27c7c60)
at ../../gcc-trunk/gcc/fortran/symbol.c:4050
#2  0x0073af45 in gfc_free_symbol (sym=0x27c7b00)
at ../../gcc-trunk/gcc/fortran/symbol.c:3091
#3  0x0073b09f in free_sym_tree (sym_tree=0x275f280)
at ../../gcc-trunk/gcc/fortran/symbol.c:3902
#4  0x0073b096 in free_sym_tree (sym_tree=0x27c5a00)
at ../../gcc-trunk/gcc/fortran/symbol.c:3900
#5  0x0073b08d in free_sym_tree (sym_tree=0x275fb90)
at ../../gcc-trunk/gcc/fortran/symbol.c:3899
#6  0x0073b08d in free_sym_tree (sym_tree=0x27c79a0)
at ../../gcc-trunk/gcc/fortran/symbol.c:3899
#7  0x0073ad12 in gfc_free_namespace (ns=0x27c2670)
at ../../gcc-trunk/gcc/fortran/symbol.c:4041
#8  0x0073b34b in gfc_symbol_done_2 ()
at ../../gcc-trunk/gcc/fortran/symbol.c:4101
#9  0x006d9379 in gfc_done_2 () at
../../gcc-trunk/gcc/fortran/misc.c:358
#10 0x006f2053 in clean_up_modules (gsym=0x275e880)
at ../../gcc-trunk/gcc/fortran/parse.c:6267
#11 0x006f201d in clean_up_modules (gsym=0x2823580)
at ../../gcc-trunk/gcc/fortran/parse.c:6259
#12 0x006fd73c in translate_all_program_units
(gfc_global_ns_list=)
at ../../gcc-trunk/gcc/fortran/parse.c:6330
#13 gfc_parse_file () at ../../gcc-trunk/gcc/fortran/parse.c:6546
#14 0x00749f00 in gfc_be_parse_file ()
at ../../gcc-trunk/gcc/fortran/f95-lang.c:212
#15 0x00d74e8f in compile_file () at ../../gcc-trunk/gcc/toplev.c:458
#16 0x006621c9 in do_compile () at ../../gcc-trunk/gcc/toplev.c:2307
#17 toplev::main (this=this@entry=0x7fffd4ae, argc=,
argc@entry=2, 
argv=, argv@entry=0x7fffd5a8) at
../../gcc-trunk/gcc/toplev.c:2446
#18 0x0066602b in main (argc=2, argv=0x7fffd5a8)
at ../../gcc-trunk/gcc/main.c:39
(gdb) p label
$1 = (gfc_st_label *) 0x0

[Bug fortran/96087] New: [9/10/11 Regression] ICE in gfc_get_symbol_decl, at fortran/trans-decl.c:1575

[gs...@t-online.de]

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

Bug ID: 96087
   Summary: [9/10/11 Regression] ICE in gfc_get_symbol_decl, at
fortran/trans-decl.c:1575
   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: ---

This changed between 20200308 and 20200412 :


$ cat z1.f90
module m
   interface
  module function f(n) result(z)
 integer, intent(in) :: n
 real :: z(n)
  end
   end interface
contains
   module procedure f
  z = 1
   end procedure
end


$ gfortran-10-20200308 -c z1.f90
$
$ gfortran-11-20200705 -c z1.f90
z1.f90:3:0:

3 |   module function f(n) result(z)
  |
internal compiler error: in gfc_get_symbol_decl, at fortran/trans-decl.c:1575
0x72bceb gfc_get_symbol_decl(gfc_symbol*)
../../gcc/fortran/trans-decl.c:1575
0x73a4b8 gfc_conv_variable
../../gcc/fortran/trans-expr.c:2735
0x7366ca gfc_conv_expr(gfc_se*, gfc_expr*)
../../gcc/fortran/trans-expr.c:8693
0x739523 gfc_conv_expr_val(gfc_se*, gfc_expr*)
../../gcc/fortran/trans-expr.c:8738
0x739670 gfc_conv_expr_type(gfc_se*, gfc_expr*, tree_node*)
../../gcc/fortran/trans-expr.c:8752
0x712edf gfc_trans_dummy_array_bias(gfc_symbol*, tree_node*,
gfc_wrapped_block*)
../../gcc/fortran/trans-array.c:6668
0x72ce1c gfc_trans_deferred_vars(gfc_symbol*, gfc_wrapped_block*)
../../gcc/fortran/trans-decl.c:4862
0x72f408 gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6945
0x709c49 gfc_generate_module_code(gfc_namespace*)
../../gcc/fortran/trans.c:2264
0x6b6901 translate_all_program_units
../../gcc/fortran/parse.c:6294
0x6b6901 gfc_parse_file()
../../gcc/fortran/parse.c:6546
0x70284f gfc_be_parse_file
../../gcc/fortran/f95-lang.c:212

[Bug fortran/96087] [9/10/11 Regression] ICE in gfc_get_symbol_decl, at fortran/trans-decl.c:1575

[gs...@t-online.de]

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

G. Steinmetz  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code

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

This related valid case also ICEs, but down to r6 :


$ cat z2.f90
module m
   interface
  module subroutine f(n, z)
 integer, intent(in) :: n
 real :: z(n)
  end
   end interface
contains
   module procedure f
  z = 1
   end procedure
end

[Bug fortran/95980] ICE in get_unique_type_string, at fortran/class.c:485

[dominiq at lps dot ens.fr]

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

--- Comment #5 from Dominique d'Humieres  ---
> The master branch has been updated by Harald Anlauf :

AFAICT the patch fixes the ICE for z2.f90, but not for z1.f90.

> Related (and presumably also pr86551) :

The patch seems to also fix the ICEs for pr86551.

[Bug fortran/96086] New: ICE in gfc_match_select_rank, at fortran/match.c:6645

[gs...@t-online.de]

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

Bug ID: 96086
   Summary: ICE in gfc_match_select_rank, at fortran/match.c:6645
   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: ---

Affects versions r10/r11, with a missing attribute allocatable/pointer :


$ cat z1.f90
subroutine s
   class(*) :: x(..)
   select rank (y => x)
   end select
end


$ cat z2.f90
subroutine s
   type t
   end type
   class(t) :: x(..)
   select rank (y => x)
   end select
end


$ cat z3.f90
program p
   class(*) :: x(..)
   select rank (y => x)
   end select
end


$ gfortran-11-20200705 -c z1.f90
f951: internal compiler error: Segmentation fault
0xbd3bdf crash_signal
../../gcc/toplev.c:328
0x69083d gfc_match_select_rank()
../../gcc/fortran/match.c:6645
0x6af35e match_word
../../gcc/fortran/parse.c:65
0x6af35e decode_statement
../../gcc/fortran/parse.c:429
0x6b0b6a next_free
../../gcc/fortran/parse.c:1280
0x6b0b6a next_statement
../../gcc/fortran/parse.c:1512
0x6b21bb parse_spec
../../gcc/fortran/parse.c:3923
0x6b4f8c parse_progunit
../../gcc/fortran/parse.c:5852
0x6b6a4c gfc_parse_file()
../../gcc/fortran/parse.c:6400
0x70284f gfc_be_parse_file
../../gcc/fortran/f95-lang.c:212

[Bug fortran/96085] New: ICE in gfc_finish_var_decl, at fortran/trans-decl.c:694

[gs...@t-online.de]

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

Bug ID: 96085
   Summary: ICE in gfc_finish_var_decl, at
fortran/trans-decl.c:694
   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: ---

Affects versions down to at least r5 :


$ cat z1.f90
module m
   integer, parameter :: a = 1
contains
   subroutine s
  assign 2 to a
2 print *, a
   end
end


$ cat z2.f90
subroutine sub
   integer, parameter :: a = 1
   call s
contains
   subroutine s
  assign 2 to a
2 print *, a
   end
end


$ gfortran-11-20200705 -c z2.f90   # accepts invalid
z2.f90:5:19:

6 |   assign 2 to a
  |   1
Warning: Deleted feature: ASSIGN statement at (1)


$ gfortran-11-20200705 -c z1.f90
z1.f90:5:19:

5 |   assign 2 to a
  |   1
Warning: Deleted feature: ASSIGN statement at (1)
z1.f90:5:0:

5 |   assign 2 to a
  |
internal compiler error: in gfc_finish_var_decl, at fortran/trans-decl.c:694
0x72c269 gfc_finish_var_decl
../../gcc/fortran/trans-decl.c:694
0x72b5c1 gfc_get_symbol_decl(gfc_symbol*)
../../gcc/fortran/trans-decl.c:1852
0x73a4b8 gfc_conv_variable
../../gcc/fortran/trans-expr.c:2735
0x7366ca gfc_conv_expr(gfc_se*, gfc_expr*)
../../gcc/fortran/trans-expr.c:8693
0x775a36 gfc_conv_label_variable(gfc_se*, gfc_expr*)
../../gcc/fortran/trans-stmt.c:80
0x775aac gfc_trans_label_assign(gfc_code*)
../../gcc/fortran/trans-stmt.c:104
0x705d97 trans_code
../../gcc/fortran/trans.c:1868
0x72f324 gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6840
0x709c49 gfc_generate_module_code(gfc_namespace*)
../../gcc/fortran/trans.c:2264
0x6b6901 translate_all_program_units
../../gcc/fortran/parse.c:6294
0x6b6901 gfc_parse_file()
../../gcc/fortran/parse.c:6546
0x70284f gfc_be_parse_file
../../gcc/fortran/f95-lang.c:212

[Bug fortran/96084] New: ICE in free_expr0, at fortran/expr.c:446

[gs...@t-online.de]

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

Bug ID: 96084
   Summary: ICE in free_expr0, at fortran/expr.c:446
   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: ---

This invalid code produces errors up to name length 61, and gives
an ICE (or bailing out) for 62/63. To get a traceback it's better
to use a test version (configured with --enable-checking=yes).


$ cat z1_61.f90
program p
   type n234567890123456789012345678901234567890123456789012345678901
  integer :: i234567890123456789012345678901234567890123456789012345678901
   end type
   dimension a234567890123456789012345678901234567890123456789012345678901(1)
   class (n234567890123456789012345678901234567890123456789012345678901),
allocatable :: &
  a234567890123456789012345678901234567890123456789012345678901, &
  b234567890123456789012345678901234567890123456789012345678901
   call s(b234567890123456789012345678901234567890123456789012345678901 % &
  j234567890123456789012345678901234567890123456789012345678901)
end


$ cat z1_62.f90
program p
   type n2345678901234567890123456789012345678901234567890123456789012
  integer :: i2345678901234567890123456789012345678901234567890123456789012
   end type
   dimension a2345678901234567890123456789012345678901234567890123456789012(1)
   class (n2345678901234567890123456789012345678901234567890123456789012),
allocatable :: &
  a2345678901234567890123456789012345678901234567890123456789012, &
  b2345678901234567890123456789012345678901234567890123456789012
   call s(b2345678901234567890123456789012345678901234567890123456789012 % &
  j2345678901234567890123456789012345678901234567890123456789012)
end


$ cat z1_63.f90
program p
   type n23456789012345678901234567890123456789012345678901234567890123
  integer ::
i23456789012345678901234567890123456789012345678901234567890123
   end type
   dimension a23456789012345678901234567890123456789012345678901234567890123(1)
   class (n23456789012345678901234567890123456789012345678901234567890123),
allocatable :: &
  a23456789012345678901234567890123456789012345678901234567890123, &
  b23456789012345678901234567890123456789012345678901234567890123
   call s(b23456789012345678901234567890123456789012345678901234567890123 % &
  j23456789012345678901234567890123456789012345678901234567890123)
end


$ gfortran-11-20200705 -c z1_63.f90
z1_63.f90:10:74:

   10 |  
j23456789012345678901234567890123456789012345678901234567890123)
  |
 1
Error: 'j23456789012345678901234567890123456789012345678901234567890123' at (1)
is not a member of the
'n23456789012345678901234567890123456789012345678901234567890123' structure;
did you mean 'i23456789012345678901234567890123456789012345678901234567890123'?
z1_63.f90:5:76:

5 |dimension
a23456789012345678901234567890123456789012345678901234567890123(1)
  |
   1
Error: Allocatable array
'a23456789012345678901234567890123456789012345678901234567890123' at (1) must
have a deferred shape or assumed rank
f951: internal compiler error: Segmentation fault
0xd6980f crash_signal
../../gcc/toplev.c:328
0x699981 free_expr0
../../gcc/fortran/expr.c:446
0x699ae8 gfc_free_expr(gfc_expr*)
../../gcc/fortran/expr.c:530
0x666721 gfc_free_array_spec(gfc_array_spec*)
../../gcc/fortran/array.c:351
0x73364f free_components
../../gcc/fortran/symbol.c:2605
0x73364f gfc_free_symbol(gfc_symbol*)
../../gcc/fortran/symbol.c:3077
0x73383e free_sym_tree
../../gcc/fortran/symbol.c:3902
0x73382c free_sym_tree
../../gcc/fortran/symbol.c:3899
0x73382c free_sym_tree
../../gcc/fortran/symbol.c:3899
0x73382c free_sym_tree
../../gcc/fortran/symbol.c:3899
0x73382c free_sym_tree
../../gcc/fortran/symbol.c:3899
0x7334b1 gfc_free_namespace(gfc_namespace*)
../../gcc/fortran/symbol.c:4041
0x733aea gfc_symbol_done_2()
../../gcc/fortran/symbol.c:4101
0x6d1e18 gfc_done_2()
../../gcc/fortran/misc.c:358
0x6f5fa0 translate_all_program_units
../../gcc/fortran/parse.c:6326
0x6f5fa0 gfc_parse_file()
../../gcc/fortran/parse.c:6546
0x74269f gfc_be_parse_file
../../gcc/fortran/f95-lang.c:212

[Bug fortran/96073] [11.0 regression] regression in gfc_format_decoder

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

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

--- Comment #3 from Thomas Koenig  ---
>From the backtrace, that was very probably me with
https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=cc9a9229285a26ac12bc8de53237ce9c4d42f867
.

[Bug fortran/95980] ICE in get_unique_type_string, at fortran/class.c:485

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r11-1855-gf2151227dfe90a5fe73297c370786be98b0b090f
Author: Harald Anlauf 
Date:   Mon Jul 6 18:58:23 2020 +0200

PR fortran/95980 - ICE on using sync images with -fcheck=bounds

In SELECT TYPE, the argument may be an incorrectly specified unlimited
polymorphic variable.  Avoid a NULL pointer dereference for clean error
recovery.

gcc/fortran/
PR fortran/95980
* match.c (copy_ts_from_selector_to_associate, build_class_sym):
Distinguish between unlimited polymorphic and ordinary variables
to avoid NULL pointer dereference.
* resolve.c (resolve_select_type):
Distinguish between unlimited polymorphic and ordinary variables
to avoid NULL pointer dereference.

[Bug fortran/95709] [9/10/11 Regression] ICE in gfc_resolve_code, at fortran/resolve.c:11807

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:824084e72e388f81015e7f67922c75f50741355a

commit r11-1854-g824084e72e388f81015e7f67922c75f50741355a
Author: Harald Anlauf 
Date:   Mon Jul 6 18:52:39 2020 +0200

PR fortran/95709 - ICE in gfc_resolve_code, at fortran/resolve.c:11807

The legacy "assigned GOTO" accepts only scalar integer variables.
Check for proper arguments.

gcc/fortran/
PR fortran/95709
* resolve.c (gfc_resolve_code): Check for valid arguments to
assigned GOTO.

[Bug libstdc++/96083] New: Clang can't compile : error: use of undeclared identifier '__builtin_sprintf'

[redi at gcc dot gnu.org]

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

Bug ID: 96083
   Summary: Clang can't compile : error:
use of undeclared identifier '__builtin_sprintf'
   Product: gcc
   Version: 10.1.1
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

$ clang++   -include bits/extc++.h -x c++ - :1:
In file included from
/usr/bin/../lib/gcc/x86_64-redhat-linux/9/../../../../include/c++/9/x86_64-redhat-linux/bits/extc++.h:69:
/usr/bin/../lib/gcc/x86_64-redhat-linux/9/../../../../include/c++/9/ext/throw_allocator.h:316:7:
error: use of undeclared identifier '__builtin_sprintf'
  __builtin_sprintf(buf, "%lu", l);
  ^
/usr/bin/../lib/gcc/x86_64-redhat-linux/9/../../../../include/c++/9/ext/throw_allocator.h:321:7:
error: use of undeclared identifier '__builtin_sprintf'
  __builtin_sprintf(buf, "%lu", l);
  ^
/usr/bin/../lib/gcc/x86_64-redhat-linux/9/../../../../include/c++/9/ext/throw_allocator.h:325:7:
error: use of undeclared identifier '__builtin_sprintf'
  __builtin_sprintf(buf, "%p", ref.first);
  ^
/usr/bin/../lib/gcc/x86_64-redhat-linux/9/../../../../include/c++/9/ext/throw_allocator.h:338:7:
error: use of undeclared identifier '__builtin_sprintf'
  __builtin_sprintf(buf, "%lu", l);
  ^
/usr/bin/../lib/gcc/x86_64-redhat-linux/9/../../../../include/c++/9/ext/throw_allocator.h:342:7:
error: use of undeclared identifier '__builtin_sprintf'
  __builtin_sprintf(buf, "%p", ref.first);
  ^
/usr/bin/../lib/gcc/x86_64-redhat-linux/9/../../../../include/c++/9/ext/throw_allocator.h:575:4:
error: use of undeclared identifier '__builtin_sprintf'
  __builtin_sprintf(buf, "%f", random);
  ^
6 errors generated.

[Bug middle-end/92929] OpenACC/OpenMP 'target' 'exit data'/'update' optimizations

[tschwinge at gcc dot gnu.org]

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

--- Comment #9 from Thomas Schwinge  ---
(In reply to Thomas Schwinge from comment #0)
> As of Tobias' recent r277631 "Fortran/OpenMP] Don't create "alloc:" for
> 'target exit data'",
>  1355b9417...@codesourcery.com>, this is done for Fortran OpenMP '!$omp
> target exit data'/'!$omp target update', but not for OpenACC '!$acc exit
> data'/'!$acc update'; see 'gcc/gimplify.c:gimplify_scan_omp_clauses':
> 
> /* For Fortran, not only the pointer to the data is mapped but also
>the address of the pointer, the array descriptor etc.; for
>'exit data' - and in particular for 'delete:' - having an 'alloc:'
>does not make sense.  Likewise, for 'update' only transferring the
>data itself is needed as the rest has been handled in previous
>directives.  */
> if ((code == OMP_TARGET_EXIT_DATA || code == OMP_TARGET_UPDATE)
> && (OMP_CLAUSE_MAP_KIND (c) == GOMP_MAP_POINTER
> || OMP_CLAUSE_MAP_KIND (c) == GOMP_MAP_TO_PSET))
>   remove = true;

Is it actually correct to remove 'GOMP_MAP_TO_PSET' for 'OMP_TARGET_UPDATE'?

Untested -- I'm thinking of the following Fortran scenario:

arrays a1, a2
pointer p

[target] enter data(a1, a2)

p => a1
[target] enter data(p)
! creates persistent, visible device copy of 'p', initially pointing to
'a1'

p => a2
[target] update to(p)
! do we now still have 'p => a1' on the device, or 'p => a2'?

What is this '[target] update' to do?  Just update the data pointed to, and
also/or only update the array descriptor on the device?  If the latter, then
didn't get this broken by r277631 (cited above)?  Again: unverified.

But (also unverified), would 'libgomp/target.c:gomp_update' actually do the
right thing for 'GOMP_MAP_TO_PSET', given the current 'GOMP_MAP_COPY_TO_P'
definition?

Am I confused, or the code?

[Bug c++/96063] [10/11 Regression] mismatched-tags warnings in stdlib headers

[redi at gcc dot gnu.org]

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

--- Comment #8 from Jonathan Wakely  ---
Created attachment 48838
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48838=edit
Fix orphaned notes.

[Bug c++/96063] [10/11 Regression] mismatched-tags warnings in stdlib headers

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
  Component|libstdc++   |c++
Summary|mismatched-tags warnings in |[10/11 Regression]
   |stdlib headers  |mismatched-tags warnings in
   ||stdlib headers
  Known to fail||10.1.0, 11.0
   Target Milestone|11.0|10.2
 Resolution|FIXED   |---
  Known to work||9.3.0
 CC||msebor at gcc dot gnu.org

--- Comment #7 from Jonathan Wakely  ---
Gah, that's a compiler bug.

Martin, the -Wmismatched-tags warning adds loads of notes which are printed
unconditionally when -Wmismatched-tags is used. They need to be gated on
whether the actual warning is printed, so that you don't get orphaned notes for
warnings that are suppressed due to occurring in system headers.

I've changed the libstdc++ headers on trunk, but not on gcc-10, so you can
still reproduce it easily on that branch.

[Bug libstdc++/96063] mismatched-tags warnings in stdlib headers

[ian.s.mcinerney at ieee dot org]

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

--- Comment #6 from Ian McInerney  ---
They are showing up when I don't have -Wsystem-headers passed in on the command
line. Compiling the attached test program with `g++ -Wmismatched-tags main.cpp`
shows the warnings. All that is doing is including basically all public library
headers.

[Bug libstdc++/96063] mismatched-tags warnings in stdlib headers

[ian.s.mcinerney at ieee dot org]

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

--- Comment #5 from Ian McInerney  ---
Created attachment 48837
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48837=edit
test program

[Bug middle-end/92929] OpenACC/OpenMP 'target' 'exit data'/'update' optimizations

[tschwinge at gcc dot gnu.org]

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

Thomas Schwinge  changed:

   What|Removed |Added

   Target Milestone|--- |10.0
 Ever confirmed|0   |1
   Last reconfirmed||2020-07-06
 Status|UNCONFIRMED |NEW
 Depends on||94635

--- Comment #8 from Thomas Schwinge  ---
In addition to r277631 "Fortran/OpenMP] Don't create "alloc:" for 'target exit
data'", as shown in the PR94635 commit af557050fd011a03d21dc26b31959033061a0443
"[OpenMP] Fix 'omp exit data' for Fortran arrays (PR 94635)", and commit
9f0f7da9aa98eec28b4e5e34ade0aa0028df161d "[OpenMP] Fix 'omp exit data' for
Fortran arrays (PR 94635)", this is not only an optimization but also a
correctness issue.

The OpenMP cases now presumably have been addressed, but OpenACC not yet?


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94635
[Bug 94635] [OpenMP][Offloading] mapping with alloc/delete followed by
map(from/tofrom:)  fails

[Bug libstdc++/96063] mismatched-tags warnings in stdlib headers

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
What I meant was that I was tempted to disable them completely *even with*
-Wsystem-headers. All warnings are already disabled by default in libstdc++
headers. If your build is adding -Wsystem-headers then that's the problem.
Don't do that, and you won't get so much noise.

[Bug libstdc++/96063] mismatched-tags warnings in stdlib headers

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|--- |11.0
 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from Jonathan Wakely  ---
That's not the case. You'll only see those warnings with -Wsystem-headers
enabled, which is off by default. So they *are* disabled from the start.

Fixed in r11-1853-0e5abeb0cb06f9798a559e1238839c5d6581657e

[Bug target/96062] Partial register stall caused by avoidable use of SETcc, and useless MOVZBL

[josephcsible at gmail dot com]

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

--- Comment #2 from Joseph C. Sible  ---
(In reply to Uroš Bizjak from comment #1)
> Just declare "_Bool carry". There is no need for int.

While that indeed makes my first suggestion happen, it feels unsatisfying that
doing so is necessary. Isn't the point of an optimizing compiler to take care
of things like that for you?

[Bug c++/96068] Extra semicolon outside of a function should be allowed after c++11?

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
   Target Milestone|--- |11.0
 Resolution|--- |FIXED

--- Comment #4 from Jonathan Wakely  ---
Fixed on trunk

[Bug c++/96068] Extra semicolon outside of a function should be allowed after c++11?

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:92414bb6b077642eefc24080637b6bc766499391

commit r11-1852-g92414bb6b077642eefc24080637b6bc766499391
Author: Jonathan Wakely 
Date:   Mon Jul 6 15:58:33 2020 +0100

c++: Allow empty-declaration in C++11 and later (PR 96068)

Since C++11 a semim-colon on its own at namespace scope is not invalid,
so do not give a pedantic diagnostic about it.

gcc/cp/ChangeLog:

PR c++/96068
* parser.c (cp_parser_toplevel_declaration): Only do pedwarn for
empty-declaration in C++98.

gcc/testsuite/ChangeLog:

* g++.old-deja/g++.bugs/900404_04.C: Add c++98_only selector to
dg-error for extra ';'.
* g++.old-deja/g++.law/missed-error2.C: Likewise.

[Bug fortran/96073] [11.0 regression] regression in gfc_format_decoder

[juergen.reuter at desy dot de]

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

Jürgen Reuter  changed:

   What|Removed |Added

Summary|[11 Regression] regression  |[11.0 regression]
   |in gfc_format_decoder   |regression in
   ||gfc_format_decoder

--- Comment #2 from Jürgen Reuter  ---
Ok, this is triggered by a stupid thing in our own code, but I think the
compiler should not stumble over it. The error appears when there is a routine
that is defined as external, but there is also an explicit interface for it:
module m
  implicit none
  private

  interface
 subroutine GetXminM (set, xmin)
   integer, intent(in) :: set
   real, intent(out) :: xmin
 end subroutine GetXminM
  end interface

contains

  subroutine s ()
real :: xmin
integer :: set
external :: GetXminM
call GetXminM (set, xmin)
  end subroutine s

end module m

[Bug libstdc++/96063] mismatched-tags warnings in stdlib headers

[ian.s.mcinerney at ieee dot org]

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

--- Comment #2 from Ian McInerney  ---
I'd be fine with disabling them for the library (although I would have hoped
they would have been disabled there from the start since warnings from the
library weren't requested), but as it stands currently the warning can't be
used due to all the noise being generated.

[Bug c++/96082] New: GCC rejects the template disambiguator with "typename"

[haoxintu at gmail dot com]

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

Bug ID: 96082
   Summary: GCC rejects the template disambiguator with "typename"
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: haoxintu at gmail dot com
  Target Milestone: ---

Hi, all.

This code, test.cc, GCC rejects it in versions from 9.1 to trunk, but accepts
it from 8.3 to 4.8 versions. 

$cat test.cc
template  class A {};
int main () { 
typename :: template A  a;
}

$g++ test.cc
test.cc: In function ‘int main()’:
test.cc:3:26: error: ‘template’ must follow a nested-name-specifier
3 | typename :: template A  a;
  |  ^~~
test.cc:3:26: error: expected ‘(’
3 | typename :: template A  a;
  |  ^~~
  |

I also tested in clang, icc, and msvc, they all accept this code.

[Bug inline-asm/96081] New: changed placement of file scope asm() contents

[jbeulich at suse dot com]

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

Bug ID: 96081
   Summary: changed placement of file scope asm() contents
   Product: gcc
   Version: 9.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: inline-asm
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jbeulich at suse dot com
  Target Milestone: ---

>From 9.2 to 9.3 (and presumably then also to 10.1) a change in when, inside the
resulting assembly, file scope asm()-s get output has caused a breakage in one
of the Xen Project's auxiliary tools. What I can observe is that, with any kind
of optimization enabled, all asm()-s get processed first, whereas the data that
we want them to control gets output last.

I realize the output order is really unspecified, but I'd still like to
understand if there's at least a workaround here. What we want to achieve is
control over the ELF type of certain symbols, and this without triggering
modern gas'es "symbol '...' already has its type set" warnings (which the new
behavior not triggers, thus becoming aware of the change in the first place).
Up to gcc 9.2 we simply could put

.type , STT_NOTYPE;
.type , STT_FUNC;

after the data definition and get gcc's respective ".type , @object"
overridden this way.

But of course in the more general case it may also be necessary / desirable to
have certain asm()-s take effect _after_ compiler output.

[Bug fortran/96073] [11 Regression] regression in gfc_format_decoder

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P4
   Target Milestone|--- |11.0
Summary|[11.0 regression]   |[11 Regression] regression
   |regression in   |in gfc_format_decoder
   |gfc_format_decoder  |

[Bug c++/96078] [10/11 Regression] flatten attribute on constructor and destructor causes spurious warning

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |10.2

[Bug fortran/96018] [9/10/11 Regression] Optimization issue with external HDF5 library

[tkoenig at gcc dot gnu.org]

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

--- Comment #13 from Thomas Koenig  ---
In the last comment I meant -fdump-fortran-original, of course.

[Bug fortran/96080] New: [OpenACC] 'acc_is_present' for Fortran 'pointer'

[tschwinge at gcc dot gnu.org]

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

Bug ID: 96080
   Summary: [OpenACC] 'acc_is_present' for Fortran 'pointer'
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: openacc
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: burnus at gcc dot gnu.org
  Target Milestone: ---

Do we have to clarify what 'acc_is_present' on a pointer means: whether the
data it points to is present, or whether the pointer object itself is present
-- or invalid?

program main
  use openacc
  implicit none
  integer, dimension (:), allocatable, target :: a
  integer, dimension (:), pointer :: p

  allocate (a(10))
  !$acc enter data create(a)
  if (.not. acc_is_present (a)) stop 1

  p => a
  ! At this point, the data it points to is present, but the 'p' object
itself isn't.
  if (acc_is_present (p)) stop 2

  !$acc enter data create(p)
  ! At this point, both the data it points to, and the 'p' object are
present.
  if (.not. acc_is_present (p)) stop 3 !TODO This fails -- unexpectedly?

end program main

[Bug c++/96068] Extra semicolon outside of a function should be allowed after c++11?

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Keywords||patch
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org

--- Comment #2 from Jonathan Wakely  ---
Patch submitted:
https://gcc.gnu.org/pipermail/gcc-patches/2020-July/549453.html

[Bug fortran/96018] [9/10/11 Regression] Optimization issue with external HDF5 library

[tkoenig at gcc dot gnu.org]

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

--- Comment #12 from Thomas Koenig  ---
I don't have a debuggable source here at the moment, but I think there
may be a problem with implicit_pure, which was either introduced by
a patch in the range that Dominique provided (maybe for PR 85599?), or
exposed by something in the middle end.

The problem can be seen with -fdump-tree-original (in my case, with 9.3.0):

Namespace: A-Z: (UNKNOWN 0)
procedure name = wrapper
  symtree: 'call_side_effect'|| symbol: 'call_side_effect'
type spec : (INTEGER 4)
attributes: (PROCEDURE MODULE-PROC  FUNCTION)
result: ierr
  symtree: 'inner_3d'|| symbol: 'inner_3d'
type spec : (INTEGER 4)
attributes: (PROCEDURE MODULE-PROC  FUNCTION)
result: ierr
Formal arglist: array
  symtree: 'inner_4d'|| symbol: 'inner_4d'
type spec : (INTEGER 4)
attributes: (PROCEDURE MODULE-PROC  FUNCTION IMPLICIT_PURE)
result: ierr
Formal arglist: array

IMPLICIT_PURE should not be set on inner_4d, because it evaluates the
function call_side_effect (and marking is as PURE is correctly rejected
because of that).

It is also strange that inner_3d is not also wrongly marked as
IMPLICIT_PURE, I do not really see a significant difference between

   integer function inner_3d(array) result(ierr)
  real, intent(in) :: array(:,:,:)
  integer dimensions(3)
  dimensions = shape(array)
  ierr = call_side_effect()
   end function inner_3d

and

   integer function inner_4d(array) result(ierr)
  real, intent(in) :: array(:,:,:,:)
  integer dimensions(4)
  dimensions = shape(array)
  ierr = call_side_effect()
   end function inner_4d

[Bug fortran/96041] [11 regression] ICE in gfortran.dg/pr93423.f90 after r11-1792

[seurer at linux dot vnet.ibm.com]

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

--- Comment #5 from Bill Seurer  ---
It hits that breakpoints many times and for the first many it was always 0. 
Then I just let it run until it ICEd and backed up the call stack a bit.


Program received signal SIGSEGV, Segmentation fault.
0x106dcbd4 in free_st_labels (label=0x981) at
/home/seurer/gcc/git/gcc-test/gcc/fortran/symbol.c:2662
2662  free_st_labels (label->left);
(gdb) where
#0  0x106dcbd4 in free_st_labels (label=0x981) at
/home/seurer/gcc/git/gcc-test/gcc/fortran/symbol.c:2662
#1  0x106dcbe0 in free_st_labels (label=0x13492760) at
/home/seurer/gcc/git/gcc-test/gcc/fortran/symbol.c:2662
#2  0x106dcbe0 in free_st_labels (label=0x3fffb7e50a58 )
at /home/seurer/gcc/git/gcc-test/gcc/fortran/symbol.c:2662
#3  0x106dff28 in gfc_free_namespace (ns=0x13495ae0) at
/home/seurer/gcc/git/gcc-test/gcc/fortran/symbol.c:4050
#4  0x106dda60 in gfc_free_symbol (sym=0x13493e40) at
/home/seurer/gcc/git/gcc-test/gcc/fortran/symbol.c:3084
#5  0x106ddc14 in gfc_release_symbol (sym=0x13493e40) at
/home/seurer/gcc/git/gcc-test/gcc/fortran/symbol.c:3125
#6  0x106dfa10 in free_sym_tree (sym_tree=0x13493e00) at
/home/seurer/gcc/git/gcc-test/gcc/fortran/symbol.c:3902
#7  0x106dfa00 in free_sym_tree (sym_tree=0x13493ac0) at
/home/seurer/gcc/git/gcc-test/gcc/fortran/symbol.c:3900
#8  0x106df9f0 in free_sym_tree (sym_tree=0x13493fa0) at
/home/seurer/gcc/git/gcc-test/gcc/fortran/symbol.c:3899
#9  0x106dfe90 in gfc_free_namespace (ns=0x1348f6b0) at
/home/seurer/gcc/git/gcc-test/gcc/fortran/symbol.c:4041
#10 0x106e0144 in gfc_symbol_done_2 () at
/home/seurer/gcc/git/gcc-test/gcc/fortran/symbol.c:4101
#11 0x1062536c in gfc_done_2 () at
/home/seurer/gcc/git/gcc-test/gcc/fortran/misc.c:358
#12 0x1066cec8 in clean_up_modules (gsym=0x13490330) at
/home/seurer/gcc/git/gcc-test/gcc/fortran/parse.c:6267
#13 0x1066d22c in translate_all_program_units
(gfc_global_ns_list=0x13477bf0) at
/home/seurer/gcc/git/gcc-test/gcc/fortran/parse.c:6330
#14 0x1066da84 in gfc_parse_file () at
/home/seurer/gcc/git/gcc-test/gcc/fortran/parse.c:6546
#15 0x106f0488 in gfc_be_parse_file () at
/home/seurer/gcc/git/gcc-test/gcc/fortran/f95-lang.c:212
#16 0x11248514 in compile_file () at
/home/seurer/gcc/git/gcc-test/gcc/toplev.c:458
#17 0x1124d87c in do_compile () at
/home/seurer/gcc/git/gcc-test/gcc/toplev.c:2307
#18 0x1124dda4 in toplev::main (this=0x3fffe910, argc=20,
argv=0x3fffed78) at /home/seurer/gcc/git/gcc-test/gcc/toplev.c:2446
#19 0x124facf4 in main (argc=20, argv=0x3fffed78) at
/home/seurer/gcc/git/gcc-test/gcc/main.c:39

up a few times...

4050  free_st_labels (ns->st_labels);
(gdb) print ns->st_labels
$8 = (gfc_st_label *) 0x3fffb7e50a58 

[Bug tree-optimization/96075] [8/9/10 Regression] bogus alignment for negative step grouped access

[rguenth at gcc dot gnu.org]

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

--- Comment #8 from Richard Biener  ---
On the 10 branch we "optimize" the load as

  _19 = MEM[(double *)vectp_y.4_7 + 8B];
  _17 = {0, _19};

possibly because of the gap.

[Bug tree-optimization/96075] [8/9/10 Regression] bogus alignment for negative step grouped access

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||11.0
Summary|[8/9/10/11 Regression]  |[8/9/10 Regression] bogus
   |bogus alignment for |alignment for negative step
   |negative step grouped   |grouped access
   |access  |

--- Comment #7 from Richard Biener  ---
Fixed on trunk sofar, surely latent on the GCC 10 branch.

[Bug tree-optimization/96075] [8/9/10/11 Regression] bogus alignment for negative step grouped access

[cvs-commit at gcc dot gnu.org]

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

--- Comment #6 from CVS Commits  ---
The master branch has been updated by Richard Biener :

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

commit r11-1851-gdccbf1e2a6e544f71b4a5795f0c79015db019fc3
Author: Richard Biener 
Date:   Mon Jul 6 16:26:50 2020 +0200

tree-optimization/96075 - fix bogus misalignment calculation

This fixes bogus misalignment calculation for negative steps
since an assertion a previous comment indicated no longer holds:

  /* DR_STEP(dr) is the same as -TYPE_SIZE of the scalar type,
 otherwise we wouldn't be here.  */

Thus the following replaces DR_STEP by -TYPE_SIZE.

2020-07-06  Richard Biener  

PR tree-optimization/96075
* tree-vect-data-refs.c (vect_compute_data_ref_alignment): Use
TYPE_SIZE_UNIT of the vector component type instead of DR_STEP
for the misalignment calculation for negative step.

* gcc.dg/vect/slp-46.c: New testcase.

[Bug fortran/96018] [9/10/11 Regression] Optimization issue with external HDF5 library

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||needs-bisection

--- Comment #11 from Richard Biener  ---
So on trunk I get with -O2 (with or without -fno-inline)

> ./a.out 
write text
write text
 3d works
write text
 4d does not

and with -O0

> ./a.out 
write text
write text
 3d works
write text
write text
 4d does not

where write_4d is optimized to

write_4d ()
{
   [local count: 1073741824]:
  # .MEM_22 = VDEF <.MEM_1(D)>
  call_side_effect (); [tail call]
  # VUSE <.MEM_22>
  return;

}

the interesting fact is that inner_4d is computed "pure" (no side-effects)
while inner_3d is not and this is so from the start so done by the FE.

[Bug tree-optimization/96075] [8/9/10/11 Regression] bogus alignment for negative step grouped access

[rguenther at suse dot de]

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

--- Comment #5 from rguenther at suse dot de  ---
On Mon, 6 Jul 2020, rsandifo at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96075
> 
> --- Comment #4 from rsandifo at gcc dot gnu.org  
> ---
> (In reply to Richard Biener from comment #3)
> > So we end up calling get_negative_load_store_type for this group which seems
> > to only handle contiguous accesses but this one is single element
> > interleaving
> > aka contiguous with gap.
> > 
> > vect_supportable_dr_alignment returns dr_aligned which is seemingly OK for
> > 
> > #(Data Ref: 
> > #  bb: 3 
> > #  stmt: _4 = y[_2];
> > #  ref: y[_2];
> > #  base_object: y;
> > #  Access function 0: {1022, +, -2}_1
> Are you sure we support this?  I think…
> 
> >   /* If this is a backward running DR then first access in the larger
> >  vectype actually is N-1 elements before the address in the DR.
> >  Adjust misalign accordingly.  */
> >   if (tree_int_cst_sgn (step) < 0)
> > { 
> >   tree offset = ssize_int (TYPE_VECTOR_SUBPARTS (vectype) - 1);
> >   /* DR_STEP(dr) is the same as -TYPE_SIZE of the scalar type,
> >  otherwise we wouldn't be here.  */
> …really was the assumption for negative steps at one time,
> and I'm not sure off-hand when/if that changed.
> 
> (Of course, it might be that one of my patches changed it.)

Yeah - me too.  We still don't seem to support those for
interleaving [single element] groups but we let them slip
through for SLP ...

That said, the patch shouldn't make the situation worse at least ;)

[Bug tree-optimization/96075] [8/9/10/11 Regression] bogus alignment for negative step grouped access

[rsandifo at gcc dot gnu.org]

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

--- Comment #4 from rsandifo at gcc dot gnu.org  
---
(In reply to Richard Biener from comment #3)
> So we end up calling get_negative_load_store_type for this group which seems
> to only handle contiguous accesses but this one is single element
> interleaving
> aka contiguous with gap.
> 
> vect_supportable_dr_alignment returns dr_aligned which is seemingly OK for
> 
> #(Data Ref: 
> #  bb: 3 
> #  stmt: _4 = y[_2];
> #  ref: y[_2];
> #  base_object: y;
> #  Access function 0: {1022, +, -2}_1
Are you sure we support this?  I think…

>   /* If this is a backward running DR then first access in the larger
>  vectype actually is N-1 elements before the address in the DR.
>  Adjust misalign accordingly.  */
>   if (tree_int_cst_sgn (step) < 0)
> { 
>   tree offset = ssize_int (TYPE_VECTOR_SUBPARTS (vectype) - 1);
>   /* DR_STEP(dr) is the same as -TYPE_SIZE of the scalar type,
>  otherwise we wouldn't be here.  */
…really was the assumption for negative steps at one time,
and I'm not sure off-hand when/if that changed.

(Of course, it might be that one of my patches changed it.)

[Bug c++/96077] GCC accepts ill-legal local enum definition

[haoxintu at gmail dot com]

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

--- Comment #2 from Haoxin Tu  ---
(In reply to Jonathan Wakely from comment #1)
> It's not ideal to provide a testcase that doesn't compile for an
> accepts-invalid bug. A testcase that actually compiles is a better
> demonstration that the invalid code is accepted

OK, I got it. Thank you Jonathan. I will do better next time.

[Bug c++/96077] GCC accepts ill-legal local enum definition

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
It's not ideal to provide a testcase that doesn't compile for an
accepts-invalid bug. A testcase that actually compiles is a better
demonstration that the invalid code is accepted, e.g.

int main () {
enum { a = ( 1 ) ? ( 2 ) : ( 2 + 1 /* missing ")" here */ } l_e; //accept
}


Every version from 4.0 onwards behaves the same (I didn't test anything older).

[Bug jit/96079] Unresolved atomic builtins

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
It seems like all these bugs with atomics in libgccjit could be a single bug
report.

[Bug c++/96078] [10/11 Regression] flatten attribute on constructor and destructor causes spurious warning

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Known to work||9.3.0
   Keywords||diagnostic
   Last reconfirmed||2020-07-06
 Ever confirmed|0   |1
  Known to fail||10.1.0, 11.0

[Bug fortran/96018] [9/10/11 Regression] Optimization issue with external HDF5 library

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Target Milestone|--- |9.4
   Priority|P3  |P4
Summary|Optimization issue with |[9/10/11 Regression]
   |external HDF5 library   |Optimization issue with
   ||external HDF5 library
  Known to fail||10.1.0, 11.0, 9.3.0
  Known to work||8.4.1
 Status|WAITING |NEW
 CC||rguenth at gcc dot gnu.org

--- Comment #10 from Dominique d'Humieres  ---
Confirmed, the change occurred between regions r262584 (2018-07-12, OK) and
r263045 (2018-07-28, wrong code). I am not sure this a gfortran bug).

[Bug jit/96079] New: Unresolved atomic builtins

[bouanto at zoho dot com]

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

Bug ID: 96079
   Summary: Unresolved atomic builtins
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: jit
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: bouanto at zoho dot com
  Target Milestone: ---

Created attachment 48836
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48836=edit
Reproducer

Hi.
When I try to use an atomic builtin, it gives an error like:

libgccjit.so: error: /tmp/libgccjit-1VoggR/fake.so: undefined symbol:
__atomic_store_n

I tried setting the arch with:

gcc_jit_context_add_command_line_option(ctxt, "-march=x86-64");


but it didn't change anything.

>From inspecting the source code of gcc, it seems it does not support that yet
because it does not call resolve_overloaded_builtin (I might be wrong, I don't
have much knowledge of the gcc codebase).

So, is there a way to do that currently or is it a bug?

Thanks.

[Bug tree-optimization/96075] [8/9/10/11 Regression] bogus alignment for negative step grouped access

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #3 from Richard Biener  ---
So we end up calling get_negative_load_store_type for this group which seems
to only handle contiguous accesses but this one is single element interleaving
aka contiguous with gap.

vect_supportable_dr_alignment returns dr_aligned which is seemingly OK for

#(Data Ref: 
#  bb: 3 
#  stmt: _4 = y[_2];
#  ref: y[_2];
#  base_object: y;
#  Access function 0: {1022, +, -2}_1

but then as said the vls type is computed as VMAT_CONTIGUOUS_REVERSE where
we eventually do

  if (memory_access_type == VMAT_CONTIGUOUS_DOWN
  || memory_access_type == VMAT_CONTIGUOUS_REVERSE)
offset = size_int (-TYPE_VECTOR_SUBPARTS (vectype) + 1);

invalidating that alignment...

  /* If this is a backward running DR then first access in the larger
 vectype actually is N-1 elements before the address in the DR.
 Adjust misalign accordingly.  */
  if (tree_int_cst_sgn (drb->step) < 0)
/* PLUS because STEP is negative.  */
misalignment += ((TYPE_VECTOR_SUBPARTS (vectype) - 1)
 * TREE_INT_CST_LOW (drb->step));

looks a bit odd since this does not offset by N-1 elements but N-1
"steps" (where a step is two elements in this case).  Here's probably
where the problem resides.  On the GCC 7 branch we see

  /* If this is a backward running DR then first access in the larger
 vectype actually is N-1 elements before the address in the DR.
 Adjust misalign accordingly.  */
  if (tree_int_cst_sgn (step) < 0)
{ 
  tree offset = ssize_int (TYPE_VECTOR_SUBPARTS (vectype) - 1);
  /* DR_STEP(dr) is the same as -TYPE_SIZE of the scalar type,
 otherwise we wouldn't be here.  */
  offset = fold_build2 (MULT_EXPR, ssizetype, offset, step);
  /* PLUS because STEP was negative.  */
  misalign = size_binop (PLUS_EXPR, misalign, offset);
}

and mind that comment about DR_STEP isn't true ...

diff --git a/gcc/tree-vect-data-refs.c b/gcc/tree-vect-data-refs.c
index 2462276e7c2..959c2d3378f 100644
--- a/gcc/tree-vect-data-refs.c
+++ b/gcc/tree-vect-data-refs.c
@@ -1109,7 +1109,7 @@ vect_compute_data_ref_alignment (vec_info *vinfo,
dr_vec_info *dr_info)
   if (tree_int_cst_sgn (drb->step) < 0)
 /* PLUS because STEP is negative.  */
 misalignment += ((TYPE_VECTOR_SUBPARTS (vectype) - 1)
-* TREE_INT_CST_LOW (drb->step));
+* -TREE_INT_CST_LOW (TYPE_SIZE_UNIT (TREE_TYPE
(vectype;

   unsigned int const_misalignment;
   if (!known_misalignment (misalignment, vect_align_c, _misalignment))

fixes that.

[Bug c++/96078] New: [10/11 Regression] flatten attribute on constructor and destructor causes spurious warning

[rs2740 at gmail dot com]

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

Bug ID: 96078
   Summary: [10/11 Regression] flatten attribute on constructor
and destructor causes spurious warning
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rs2740 at gmail dot com
  Target Milestone: ---

struct A {
[[gnu::flatten]] A() {}
[[gnu::flatten]] ~A() {}
};

A a;

Produces no warnings with GCC 9 but on GCC 10 and trunk warns:

:3:22: warning: 'flatten' attribute is ignored on aliases
[-Wattributes]

3 | [[gnu::flatten]] ~A() {}

  |  ^

:2:22: warning: 'flatten' attribute is ignored on aliases
[-Wattributes]

2 | [[gnu::flatten]] A() {}

  |  ^

The warning appears to be introduced by the fix to PR92372.

Marking `A` as `final` eliminates the warnings, as does giving it an virtual
base class. Presumably the issue is that in the problematic case one of the
complete/base object c/dtors was treated as an alias for the other?

[Bug c++/95153] Arrays of 'const void *' should not be copyable in C++20

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #4 from Jonathan Wakely  ---
Status -> RESOLVED INVALID

[Bug tree-optimization/96075] [8/9/10/11 Regression] bogus alignment for negative step grouped access

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||10.1.1
  Known to fail|10.1.1  |

--- Comment #2 from Richard Biener  ---
Correction, the GCC 10 branch seems unaffected.

[Bug libstdc++/95989] Segmentation fault compiling with static libraries and using jthread::request_stop

[fw at gcc dot gnu.org]

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

--- Comment #11 from Florian Weimer  ---
It turns out that libc.a did not contain pthread_self until glibc 2.27.  The
symbol was only present in libc.so.6 (as a weird forwarder, for compatibility
with long-defunct LinuxThreads).

This means there could be some fallout from requiring a definition of
pthread_self in the statically linked case, in the form of linking failures
without -lpthread on older glibc (such 2.17, as including in Red Hat Enterprise
Linux 7).

[Bug c++/96077] New: GCC accepts ill-legal local enum definition

[haoxintu at gmail dot com]

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

Bug ID: 96077
   Summary: GCC accepts ill-legal local enum definition
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: accepts-invalid
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: haoxintu at gmail dot com
  Target Milestone: ---

Hi, all.

This code, test.cc, has a grammar issue in "missing ')'", but GCC accepts it
well.

$cat test.cc
enum { a = ( 1 ) ? ( 2 ) : ( 2 + 1 } g_e; //reject
int main () {
enum { a = ( 1 ) ? ( 2 ) : ( 2 + 1 /* missing ")" here */ } l_e; //accept
return 0;
}

$g++ test.cc
test.cc:1:35: error: expected ‘)’ before ‘}’ token
1 | enum { a = ( 1 ) ? ( 2 ) : ( 2 + 1 } g_e; //reject
  |~  ^~
  |  )

GCC only rejects line 1 but accepts line 3.

While in Clang

$clang++ test.cc
test.cc:1:36: error: expected ')'
enum { a = ( 1 ) ? ( 2 ) : ( 2 + 1 } g_e; //reject
   ^
test.cc:1:28: note: to match this '('
enum { a = ( 1 ) ? ( 2 ) : ( 2 + 1 } g_e; //reject
   ^
test.cc:3:63: error: expected ')'
enum { a = ( 1 ) ? ( 2 ) : ( 2 + 1 /* missing ")" here */ } l_e; //accept
  ^
test.cc:3:32: note: to match this '('
enum { a = ( 1 ) ? ( 2 ) : ( 2 + 1 /* missing ")" here */ } l_e; //accept
   ^
2 errors generated.


$g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/home/haoxin/corpus-compilers/gcc-trunk/gcc-master/build/libexec/gcc/x86_64-pc-linux-gnu/11.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure
--prefix=/home/haoxin/corpus-compilers/gcc-trunk/gcc-master/build/
--enable-languages=c,c++ CC=gcc CXX=g++
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.0.0 20200630 (experimental) (GCC)

[Bug c++/95153] Arrays of 'const void *' should not be copyable in C++20

[alisdairm at me dot com]

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

--- Comment #3 from Alisdair Meredith  ---
Sorry, thought I had confirmed that I agree with the analysis above - this is a
(perhaps surprising) change to the specification of C++20.

What is the best way to withdraw this report as invalid?

[Bug fortran/96073] [11.0 regression] regression in gfc_format_decoder

[juergen.reuter at desy dot de]

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

--- Comment #1 from Jürgen Reuter  ---
Next step, full error message: 
ibtool: compile:  gfortran -I../basics -I../utilities -I../testing -I../system
-I../combinatorics -I../rng -I../physics -I../fastjet -I../qft -I../types
-I../particles -I../../circe1/src -I../../circe2/src -I../pdf_builtin
-I../lhapdf -I../qed_pdf -I../variables -I../expr_base -I../parsing -g -O2 -c
sf_lhapdf.f90  -fPIC -o .libs/sf_lhapdf.o

in gfc_format_decoder, at fortran/error.c:970
0x5f46ce gfc_format_decoder
../../gcc/fortran/error.c:970
0x18b722c pp_format(pretty_printer*, text_info*)
../../gcc/pretty-print.c:1475
0x189c41e diagnostic_report_diagnostic(diagnostic_context*, diagnostic_info*)
../../gcc/diagnostic.c:1159
0x807a05 gfc_report_diagnostic
../../gcc/fortran/error.c:782
0x807a05 gfc_warning
../../gcc/fortran/error.c:815
0x808016 gfc_warning(int, char const*, ...)
../../gcc/fortran/error.c:846
0x9572bf check_against_globals
../../gcc/fortran/frontend-passes.c:5528
0x8a8b02 do_traverse_symtree
../../gcc/fortran/symbol.c:4170
0x95f5d1 gfc_check_externals(gfc_namespace*)
../../gcc/fortran/frontend-passes.c:5563
0x86e554 gfc_parse_file()
../../gcc/fortran/parse.c:6499
0x8bf9bf gfc_be_parse_file
../../gcc/fortran/f95-lang.c:212
Please submit a full bug report,


Code will follow in a minute.

[Bug c/96076] Compiling Glibc-2.11.1 on Raspberrypi4 fails as config.guess returns armv7l unknown

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |MOVED

--- Comment #1 from Jonathan Wakely  ---
(In reply to Rob Hookham from comment #0)
> I don't know the answer to this, sorry. You will need to ask the glibc
> folks.

This bugzilla is for GCC not glibc.

See https://www.gnu.org/software/libc/bugs.html for glibc bugs.

[Bug jit/96067] __atomic_compare_exchange_n should return bool instead of void

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #3 from Jonathan Wakely  ---
Thanks

[Bug c/96076] New: Compiling Glibc-2.11.1 on Raspberrypi4 fails as config.guess returns armv7l unknown

[rh100605 at aol dot com]

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

Bug ID: 96076
   Summary: Compiling Glibc-2.11.1 on Raspberrypi4 fails as
config.guess returns armv7l unknown
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rh100605 at aol dot com
  Target Milestone: ---

I am trying to compile an old gligc-2.11.1 on a Raspberry pi 4. As the
configure script fails with armv7l unsupported, I cannot start make.
I do not have any problem with compiling OpenSSL or other packages on the RPi4.

I thought that the script config.guess was faulty, the owner
config-patc...@gnu.org  (Ben Ellison) says that he does not know what is wrong.
The compiler when configured for native reports alot more information see below
The problem falls between the compiler and the config.guess script. 
Below is the detail

Ben Elliston (b...@air.net.au)
To:you Details
I don't know the answer to this, sorry. You will need to ask the glibc
folks.
Cheers,
Ben
 (rh100...@aol.com)
To:b...@air.net.au Details
Ben
The actual invocation of configure with error messages is below. My thoughts
are that the term "armv7l" will need translation to be understood by the
compiler. I think it means armv7  32bit without hard floating point, but as
most of the code in an Rpi4 is armhf ( hard float 32bit) as in the eabi, this
is misleading. The cpu is in fact 64bit capable but Rpi OS's do not use this.


pi@raspberrypi:~/Downloads/glibc-build $ sudo ../glibc-2.11.1/configure
--prefix=/opt/glibc/2.11.1 --enable-kernel=2.6.3$
checking build system type... armv7l-unknown-linux-gnueabihf
checking host system type... armv7l-unknown-linux-gnueabihf
checking for gcc... gcc
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking how to run the C preprocessor... gcc -E
checking for g++... g++
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
configure: running configure fragment for add-on libidn
configure: running configure fragment for add-on nptl
checking sysdep dirs... configure: error: The armv7l is not supported.



The compiler asked for -march and -mcpu as native, gets more detail from
somewhere and gives

pi@raspberrypi:~/Downloads/glibc-build $ gcc -mcpu=native -march=native -Q
--help=target
The following options are target specific:
  -mabi=aapcs-linux
  -mabort-on-noreturn   [disabled]
  -mandroid [disabled]
  -mapcs[disabled]
  -mapcs-frame  [disabled]
  -mapcs-reentrant  [disabled]
  -mapcs-stack-check[disabled]
  -march=   armv8-a+crc+simd
  -marm [enabled]
  -masm-syntax-unified  [disabled]
  -mbe32[enabled]
  -mbe8 [disabled]
  -mbig-endian  [disabled]
  -mbionic  [disabled]
  -mbranch-cost=-1
  -mcallee-super-interworking   [disabled]
  -mcaller-super-interworking   [disabled]
  -mcmse[disabled]
  -mcpu=cortex-a72
  -mfix-cortex-m3-ldrd  [disabled]
  -mflip-thumb  [disabled]
  -mfloat-abi=  hard
  -mfp16-format=none
  -mfpu=vfp
  -mglibc   [enabled]
  -mhard-float  
  -mlittle-endian   [enabled]
  -mlong-calls  [disabled]
  -mmusl[disabled]
  -mneon-for-64bits [disabled]
  -mpic-data-is-text-relative   [enabled]
  -mpic-register=   
  -mpoke-function-name  [disabled]
  -mprint-tune-info [disabled]
  -mpure-code   [disabled]
  -mrestrict-it [disabled]
  -msched-prolog[enabled]
  -msingle-pic-base [disabled]
  -mslow-flash-data [disabled]
  -msoft-float  
  -mstructure-size-boundary=8
  -mthumb   [disabled]
  -mthumb-interwork [disabled]
  -mtls-dialect=gnu
  -mtp= cp15
  -mtpcs-frame  [disabled]
  -mtpcs-leaf-frame [disabled]
  -mtune=   
  -muclibc 

[Bug tree-optimization/96075] [8/9/10/11 Regression] bogus alignment for negative step grouped access

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
 CC||marxin at gcc dot gnu.org
Summary|bogus alignment for |[8/9/10/11 Regression]
   |negative step grouped   |bogus alignment for
   |access  |negative step grouped
   ||access
   Target Milestone|--- |8.5
   Keywords||needs-bisection
  Known to fail||10.1.1, 8.4.0, 9.3.0
  Known to work||10.1.0, 7.5.0, 8.3.0, 9.2.0

--- Comment #1 from Richard Biener  ---
Regressed somewhere on all branches but GCC 7.  Bisecting on the GCC 10 branch
appreciated.

[Bug middle-end/96044] GCC hangs in tight loop resolving __builtin_jn using MPFR

[vincent-gcc at vinc17 dot net]

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

--- Comment #10 from Vincent Lefèvre  ---
(In reply to Richard Biener from comment #8)
> The issue with timeouts (as in wall-clock) is that it makes builds
> dependent on CPU speed which is something we generally avoid.  For ISL
> computations where we employ this kind of thing there's tracking of
> "number of ops" that are performed by ISL itself plus the ability for
> the client to set an upper bound after which operations return with
> an appropriate error.  gmp/mpfr/mpc could for example track the number
> of 64bit multiplies and support limiting there - but I expect this would
> be a lot of work.  Eventually we could make GCC use mini-gmp (would
> a host libmpfr then use the built-in mini-gmp?) and patch in this kind
> of accounting there...

The result would depend on the algorithm, i.e. on the MPFR version. And for
this reason, I agree with:

> But IMHO simply classifying a value-range where we do and where we do not
> constant fold certain functions would be reasonable as well - unless C++
> at some point magically requires to constexpr evaluate jn().

[Bug jit/96067] __atomic_compare_exchange_n should return bool instead of void

[bouanto at zoho dot com]

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

--- Comment #2 from Antoni  ---
Created attachment 48835
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48835=edit
Reproducer for thebug

Here's a reproducer for the bug.
The doc says it should return bool
(https://gcc.gnu.org/onlinedocs/gcc/_005f_005fatomic-Builtins.html), but this
reproducer shows the following error:

libgccjit.so: error: gcc_jit_block_end_with_return: mismatching types: return
of __atomic_compare_exchange_n ((), (), (int)0, (bool)0, (int)0,
(int)0) (type: void) in function hello (return type: bool)

[Bug tree-optimization/96075] New: bogus alignment for negative step grouped access

[rguenth at gcc dot gnu.org]

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

Bug ID: 96075
   Summary: bogus alignment for negative step grouped access
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

double x[1024], y[1024];

void __attribute__((noipa)) boo()
{
  for (int i = 0; i < 512; ++i)
{
  x[2*i] = y[2*(511-i)];
  x[2*i+1] = y[2*(511-i)];
}
}

int
main ()
{   
  for (int i = 0; i < 1024; ++i)
{
  x[i] = 0;
  y[i] = i;
  __asm__ volatile ("");
}

  boo ();
  for (int i = 0; i < 1024; ++i)
if (x[i] != y[2*(511 - i/2)])
  abort ();

  return 0;
}


segfaults because we emit

boo:
.LFB8:
.cfi_startproc
xorl%eax, %eax
.p2align 4,,10
.p2align 3
.L21:
movapd  y+8168(%rax), %xmm0
movq%rax, %rdx

where this is obviously misaligned.

[Bug libstdc++/96074] Associative containers never propagate allocator on copy assignment

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

[Bug libstdc++/96074] New: Associative containers never propagate allocator on copy assignment

[alisdairm at me dot com]

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

Bug ID: 96074
   Summary: Associative containers never propagate allocator on
copy assignment
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: alisdairm at me dot com
  Target Milestone: ---

Created attachment 48834
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48834=edit
Validate allocator propagation for all containers

The attached test driver is a simple validation that each container correctly
propgates allocators, given all 16 possible permutations of the traits.

All containers pass with the exception of the 4 associative containers that
each ignore the propagate_on_container_copy_assigment trait.

Note the test driver is slow to build as it instantiates a lot of templates.

[Bug libstdc++/96063] mismatched-tags warnings in stdlib headers

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Keywords||diagnostic
   Last reconfirmed||2020-07-06

--- Comment #1 from Jonathan Wakely  ---
I'm tempted to just disable the warning in all libstdc++ headers. It's a silly
warning, and the "may result in linker errors under the Microsoft C++ ABI" is a
false alarm in our case (we never *only* declare it without also defining it).

[Bug fortran/96018] Optimization issue with external HDF5 library

[martin.schlipf at damnthespam dot com]

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

martin.schlipf at damnthespam dot com changed:

   What|Removed |Added

  Attachment #48817|0   |1
is obsolete||

--- Comment #9 from martin.schlipf at damnthespam dot com ---
Created attachment 48833
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48833=edit
Minimal example to demonstrate the issue.

The example is now independent of HDF5 which makes it much simpler.

[Bug libstdc++/96042] Reference type of std::ranges::iota is __int128 with -std=c++2a?!

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
(In reply to gcc-bugs from comment #2)
> I think this is too easy to say that this is not a "bug", we can also weaken
> the terminology and say "potential-inconsistency".
> 
> Technically you are right, but only because there seems to be a specific
> "exception" for the implementation does not mean that this is the right
> thing to do.

I disagree. In the strongest possible terms.

> 
> I personally don't understand why the standard allows exceptions outside
> it's echo-system, I guess the stdlib implementers understand the subject
> better when forming the standard, and are lobbing harder for their
> necessities which is sometimes different from the needs / expectation of the
> end-user.
> 

This has nothing to do with our own necessities, this is to support end users.

> Can you help me figure out in which cases `-std=c++2a` would produce this
> type? Or asked differently: In which cases, other than this, do I encounter
> a `__int128` from using only types and functions defined in the standard?

I'm not aware of any others currently. That could change in future if the C and
C++ standards are changed to allow types larger than long long to be treated as
standard integer types. I would be very happy to see the ideas described in
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2425.pdf happen.

> I have the feeling from your answer that this type is an everyday type.

No. It's not, and that's exactly why we used it for IOTA-DIFF-T.

> Looking at https://eel.is/c++draft/range.iota#view-1, and if I read it
> correctly, this is case 3:
> 
> > Otherwise, IOTA-DIFF-T(W) is an unspecified signed-integer-like type
> > ([iterator.concept.winc]) of width not less than the width of W.
> > 
> > [Note: It is unspecified whether this type satisfies
> > weakly_­incrementable. — end note]
> 
> It means it would be totally fine to return the signed version of `size_t`,
> because it has at least the same width. (This would be a valid option, too)

But it wouldn't be totally fine, because that type (i.e. ptrdiff_t) cannot
represent the difference between the begin and end iterators of
iota_view.

The whole point of allowing IOTA-DIFF-T to be an unspecified integer-like type
is to solve that problem. It has to be a type larger than size_t, otherwise you
can't use large iota_view types, and that make a different group of users
unhappy.

Our implementation will soon be updated to use a custom class type that behaves
like an integer, so that we can also represent the maximum difference for
iota_view. Will you still complain
that "it is unexpected that I get a type that is not described in the
standard"? 

It's **not possible** to represent the difference type of iota_view for
every W without using a type that isn't in the set of types allowed for W. See
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1522r1.pdf for the
background.

Why is using __int128 here a problem? Do you really think we should treat "I am
surprised by this" as a more serious concern than "Some specializations of
iota_view have undefined bhaviour because the alternative would surprise some
people"?

You being unhappy because you don't expect something can (I hope) be resolved
by explaining the pragmatic engineering reasons behind the decision. Some code
being impossible to write cannot really be explained just by saying "we know
how to make this work, but it made somebody sad so we decided not to support
it, sorry".

The problem here seems to be that you expect the difference type of an
iota_view to be a normal integer type. Your expectation is wrong. You should
change your expectation.

[Bug rtl-optimization/96031] suboptimal codegen for store low 16-bits value

[zhongyunde at tom dot com]

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

--- Comment #1 from zhongyunde at tom dot com  ---
this may can be enhance by ivopts.
If the case adjusted as following, then the 'and w2, w2, 65535 ' will
disappear.


typedef unsigned int UINT32;
typedef unsigned short UINT16;


UINT16 array[12];

void foo (UINT32 len, UINT32 step)  
{
UINT32 index = 0;
UINT32 sum = 0;
for (index = 0; index < len; index++ )
{  
array[index] = sum;
sum += step;
}
}

// the assemble of kernel loop body --
.L9:
add x2, x2, 2 // ivtmp.6, ivtmp.6,
.L3:
strhw3, [x4]// sum, MEM[base: _12, offset: 0B]
cmp x2, x0// ivtmp.6, _22
add w3, w3, w1// sum, sum, step
mov x4, x2// ivtmp.6, ivtmp.6
bne .L9 //,