[Bug c/98086] [9/10/11 Regression] ICE in extract_insn, at recog.c:2315

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |9.4
   Keywords||ice-on-invalid-code

[Bug middle-end/98086] [9/10/11 Regression] ICE in extract_insn, at recog.c:2315

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

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||error-recovery
  Component|c   |middle-end
 Target||x86_64-*-*

--- Comment #1 from Richard Biener  ---
x86_64 I presume?

[Bug c/98087] [11 Regression] ICE: Floating point exception

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug middle-end/98088] [9/10/11 Regression] ICE in expand_oacc_collapse_init, at omp-expand.c:1533

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

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code, openmp
  Component|c   |middle-end
   Target Milestone|--- |9.4

[Bug c/98090] ICE in simd_clone_adjust_argument_types, at omp-simd-clone.c:591

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

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||accepts-invalid,
   ||ice-on-invalid-code, openmp

--- Comment #2 from Richard Biener  ---
I guess a void f() isn't sth suitable for OMP SIMD so we should reject it when
defined (not declared, it's not a prototype).

[Bug target/98092] [11 Regression] ICE in extract_insn, at recog.c:2315 (error: unrecognizable insn)

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |11.0

[Bug c/98087] [11 Regression] ICE: Floating point exception

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

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #2 from Martin Liška  ---
It's simple to fix, I'll do it.

[Bug tree-optimization/98069] [8/9/10/11 Regression] Miscompilation with -O3 since r8-2380-g2d7744d4ef93bfff

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

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

--- Comment #4 from Richard Biener  ---
The following helps:

diff --git a/gcc/tree-data-ref.c b/gcc/tree-data-ref.c
index 3bf460cccfd..a7606b3db99 100644
--- a/gcc/tree-data-ref.c
+++ b/gcc/tree-data-ref.c
@@ -754,9 +759,10 @@ split_constant_offset_1 (tree type, tree op0, enum
tree_code code, tree op1,
&& TYPE_PRECISION (type) >= TYPE_PRECISION (itype)
&& (POINTER_TYPE_P (type) || INTEGRAL_TYPE_P (type)))
  {
-   if (INTEGRAL_TYPE_P (itype) && TYPE_OVERFLOW_WRAPS (itype)
+   if (INTEGRAL_TYPE_P (itype)
&& (TYPE_PRECISION (type) > TYPE_PRECISION (itype)
-   || TYPE_UNSIGNED (itype) != TYPE_UNSIGNED (type)))
+   || (TYPE_UNSIGNED (itype) != TYPE_UNSIGNED (type)
+   && TYPE_OVERFLOW_WRAPS (itype
  {
/* Split the unconverted operand and try to prove that
   wrapping isn't a problem.  */

but I fear this will have quite some negative impact on dependence analysis.

I'm still not sure I have the issue nailed down properly :/

[Bug c++/97452] [coroutines] incorrect sequencing of await_resume() when multiple co_await expressions occur in a single statement

[davidledger at live dot com.au via Gcc-bugs]

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

--- Comment #6 from David Ledger  ---
Is this the right place for me to track this bug?

[Bug c++/97452] [coroutines] incorrect sequencing of await_resume() when multiple co_await expressions occur in a single statement

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

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

--- Comment #7 from Iain Sandoe  ---
(In reply to David Ledger from comment #6)
> Is this the right place for me to track this bug?

yes - it's just waiting for someone to have time to address it.

[Bug middle-end/98086] [9/10/11 Regression] ICE in extract_insn, at recog.c:2315

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

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 CC||marxin at gcc dot gnu.org,
   ||rth at gcc dot gnu.org
 Ever confirmed|0   |1
   Last reconfirmed||2020-12-02

--- Comment #2 from Martin Liška  ---
Yes.
Started with r6-1854-gf767f58360e4a029.

[Bug tree-optimization/98094] New: ICE in decompose, at wide-int.h:984

[stefansf at linux dot ibm.com via Gcc-bugs]

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

Bug ID: 98094
   Summary: ICE in decompose, at wide-int.h:984
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: stefansf at linux dot ibm.com
  Target Milestone: ---

Compiling SPEC benchmark 502.gcc_r on S/390 results in the following ICE:

$ /devel/gcc-2/dst/bin/gcc -c -o tree.o -DSPEC -DNDEBUG -I. -I./include
-I./spec_qsort -DSPEC_502 -DSPEC_AUTO_SUPPRESS_OPENMP -DIN_GCC -DHAVE_CONFIG_H
-march=arch13 -O3 -std=gnu89 -DSPEC_LP64 tree.c 
during GIMPLE pass: iftoswitch
tree.c: In function 'tree_floor_log2':
tree.c:10732: internal compiler error: in decompose, at wide-int.h:984
0x119ce51 wi::int_traits >
>::decompose(long*, unsigned int, generic_wide_int > const&)
/devel/gcc-2/src/gcc/wide-int.h:984
0x1a44837 wi::int_traits >
>::decompose(long*, unsigned int, generic_wide_int > const&)
/devel/gcc-2/src/gcc/tree.h:3445
0x1a44837 wide_int_ref_storage::wide_int_ref_storage > >(generic_wide_int > const&, unsig
ned int)
/devel/gcc-2/src/gcc/wide-int.h:1034
0x1a44837 generic_wide_int
>::generic_wide_int >
>(generic_wide_int 
> const&, unsigned int)
/devel/gcc-2/src/gcc/wide-int.h:790
0x1a44837 wi::binary_traits
>, generic_wide_int >,
wi::int_traits > >::precision_type,
wi::int_traits >
>::precision_type>::result_type
wi::sub >, generic_wide_int >
>(generic_wide_int > const&,
generic_wide_int > const&)
/devel/gcc-2/src/gcc/wide-int.h:2513
0x1a44837 wi::binary_traits
>, generic_wide_int >,
wi::int_traits > >::precision_type,
wi::int_traits >
>::precision_type>::operator_result
operator- >, generic_wide_int >
>(generic_wide_int > const&,
generic_wide_int > co
nst&)
/devel/gcc-2/src/gcc/wide-int.h:3297
0x1a44837 tree_switch_conversion::cluster::get_range(tree_node*, tree_node*)
/devel/gcc-2/src/gcc/tree-switch-conversion.h:87
0x1a3771d
tree_switch_conversion::jump_table_cluster::can_be_handled(vec const&, unsigned int, unsigned int)
/devel/gcc-2/src/gcc/tree-switch-conversion.c:1265
0x1a3d8d5
tree_switch_conversion::jump_table_cluster::can_be_handled(vec const&, unsigned int, unsigned int)
/devel/gcc-2/src/gcc/tree-switch-conversion.c:1258
0x1a3d8d5
tree_switch_conversion::jump_table_cluster::find_jump_tables(vec&)
/devel/gcc-2/src/gcc/tree-switch-conversion.c:1201
0x1a3d8d5
tree_switch_conversion::jump_table_cluster::find_jump_tables(vec&)
/devel/gcc-2/src/gcc/tree-switch-conversion.c:1175
0x22876d9 if_chain::is_beneficial()
/devel/gcc-2/src/gcc/gimple-if-to-switch.cc:244
0x2289237 execute
/devel/gcc-2/src/gcc/gimple-if-to-switch.cc:530
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

Bisect stops at 03eb09292ef228d1d12b5168cdd748583b1f992a

[Bug tree-optimization/98094] ICE in decompose, at wide-int.h:984

[stefansf at linux dot ibm.com via Gcc-bugs]

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

--- Comment #1 from Stefan Schulze Frielinghaus  
---
Reduced program:

struct {
  unsigned a : 10   
} b;
c;  
d() {   
  c = b.a;  
  if (c == 8 || c == 0) 
;   
  else if (c > 8 * 8)   
;   
  else if (c < 8 * 8)   
e();
}

[Bug tree-optimization/98094] ICE in decompose, at wide-int.h:984

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

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
 Ever confirmed|0   |1
   Last reconfirmed||2020-12-02

--- Comment #2 from Richard Biener  ---
I think there's a dup and/or Martin already fixed this with
g:e4c02ce4ab6fce1148f4025360096f18764deadf - can you confirm?

[Bug c/98087] [11 Regression] ICE: Floating point exception

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

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

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

https://gcc.gnu.org/g:337d6362458ab033d3bfe287dda37f9da5577406

commit r11-5647-g337d6362458ab033d3bfe287dda37f9da5577406
Author: Martin Liska 
Date:   Wed Dec 2 09:44:40 2020 +0100

Fix __builtin_clear_padding for empty struct.

gcc/ChangeLog:

PR c/98087
* gimple-fold.c (clear_padding_type): Do not divide by zero.

gcc/testsuite/ChangeLog:

PR c/98087
* gcc.c-torture/compile/pr98087.c: New test.

[Bug c/98087] [11 Regression] ICE: Floating point exception

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

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

Martin Liška  changed:

   What|Removed |Added

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

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

[Bug rtl-optimization/97459] __uint128_t remainder for division by 3

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

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

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

https://gcc.gnu.org/g:037fe26ee1ac18581bf0ad646d48591c97d10bd3

commit r11-5648-g037fe26ee1ac18581bf0ad646d48591c97d10bd3
Author: Jakub Jelinek 
Date:   Wed Dec 2 11:32:19 2020 +0100

expansion: Further improve double-word modulo, division and divmod
[PR97459]

The following patch implements what Thomas wrote about, in particular
that we can handle also double-word divison by the constants for which
the earlier patch optimized modulo (if it would be otherwise a library
call) and that we can also easily handle such constants shifted to the
left.
Unfortunately, seems CSE isn't able to optimize away the two almost
identical sequences (one to compute remainder, one to compute quotient),
probably because of the ADD_OVERFLOW introduced jumps, so the patch also
adjusts expand_DIVMOD.

2020-12-02  Jakub Jelinek  

PR rtl-optimization/97459
* optabs.h (expand_doubleword_divmod): Declare.
* optabs.c (expand_doubleword_divmod): New function.
(expand_binop): Use it.
* internal-fn.c (expand_DIVMOD): Likewise.

* gcc.target/i386/pr97282.c (foo): Use 123456 divisor instead of
10.
* gcc.dg/pr97459-1.c (TESTS): Add tests for 10, 12 and
6144.
* gcc.dg/pr97459-2.c (TESTS): Likewise.
* gcc.dg/pr97459-3.c: New test.
* gcc.dg/pr97459-4.c: New test.
* gcc.dg/pr97459-5.c: New test.
* gcc.dg/pr97459-6.c: New test.

[Bug tree-optimization/98094] ICE in decompose, at wide-int.h:984

[stefansf at linux dot ibm.com via Gcc-bugs]

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

--- Comment #3 from Stefan Schulze Frielinghaus  
---
I still run into the same error with e4c02ce4ab6fce1148f4025360096f18764deadf

[Bug tree-optimization/98094] ICE in decompose, at wide-int.h:984

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

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

Richard Biener  changed:

   What|Removed |Added

 Ever confirmed|1   |0
 Status|WAITING |UNCONFIRMED

--- Comment #4 from Richard Biener  ---
(In reply to Stefan Schulze Frielinghaus from comment #3)
> I still run into the same error with e4c02ce4ab6fce1148f4025360096f18764deadf

Hmm, it doesn't reproduce for me with a cc1 cross and your reduced testcase.

[Bug tree-optimization/98094] ICE in decompose, at wide-int.h:984

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

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

--- Comment #5 from Richard Biener  ---
Ah, so maybe g:c961e94901eb793b1a18d431a1acf7f682eaf04f which has

* gimple-if-to-switch.cc (find_conditions): Require
equal precision for low and high of a range.

[Bug tree-optimization/98094] ICE in decompose, at wide-int.h:984

[stefansf at linux dot ibm.com via Gcc-bugs]

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

Stefan Schulze Frielinghaus  changed:

   What|Removed |Added

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

--- Comment #6 from Stefan Schulze Frielinghaus  
---
Ah yes commit c961e94901eb793b1a18d431a1acf7f682eaf04f seems to have fixed
this. Closing since fixed. Thanks for your help!

[Bug tree-optimization/96698] [10 Regression] ICE during GIMPLE pass:vect

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

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

--- Comment #4 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Richard Biener
:

https://gcc.gnu.org/g:66dd83c8840a9a28f6209922b8abd5783a255207

commit r10-9106-g66dd83c8840a9a28f6209922b8abd5783a255207
Author: Richard Biener 
Date:   Wed Aug 26 15:12:17 2020 +0200

tree-optimization/96698 - fix ICE when vectorizing nested cycles

This fixes vectorized PHI latch edge updating and delay it until
all of the loop is code generated to deal with the case that the
latch def is a PHI in the same block.

2020-08-26  Richard Biener  

PR tree-optimization/96698
* tree-vectorizer.h (loop_vec_info::reduc_latch_defs): New.
(loop_vec_info::reduc_latch_slp_defs): Likewise.
* tree-vect-stmts.c (vect_transform_stmt): Only record
stmts to update PHI latches from, perform the update ...
* tree-vect-loop.c (vect_transform_loop): ... here after
vectorizing those PHIs.
(info_for_reduction): Properly handle non-reduction PHIs.

* gcc.dg/vect/pr96698.c: New testcase.

(cherry picked from commit 2130efe6ac7beba72d289e3dd145daa10aeaed54)

[Bug tree-optimization/96698] [10 Regression] ICE during GIMPLE pass:vect

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

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

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

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

commit r10-9107-ge563687cf9d3d1278f45aaebd03e0f66531076c9
Author: Richard Biener 
Date:   Fri Sep 4 14:35:39 2020 +0200

tree-optimization/96920 - another ICE when vectorizing nested cycles

This refines the previous fix for PR96698 by re-doing how and where
we arrange for setting vectorized cycle PHI backedge values.

2020-09-04  Richard Biener  

PR tree-optimization/96698
PR tree-optimization/96920
* tree-vectorizer.h (loop_vec_info::reduc_latch_defs): Remove.
(loop_vec_info::reduc_latch_slp_defs): Likewise.
* tree-vect-stmts.c (vect_transform_stmt): Remove vectorized
cycle PHI latch code.
* tree-vect-loop.c (maybe_set_vectorized_backedge_value): New
helper to set vectorized cycle PHI latch values.
(vect_transform_loop): Walk over all PHIs again after
vectorizing them, calling maybe_set_vectorized_backedge_value.
Call maybe_set_vectorized_backedge_value for each vectorized
stmt.  Remove delayed update code.
* tree-vect-slp.c (vect_analyze_slp_instance): Initialize
SLP instance reduc_phis member.
(vect_schedule_slp): Set vectorized cycle PHI latch values.

* gfortran.dg/vect/pr96920.f90: New testcase.
* gcc.dg/vect/pr96920.c: Likewise.

(cherry picked from commit 46a58c779af3055a4b10b285a1f4be28abe4351c)

[Bug tree-optimization/96920] [10 Regression] ICE segmentation fault in tree-vectorizer at -O3

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

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

--- Comment #7 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Richard Biener
:

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

commit r10-9107-ge563687cf9d3d1278f45aaebd03e0f66531076c9
Author: Richard Biener 
Date:   Fri Sep 4 14:35:39 2020 +0200

tree-optimization/96920 - another ICE when vectorizing nested cycles

This refines the previous fix for PR96698 by re-doing how and where
we arrange for setting vectorized cycle PHI backedge values.

2020-09-04  Richard Biener  

PR tree-optimization/96698
PR tree-optimization/96920
* tree-vectorizer.h (loop_vec_info::reduc_latch_defs): Remove.
(loop_vec_info::reduc_latch_slp_defs): Likewise.
* tree-vect-stmts.c (vect_transform_stmt): Remove vectorized
cycle PHI latch code.
* tree-vect-loop.c (maybe_set_vectorized_backedge_value): New
helper to set vectorized cycle PHI latch values.
(vect_transform_loop): Walk over all PHIs again after
vectorizing them, calling maybe_set_vectorized_backedge_value.
Call maybe_set_vectorized_backedge_value for each vectorized
stmt.  Remove delayed update code.
* tree-vect-slp.c (vect_analyze_slp_instance): Initialize
SLP instance reduc_phis member.
(vect_schedule_slp): Set vectorized cycle PHI latch values.

* gfortran.dg/vect/pr96920.f90: New testcase.
* gcc.dg/vect/pr96920.c: Likewise.

(cherry picked from commit 46a58c779af3055a4b10b285a1f4be28abe4351c)

[Bug tree-optimization/96698] [10 Regression] ICE during GIMPLE pass:vect

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

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

Richard Biener  changed:

   What|Removed |Added

  Known to fail||10.2.0
  Known to work||10.2.1
 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

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

[Bug tree-optimization/96920] [10 Regression] ICE segmentation fault in tree-vectorizer at -O3

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

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

Richard Biener  changed:

   What|Removed |Added

 Resolution|--- |FIXED
  Known to work||10.2.1
 Status|ASSIGNED|RESOLVED

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

[Bug tree-optimization/98095] New: Optimize __builtin_unordered (...) || __builtin_is{less,greater}{,equal}

[ubizjak at gmail dot com via Gcc-bugs]

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

Bug ID: 98095
   Summary: Optimize __builtin_unordered (...) ||
__builtin_is{less,greater}{,equal}
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ubizjak at gmail dot com
  Target Milestone: ---

These two functions are equivalent:

int t3 (float a, float b)
{
  return  __builtin_isless (a, b) || __builtin_isunordered (a, b);
}

int t4 (float a, float b)
{
  return  !__builtin_isgreaterequal (a, b);
}

gcc -O2:

t3:
ucomiss %xmm0, %xmm1
seta%al
ucomiss %xmm1, %xmm0
setp%dl
orl %edx, %eax
movzbl  %al, %eax
ret

t4:
xorl%eax, %eax
ucomiss %xmm1, %xmm0
setb%al
ret

Proof:

for ordered operands:
the result of t3 is (a < b); the result of t4 is !(a >= b) = (a < b)

for unordered operands:
the result of the t3 is true; the result of t4 is !false = true.

q.e.d.

The above equivalence is true for all relations. I didn't check
__builtin_islessgreater; although gcc provides UNEQ, it doesn't provide
__builtin_isequal builtin function.

[Bug debug/97060] Missing DW_AT_declaration=1 in dwarf data

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

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

Alexandre Oliva  changed:

   What|Removed |Added

 CC||aoliva at gcc dot gnu.org

--- Comment #18 from Alexandre Oliva  ---
The pr97060 test is failing for me, in the gcc-10 branch, at least on target
arm-eabi.  It passes when optimization is enabled, because then the DIE with
the declaration tag, generated in resolve_addr, makes to the output.  With
optimization disabled, it's created and resolved, but doesn't make it.

It looks like this only works at -O0 with the patch for bug 96383, but it
hasn't been backported to gcc-10.  Only Red Hat's gcc-10 branch has it, as
stated in comment 6.

[Bug tree-optimization/97630] [11 Regression] SLP vectorizer leaks memory

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

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

--- Comment #1 from Richard Biener  ---
The least resistance attempt to fix it would be to keep track of allocated
SLP trees in _slp_tree::operator new/delete using a hash_set<> for example
and call the DTOR on still allocated ones when destroying the alloc-pool.
A double-linked list of all allocated nodes would work as well.

Otherwise each vect_free_slp_tree would need to check whether it was the
last entry into a cycle which would be quite expensive.

Tracking cycle [entries] separately is somewhat difficult since via
vectorizable_* we can later break cycles at arbitrary places so we can't
use weak references for backedges because what and what is not a backedge
can change.

[Bug tree-optimization/98084] [11 Regression] ICE in error: non-integral type switch statement

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

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

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

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

commit r11-5651-gd01ebe56c2f54bf4ac91ce389ecef734f557ea3e
Author: Martin Liska 
Date:   Wed Dec 2 13:08:56 2020 +0100

Add new test-case.

gcc/testsuite/ChangeLog:

PR tree-optimization/98084
* gcc.dg/tree-ssa/pr98094.c: New test.

[Bug tree-optimization/98094] ICE in decompose, at wide-int.h:984

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

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #7 from Martin Liška  ---
The master branch has been updated by Martin Liska :

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

commit r11-5651-gd01ebe56c2f54bf4ac91ce389ecef734f557ea3e
Author: Martin Liska 
Date:   Wed Dec 2 13:08:56 2020 +0100

Add new test-case.

gcc/testsuite/ChangeLog:

PR tree-optimization/98084
* gcc.dg/tree-ssa/pr98094.c: New test.

[Bug debug/96383] [8/9/10 Regression] Full ABI information missing from GCC compiled C

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

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

Alexandre Oliva  changed:

   What|Removed |Added

 CC||aoliva at gcc dot gnu.org

--- Comment #27 from Alexandre Oliva  ---
FTR, the patch for bug 97060 was backported to gcc-10, but it depends on this
patch to work at -O0.

[Bug tree-optimization/96370] [8/9 Regression] ICE with -ffast-math since r7-950-g8a85cee26eabf5cf

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

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

--- Comment #9 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Richard Biener
:

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

commit r9-9087-ga5fff78405c3bfea287434e7711c6f10a770cb0a
Author: Richard Biener 
Date:   Thu Jul 30 10:24:42 2020 +0200

tree-optimization/96370 - make reassoc expr rewrite more robust

In the face of the more complex tricks in reassoc with respect
to negate processing it can happen that the expression rewrite
is fooled to recurse on a leaf and pick up a bogus expression
code.  The following patch makes the expression rewrite more
robust in providing the expression code to it directly since
it is the same for all operations in a chain.

2020-07-30  Richard Biener  

PR tree-optimization/96370
* tree-ssa-reassoc.c (rewrite_expr_tree): Add operation
code parameter and use it instead of picking it up from
the stmt that is being rewritten.
(reassociate_bb): Pass down the operation code.

* gcc.dg/pr96370.c: New testcase.

(cherry picked from commit 2c558d2655cb22f472c83e8296b5cd2a92365cd3)

[Bug tree-optimization/96579] [8/9 Regression] ICE in gimple check: expected gimple_assign(error_mark), have gimple_nop() in gimple_assign_rhs1, at gimple.h:2605 since r7-950-g8a85cee26eabf5cf

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

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

--- Comment #8 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Richard Biener
:

https://gcc.gnu.org/g:92b6627874cc924eeed9084a09f09504e20b5387

commit r9-9088-g92b6627874cc924eeed9084a09f09504e20b5387
Author: Richard Biener 
Date:   Thu Aug 27 10:02:22 2020 +0200

tree-optimization/96579 - another special-operands fix in reassoc

This makes sure to put special-ops expanded rhs left where
expression rewrite expects it.

2020-08-27  Richard Biener  

PR tree-optimization/96579
* tree-ssa-reassoc.c (linearize_expr_tree): If we expand
rhs via special ops make sure to swap operands.

* gcc.dg/pr96579.c: New testcase.

(cherry picked from commit ff7463172e564c5dd2432d7af8eaa0124cbd4af7)

[Bug tree-optimization/96514] [9 Regression] ICE: verify_flow_info failed (error: control flow in the middle of basic block 3)

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

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

--- Comment #5 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Richard Biener
:

https://gcc.gnu.org/g:6178c27b4bbea186305ecbfeb4b9939dece75a9d

commit r9-9086-g6178c27b4bbea186305ecbfeb4b9939dece75a9d
Author: Richard Biener 
Date:   Fri Aug 7 10:16:05 2020 +0200

tree-optimization/96514 - avoid if-converting control-altering calls

This avoids if-converting when encountering control-altering calls.

2020-08-07  Richard Biener  

PR tree-optimization/96514
* tree-if-conv.c (if_convertible_bb_p): If the last stmt
is a call that is control-altering, fail.

* gcc.dg/pr96514.c: New testcase.

(cherry picked from commit c3f94f5786a014515c09c7852db228c74adf51e5)

[Bug tree-optimization/97255] [8/9 Regression] Vectorizer gives a boolean a value of 255

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

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

--- Comment #6 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Richard Biener
:

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

commit r9-9091-gf720a0d776252aac3002a0a9307a96465f1975bd
Author: Richard Biener 
Date:   Thu Oct 1 09:29:32 2020 +0200

tree-optimization/97255 - missing vector bool pattern of SRAed bool

SRA tends to use VIEW_CONVERT_EXPR when replacing bool fields with
unsigned char fields.  Those are not handled in vector bool pattern
detection causing vector true values to leak.  The following fixes
this by turning those into b ? 1 : 0 as well.

2020-10-01  Richard Biener  

PR tree-optimization/97255
* tree-vect-patterns.c (vect_recog_bool_pattern): Also handle
VIEW_CONVERT_EXPR.

* g++.dg/vect/pr97255.cc: New testcase.

(cherry picked from commit 36e691d3a62145fda1f4a1b3143d215cc113c10a)

[Bug tree-optimization/97081] [8/9 Regression] wrong code for rotate vectorization (x86 target)

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

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

--- Comment #11 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Richard Biener
:

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

commit r9-9089-g86b25a1a5e1956c30fe7eaee80ebf719b759d631
Author: Richard Biener 
Date:   Fri Sep 18 13:36:24 2020 +0200

tree-optimization/97081 - fix wrong-code with vectorized shift

This corrects the mask for creation of x << s | x >> (-x & mask)
from a rotate x <

PR tree-optimization/97081
* tree-vect-patterns.c (vect_recog_rotate_pattern): Use the
precision of the shifted operand to determine the mask.

* gcc.dg/vect/pr97081.c: New testcase.

(cherry picked from commit 9c9b88fdcff3520b2c4fb520c5d3b422eaa9a72f)

[Bug tree-optimization/97081] [8/9 Regression] wrong code for rotate vectorization (x86 target)

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

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

--- Comment #12 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Richard Biener
:

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

commit r9-9090-gf75352bdb139c40abb400746c03d9242a0c30bd6
Author: Jakub Jelinek 
Date:   Fri Sep 18 15:05:53 2020 +0200

testsuite: add another test for the rotate vectorization miscompilation

This time with short and char where the used mask used to be larger
than it should have been.

2020-09-18  Jakub Jelinek  

PR tree-optimization/97081
* gcc.dg/vect/pr97081-2.c: New test.

(cherry picked from commit 3d3fe967b0961cb59f5df03ae2a55d83dc4bbd34)

[Bug tree-optimization/97812] [9 Regression] Wrong output when compiling the testcase with -O2 -flto since r9-4558-g476a31b55b5471262

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

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

--- Comment #15 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Richard Biener
:

https://gcc.gnu.org/g:165ae61a9f7e484cd9cc1ad09f477ecad59c77e9

commit r9-9092-g165ae61a9f7e484cd9cc1ad09f477ecad59c77e9
Author: Richard Biener 
Date:   Fri Nov 13 11:31:22 2020 +0100

tree-optimization/97812 - fix range query in VRP assert discovery

This makes sure to properly extend the input range before seeing
whether it fits the target.

2020-11-13  Richard Biener  

PR tree-optimization/97812
* tree-vrp.c (register_edge_assert_for_2): Extend the range
according to its sign before seeing whether it fits.

* gcc.dg/torture/pr97812.c: New testcase.

(cherry picked from commit dcfd302a79a5e2ea3bb16fc4fc45a5ee31cc0eab)

[Bug debug/96383] [8/9/10 Regression] Full ABI information missing from GCC compiled C

[rguenther at suse dot de via Gcc-bugs]

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

--- Comment #28 from rguenther at suse dot de  ---
On Wed, 2 Dec 2020, aoliva at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96383
> 
> Alexandre Oliva  changed:
> 
>What|Removed |Added
> 
>  CC||aoliva at gcc dot gnu.org
> 
> --- Comment #27 from Alexandre Oliva  ---
> FTR, the patch for bug 97060 was backported to gcc-10, but it depends on this
> patch to work at -O0.

I do not plan to backport this patch further.

[Bug tree-optimization/97812] [9 Regression] Wrong output when compiling the testcase with -O2 -flto since r9-4558-g476a31b55b5471262

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

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

Richard Biener  changed:

   What|Removed |Added

 Resolution|--- |FIXED
  Known to work||9.3.1
 Status|ASSIGNED|RESOLVED

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

[Bug tree-optimization/96514] [9 Regression] ICE: verify_flow_info failed (error: control flow in the middle of basic block 3)

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

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

Richard Biener  changed:

   What|Removed |Added

 Resolution|--- |FIXED
  Known to fail||9.3.0
 Status|ASSIGNED|RESOLVED
  Known to work||9.3.1

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

[Bug fortran/80255] Segfault from accessing class(*) component in an array of any-type-wrappers

[pedsxing at gmx dot net via Gcc-bugs]

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

pedsxing at gmx dot net changed:

   What|Removed |Added

Version|7.0.1   |10.1.0

--- Comment #3 from pedsxing at gmx dot net ---
I just tried again with gfortran 10.1.0 and the problem is still there. (I can
not get it to print "other type" anymore though. Now it just always segfaults.)

I do believe this is standard conforming Fortran. Here is what the standard
says about intrinsic assignment to allocatable variables:
"If the variable is [...] an unallocated allocatable variable, it is then
allocated with: * if the variable is polymorphic, the same dynamic type as
expr"
I would think that unlimited polymorphic "class(*)" should count as
polymorphic.

[Bug target/92729] [avr] Convert the backend to MODE_CC so it can be kept in future releases

[abebeos at lazaridis dot com via Gcc-bugs]

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

--- Comment #29 from abebeos at lazaridis dot com ---
(In reply to abebeos from comment #23)
> (In reply to Senthil Kumar Selvaraj from comment #21)
> > (https://github.com/saaadhu/gcc-avr-cc0/tree/avr-cc0-squashed)
> 
> I can still do a test-run, to see if it produces less fails
[...]

Test-Delta of your non-cc0 avr-backend is 0

> > I don't have the spare time now to start full fledged work on this, but I
> > can help with any issues you run into.

My understanding is that you have already contributor status here, so could you
make the patch available to the project?

I will today focus on publishing my test-setup, so that my test-results can be
peer-reviewed. Should be available within 12 hours, max 36.

If I did nothing wrong, then this means that your patch could go in. An
alternative would be to iron-out the last issues from pipcet's version
(possibly by using the constructs from your work).

[Bug testsuite/97959] Random FAIL: gcc.dg/lto/save-temps c_lto_save-temps_0.o-c_lto_save-temps_0.o link, -O -flto -save-temps

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

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

H.J. Lu  changed:

   What|Removed |Added

   Target Milestone|--- |11.0
   Last reconfirmed||2020-12-02
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #2 from H.J. Lu  ---
Is gcc.dg/lto/lto.exp missing

gcc_parallel_test_enable 0
...
gcc_parallel_test_enable 1

[Bug target/92729] [avr] Convert the backend to MODE_CC so it can be kept in future releases

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

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

--- Comment #30 from Jonathan Wakely  ---
(In reply to abebeos from comment #29)
> My understanding is that you have already contributor status here, so could
> you make the patch available to the project?

I don't think that's true, is it? I think Senthil Kumar needs to complete the
paperwork with the FSF for the patches to be "available to the project". Tht
can be done by assigning copyright to the FSF or completing a disclaimer to
place the work in the public domain.

[Bug tree-optimization/96369] [8/9 Regression] Wrong evaluation order of || operator

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

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

--- Comment #7 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Richard Biener
:

https://gcc.gnu.org/g:505767905735a3c8f171c140108ee263f9fdcad6

commit r9-9093-g505767905735a3c8f171c140108ee263f9fdcad6
Author: Richard Biener 
Date:   Fri Jul 31 08:41:56 2020 +0200

middle-end/96369 - fix missed short-circuiting during range folding

This makes the special case of constant evaluated LHS for a
short-circuiting or/and explicit rather than doing range
merging and eventually exposing a side-effect that shouldn't be
evaluated.

2020-07-31  Richard Biener  

PR middle-end/96369
* fold-const.c (fold_range_test): Special-case constant
LHS for short-circuiting operations.

* c-c++-common/pr96369.c: New testcase.

(cherry picked from commit 10231958fcfb13bc4847729eba21470c101b4a88)

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

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

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

--- Comment #12 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Richard Biener
:

https://gcc.gnu.org/g:53d76fe758a3e8e0c1f049e75030278427a8fe5d

commit r9-9094-g53d76fe758a3e8e0c1f049e75030278427a8fe5d
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.

(cherry picked from commit dccbf1e2a6e544f71b4a5795f0c79015db019fc3)

[Bug target/92729] [avr] Convert the backend to MODE_CC so it can be kept in future releases

[glaubitz at physik dot fu-berlin.de via Gcc-bugs]

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

--- Comment #31 from John Paul Adrian Glaubitz  ---
(In reply to Jonathan Wakely from comment #30)
> I don't think that's true, is it? I think Senthil Kumar needs to complete
> the paperwork with the FSF for the patches to be "available to the project".
> Tht can be done by assigning copyright to the FSF or completing a disclaimer
> to place the work in the public domain.

The question will also be who will get to claim the bounty? If everyone
contributes something, it will be more difficult to determine who gets what.

[Bug rtl-optimization/97459] __uint128_t remainder for division by 3

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #25 from Jakub Jelinek  ---
Should be implemented now.

[Bug middle-end/93195] -fpatchable-function-entries : __patchable_function_entries should consider comdat groups

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

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

--- Comment #7 from CVS Commits  ---
The master branch has been updated by H.J. Lu :

https://gcc.gnu.org/g:694d4a6d0c466d0fbc97920a9c6641a7b349ca35

commit r11-5656-g694d4a6d0c466d0fbc97920a9c6641a7b349ca35
Author: H.J. Lu 
Date:   Wed Dec 2 05:32:37 2020 -0800

Use the section flag 'o' for __patchable_function_entries

This commit in GNU binutils 2.35:

   
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=b7d072167715829eed0622616f6ae0182900de3e

added the section flag 'o' to .section directive:

.section __patchable_function_entries,"awo",@progbits,foo

which specifies the symbol name which the section references.  Assembler
creates a unique __patchable_function_entries section with the section,
where foo is defined, as its linked-to section.  Linker keeps a section
if its linked-to section is kept during garbage collection.

This patch checks assembler support for the section flag 'o' and uses
it to implement __patchable_function_entries section.  Since Solaris may
use GNU assembler with Solairs ld.  Even if GNU assembler supports the
section flag 'o', it doesn't mean that Solairs ld supports it.  This
feature is disabled for Solairs targets.

gcc/

PR middle-end/93195
PR middle-end/93197
* configure.ac (HAVE_GAS_SECTION_LINK_ORDER): New.  Define 1 if
the assembler supports the section flag 'o' for specifying
section with link-order.
* output.h (SECTION_LINK_ORDER): New.  Defined to 0x800.
(SECTION_MACH_DEP): Changed from 0x800 to 0x1000.
* targhooks.c (default_print_patchable_function_entry): Pass
SECTION_LINK_ORDER to switch_to_section if the section flag 'o'
works.  Pass current_function_decl to switch_to_section.
* varasm.c (default_elf_asm_named_section): Use 'o' flag for
SECTION_LINK_ORDER if assembler supports it.
* config.in: Regenerated.
* configure: Likewise.
* doc/sourcebuild.texi: Document o_flag_in_section.

gcc/testsuite/

PR middle-end/93195
* g++.dg/pr93195a.C: New test.
* g++.dg/pr93195b.C: Likewise.
* lib/target-supports.exp
(check_effective_target_o_flag_in_section): New proc.

[Bug middle-end/93197] -fpatchable-function-entries : __patchable_function_entries does not survive under --gc-sections

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

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by H.J. Lu :

https://gcc.gnu.org/g:694d4a6d0c466d0fbc97920a9c6641a7b349ca35

commit r11-5656-g694d4a6d0c466d0fbc97920a9c6641a7b349ca35
Author: H.J. Lu 
Date:   Wed Dec 2 05:32:37 2020 -0800

Use the section flag 'o' for __patchable_function_entries

This commit in GNU binutils 2.35:

   
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=b7d072167715829eed0622616f6ae0182900de3e

added the section flag 'o' to .section directive:

.section __patchable_function_entries,"awo",@progbits,foo

which specifies the symbol name which the section references.  Assembler
creates a unique __patchable_function_entries section with the section,
where foo is defined, as its linked-to section.  Linker keeps a section
if its linked-to section is kept during garbage collection.

This patch checks assembler support for the section flag 'o' and uses
it to implement __patchable_function_entries section.  Since Solaris may
use GNU assembler with Solairs ld.  Even if GNU assembler supports the
section flag 'o', it doesn't mean that Solairs ld supports it.  This
feature is disabled for Solairs targets.

gcc/

PR middle-end/93195
PR middle-end/93197
* configure.ac (HAVE_GAS_SECTION_LINK_ORDER): New.  Define 1 if
the assembler supports the section flag 'o' for specifying
section with link-order.
* output.h (SECTION_LINK_ORDER): New.  Defined to 0x800.
(SECTION_MACH_DEP): Changed from 0x800 to 0x1000.
* targhooks.c (default_print_patchable_function_entry): Pass
SECTION_LINK_ORDER to switch_to_section if the section flag 'o'
works.  Pass current_function_decl to switch_to_section.
* varasm.c (default_elf_asm_named_section): Use 'o' flag for
SECTION_LINK_ORDER if assembler supports it.
* config.in: Regenerated.
* configure: Likewise.
* doc/sourcebuild.texi: Document o_flag_in_section.

gcc/testsuite/

PR middle-end/93195
* g++.dg/pr93195a.C: New test.
* g++.dg/pr93195b.C: Likewise.
* lib/target-supports.exp
(check_effective_target_o_flag_in_section): New proc.

[Bug middle-end/93195] -fpatchable-function-entries : __patchable_function_entries should consider comdat groups

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

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #8 from H.J. Lu  ---
Fixed for GCC 11.

[Bug inline-asm/98096] New: Inconsistent operand numbering for asm goto with in-out operands

[jwjagersma at gmail dot com via Gcc-bugs]

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

Bug ID: 98096
   Summary: Inconsistent operand numbering for asm goto with
in-out operands
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: inline-asm
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jwjagersma at gmail dot com
  Target Milestone: ---

For the following code:

asm goto ("# %0 %1 %2" : "+r" (i) ::: jmp);

Two registers are printed before the label name, because the in-out operand is
split internally.  This is somewhat surprising from a user perspective.

But then:

asm goto ("# %l[jmp]" : "+r" (i) ::: jmp);

Produces an error: '%l' operand isn't a label.

So label operands are numbered after the in-out operand is split, but %l is
evaluated without this split taken into account.  Docs suggest it should be
possible to use asm goto with both in-outs and %l operands simultaneously.

[Bug plugins/98059] [11 regression] Plugins don't compile with c++20

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
Indeed, C++20 rejects this since
r11-532-g4b38d56dbac6742b038551a36ec80200313123a1
DR2237 http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#2237
change.

[Bug target/92729] [avr] Convert the backend to MODE_CC so it can be kept in future releases

[abebeos at lazaridis dot com via Gcc-bugs]

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

--- Comment #32 from abebeos at lazaridis dot com ---
(In reply to Jonathan Wakely from comment #30)
> (In reply to abebeos from comment #29)
> > My understanding is that you have already contributor status here, so could
> > you make the patch available to the project?
> 
> I don't think that's true, is it? I think Senthil Kumar
[...]

See:

https://gcc.gnu.org/git/?p=gcc.git;a=search;h=e7d55c6b8175d81e35f7c0116bbdffccb682;s=Senthil+Kumar+Selvaraj;st=committer

[Bug ipa/98075] [10/11 Regression] ICE: verify_cgraph_node failed (error: malloc attribute should be used for a function that returns a pointer) since r10-6699-g33351ff9faa21c4c

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

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Martin Liska :

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

commit r11-5657-gf5850e7da93a6b1e4bec3e8740d08e985433eef3
Author: Martin Liska 
Date:   Wed Dec 2 13:01:47 2020 +0100

ipa: do not DECL_IS_MALLOC for void fns

gcc/ChangeLog:

PR ipa/98075
* cgraph.c (cgraph_node::dump): Dump decl_is_malloc flag.
* ipa-pure-const.c (propagate_malloc): Do not set malloc
attribute for void functions.

gcc/testsuite/ChangeLog:

PR ipa/98075
* g++.dg/ipa/pr98075.C: New test.

[Bug ipa/98075] [10/11 Regression] ICE: verify_cgraph_node failed (error: malloc attribute should be used for a function that returns a pointer) since r10-6699-g33351ff9faa21c4c

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

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

Martin Liška  changed:

   What|Removed |Added

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

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

[Bug target/92729] [avr] Convert the backend to MODE_CC so it can be kept in future releases

[abebeos at lazaridis dot com via Gcc-bugs]

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

--- Comment #33 from abebeos at lazaridis dot com ---
(In reply to John Paul Adrian Glaubitz from comment #31)
[...]
> The question will also be who will get to claim the bounty? If everyone
> contributes something, it will be more difficult to determine who gets what.

See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729#c11 and

It is essentially not one bounty, but 2 or even 3, that's why I asked for the
increase of the bounty, see "Update" section:

https://www.bountysource.com/issues/84630749-avr-convert-the-backend-to-mode_cc-so-it-can-be-kept-in-future-releases.

But!!!

We're risking to interrupt my perfect flow with such stuff ("paperwork"
"bounty" etc.). I need my flow for 2 more days minimum.

[Bug tree-optimization/98097] New: Missing warning about strcmp (char[4], "BARZ")

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

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

Bug ID: 98097
   Summary: Missing warning about strcmp (char[4], "BARZ")
   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: ---

#include 

struct info {
   char type[4];
   unsigned int status;
};

int foo (struct info *i)
{
  return strcmp (i->type, "ECKD") == 0;
}

Does not warn with -Wstring-compare, the variant with i passed by value does.

[Bug tree-optimization/98097] Missing warning about strcmp (char[4], "BARZ")

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

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||diagnostic
 CC||msebor at gcc dot gnu.org

--- Comment #1 from Richard Biener  ---
Likely because &i->type is not a gimple invariant and thus in a separate stmt?

[Bug target/98086] [9/10/11 Regression] ICE in extract_insn, at recog.c:2315

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #3 from Jakub Jelinek  ---
Created attachment 49661
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49661&action=edit
gcc11-pr98086.patch

Untested fix.

[Bug plugins/98059] [11 regression] Plugins don't compile with c++20

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

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

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

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

commit r11-5660-gbad800c03d00a57fc21718c160459d9a1e8d747a
Author: Scott Snyder 
Date:   Wed Dec 2 15:42:56 2020 +0100

vec.h: Fix GCC build with -std=gnu++20 [PR98059]

Apparently vec.h doesn't build with -std=c++20/gnu++20, since the
DR2237 r11-532 change.
template 
class auto_delete_vec
{
private:
  auto_vec_delete (const auto_delete_vec &) = delete;
};
which vec.h uses is invalid C++20, one needs to use
  auto_vec_delete (const auto_delete_vec &) = delete;
instead which is valid all the way back to C++11 (and without = delete
to C++98).

2020-12-02  Scott Snyder  

PR plugins/98059
* vec.h (auto_delete_vec): Use
DISABLE_COPY_AND_ASSIGN(auto_delete_vec) instead of
DISABLE_COPY_AND_ASSIGN(auto_delete_vec) to make it valid C++20
after DR2237.

[Bug tree-optimization/97630] [11 Regression] SLP vectorizer leaks memory

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

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

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

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

commit r11-5661-gfeb93adf76eda52385a73eb57c5bef7c870a2564
Author: Richard Biener 
Date:   Wed Dec 2 14:43:59 2020 +0100

tree-optimization/97630 - fix SLP cycle memory leak

This fixes SLP cycles leaking memory by maintaining a double-linked
list of allocatd SLP nodes we can zap when we free the alloc pool.

2020-12-02  Richard Biener  

PR tree-optimization/97630
* tree-vectorizer.h (_slp_tree::next_node,
_slp_tree::prev_node): New.
(vect_slp_init): Declare.
(vect_slp_fini): Likewise.
* tree-vectorizer.c (vectorize_loops): Call vect_slp_init/fini.
(pass_slp_vectorize::execute): Likewise.
* tree-vect-slp.c (vect_slp_init): New.
(vect_slp_fini): Likewise.
(slp_first_node): New global.
(_slp_tree::_slp_tree): Link node into the SLP tree list.
(_slp_tree::~_slp_tree): Delink node from the SLP tree list.

[Bug tree-optimization/97630] [11 Regression] SLP vectorizer leaks memory

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

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug target/98060] Failure to optimize cmp+setnb+add to cmp+sbb

[ubizjak at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Uroš Bizjak  ---
Created attachment 49662
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49662&action=edit
Testcases

[Bug target/98060] Failure to optimize cmp+setnb+add to cmp+sbb

[ubizjak at gmail dot com via Gcc-bugs]

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

Uroš Bizjak  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |ubizjak at gmail dot com
 Status|NEW |ASSIGNED

--- Comment #3 from Uroš Bizjak  ---
Created attachment 49663
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49663&action=edit
Proposed patch

Proposed patch does a couple of things:

a) introduces reversed adc and sbb insn patterns
b) introduces carry_flag_unset_operator
c) SUBSTANTIALLY cleans carry flag checking predicates
d) rearranges integer compares to allow more combines with carry flag
e) enhances ix86_unary_operator_ok to allow input memory operand for adc and
sbb

I don't think this patch is appropriate for stage-3+, let's wait for stage-1 to
reopen.

[Bug tree-optimization/98097] Missing warning about strcmp (char[4], "BARZ")

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

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

Martin Sebor  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2020-12-02
 Ever confirmed|0   |1

--- Comment #2 from Martin Sebor  ---
The failure to diagnose this is due to the warning using the same conservative
assumption as for the strcmp and strlen optimization.  The optimization assumes
that strlen(i->type) is bounded by the size of the object i points to if it can
be determined, or by MAX_OBJECT_SIZE if not.  (You'll recall the long,
contentious  discussion about this.)  This assumption is overly conservative
for warnings but because -Wstring-compare was an optimization first and the
warning only an afterthought (after testing showed the optimization didn't
trigger enough to matter), I didn't remember to decouple the two.  Let me do
that.

[Bug tree-optimization/98097] Missing warning about strcmp (char[4], "BARZ")

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
For optimizations indeed we shouldn't do any such assumptions, the fact that
the function is called with a particular pointer type doesn't necessarily mean
that is the dynamic type of the underlying object, and strcmp etc. functions
read or write the memory through char type which can alias anything.
But for warnings, we can indeed use the passed in type as a reasonable hint
what is ok and what is suspicious.

[Bug plugins/98059] [11 regression] Plugins don't compile with c++20

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

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

--- Comment #3 from Jonathan Wakely  ---
This change is incorrect, r11-532-g4b38d56dbac6742b038551a36ec80200313123a1 is
wrong to reject that assignment operator. The declarator-id is "operator=" and
so doesn't contain a template-id at all.

[Bug rtl-optimization/98037] ICE in dse.c:find_shift_sequence for large non-integer modes

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

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

--- Comment #2 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Richard Sandiford
:

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

commit r10-9108-gfb9ee3e7419178e6530c09b99272022d062b50f3
Author: Richard Sandiford 
Date:   Wed Dec 2 16:20:34 2020 +

dse: Cope with bigger-than-integer modes [PR98037]

dse.c:find_shift_sequence tries to represent a store and load
back as a shift right followed by a truncation.  It therefore
needs to find an integer mode in which to do the shift right.
The loop it uses has the form:

  FOR_EACH_MODE_FROM (new_mode_iter,
  smallest_int_mode_for_size (GET_MODE_BITSIZE
(read_mode)))

which implicitly assumes that read_mode has an equivalent integer mode.
As shown in the testcase, not all modes have such an integer mode.

This patch just makes the code start from the smallest integer mode and
skip modes that are too small.  The loop already breaks at the first
mode wider than word_mode.

gcc/
PR rtl-optimization/98037
* dse.c (find_shift_sequence): Iterate over all integers and
skip modes that are too small.

gcc/testsuite/
PR rtl-optimization/98037
* gcc.target/aarch64/sve/acle/general/pr98037.c: New test.

(cherry picked from commit f835e9f6562dda9c8a1384be2c9d4e45c112ed8e)

[Bug tree-optimization/97904] ICE with AArch64 SVE intrinsics

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

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

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

https://gcc.gnu.org/g:20fc59de1e21aaddc9ae08bc9d7e060df6706579

commit r10-9110-g20fc59de1e21aaddc9ae08bc9d7e060df6706579
Author: Richard Sandiford 
Date:   Wed Dec 2 16:20:36 2020 +

c++: Add missing verify_type_context call [PR97904]

When adding the verify_type_context target hook, I'd missed
a site that needs to check an array element type.

gcc/cp/
PR c++/97904
* pt.c (tsubst): Use verify_type_context to check the type
of an array element.

gcc/testsuite/
PR c++/97904
* g++.dg/ext/sve-sizeless-1.C: Add more template tests.
* g++.dg/ext/sve-sizeless-2.C: Likewise.

(cherry picked from commit d3585f5d0df47ffa453f5fe436fdf588301e5314)

[Bug plugins/98059] [11 regression] Plugins don't compile with c++20

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

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

--- Comment #4 from Jonathan Wakely  ---
Well, strictly speaking the change isn't wrong, and arguably it's an
improvement. But it's incorrect for GCC to require it in C++20 mode.

[Bug libstdc++/98098] New: std::call_once throws std::system_error in statically linked executable

[g.bonacci at libero dot it via Gcc-bugs]

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

Bug ID: 98098
   Summary: std::call_once throws std::system_error in statically
linked executable
   Product: gcc
   Version: 8.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: g.bonacci at libero dot it
  Target Milestone: ---

This program, based on std::call_once,

#include 
#include 
#include 

int count = 99;

void f() { count++; }

int main() {
std::once_flag once;
std::call_once(once, f);
std::call_once(once, f);
std::cout << count << '\n';
}

fails when linked statically:

$ c++ -pthread -static  -std=c++11 -Wall -Wextra call-once.cc ; ./a.out 
terminate called after throwing an instance of 'std::system_error'
  what():  Unknown error -1
Aborted

As far as I can tell, what triggers the error is this function called by
std::call_once:

static inline int
__gthread_active_p (void)
{
  static void *const __gthread_active_ptr
= __extension__ (void *) >HR_ACTIVE_PROXY;
  return __gthread_active_ptr != 0;
}

where GTHR_ACTIVE_PROXY is 0 when statically linked, and a pointer to
__GI___pthread_key_create when dynamically linked.

A similar program based on pthread_once():

#include 
#include 

int count = 99;

void f() { count++; }

int main() {
pthread_once_t once = PTHREAD_ONCE_INIT;
pthread_once(&once, f);
pthread_once(&once, f);
std::cout << count << '\n';
}

works as expected when linked statically:

$ c++ -pthread -static -std=c++11 -Wall -Wextra pthread-once.cc; ./a.out
100

Best regards,
  g.b

[Bug plugins/98059] [11 regression] Plugins don't compile with c++20

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

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

--- Comment #5 from Jakub Jelinek  ---
We were using:
template 
struct S {
private:
  S (const S &) = delete;
  S operator = (const S &) = delete;
};
With the change we are using:
template 
struct S {
private:
  S (const S &) = delete;
  S operator = (const S &) = delete;
};
We could be using also:
template 
struct S {
private:
  S (const S &) = delete;
  S operator = (const S &) = delete;
};
and it would be still valid C++20 (and is accepted), just the first form is
not, because after DR2237 one can't use S () for the constructor.

[Bug plugins/98059] [11 regression] Plugins don't compile with c++20

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

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

--- Comment #6 from Jonathan Wakely  ---
(In reply to CVS Commits from comment #2)
> Apparently vec.h doesn't build with -std=c++20/gnu++20, since the
> DR2237 r11-532 change.
> template 
> class auto_delete_vec
> {
> private:
>   auto_vec_delete (const auto_delete_vec &) = delete;


Ugh, I misread this as an assignment operator despite there being no operator=
there at all.

It's a copy ctor, and yes, it's invalid. Sorry.

> };
> which vec.h uses is invalid C++20, one needs to use
>   auto_vec_delete (const auto_delete_vec &) = delete;

The  is allowed on the parameter, it's only disallowed on the first one, so
this would be OK too:

 auto_vec_delete (const auto_delete_vec &) = delete;

But the macro can't generate that, and there's no reason to prefer it.

Sorry for the noise  :-(

[Bug plugins/98059] [11 regression] Plugins don't compile with c++20

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #7 from Jakub Jelinek  ---
Anyway, fixed now.

[Bug libstdc++/98098] std::call_once throws std::system_error in statically linked executable

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
See Bug 58909 which is exactly the same issue. Comment 2 has the solution.

This is no longer a problem with the GCC development trunk because
std::call_once doesn't use pthread_once.

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

[Bug libstdc++/58909] C++11's condition variables fail with static linking

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||g.bonacci at libero dot it

--- Comment #11 from Jonathan Wakely  ---
*** Bug 98098 has been marked as a duplicate of this bug. ***

[Bug libstdc++/68735] FAIL: libstdc++-prettyprinters/libfundts.cc print ab

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed|2017-12-17 00:00:00 |2020-12-02

--- Comment #4 from Jonathan Wakely  ---
The exceptions come from this line:

func = gdb.block_for_pc(int(mgr.cast(gdb.lookup_type('intptr_t'

This casts a function pointer to intptr_t and then tries to find the gdb.Block
corresponding to that address.

The GDB docs say that gdb.block_for_pc will return None, but it seems to throw
instead.

The same thing happens on powerpc64 linux (but not powerpc64le).

[Bug libstdc++/68735] FAIL: libstdc++-prettyprinters/libfundts.cc print ab

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

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

--- Comment #5 from Jonathan Wakely  ---
Ah, I think the problem is that Python 2 has a 42-bit int and so casting a big
endian pointer to int loses half the bits.

[Bug inline-asm/69899] gcc ICE on invalid code on x86_64-linux-gnu in "replace_reg"

[gscfq--- via Gcc-bugs]

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

G. Steinmetz  changed:

   What|Removed |Added

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

--- Comment #4 from G. Steinmetz  ---

None of the above test cases gives an ICE on x86_64-pc-linux-gnu,
even when gcc-11 is configured with --enable-checking=yes.

[Bug c/98099] New: ICE in gen_lowpart_common, at emit-rtl.c:1554

[gscfq--- via Gcc-bugs]

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

Bug ID: 98099
   Summary: ICE in gen_lowpart_common, at emit-rtl.c:1554
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Affects versions down to r6 :


$ cat z1.c
struct S { _Decimal128 a; };

_Decimal128 f (struct S x)
{
  return x.a;
}


$ gcc-11-20201129 -c z1.c -m32 -fsso-struct=big-endian
during RTL pass: expand
z1.c: In function 'f':
z1.c:5:11: internal compiler error: Segmentation fault
5 |   return x.a;
  |  ~^~
0xb49eaf crash_signal
../../gcc/toplev.c:330
0x825a2f gen_lowpart_common(machine_mode, rtx_def*)
../../gcc/emit-rtl.c:1554
0xafa9ec gen_lowpart_general(machine_mode, rtx_def*)
../../gcc/rtlhooks.c:48
0x83ef31 extract_bit_field_1
../../gcc/expmed.c:1826
0x83f7ff extract_bit_field(rtx_def*, poly_int<1u, unsigned long>, poly_int<1u,
unsigned long>, int, rtx_def*, machine_mode, machine_mode, bool, rtx_def**)
../../gcc/expmed.c:2119
0x84e8ca expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../gcc/expr.c:3
0x859e43 store_expr(tree_node*, rtx_def*, int, bool, bool)
../../gcc/expr.c:5859
0x85b206 expand_assignment(tree_node*, tree_node*, bool)
../../gcc/expr.c:5595
0x750c10 expand_gimple_stmt_1
../../gcc/cfgexpand.c:3901
0x750c10 expand_gimple_stmt
../../gcc/cfgexpand.c:3999
0x755e07 expand_gimple_basic_block
../../gcc/cfgexpand.c:6040
0x758476 execute
../../gcc/cfgexpand.c:6724

[Bug gcov-profile/96919] [GCOV] uncovered line of stack allocation while using virutal destructor

[bhavana.kilambi at blackfigtech dot com via Gcc-bugs]

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

--- Comment #9 from Bhavana Kilambi  
---
Hi, The problem seems to be with the code in add_line_counts() function in
gcov.c. Specifically with this statement - 
line->blocks.push_back (block);

This line is present inside the line!= NULL condition while in gcc7 it is
within the flag_all_blocks condition. Since all the lines in the function
satisfy the condition of line != NULL, this push_back() function gets executed
almost everytime. Also, looking at the way the tool is built, initially the
relevant data structures would have already been created and in place in the
process_file() and other functions while the generate_results() function (which
in turn calls add_line_counts() function) is supposed to technically only
read/traverse the appropriate data structures and update the coverage
information.

After removing the above line, the coverage for the testcase in this bug is
100% as required with the -a and -m flags. 
Also, tested the testcase mentioned in bug #79891. It also shows the expected
coverage output. 

I have attached the patch in this bug.

Output after the patch for the testcase specified in this bug : 

gcov main.cpp -a

File 'hello.h'
Lines executed:0.00% of 2
Creating 'hello.h.gcov'

File 'main.cpp'
Lines executed:100.00% of 4
Creating 'main.cpp.gcov'

Lines executed:66.67% of 6

[Bug c/98100] New: ICE in expand_debug_locations, at cfgexpand.c:5610

[gscfq--- via Gcc-bugs]

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

Bug ID: 98100
   Summary: ICE in expand_debug_locations, at cfgexpand.c:5610
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Affects versions down to r7 :


$ cat z1.c
__attribute__((target_clones("default","sse2")))
void f ()
{
  __attribute__((__vector_size__(4 * sizeof(float int b = {};
}


$ gcc-11-20201129 -c z1.c -O2 -mgeneral-regs-only -fvar-tracking-assignments
during RTL pass: expand
z1.c: In function 'f.sse2.0':
z1.c:2:6: internal compiler error: in expand_debug_locations, at
cfgexpand.c:5610
2 | void f ()
  |  ^
0x759573 expand_debug_locations
../../gcc/cfgexpand.c:5606
0x759573 execute
../../gcc/cfgexpand.c:6727

[Bug gcov-profile/96919] [GCOV] uncovered line of stack allocation while using virutal destructor

[bhavana.kilambi at blackfigtech dot com via Gcc-bugs]

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

--- Comment #10 from Bhavana Kilambi  
---
Created attachment 49664
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49664&action=edit
Removes the push_back() statement

[Bug c++/98101] New: ICE in mark_reachable_handlers, at tree-eh.c:4033

[gscfq--- via Gcc-bugs]

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

Bug ID: 98101
   Summary: ICE in mark_reachable_handlers, at tree-eh.c:4033
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Affects versions down to at least r5, only at -O0 :
(used options affect also several testsuite files)
(under the hood maybe related to pr59507/pr88640)


$ cat z1.cc
struct A { virtual ~A(); };
struct B { A a[1]; } b;


$ g++-11-20201129 -c z1.cc -fnon-call-exceptions -fvtable-verify=std -O2
$
$ g++-11-20201129 -c z1.cc -fnon-call-exceptions -fvtable-verify=std
during GIMPLE pass: ehcleanup
z1.cc: In destructor 'B::~B()':
z1.cc:2:8: internal compiler error: in mark_reachable_handlers, at
tree-eh.c:4033
2 | struct B { A a[1]; } b;
  |^
0xcd644d mark_reachable_handlers
../../gcc/tree-eh.c:4033
0xcd6482 remove_unreachable_handlers
../../gcc/tree-eh.c:4080
0xcda601 execute_cleanup_eh_1
../../gcc/tree-eh.c:4783
0xcda601 execute
../../gcc/tree-eh.c:4850

---

z1.cc: In destructor 'B::~B()':
z1.cc:2:8: error: statement marked for throw in middle of block
2 | struct B { A a[1]; } b;
  |^
# VUSE <.MEM_7>
_13 = _12->_vptr.A;
during GIMPLE pass: vtable-verify
z1.cc:2:8: internal compiler error: verify_gimple failed
0xfcaaf4 verify_gimple_in_cfg(function*, bool)
../../gcc/tree-cfg.c:5467
0xe867ee execute_function_todo
../../gcc/passes.c:2039
0xe87692 execute_todo
../../gcc/passes.c:2093

[Bug c++/98102] New: [9/10/11 Regression] ICE tree check: expected block, have function_decl in change_scope, at final.c:1480

[gscfq--- via Gcc-bugs]

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

Bug ID: 98102
   Summary: [9/10/11 Regression] ICE tree check: expected block,
have function_decl in change_scope, at final.c:1480
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

This combination of options affects several files
from gcc/testsuite at -O2+, and goes back to r7 :


$ g++-6 -c pr61654.C -g -O2 -fvtable-verify=std -fopenacc
$ g++-11-20201129 -c pr61654.C -g -O1 -fvtable-verify=std -fopenacc
$
$ g++-11-20201129 -c pr61654.C -g -O2 -fvtable-verify=std -fopenacc
during RTL pass: final
pr61654.C: In function '(static initializers for pr61654.C)':
pr61654.C:17:12: internal compiler error: tree check: expected block, have
function_decl in change_scope, at final.c:1480
   17 |   return a ('\0');
  |  ~~^~
0x64cac4 tree_check_failed(tree_node const*, char const*, int, char const*,
...)
../../gcc/tree.c:9810
0xbc4b19 tree_check(tree_node*, char const*, int, char const*, tree_code)
../../gcc/tree.h:3331
0xbc4b19 change_scope
../../gcc/final.c:1480
0xbce0c0 reemit_insn_block_notes
../../gcc/final.c:1581
0xbce0c0 final_start_function_1
../../gcc/final.c:1784
0xbce609 rest_of_handle_final
../../gcc/final.c:4675
0xbce609 execute
../../gcc/final.c:4754

[Bug c++/98101] ICE in mark_reachable_handlers, at tree-eh.c:4033

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

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

Marek Polacek  changed:

   What|Removed |Added

   Last reconfirmed||2020-12-02
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
 CC||mpolacek at gcc dot gnu.org

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

[Bug c++/98103] New: [10/11 Regression] ICE tree check: expected tree that contains 'decl minimal' structure, have 'integer_cst' in cxx_eval_dynamic_cast_fn, at cp/constexpr.c:2003

[gscfq--- via Gcc-bugs]

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

Bug ID: 98103
   Summary: [10/11 Regression] ICE tree check: expected tree that
contains 'decl minimal' structure, have 'integer_cst'
in cxx_eval_dynamic_cast_fn, at cp/constexpr.c:2003
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Using testfile gcc/testsuite/g++.dg/cpp2a/constexpr-dynamic17.C
This changed between 20191215 and 20200105 :


$ g++-11-20201129 -c constexpr-dynamic17.C -std=gnu++2a -fsanitize=vptr
constexpr-dynamic17.C:20:13:   in 'constexpr' expansion of '((D*)(&
d))->D::D()'
constexpr-dynamic17.C:12:35:   in 'constexpr' expansion of
'((D*)this)->D::.B::B((&(&((D*)this)->D::)->A::),
(&((D*)this)->D::))'
constexpr-dynamic17.C:20:13: internal compiler error: tree check: expected tree
that contains 'decl minimal' structure, have 'integer_cst' in
cxx_eval_dynamic_cast_fn, at cp/constexpr.c:2003
   20 | constexpr D d;
  | ^
0x64d1b5 tree_contains_struct_check_failed(tree_node const*,
tree_node_structure_enum, char const*, int, char const*)
../../gcc/tree.c:9984
0x6ebbe3 contains_struct_check(tree_node*, tree_node_structure_enum, char
const*, int, char const*)
../../gcc/tree.h:3445
0x6ebbe3 cxx_eval_dynamic_cast_fn
../../gcc/cp/constexpr.c:2003
0x6ebbe3 cxx_eval_call_expression
../../gcc/cp/constexpr.c:2421
0x6eec61 cxx_eval_constant_expression
../../gcc/cp/constexpr.c:5866
0x6ed3de cxx_eval_constant_expression
../../gcc/cp/constexpr.c:6358
0x6ed3de cxx_eval_constant_expression
../../gcc/cp/constexpr.c:6358
0x6eeb2a cxx_eval_constant_expression
../../gcc/cp/constexpr.c:6305
0x6ed39a cxx_eval_constant_expression
../../gcc/cp/constexpr.c:6176
0x6eebda cxx_eval_constant_expression
../../gcc/cp/constexpr.c:6044
0x6ee1ee cxx_eval_statement_list
../../gcc/cp/constexpr.c:5436
0x6ee1ee cxx_eval_constant_expression
../../gcc/cp/constexpr.c:6502
0x6eea4e cxx_eval_constant_expression
../../gcc/cp/constexpr.c:6537
0x6ee1ee cxx_eval_statement_list
../../gcc/cp/constexpr.c:5436
0x6ee1ee cxx_eval_constant_expression
../../gcc/cp/constexpr.c:6502
0x6eb576 cxx_eval_call_expression
../../gcc/cp/constexpr.c:2687
0x6eec61 cxx_eval_constant_expression
../../gcc/cp/constexpr.c:5866
0x6ed39a cxx_eval_constant_expression
../../gcc/cp/constexpr.c:6176
0x6eebda cxx_eval_constant_expression
../../gcc/cp/constexpr.c:6044
0x6ee1ee cxx_eval_statement_list
../../gcc/cp/constexpr.c:5436

[Bug c++/98103] [10/11 Regression] ICE tree check: expected tree that contains 'decl minimal' structure, have 'integer_cst' in cxx_eval_dynamic_cast_fn, at cp/constexpr.c:2003

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

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

Marek Polacek  changed:

   What|Removed |Added

   Last reconfirmed||2020-12-02
   Keywords||ice-on-invalid-code
 Ever confirmed|0   |1
 CC||mpolacek at gcc dot gnu.org
   Priority|P3  |P2
 Status|UNCONFIRMED |NEW
   Target Milestone|--- |10.3

--- Comment #1 from Marek Polacek  ---
ICE confirmed.

[Bug ipa/98082] [11 Regression] ICE in set_rtl, at cfgexpand.c:178 since r11-3257-g225a08220e444371

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #6 from Jakub Jelinek  ---
(In reply to Richard Biener from comment #5)
> Note the GIMPLE we expand from looks weird:
> 
> struct GoodIterD.2094 operator+ (intD.9 D.2129, struct GoodIterD.2094 &
> restrict D.2130)
> {
>[local count: 1]:
>   *_2(D) = operator- (_3(D), _4(D)); [return slot optimization] [tail call]
>   return _2(D);
> 
> somehow the inlined(?) thunk has some indirection exposed and the RSO
> looks misplaced.

How else we can express calls returning through hidden reference at GIMPLE?
I believe the above is effectively telling that the thunk should pass _2(D) as
the hidden return slot pointer.

If I use
struct S { S (); S (const S &); };
int baz (int);

S
foo ()
{
  baz (baz (baz (baz (baz (0);
  baz (baz (baz (baz (baz (1);
  baz (baz (baz (baz (baz (2);
  baz (baz (baz (baz (baz (3);
  baz (baz (baz (baz (baz (4);
  baz (baz (baz (baz (baz (5);
  baz (baz (baz (baz (baz (6);
  baz (baz (baz (baz (baz (7);
  baz (baz (baz (baz (baz (8);
  baz (baz (baz (baz (baz (9);
  return S ();
}

S
bar ()
{
  baz (baz (baz (baz (baz (0);
  baz (baz (baz (baz (baz (1);
  baz (baz (baz (baz (baz (2);
  baz (baz (baz (baz (baz (3);
  baz (baz (baz (baz (baz (4);
  baz (baz (baz (baz (baz (5);
  baz (baz (baz (baz (baz (6);
  baz (baz (baz (baz (baz (7);
  baz (baz (baz (baz (baz (8);
  baz (baz (baz (baz (baz (9);
  return S ();
}

instead such that it is at -O2 ipa-icf optimized and is not inlined back, then
that
struct S bar ()
{
   [local count: 1073741824]:
  *_2(D) = foo (); [return slot optimization] [tail call]
  return _2(D);

}
appears in *.optimized dump, yet we apparently don't tail call optimize it even
when we should:
_Z3barv:
.LFB3:
.cfi_startproc
pushq   %r12
.cfi_def_cfa_offset 16
.cfi_offset 12, -16
movq%rdi, %r12
call_Z3foov
movq%r12, %rax
popq%r12
.cfi_def_cfa_offset 8
ret
.cfi_endproc
.LFE3:
.size   _Z3barv, .-_Z3barv
For -O0, perhaps IPA-ICF should be really disabled if !optimize no matter what
the user said, as we e.g. can't really expect any attempts on emitting the tail
calls in that case.  But it wouldn't hurt to fix expansion so that it doesn't
ICE on it too.

[Bug c++/98072] [9/10 Regression] ICE in cp_parser_omp_var_list_no_open, at cp/parser.c:34843

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

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[9/10/11 Regression] ICE in |[9/10 Regression] ICE in
   |cp_parser_omp_var_list_no_o |cp_parser_omp_var_list_no_o
   |pen, at cp/parser.c:34843   |pen, at cp/parser.c:34843
   Target Milestone|11.0|9.4

--- Comment #5 from Jakub Jelinek  ---
Fixed on the trunk, needs to be backported to release branches where it
regressed since the latest released minor versions.

[Bug libstdc++/68735] FAIL: libstdc++-prettyprinters/libfundts.cc print ab

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

[Bug libstdc++/68735] FAIL: libstdc++-prettyprinters/libfundts.cc print ab

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

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

--- Comment #6 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #5)
> Ah, I think the problem is that Python 2 has a 42-bit int

32-bit of course.

But there's also something else going on. I have a patch.

[Bug target/97457] [10 Regression] SVE: wrong code since r10-4752-g2d56600c

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

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

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

https://gcc.gnu.org/g:75a5af680a1788ba844902fd0681958da8e2a4ce

commit r10-9112-g75a5af680a1788ba844902fd0681958da8e2a4ce
Author: Richard Sandiford 
Date:   Wed Dec 2 18:39:24 2020 +

value-range: Give up on POLY_INT_CST ranges [PR97457]

This PR shows another problem with calculating value ranges for
POLY_INT_CSTs.  We have:

  ivtmp_76 = ASSERT_EXPR  POLY_INT_CST [9,
4294967294]>

where the VQ coefficient is unsigned but is effectively acting
as a negative number.  We wrongly give the POLY_INT_CST the range:

  [9, INT_MAX]

and things go downhill from there: later iterations of the unrolled
epilogue are wrongly removed as dead.

I guess this is the final nail in the coffin for doing VRP on
POLY_INT_CSTs.  For other similarly exotic testcases we could have
overflow for any coefficient, not just those that could be treated
as contextually negative.

Testing TYPE_OVERFLOW_UNDEFINED doesn't seem like an option because we
couldn't handle warn_strict_overflow properly.  At this stage we're
just recording a range that might or might not lead to strict-overflow
assumptions later.

It still feels like we should be able to do something here, but for
now removing the code seems safest.  It's also telling that there
are no testsuite failures on SVE from doing this.

gcc/
PR tree-optimization/97457
* value-range.cc (irange::set): Don't decay POLY_INT_CST ranges
to integer ranges.

gcc/testsuite/
PR tree-optimization/97457
* gcc.dg/vect/pr97457.c: New test.

(cherry picked from commit 54ef7701a9dec8c923a12d1983f8a051ba88a7b9)

[Bug rtl-optimization/98037] ICE in dse.c:find_shift_sequence for large non-integer modes

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

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

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

--- Comment #3 from rsandifo at gcc dot gnu.org  
---
Fixed on trunk and GCC 10 branch.

[Bug libstdc++/68735] FAIL: libstdc++-prettyprinters/libfundts.cc print ab

[dave.anglin at bell dot net via Gcc-bugs]

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

--- Comment #7 from dave.anglin at bell dot net ---
Currently, we also have the following two additional fails:

FAIL: libstdc++-prettyprinters/91997.cc print a
FAIL: libstdc++-prettyprinters/91997.cc print a

[Bug tree-optimization/97904] ICE with AArch64 SVE intrinsics

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

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

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

--- Comment #7 from rsandifo at gcc dot gnu.org  
---
Fixed on trunk and GCC 10 branch.

[Bug target/97457] [10 Regression] SVE: wrong code since r10-4752-g2d56600c

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

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

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

--- Comment #6 from rsandifo at gcc dot gnu.org  
---
Fixed on trunk and GCC 10 branch.