[Bug middle-end/104260] [12 Regression] Misplaced waccess3 pass

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

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

--- Comment #2 from Richard Biener  ---
There is also

  PUSH_INSERT_PASSES_WITHIN (pass_build_ssa_passes)
...
 NEXT_PASS (pass_rebuild_cgraph_edges);
 NEXT_PASS (pass_warn_access, /*early=*/true);
  POP_INSERT_PASSES ()

where pass_rebuild_cgraph_edges should be last.  Not sure whether you
put warn_access behind ubsan for a reason, otherwise I'd put it next
to the other warning passes.

[Bug target/104261] gcc uses fildq and fistpq on unaligned addesss for atomic accesses

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

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

Richard Biener  changed:

   What|Removed |Added

 Target|i?86|i?86-*-*
   Last reconfirmed||2022-01-28
 Ever confirmed|0   |1
 CC||jsm28 at gcc dot gnu.org
   Keywords||wrong-code
 Status|UNCONFIRMED |NEW

--- Comment #2 from Richard Biener  ---
Confirmed, the following fails

struct s {
unsigned misalign;
struct { _Atomic unsigned long long a; };
};
_Static_assert (__alignof__ (struct s) == sizeof (unsigned long long));

[Bug debug/104263] [10/11/12 Regression] '-fcompare-debug' failure (length) w/ -O2 -fnon-call-exceptions -fno-inline-small-functions

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |10.4
 Ever confirmed|0   |1
   Last reconfirmed||2022-01-28
   Priority|P3  |P2
 Status|UNCONFIRMED |NEW

--- Comment #1 from Richard Biener  ---
Confirmed.  Caused by store-merging:

-Coalescing successful!
-Merged into 1 stores
-New sequence of 1 stores to replace old one of 2 stores
-Merging successful!
 __attribute__((returns_twice, pure))
 int foo ()
 {
[local count: 1073741824]:
+  # DEBUG BEGIN_STMT
+  # DEBUG INLINE_ENTRY bar
+  # DEBUG BEGIN_STMT
+  # DEBUG BEGIN_STMT
+  n = 0;
+  # DEBUG BEGIN_STMT
+  # DEBUG a => 0
+  # DEBUG BEGIN_STMT

[local count: 1073312329]:
-  MEM[(int *)&n] = 1;
+  n = 1;
+  # DEBUG BEGIN_STMT

[local count: 1073741824]:
+  # DEBUG BEGIN_STMT
   return 0;

[local count: 429496]:

so we fail to merge n = 0 and n = 1 with -g.

[Bug c++/104266] New: Temporaries with protected destructor are erroneously permitted

[fchelnokov at gmail dot com via Gcc-bugs]

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

Bug ID: 104266
   Summary: Temporaries with protected destructor are erroneously
permitted
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fchelnokov at gmail dot com
  Target Milestone: ---

This is invalid code currently accepted by GCC:
```
struct A {
protected:
  ~A() { }
};

struct B : A {};

int main() {
B b{};
}
```
but rejected in Clang and MSVC, because `B b{}` during aggregate initialization
implicitly creates a temporary `A{}`, which is not allowed in the context.

Demo: https://gcc.godbolt.org/z/Yehch5PzK

[Bug tree-optimization/104263] [10/11/12 Regression] '-fcompare-debug' failure (length) w/ -O2 -fnon-call-exceptions -fno-inline-small-functions

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

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

--- Comment #2 from Richard Biener  ---
Note we have an abnormal edge from BB2 to the abnormal dispatcher (missed
optimization, we should get rid of it), but the last stmts in the abnormal
edge sources are debug vs. non-debug stmts (but neither are calls which
are the only sources of abnormal control flow - thus the missed optimization,
to be rectified in CFG cleanup I guess or some pass missing to call
abnormal cleanup - that would be IPA inlining in this case).

int foo ()
{
;;   basic block 2, loop depth 0
;;pred:   ENTRY
  # DEBUG BEGIN_STMT
  # DEBUG INLINE_ENTRY bar
  # DEBUG BEGIN_STMT
  # DEBUG BEGIN_STMT
  n = 0;
  # DEBUG BEGIN_STMT
  # DEBUG a => 0
  # DEBUG BEGIN_STMT
;;succ:   3
;;5

;;   basic block 3, loop depth 0
;;pred:   2
  n = 1;
  # DEBUG BEGIN_STMT
;;succ:   4

;;   basic block 4, loop depth 0
;;pred:   3
;;5
  # DEBUG BEGIN_STMT
  return 0;
;;succ:   EXIT

;;   basic block 5, loop depth 0
;;pred:   2
  .ABNORMAL_DISPATCHER (0);
;;succ:   4

[Bug c++/103790] internal compiler error: Segmentation fault when playing with coroutine

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

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

--- Comment #6 from CVS Commits  ---
The master branch has been updated by Andre Vehreschild :

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

commit r12-6910-gc9c48ab7bad9fe5e096076e56a60ce0a5a2b65f7
Author: Andre Vehreschild 
Date:   Fri Jan 28 09:20:23 2022 +0100

Prevent malicious descriptor stacking for scalar components.

gcc/fortran/ChangeLog:

PR fortran/103790
* trans-array.cc (structure_alloc_comps): Prevent descriptor
stacking for non-array data; do not broadcast caf-tokens.
* trans-intrinsic.cc (conv_co_collective): Prevent generation
of unused descriptor.

gcc/testsuite/ChangeLog:

PR fortran/103790
* gfortran.dg/coarray_collectives_18.f90: New test.

[Bug tree-optimization/104263] [10/11/12 Regression] '-fcompare-debug' failure (length) w/ -O2 -fnon-call-exceptions -fno-inline-small-functions

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
I'll have a look.

[Bug tree-optimization/104263] [10/11/12 Regression] '-fcompare-debug' failure (length) w/ -O2 -fnon-call-exceptions -fno-inline-small-functions since r10-3575-g629387a6586a7531

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

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

Martin Liška  changed:

   What|Removed |Added

Summary|[10/11/12 Regression]   |[10/11/12 Regression]
   |'-fcompare-debug' failure   |'-fcompare-debug' failure
   |(length) w/ -O2 |(length) w/ -O2
   |-fnon-call-exceptions   |-fnon-call-exceptions
   |-fno-inline-small-functions |-fno-inline-small-functions
   ||since
   ||r10-3575-g629387a6586a7531
 CC||ebotcazou at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org

--- Comment #4 from Martin Liška  ---
Started with r10-3575-g629387a6586a7531.

[Bug tree-optimization/104265] Missed vectorization in 526.blender_r

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

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org
   Last reconfirmed||2022-01-28
 Status|UNCONFIRMED |NEW
 Blocks||26163
 Ever confirmed|0   |1


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
[Bug 26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)

[Bug tree-optimization/104267] New: [12 Regression] ICE in vect_schedule_slp_node, at tree-vect-slp.c:7144 since r12-5613-g32ede1083fad4b68

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

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

Bug ID: 104267
   Summary: [12 Regression] ICE in vect_schedule_slp_node, at
tree-vect-slp.c:7144 since r12-5613-g32ede1083fad4b68
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: richard.sandiford at arm dot com
  Target Milestone: ---

I see the following ICE:

$ gfortran /home/marxin/Programming/gcc/gcc/testsuite/gfortran.dg/pr91003.f90
-Ofast -mavx512f -fsignaling-nans -c
f951: Warning: ‘-fassociative-math’ disabled; other options take precedence
during GIMPLE pass: vect
/home/marxin/Programming/gcc/gcc/testsuite/gfortran.dg/pr91003.f90:3:20:

3 |   SUBROUTINE FOO(N, A, B, C, D, E, F, G)
  |^
internal compiler error: in vect_schedule_slp_node, at tree-vect-slp.cc:7172
0x7e39cd vect_schedule_slp_node
/home/marxin/Programming/gcc/gcc/tree-vect-slp.cc:7172
0x1282b33 vect_schedule_scc
/home/marxin/Programming/gcc/gcc/tree-vect-slp.cc:7470
0x12828b1 vect_schedule_scc
/home/marxin/Programming/gcc/gcc/tree-vect-slp.cc:7451
0x12828b1 vect_schedule_scc
/home/marxin/Programming/gcc/gcc/tree-vect-slp.cc:7451
0x12828b1 vect_schedule_scc
/home/marxin/Programming/gcc/gcc/tree-vect-slp.cc:7451
0x12828b1 vect_schedule_scc
/home/marxin/Programming/gcc/gcc/tree-vect-slp.cc:7451
0x12828b1 vect_schedule_scc
/home/marxin/Programming/gcc/gcc/tree-vect-slp.cc:7451
0x12828b1 vect_schedule_scc
/home/marxin/Programming/gcc/gcc/tree-vect-slp.cc:7451
0x128317f vect_schedule_slp(vec_info*, vec<_slp_instance*, va_heap, vl_ptr>
const&)
/home/marxin/Programming/gcc/gcc/tree-vect-slp.cc:7587
0x1258234 vect_transform_loop(_loop_vec_info*, gimple*)
/home/marxin/Programming/gcc/gcc/tree-vect-loop.cc:9753
0x128f5dd vect_transform_loops
/home/marxin/Programming/gcc/gcc/tree-vectorizer.cc:1003
0x128f5dd try_vectorize_loop_1
/home/marxin/Programming/gcc/gcc/tree-vectorizer.cc:1133
0x128f5dd try_vectorize_loop
/home/marxin/Programming/gcc/gcc/tree-vectorizer.cc:1162
0x128fe14 execute
/home/marxin/Programming/gcc/gcc/tree-vectorizer.cc:1278

Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug tree-optimization/104267] [12 Regression] ICE in vect_schedule_slp_node, at tree-vect-slp.c:7144 since r12-5613-g32ede1083fad4b68

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

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

Martin Liška  changed:

   What|Removed |Added

   Target Milestone|--- |12.0
   Last reconfirmed||2022-01-28
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Priority|P3  |P1

[Bug tree-optimization/104263] [10/11/12 Regression] '-fcompare-debug' failure (length) w/ -O2 -fnon-call-exceptions -fno-inline-small-functions since r10-3575-g629387a6586a7531

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

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

--- Comment #5 from Richard Biener  ---
OK, so with the abnormal edges the issue is that DCE1 removes the recursive
call to foo () (because the function is "wrongly" pure) which causes us to
clear
cfun->calls_setjmp but then any further gimple_purge_dead_abnormal_call_edges
will simply do nothing (as premature optimization one could guess).  So the
bug would be that we fail to wipe all abnormal edges when a function no
longer calls setjmp or has a nonlocal label.

The easiest fix is to remove the premature optimization in
gimple_purge_dead_abnormal_call_edges.  That leaves the abnormal edges from
bar() even after DCE removes the recursive call to foo() (still a missed
optimization) but it at least will not leave us with stray abnormal edges
from non-call / non-computed goto stmts in the IL.

It also resolves the compare-debug failure for this testcase (but maybe there's
a latent issue in store-merging still).

[Bug tree-optimization/104263] [10/11/12 Regression] '-fcompare-debug' failure (length) w/ -O2 -fnon-call-exceptions -fno-inline-small-functions since r10-3575-g629387a6586a7531

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

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

--- Comment #6 from Richard Biener  ---
I'm testing a patch to gimple_purge_dead_abnormal_call_edges, leaving the
store-merging issue to Jakub.

[Bug tree-optimization/104267] [12 Regression] ICE in vect_schedule_slp_node, at tree-vect-slp.c:7144 since r12-5613-g32ede1083fad4b68

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #1 from Richard Biener  ---
I will have a look.

[Bug ada/104258] [11/12 regression] wrong operator for universal_integer operands in instance

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

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Eric Botcazou :

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

commit r12-6912-gb16a3dea1d1bfa3dde556af84b3592140320b605
Author: Eric Botcazou 
Date:   Fri Jan 28 11:04:06 2022 +0100

Fix wrong operator for universal_integer operands in instance

This is a regression present on mainline and 11 branch: the transformation
applied during expansion by Narrow_Large_Operation would incorrectly
perform
name resolution for the operator again.

gcc/ada/
PR ada/104258
* exp_ch4.adb (Narrow_Large_Operation): Also copy the entity, if
any, when rewriting the operator node.

gcc/testsuite/
* gnat.dg/generic_comp.adb: New test.

[Bug ada/104258] [11/12 regression] wrong operator for universal_integer operands in instance

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

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

--- Comment #4 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Eric Botcazou
:

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

commit r11-9522-g0d87092f8897fe6e0a86a566bf3c6a924db152c6
Author: Eric Botcazou 
Date:   Fri Jan 28 11:04:06 2022 +0100

Fix wrong operator for universal_integer operands in instance

This is a regression present on mainline and 11 branch: the transformation
applied during expansion by Narrow_Large_Operation would incorrectly
perform
name resolution for the operator again.

gcc/ada/
PR ada/104258
* exp_ch4.adb (Narrow_Large_Operation): Also copy the entity, if
any, when rewriting the operator node.

gcc/testsuite/
* gnat.dg/generic_comp.adb: New test.

[Bug ada/104258] [11/12 regression] wrong operator for universal_integer operands in instance

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

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #5 from Eric Botcazou  ---
Thanks for reporting the problem.

[Bug target/104268] New: 390: inefficient vec_popcnt for 16-bit for z13

[jens.seifert at de dot ibm.com via Gcc-bugs]

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

Bug ID: 104268
   Summary: 390: inefficient vec_popcnt for 16-bit for z13
   Product: gcc
   Version: 10.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jens.seifert at de dot ibm.com
  Target Milestone: ---

#include 

vector unsigned short popcnt(vector unsigned short a)
{
   return vec_popcnt(a);
}

Generates with -march=z13

_Z6popcntDv8_t:
.LFB1:
.cfi_startproc
vzero   %v0
vpopct  %v24,%v24,0
vleib   %v0,8,7
vsrlb   %v0,%v24,%v0
vab %v24,%v24,%v0
vgbm%v0,21845
vn  %v24,%v24,%v0
br  %r14
.cfi_endproc


Optimal sequence would be:
vector unsigned short popcnt_opt(vector unsigned short a)
{
   vector unsigned short r = (vector unsigned short)vec_popcnt((vector unsigned
char)a);
   vector unsigned short b = vec_rli(r, 8);
   r = r + b;
   r = r >> 8;
   return r;
}

_Z10popcnt_optDv8_t:
.LFB3:
.cfi_startproc
vpopct  %v24,%v24,0
verllh  %v0,%v24,8
vah %v24,%v0,%v24
vesrlh  %v24,%v24,8
br  %r14
.cfi_endproc

[Bug tree-optimization/104267] [12 Regression] ICE in vect_schedule_slp_node, at tree-vect-slp.c:7144 since r12-5613-g32ede1083fad4b68

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

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

--- Comment #2 from Richard Biener  ---
pr91003.f90:8:13: note:   -->vectorizing SLP node starting from: _61 =
.COND_MUL (_202, j_42(D), bnrm2_60(D), 0.0);
pr91003.f90:8:13: missed:   could not find an appropriate vector mask type.
pr91003.f90:8:13: note:   -->vectorizing SLP node starting from: M.6_62 =
.COND_MAX (_202, _36, _61, 0.0);

I can't find where we actually verify we can use .COND_MUL for this node.  Huh.

Note it's

pr91003.f90:8:13: note:   node 0x426e8c8 (max_nunits=16, refcnt=1)
pr91003.f90:8:13: note:   op template: _61 = .COND_MUL (_202, j_42(D),
bnrm2_60(D), 0.0);
pr91003.f90:8:13: note: stmt 0 _61 = .COND_MUL (_202, j_42(D),
bnrm2_60(D), 0.0);
pr91003.f90:8:13: note: stmt 1 _61 = .COND_MUL (_202, j_42(D),
bnrm2_60(D), 0.0);
pr91003.f90:8:13: note: children 0x426e950 0x426e9d8 0x426ea60
0x426eae8
pr91003.f90:8:13: note:   node (external) 0x426e950 (max_nunits=1, refcnt=1)
pr91003.f90:8:13: note: { _202, _202 }
pr91003.f90:8:13: note:   node (external) 0x426e9d8 (max_nunits=1, refcnt=1)
pr91003.f90:8:13: note: { j_42(D), j_42(D) }
pr91003.f90:8:13: note:   node (external) 0x426ea60 (max_nunits=1, refcnt=1)
pr91003.f90:8:13: note: { bnrm2_60(D), bnrm2_60(D) }
pr91003.f90:8:13: note:   node (constant) 0x426eae8 (max_nunits=1, refcnt=1)
pr91003.f90:8:13: note: { 0.0, 0.0 }

so _all_ childs are external/constant.  I think the issue here is that
we pushed vector(16) real(kind=4) as vector type for this external def
but we are expecting a VECTOR_BOOLEAN_TYPE_P here.

diff --git a/gcc/tree-vect-stmts.cc b/gcc/tree-vect-stmts.cc
index 824ebb6354b..000a0f4b47e 100644
--- a/gcc/tree-vect-stmts.cc
+++ b/gcc/tree-vect-stmts.cc
@@ -3444,7 +3444,9 @@ vectorizable_call (vec_info *vinfo,
 {
   if (slp_node)
for (i = 0; i < nargs; ++i)
- if (!vect_maybe_update_slp_op_vectype (slp_op[i], vectype_in))
+ if (!vect_maybe_update_slp_op_vectype (slp_op[i],
+vectypes[i]
+? vectypes[i] : vectype_in))
{
  if (dump_enabled_p ())
dump_printf_loc (MSG_MISSED_OPTIMIZATION, vect_location,

fixes this.

[Bug tree-optimization/104263] [10/11/12 Regression] '-fcompare-debug' failure (length) w/ -O2 -fnon-call-exceptions -fno-inline-small-functions since r10-3575-g629387a6586a7531

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #7 from Jakub Jelinek  ---
Created attachment 52309
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52309&action=edit
gcc12-pr104263.patch

Untested fix for the store-merging bug.

[Bug tree-optimization/104263] [10/11/12 Regression] '-fcompare-debug' failure (length) w/ -O2 -fnon-call-exceptions -fno-inline-small-functions since r10-3575-g629387a6586a7531

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

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

--- Comment #8 from Eric Botcazou  ---
> Untested fix for the store-merging bug.

FWIW it looks good to me, thanks!

[Bug lto/104237] [11/12 Regression] Emitted binary code changes when -g is enabled at -O1 -flto and optimize attribute since r11-3126-ga8f9b4c54cc35062

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

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

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

https://gcc.gnu.org/g:430dca620fa3d03e53f6771a2b61d3f0ebb73756

commit r12-6914-g430dca620fa3d03e53f6771a2b61d3f0ebb73756
Author: Jakub Jelinek 
Date:   Fri Jan 28 11:48:18 2022 +0100

cfgrtl: Fix up locus comparison in unique_locus_on_edge_between_p
[PR104237]

The testcase in the PR (not included for the testsuite because we don't
have an (easy) way to -fcompare-debug LTO, we'd need 2
compilations/linking,
one with -g and one with -g0 and -fdump-rtl-final= at the end of lto1
and compare that) has different code generation for -g vs. -g0.

The difference appears during expansion, where we have a goto_locus
that is at -O0 compared to the INSN_LOCATION of the previous and next insn
across an edge.  With -g0 the locations are equal and so no nop is added.
With -g the locations aren't equal and so a nop is added holding that
location.

The reason for the different location is in the way how we stream in
locations by lto1.
We have lto_location_cache::apply_location_cache that is called with some
set of expanded locations, qsorts them, creates location_t's for those
and remembers the last expanded location.
lto_location_cache::input_location_and_block when read in expanded_location
is equal to the last expanded location just reuses the last location_t
(or adds/changes/removes LOCATION_BLOCK in it), when it is not queues
it for next apply_location_cache.  Now, when streaming in -g input, we can
see extra locations that don't appear with -g0, and if we are unlucky
enough, those can be sorted last during apply_location_cache and affect
what locations are used from the single entry cache next.
In particular, second apply_location_cache with non-empty loc_cache in
the testcase has 14 locations with -g0 and 16 with -g and those 2 extra
ones sort both last (they are the same).  The last one from -g0 then
appears to be input_location_and_block sourced again, for -g0 triggers
the single entry cache, while for -g it doesn't and so apply_location_cache
will create for it another location_t with the same content.

The following patch fixes it by comparing everything we care about the
location instead (well, better in addition) to a simple location_t ==
location_t check.  I think we don't care about the sysp flag for debug
info...

2022-01-28  Jakub Jelinek  

PR lto/104237
* cfgrtl.cc (loc_equal): New function.
(unique_locus_on_edge_between_p): Use it.

[Bug lto/104237] [11 Regression] Emitted binary code changes when -g is enabled at -O1 -flto and optimize attribute since r11-3126-ga8f9b4c54cc35062

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

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[11/12 Regression] Emitted  |[11 Regression] Emitted
   |binary code changes when -g |binary code changes when -g
   |is enabled at -O1 -flto and |is enabled at -O1 -flto and
   |optimize attribute since|optimize attribute since
   |r11-3126-ga8f9b4c54cc35062  |r11-3126-ga8f9b4c54cc35062

--- Comment #8 from Jakub Jelinek  ---
Fixed on the trunk so far.

[Bug c++/104142] [9/10/11/12 Regression] Spurios warning unused-variable on const static variable and defaulted constructor

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
It isn't clear what exactly is the regression.
We warn on b with -Wunused-variable since
r9-412-gb46b715d5b838d9869f89d3594ebf7d0b7cb374c
A and B aren't the same, one has explicit defaulted ctor, the other has
implicit ctor.
-Wunused-const-variable warns about a and not b since its introduction in
r6-3283-g0f876f22887f239cedca64ff170b71e5f1daaf54

[Bug c++/103790] internal compiler error: Segmentation fault when playing with coroutine

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

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

--- Comment #7 from CVS Commits  ---
The master branch has been updated by Andre Vehreschild :

https://gcc.gnu.org/g:26e237fb5b83582b30ef7c5a388bc4e968a5a289

commit r12-6915-g26e237fb5b83582b30ef7c5a388bc4e968a5a289
Author: Andre Vehreschild 
Date:   Fri Jan 28 12:34:17 2022 +0100

Prevent malicious descriptor stacking for scalar components [V2].

gcc/fortran/ChangeLog:

PR fortran/103790
* trans-array.cc (structure_alloc_comps): Prevent descriptor
stacking for non-array data; do not broadcast caf-tokens.
* trans-intrinsic.cc (conv_co_collective): Prevent generation
of unused descriptor.

gcc/testsuite/ChangeLog:

PR fortran/103790
* gfortran.dg/coarray_collectives_18.f90: New test.

[Bug c++/104142] [9/10/11/12 Regression] Spurios warning unused-variable on const static variable and defaulted constructor

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org,
   ||ppalka at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
If we want the same warning, we'd need to probably special case const vars with
defaulted default ctors and empty classes, if it isn't empty class, both of
these are rejected already:
pr104142.C:2:16: error: uninitialized ‘const a’ [-fpermissive]
2 | static const A a;
  |^
pr104142.C:1:8: note: ‘const struct A’ has no user-provided default constructor
1 | struct A { int a; };
  |^
pr104142.C:1:16: note: and the implicitly-defined constructor does not
initialize ‘int A::a’
1 | struct A { int a; };
  |^
pr104142.C:5:16: error: uninitialized ‘const b’ [-fpermissive]
5 | static const B b;
  |^
pr104142.C:4:8: note: ‘const struct B’ has no user-provided default constructor
4 | struct B { B()=default; int b; };
  |^
pr104142.C:4:12: note: constructor is not user-provided because it is
explicitly defaulted in the class body
4 | struct B { B()=default; int b; };
  |^
pr104142.C:4:29: note: and the implicitly-defined constructor does not
initialize ‘int B::b’
4 | struct B { B()=default; int b; };
  | ^

[Bug target/104172] [9/10 Regression] ppc64le mangling ICE with -flto -ffat-lto-objects

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

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[9/10/11/12 Regression] |[9/10 Regression] ppc64le
   |ppc64le mangling ICE with   |mangling ICE with -flto
   |-flto -ffat-lto-objects |-ffat-lto-objects
   Target Milestone|9.5 |11.3
 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #17 from Jakub Jelinek  ---
Fixed for 11.3/trunk, not going to backport further.

[Bug ipa/103830] [12 Regression] null pointer access optimized away by removing function call at -Og

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

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

--- Comment #6 from Richard Biener  ---
To clarify myself - the testcase is invoking UB, 'volatile' doesn't make a
difference here.  That we get the DSE as a second-order effect is unfortunate
at most, in other places we try to preserve volatile qualified accesses.  But I
do not think it's worth to pessimize -Og for that.  If you declare
MyClass::call() noinline you get the same behavior with all optimization
levels:

struct MyClass;
struct ptr {
MyClass* get() { return t; } /* line 21 */
MyClass* t;
};
struct MyClass { void __attribute__((noinline)) call(); };
void MyClass::call() {
*(volatile char*)(nullptr) = 1;  /* line 26 */
}
static void intermediate(ptr p) {
p.get()->call(); /* line 29 */
}
int main() {
intermediate(ptr{new MyClass});
}

so iff then we need to argue about the modref/ipa-pure-const behavior, not
about DCE of calls at -Og.

[Bug ipa/103830] [12 Regression] null pointer access optimized away by removing function call at -Og

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

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

--- Comment #7 from Richard Biener  ---
A fix in the source would be:

void MyClass::call() {
volatile char * volatile null = nullptr;
*null = 1;  /* line 26 */
}

which then compiles to

movq$0, -8(%rsp)
movq-8(%rsp), %rax
movb$1, (%rax)
ret

(some "advanced" means using some asm() to hide the constant from the compiler
might also work)

[Bug ipa/103830] [12 Regression] null pointer access optimized away by removing function call at -Og

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

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

Richard Biener  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

--- Comment #8 from Richard Biener  ---
I'd say invalid.  For -Og we might want to consider not doing pure/const
discovery (or modref) but stick to what the user declared so.

[Bug ipa/103830] [12 Regression] null pointer access optimized away by removing function call at -Og

[bernd.edlinger at hotmail dot de via Gcc-bugs]

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

Bernd Edlinger  changed:

   What|Removed |Added

 Resolution|INVALID |FIXED

--- Comment #9 from Bernd Edlinger  ---
(In reply to Richard Biener from comment #7)
> A fix in the source would be:
> 
> void MyClass::call() {
> volatile char * volatile null = nullptr;
> *null = 1;  /* line 26 */
> }
> 
> which then compiles to
> 
> movq$0, -8(%rsp)
> movq-8(%rsp), %rax
> movb$1, (%rax)
> ret
> 
> (some "advanced" means using some asm() to hide the constant from the
> compiler might also work)

Yes, that works, but I would prefer:

*(volatile char*)1 = 2;

[Bug middle-end/104151] [9/10/11/12 Regression] x86: excessive code generated for 128-bit byteswap

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #11 from Jakub Jelinek  ---
With -O3 it regresses with
r7-2009-g8d4fc2d3d0c8f87bb3e182be1a618a511f8f9465
__uint128_t bswap(__uint128_t a) { return __builtin_bswap128 (a); }
emits the optimal code but is only in GCC 11.1 and later.

One fix for this might be to handle
  _8 = BIT_FIELD_REF ;
  _1 = __builtin_bswap64 (_8);
  y[0] = _1;
  _10 = BIT_FIELD_REF ;
  _2 = __builtin_bswap64 (_10);
  y[1] = _2;
  _7 = MEM  [(char * {ref-all})&y];
in bswap or store merging.
Though, current bswap infrastructure I'm afraid limits it to 64-bit size,
because it tracks the bytes in uint64_t vars and uses 8 bits to determine which
byte it is (0 value of zero, 1-8 byte index and 0xff unknown).
While that is 10 different values right now, if we handled uint128_t we'd need
18 different values times 16.

Note, even:
unsigned long long
bswap (unsigned long long a)
{
  unsigned int x[2];
  __builtin_memcpy (x, &a, 8);
  unsigned int y[2];
  y[0] = __builtin_bswap32 (x[1]);
  y[1] = __builtin_bswap32 (x[0]);
  __builtin_memcpy (&a, y, 8);
  return a;
}

unsigned long long
bswap2 (unsigned long long a)
{
  return __builtin_bswap64 (a);
}
emits better code in the latter function rather than former store-merging
isn't able to handle even that.
So we want to handle it in store-merging, we should start with handling
  _8 = BIT_FIELD_REF ;
  _1 = __builtin_bswap32 (_8);
  _10 = (unsigned int) a_3(D);
  _2 = __builtin_bswap32 (_10);
  _11 = {_1, _2};
  _5 = VIEW_CONVERT_EXPR(_11);
and
  _8 = BIT_FIELD_REF ;
  _1 = __builtin_bswap32 (_8);
  y[0] = _1;
  _10 = (unsigned int) a_3(D);
  _2 = __builtin_bswap32 (_10);
  y[1] = _2;
  _7 = MEM  [(char * {ref-all})&y];
and only once that is handled try
  _8 = BIT_FIELD_REF ;
  _1 = __builtin_bswap64 (_8);
  _10 = (long long unsigned int) a_3(D);
  _2 = __builtin_bswap64 (_10);
  _11 = {_1, _2};
  _5 = VIEW_CONVERT_EXPR(_11);
Doesn't look like stage4 material though.

So in the meantime perhaps some other improvements.

[Bug debug/103788] [9/10/11/12 Regression] '-fcompare-debug' failure (length) w/ -O1

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #7 from Jakub Jelinek  ---
Dup of the many -gstatement-frontiers -fcompare-debug issues.  No idea what to
do about those.

[Bug tree-optimization/104263] [10/11/12 Regression] '-fcompare-debug' failure (length) w/ -O2 -fnon-call-exceptions -fno-inline-small-functions since r10-3575-g629387a6586a7531

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

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

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

https://gcc.gnu.org/g:5b6f04276e3d1f20817ed37b2e26e43bd12cc0d2

commit r12-6917-g5b6f04276e3d1f20817ed37b2e26e43bd12cc0d2
Author: Richard Biener 
Date:   Fri Jan 28 10:55:29 2022 +0100

tree-optimization/104263 - avoid retaining abnormal edges for non-call/goto
stmts

This removes a premature optimization from
gimple_purge_dead_abnormal_call_edges which, after eliding the
last setjmp (or computed goto) statement from a function and
thus clearing cfun->calls_setjmp, leaves us with the abnormal
edges from other calls that are elided for example via inlining
or DCE.  That's a CFG / IL combination that should be impossible
(not addressing the fact that with cfun->calls_setjmp and
cfun->has_nonlocal_label cleared we should not have any abnormal
edge at all).

For the testcase in the PR this means that IPA inlining will
remove the abormal edges from the block after inlining the call
the edge was coming from.

2022-01-28  Richard Biener  

PR tree-optimization/104263
* tree-cfg.cc (gimple_purge_dead_abnormal_call_edges):
Purge edges also when !cfun->has_nonlocal_label
and !cfun->calls_setjmp.

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

[Bug tree-optimization/104267] [12 Regression] ICE in vect_schedule_slp_node, at tree-vect-slp.c:7144 since r12-5613-g32ede1083fad4b68

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

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

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

https://gcc.gnu.org/g:9ec306582fd60e5b76f07eb81c9ed2415d9a3590

commit r12-6918-g9ec306582fd60e5b76f07eb81c9ed2415d9a3590
Author: Richard Biener 
Date:   Fri Jan 28 11:32:11 2022 +0100

tree-optimization/104267 - fix external def vector type for call args

The following fixes the vector type registered for external defs
in call arguments when vectorizing with SLP.  We assumed uniform
vectype_in types here but with calls like .COND_MUL we also have
mask arguments which, when invariant or external, need to have
a proper mask vector type.

2022-01-28  Richard Biener  

PR tree-optimization/104267
* tree-vect-stmts.cc (vectorizable_call): Properly use the
per-argument determined vector type for externals and
invariants.

[Bug tree-optimization/104267] [12 Regression] ICE in vect_schedule_slp_node, at tree-vect-slp.c:7144 since r12-5613-g32ede1083fad4b68

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

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug c++/103341] [11/12 Regression] ICE type of variable instantiation constrained on template parameter

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

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Patrick Palka :

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

commit r12-6919-ge272cf95ba048fde60b21aee046c9ca9c9264425
Author: Patrick Palka 
Date:   Fri Jan 28 08:18:28 2022 -0500

c++: var tmpl w/ dependent constrained auto type [PR103341]

When deducing the type of a variable template (or templated static data
member) with a constrained auto type, we might need its template
arguments for satisfaction since the constraint could depend on them.

PR c++/103341

gcc/cp/ChangeLog:

* decl.cc (cp_finish_decl): Pass the template arguments of a
variable template specialization or a templated static data
member to do_auto_deduction when the auto is constrained.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/concepts-class4.C: New test.
* g++.dg/cpp2a/concepts-var-templ2.C: New test.

[Bug c++/103341] [11 Regression] ICE type of variable instantiation constrained on template parameter

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

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

Patrick Palka  changed:

   What|Removed |Added

 CC||ppalka at gcc dot gnu.org
Summary|[11/12 Regression] ICE type |[11 Regression] ICE type of
   |of variable instantiation   |variable instantiation
   |constrained on template |constrained on template
   |parameter   |parameter
   Assignee|unassigned at gcc dot gnu.org  |ppalka at gcc dot 
gnu.org
 Status|NEW |ASSIGNED

--- Comment #5 from Patrick Palka  ---
Fixed for 12 so far.

[Bug tree-optimization/104269] New: Bogus -Wuse-after-free seen in xen

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

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

Bug ID: 104269
   Summary: Bogus -Wuse-after-free seen in xen
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: msebor at gcc dot gnu.org
  Target Milestone: ---

Reduced from xen package:

$ cat core.c
#include 

typedef struct xenhypfs_handle xenhypfs_handle;

typedef struct
{
  int a;
} dirent;

void *foo(dirent **);

dirent *xenhypfs_readdir(xenhypfs_handle *fshdl,
 const char *path,
 unsigned int *num_entries)
{
unsigned int n = 0, name_sz = 0;
void *buf;
dirent *ret_buf = 0; 
dirent *dirent;

buf = foo(&dirent);
if (!buf)
goto out;

ret_buf = malloc(n * sizeof(*ret_buf) + name_sz);
if (!ret_buf)
goto out;

 out:
free(buf);
free(dirent);

return ret_buf;
}

$ gcc core.c -c -O2 -Wall -Werror=use-after-free
core.c: In function ‘xenhypfs_readdir’:
core.c:33:12: error: pointer ‘ret_buf’ used after ‘free’
[-Werror=use-after-free]
   33 | return ret_buf;
  |^~~
core.c:30:5: note: call to ‘free’ here
   30 | free(buf);
  | ^
cc1: some warnings being treated as errors

I believe the code is fine.

[Bug tree-optimization/103489] [11 Regression] ICE with -O3 in operator[], at vec.h:889 since r12-5394-g0fc859f5efcb4624

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

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

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

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

commit r11-9523-g2c7d8ca8317981c2eb21eb1e85e0f55d3f71aff1
Author: Richard Biener 
Date:   Tue Nov 30 14:08:19 2021 +0100

tree-optimization/103489 - fix ICE when bool pattern recog fails

bool pattern recog currently does not handle cycles correctly
and when it fails we can ICE later vectorizing PHIs with
mismatched bool and non-bool vector types.  The following avoids
blindly trusting bool pattern recog here and verifies things
more thoroughly in vectorizable_phi.  A bool pattern recog fix
is for GCC 13.

2021-11-30  Richard Biener  

PR tree-optimization/103489
* tree-vect-loop.c (vectorizable_phi): Verify argument
vector type compatibility to mitigate bool pattern recog
bug.

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

(cherry picked from commit 0194d92c35ca8b3aa850b805d9becb4491cf6bec)

[Bug tree-optimization/103596] [9/10/11 Regression] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in useless_type_conversion_p, at gimple-expr.c:88 since r8-565-g7581ce9a1ad6

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

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

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

https://gcc.gnu.org/g:08f594465fa9b6a4ea1e3816cfecf256e883ff53

commit r11-9524-g08f594465fa9b6a4ea1e3816cfecf256e883ff53
Author: Richard Biener 
Date:   Tue Dec 7 11:13:39 2021 +0100

tree-optimization/103596 - fix missed propagation into switches

may_propagate_copy unnecessarily restricts propagating non-abnormals
into places that currently contain an abnormal SSA name but are
not the PHI argument for an abnormal edge.  This causes VN to
not elide a CFG path that it assumes is elided, resulting in
released SSA names in the IL.

The fix is to enhance the may_propagate_copy API to specify the
destination is _not_ a PHI argument.  I chose to not update only
the relevant caller in VN and the may_propagate_copy_into_stmt API
at this point because this is a regression and needs backporting.

2021-12-07  Richard Biener  

PR tree-optimization/103596
* tree-ssa-sccvn.c (eliminate_dom_walker::eliminate_stmt):
Note we are not propagating into a PHI argument to
may_propagate_copy.
* tree-ssa-propagate.h (may_propagate_copy): Add
argument specifying whether we propagate into a PHI arg.
* tree-ssa-propagate.c (may_propagate_copy): Likewise.
When not doing so we can replace an abnormal with
something else.
(may_propagate_into_stmt): Update may_propagate_copy calls.
(replace_exp_1): Move propagation checking code to
propagate_value and rename to ...
(replace_exp): ... this and elide previous wrapper.
(propagate_value): Perform checking with adjusted
may_propagate_copy call and dispatch to replace_exp.

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

(cherry picked from commit 6e8a31275fda445fb3e8d98e53f5e1541f4727af)

[Bug tree-optimization/103489] [11 Regression] ICE with -O3 in operator[], at vec.h:889 since r12-5394-g0fc859f5efcb4624

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

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/103035] [meta-bug] YARPGen bugs

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

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

Bug 103489 Summary: [11 Regression] ICE with -O3 in operator[], at vec.h:889 
since r12-5394-g0fc859f5efcb4624
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103489

   What|Removed |Added

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

[Bug middle-end/103616] [9/10/11/12 Regression] ICE on ceph with systemtap macro since r8-5608

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

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

--- Comment #1 from Vladimir Makarov  ---
I can not reproduce ICE on this week GCC.  Probably it was fixed (or switched
off) by some recent RA patch.

As for the second issue (code generation for function foo), I thought for some
time how it could be fixed.  It seemed that LRA inheritance sub-pass could be
extended to work on memory too besides regs.  But I got to conclusion that it
would complicate already complicated LRA (inheritance subpass) more as we need
to add sophisticated analysis (including aliasing) for memory.

I guess there is an simpler alternative solution.  The problem would disappear
if double constant were in asm insn before LRA.  I think some pass before RA
could this.  It could be driven by a target, for example to promote double
constants for x86-64.

Also the problem might be solved if we had pseudo<-double insn instead of
mem<-double insn before LRA, LRA code dealing with equiv could promote double
into the asm insn (although I am not 100% sure about this but, if it is not the
case, probably code dealing with equiv could be tweaked to do this).

So my proposal is to solve the problem somehow outside RA.

[Bug c++/104255] parsing trailing return type fails with parameter pack expansion when two parameter packs at present

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

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

Patrick Palka  changed:

   What|Removed |Added

 CC||ppalka at gcc dot gnu.org

--- Comment #2 from Patrick Palka  ---
The error message is obscure, but it seems what GCC has issue with here is the
use of the function parameter seq2 in the trailing return type occurring
outside of an unevaluated context.

I'm not totally sure if the testcase is valid
(https://eel.is/c++draft/basic.scope.param#note-1 might suggest it's not?), but
one workaround is to replace the use of seq2 in the trailing return type with
decltype(seq2){} (which works because index_sequence is an empty type).

Here's a minimal testcase demonstrating the issue

  struct empty { };
  constexpr int f(empty) { return 0; }
  template struct A { };
  auto g(empty e) -> A;

which is rejected with

  error: use of parameter outside function body before ‘)’ token

due to 'e' being used outside of an unevaluated context within the signature of
the function.

[Bug middle-end/103483] [12 regression] context-sensitive ranges change triggers stringop-overread

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

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

--- Comment #21 from Jeffrey A. Law  ---
Yes, the wording is dreadful.  Yes we need a better way to express to the user
the paths followed and how they impacted the analysis.

As for suppressing. There's not a great option here, which isn't a huge
surprise.  In this specific case we'd need to be able to make mystrlen less
opaque, particularly WRT its return value.  Even if we had a solution to do
that, it's still far from good IMHO -- you end up with annotations all over the
place.

[Bug analyzer/104270] New: -Wanalyzer-use-of-uninitialized-value is incorrectly suppressed by -ftrivial-auto-var-init=

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

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

Bug ID: 104270
   Summary: -Wanalyzer-use-of-uninitialized-value is incorrectly
suppressed by -ftrivial-auto-var-init=
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: dmalcolm at gcc dot gnu.org
  Target Milestone: ---

As of GCC 12, the analyzer ought to complain about uses of uninitialized memory
via
  -Wanalyzer-use-of-uninitialized-value 
but fails to do so for trivial cases of locals when -ftrivial-auto-var-init= is
used with "pattern" or "zero".

The docs for -ftrivial-auto-var-init say:

> GCC still considers an automatic variable that doesn't have an explicit
> initializer as uninitialized, @option{-Wuninitialized} will still report
> warning messages on such automatic variables.

which implies that -ftrivial-auto-var-init is intended for mitigation, and that
the analyzer ought to still warn on such cases.

At the gimple level we have e.g.:

  i_1 = .DEFERRED_INIT (4, 1, &"i"[0]);

which the analyzer doesn't yet have any special knowledge about, and thus
treats the result as a normal value, suppressing the warning.

[Bug fortran/104228] [9/10/11/12 Regression] ICE in df_install_ref, at df-scan.cc:2294 since r8-3589-g707905d0773e5a8e

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
Seems to be a FE bug.
Already in *.gimple bug with -fdump-tree-all-uid one can see:
__attribute__((fn spec (". ")))
void p ()
{
  static voidD.27 sD.4214 (void);
  struct array01_character(kind=1) yD.4238;
  static integer(kind=8)D.9 .yD.4216;
  static struct array01_character(kind=1) xD.4249 = {.dataD.4244=0B};
  bitsizetype D.4278;
  sizetype D.4279;

  try
{
...
__attribute__((fn spec (". ")))
void s ()
{
  bitsizetype D.4285;
  sizetype .y.10D.4286;
  integer(kind=8)D.9 iftmp.14D.4287;

  {
static integer(kind=8)D.9 .yD.4216;
static struct array01_character(kind=1) xD.4249 = {.dataD.4244=0B};
bitsizetype D.4278;
sizetype D.4279;

That means that BLOCK_VARS of a BLOCK inside of p function contain
s var with DECL_UID 4214, its DECL_CHAIN is y with DECL_UID 4238 and
its DECL_CHAIN is .y with DECL_UID 4216.
But the same .y var with DECL_UID 4216 is also in BLOCK_VARS of another BLOCK
inside of s.  Vars in BLOCK_VARS are chained through DECL_CHAIN, aren't in some
vec or TREE_VEC etc., so can't be part of multiple chains.

[Bug rtl-optimization/102178] [12 Regression] SPECFP 2006 470.lbm regressions on AMD Zen CPUs after r12-897-gde56f95afaaa22

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

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

--- Comment #26 from Vladimir Makarov  ---
(In reply to Richard Biener from comment #7)
> make costs in a way that IRA/LRA prefer re-materialization of constants
> from the constant pool over spilling to GPRs (if that's possible at all -
> Vlad?)

LRA rematerialization can not rematerialize constant value from memory pool. 
It can rematerialize value of expression only consisting of other pseudos
(currently assigned to hard regs) and constants.

I guess rematerialization pass can be extended to work for constants from
constant memory pool.  It is pretty doable project opposite to
rematerialization of any memory which would require a lot analysis including
aliasing and complicated cost calculation benefits.  May be somebody could pick
this project up.

[Bug c++/101783] unnecessary error when top level cv qualifier is dropped

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

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

Patrick Palka  changed:

   What|Removed |Added

   Target Milestone|--- |12.0
 Resolution|--- |FIXED
 CC||ppalka at gcc dot gnu.org
 Status|NEW |RESOLVED
   Assignee|unassigned at gcc dot gnu.org  |nickhuang99 at hotmail 
dot com

--- Comment #11 from Patrick Palka  ---
Marking as fixed for GCC 12, thanks for working on this!

[Bug c++/102449] template parameter with default argument is used without being verified during explicit specialization

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

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

Patrick Palka  changed:

   What|Removed |Added

 CC||ppalka at gcc dot gnu.org
 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #2 from Patrick Palka  ---
(In reply to Andrew Pinski from comment #1)
> I think this is valid code as the compiler can deduce that First is int.
> All compilers I have tried accept the code.

Agreed.

[Bug fortran/104228] [9/10/11/12 Regression] ICE in df_install_ref, at df-scan.cc:2294 since r8-3589-g707905d0773e5a8e

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

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

--- Comment #4 from Jakub Jelinek  ---
The .y var is added into the s function with:
#0  add_decl_as_local (decl=) at
../../gcc/fortran/trans-decl.cc:257
#1  0x00c054f8 in gfc_finish_var_decl (decl=, sym=0x3e16a00) at ../../gcc/fortran/trans-decl.cc:649
#2  0x00c09e9e in gfc_get_symbol_decl (sym=0x3e16a00) at
../../gcc/fortran/trans-decl.cc:1882
#3  0x00c18dee in generate_local_decl (sym=0x3e16a00) at
../../gcc/fortran/trans-decl.cc:5853
#4  0x00bb5174 in do_traverse_symtree (st=0x3e16b60, st_func=0x0,
sym_func=0xc18d2a ) at
../../gcc/fortran/symbol.cc:4174
#5  0x00bb522f in gfc_traverse_ns (ns=0x3e19810, sym_func=0xc18d2a
) at ../../gcc/fortran/symbol.cc:4199
#6  0x00c19780 in generate_local_vars (ns=0x3e19810) at
../../gcc/fortran/trans-decl.cc:6064
#7  0x00c20fae in gfc_process_block_locals (ns=0x3e19810) at
../../gcc/fortran/trans-decl.cc:7940
#8  0x00ca8b60 in gfc_trans_block_construct (code=0x3e16ba0) at
../../gcc/fortran/trans-stmt.cc:2296
#9  0x00bd8645 in trans_code (code=0x3e16ba0, cond=) at
../../gcc/fortran/trans.cc:2012
#10 0x00bd8a58 in gfc_trans_code (code=0x3e16ba0) at
../../gcc/fortran/trans.cc:2268
#11 0x00c203ea in gfc_generate_function_code (ns=0x3e15530) at
../../gcc/fortran/trans-decl.cc:7654
#12 0x00c18b5d in gfc_generate_contained_functions (parent=0x3e14530)
at ../../gcc/fortran/trans-decl.cc:5777
#13 0x00c20031 in gfc_generate_function_code (ns=0x3e14530) at
../../gcc/fortran/trans-decl.cc:7586
#14 0x00bd8a9c in gfc_generate_code (ns=0x3e14530) at
../../gcc/fortran/trans.cc:2285
#15 0x00b5ca50 in translate_all_program_units
(gfc_global_ns_list=0x3e14530) at ../../gcc/fortran/parse.cc:6651
#16 0x00b5d299 in gfc_parse_file () at ../../gcc/fortran/parse.cc:6938
#17 0x00bc0539 in gfc_be_parse_file () at
../../gcc/fortran/f95-lang.cc:216
#18 0x01463e4f in compile_file () at ../../gcc/toplev.cc:452
#19 0x01466e45 in do_compile (no_backend=false) at
../../gcc/toplev.cc:2158
#20 0x0146720a in toplev::main (this=0x7fffd76a, argc=4,
argv=0x7fffd878) at ../../gcc/toplev.cc:2310
#21 0x02b3c444 in main (argc=4, argv=0x7fffd878) at
../../gcc/main.cc:39
and then pushdecl is called on it too:
#0  pushdecl (decl=) at
../../gcc/fortran/f95-lang.cc:442
#1  0x00c21086 in gfc_process_block_locals (ns=0x3e19810) at
../../gcc/fortran/trans-decl.cc:7952
#2  0x00ca8b60 in gfc_trans_block_construct (code=0x3e16ba0) at
../../gcc/fortran/trans-stmt.cc:2296
#3  0x00bd8645 in trans_code (code=0x3e16ba0, cond=) at
../../gcc/fortran/trans.cc:2012
#4  0x00bd8a58 in gfc_trans_code (code=0x3e16ba0) at
../../gcc/fortran/trans.cc:2268
#5  0x00c203ea in gfc_generate_function_code (ns=0x3e15530) at
../../gcc/fortran/trans-decl.cc:7654
#6  0x00c18b5d in gfc_generate_contained_functions (parent=0x3e14530)
at ../../gcc/fortran/trans-decl.cc:5777
#7  0x00c20031 in gfc_generate_function_code (ns=0x3e14530) at
../../gcc/fortran/trans-decl.cc:7586
#8  0x00bd8a9c in gfc_generate_code (ns=0x3e14530) at
../../gcc/fortran/trans.cc:2285
#9  0x00b5ca50 in translate_all_program_units
(gfc_global_ns_list=0x3e14530) at ../../gcc/fortran/parse.cc:6651
#10 0x00b5d299 in gfc_parse_file () at ../../gcc/fortran/parse.cc:6938
#11 0x00bc0539 in gfc_be_parse_file () at
../../gcc/fortran/f95-lang.cc:216
#12 0x01463e4f in compile_file () at ../../gcc/toplev.cc:452
#13 0x01466e45 in do_compile (no_backend=false) at
../../gcc/toplev.cc:2158
#14 0x0146720a in toplev::main (this=0x7fffd76a, argc=4,
argv=0x7fffd878) at ../../gcc/toplev.cc:2310
#15 0x02b3c444 in main (argc=4, argv=0x7fffd878) at
../../gcc/main.cc:39
with cfun->decl of s and once again in:
#0  pushdecl (decl=) at
../../gcc/fortran/f95-lang.cc:442
#1  0x00c20b7e in gfc_generate_function_code (ns=0x3e14530) at
../../gcc/fortran/trans-decl.cc:7768
#2  0x00bd8a9c in gfc_generate_code (ns=0x3e14530) at
../../gcc/fortran/trans.cc:2285
#3  0x00b5ca50 in translate_all_program_units
(gfc_global_ns_list=0x3e14530) at ../../gcc/fortran/parse.cc:6651
#4  0x00b5d299 in gfc_parse_file () at ../../gcc/fortran/parse.cc:6938
#5  0x00bc0539 in gfc_be_parse_file () at
../../gcc/fortran/f95-lang.cc:216
#6  0x01463e4f in compile_file () at ../../gcc/toplev.cc:452
#7  0x01466e45 in do_compile (no_backend=false) at
../../gcc/toplev.cc:2158
#8  0x0146720a in toplev::main (this=0x7fffd76a, argc=4,
argv=0x7fffd878) at ../../gcc/toplev.cc:2310
#9  0x02b3c444 in main (argc=4, argv=0x7fffd878) at
../../gcc/main.cc:39
with cfun->decl of p.

[Bug c++/104266] Temporaries with protected destructor are erroneously permitted

[de34 at live dot cn via Gcc-bugs]

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

Jiang An  changed:

   What|Removed |Added

 CC||de34 at live dot cn

--- Comment #1 from Jiang An  ---
I think this is CWG DR 2227 (https://wg21.link/cwg2227).

And IIUC although it is correct to reject this code, clang's error message is
wrong, because there's no temporary of type 'A' created due to guaranteed RVO
since C++17.

[Bug rtl-optimization/102178] [12 Regression] SPECFP 2006 470.lbm regressions on AMD Zen CPUs after r12-897-gde56f95afaaa22

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

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

--- Comment #27 from Vladimir Makarov  ---
(In reply to Richard Biener from comment #17)
> So in .reload we have (with unpatched trunk)
> 
>   401: NOTE_INSN_BASIC_BLOCK 6
>   462: ax:DF=[`*.LC0']
>   REG_EQUAL 9.8506899724167309977929107844829559326171875e-1
>   407: xmm2:DF=ax:DF
>   463: ax:DF=[`*.LC0']
>   REG_EQUAL 9.8506899724167309977929107844829559326171875e-1
>   408: xmm4:DF=ax:DF
> 
> why??!  We can load .LC0 into xmm4 directly.  IRA sees
> 
>   401: NOTE_INSN_BASIC_BLOCK 6
>   407: r118:DF=r482:DF
>   408: r119:DF=r482:DF
> 
> now I cannot really decipher IRA or LRA dumps but my guess would be that
> inheritance (causing us to load from LC0) interferes badly with register
> class assignment?
> 
> Changing pseudo 482 in operand 1 of insn 407 on equiv
> 9.8506899724167309977929107844829559326171875e-1
> ...
>   alt=21,overall=9,losers=1,rld_nregs=1
>  Choosing alt 21 in insn 407:  (0) v  (1) r {*movdf_internal}
>   Creating newreg=525, assigning class GENERAL_REGS to r525
>   407: r118:DF=r525:DF
> Inserting insn reload before:
>   462: r525:DF=[`*.LC0']
>   REG_EQUAL 9.8506899724167309977929107844829559326171875e-1
> 
> we should have preferred alt 14 I think (0) v (1) m, but that has
> 
>   alt=14,overall=13,losers=1,rld_nregs=0
> 0 Spill pseudo into memory: reject+=3
> Using memory insn operand 0: reject+=3
> 0 Non input pseudo reload: reject++
> 1 Non-pseudo reload: reject+=2
> 1 Non input pseudo reload: reject++
> alt=15,overall=28,losers=3 -- refuse
> 0 Costly set: reject++
> alt=16: Bad operand -- refuse
> 0 Costly set: reject++
> 1 Costly loser: reject++
> 1 Non-pseudo reload: reject+=2
> 1 Non input pseudo reload: reject++
> alt=17,overall=17,losers=2 -- refuse
> 0 Costly set: reject++
> 1 Spill Non-pseudo into memory: reject+=3
> Using memory insn operand 1: reject+=3
> 1 Non input pseudo reload: reject++
> alt=18,overall=14,losers=1 -- refuse
> 0 Spill pseudo into memory: reject+=3
> Using memory insn operand 0: reject+=3
> 0 Non input pseudo reload: reject++
> 1 Costly loser: reject++
> 1 Non-pseudo reload: reject+=2
> 1 Non input pseudo reload: reject++
> alt=19,overall=29,losers=3 -- refuse
> 0 Non-prefered reload: reject+=600
> 0 Non input pseudo reload: reject++
> alt=20,overall=607,losers=1 -- refuse
> 1 Non-pseudo reload: reject+=2
> 1 Non input pseudo reload: reject++
> 
> I'm not sure I can decipher the reasoning but I don't understand how it
> doesn't seem to anticipate the cost of reloading the GPR in the alternative
> it chooses?
> 
> Vlad?

All this diagnostics is just description of voodoo from the old reload pass. 
LRA choosing alternative the same way as the old reload pass (I doubt that any
other approach will not break all existing targets).  Simply the old reload
pass does not report its decisions in the dump.

LRA code (lra-constraints.cc::process_alt_operands) choosing the insn
alternatives (as the old reload pass) does not use any memory or register move
costs.  Instead, the alternative is chosen by heuristics and insn constraints
hints (like ? !). The only case where these costs are used, when we have
reg:=reg and the register move costs for this is 2.  In this case LRA(reload)
does not bother to check the insn constraints.

[Bug tree-optimization/94801] Failure to optimize narrowed __builtin_clz

[dragan.mladjenovic at syrmia dot com via Gcc-bugs]

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

dragan.mladjenovic at syrmia dot com changed:

   What|Removed |Added

 CC||dragan.mladjenovic at syrmia 
dot c
   ||om

--- Comment #9 from dragan.mladjenovic at syrmia dot com ---
Note that the transformation that the clang does seems to be target specific,
so it won't trigger for example on Aarch64. It does so on x86 irrespective of
the availability of lzcnt instruction.

[Bug fortran/104228] [9/10/11/12 Regression] ICE in df_install_ref, at df-scan.cc:2294 since r8-3589-g707905d0773e5a8e

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu.org

--- Comment #5 from Jakub Jelinek  ---
If the testcase is extended to:
program p
   character(:), save, allocatable :: x(:)
   call s1
   call s2
   call s3
   call s4
contains
   subroutine s1
  associate (y1 => x)
 y1 = [x]
  end associate
   end
   subroutine s2
  associate (y2 => x)
 y2 = [x]
  end associate
   end
   subroutine s3
  associate (y3 => x)
 y3 = [x]
  end associate
   end
   subroutine s4
  associate (y4 => x)
 y4 = [x]
  end associate
   end
end

then the p program contains just one of those y vars (y4/.y4):
__attribute__((fn spec (". ")))
void p ()
{
  static voidD.27 s4D.4214 (void);
  static voidD.27 s3D.4216 (void);
  static voidD.27 s2D.4218 (void);
  static voidD.27 s1D.4220 (void);
  struct array01_character(kind=1) y4D.4244;
  static integer(kind=8)D.9 .y4D.4222;
  static struct array01_character(kind=1) xD.4255 = {.dataD.4250=0B};
  bitsizetype D.4401;
  sizetype D.4402;

  D.4401 = (bitsizetype) (sizetype) NON_LVALUE_EXPR <.y4D.4222> * 8;
  D.4402 = (sizetype) NON_LVALUE_EXPR <.y4D.4222>;
  s1D.4220 ();
  s2D.4218 ();
  s3D.4216 ();
  s4D.4214 ();
}

Now, if that .y4 randomly called based on one of the associate users is just
named character length of the x
array (shouldn't it be called .x ?) of a SAVE var in p, I'd think it should go
to the BLOCK where x is defined and nowhere else, all the nested functions (==
contained subroutines) should refer to it non-locally and shouldn't have it in
its BLOCK_VARS.

[Bug c++/92752] [9/10/11/12 Regression] Bogus "ignored qualifiers" warning on const-qualified pointer-to-member-function objects

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

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

Patrick Palka  changed:

   What|Removed |Added

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

[Bug middle-end/103616] [9/10/11/12 Regression] ICE on ceph with systemtap macro since r8-5608

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

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

--- Comment #2 from Jakub Jelinek  ---
#c0 doesn't ICE on the trunk since
r12-5944-ga7acb6dca941db2b1c135107dac3a34a20650d5c

[Bug target/103676] [10/11 Regression] internal compiler error: in extract_constrain_insn, at recog.c:2671

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

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[10/11/12 Regression]   |[10/11 Regression] internal
   |internal compiler error: in |compiler error: in
   |extract_constrain_insn, at  |extract_constrain_insn, at
   |recog.c:2671|recog.c:2671

--- Comment #25 from Jakub Jelinek  ---
Fixed on the trunk.

[Bug modula2/101391] Unresolved reference to module getopt

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

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

--- Comment #8 from Gaius Mulley  ---
Is it okay to close this PR as I've git committed some regression tests to
check that cgetopt and (other modules) are present and visible to the linker?

https://gcc.gnu.org/pipermail/gcc-cvs/2022-January/359926.html

[Bug target/104271] New: 538.imagick_r run-time at -Ofast -march=native regressed by 26% on Intel Cascade Lake server CPU

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

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

Bug ID: 104271
   Summary: 538.imagick_r run-time at -Ofast -march=native
regressed by 26% on Intel Cascade Lake server CPU
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jamborm at gcc dot gnu.org
CC: liuhongt at gcc dot gnu.org
Blocks: 26163
  Target Milestone: ---
  Host: x86_64-linux
Target: x86_64-linux

On our Intel Cascade Lake server CPU, the benchmark 538.imagick_r from
the SPEC 2017 FPrate suite is 26% slower when built with GCC 12 using
options -Ofast -march=native than when built with GCC 11 with the same
options.

I have bisected the issue to r12-2549-g872da9a6f664a0:

  872da9a6f664a06d73c987aa0cb2e5b830158a10 is the first bad commit
  commit 872da9a6f664a06d73c987aa0cb2e5b830158a10
  Author: liuhongt 
  Date:   Fri Mar 26 10:56:47 2021 +0800

Add the member integer_to_sse to processor_cost as a cost simulation for
movd/pinsrd. It will be used to calculate the cost of vec_construct.

gcc/ChangeLog: 

PR target/99881
* config/i386/i386.h (processor_costs): Add new member
integer_to_sse.
* config/i386/x86-tune-costs.h (ix86_size_cost, i386_cost,
i486_cost, pentium_cost, lakemont_cost, pentiumpro_cost,
geode_cost, k6_cost, athlon_cost, k8_cost, amdfam10_cost,
bdver_cost, znver1_cost, znver2_cost, znver3_cost,
btver1_cost, btver2_cost, btver3_cost, pentium4_cost,
nocona_cost, atom_cost, atom_cost, slm_cost, intel_cost,
generic_cost, core_cost): Initialize integer_to_sse same value
as sse_op.
(skylake_cost): Initialize integer_to_sse twice as much as sse_op.
* config/i386/i386.c (ix86_builtin_vectorization_cost):
Use integer_to_sse instead of sse_op to calculate the cost of
vec_construct.


It is very likely that the problem is a load-to-store-forwarding stall
issue and so related to PR 80689 but the commit makes it either more
frequent or much worse.

Sorry for reporting this so late, unfortunately we do not benchmark
this class of CPUs periodically.  We do not see the problem on any of
the AMD Zens or Intel Kabylake (client) CPUs.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
[Bug 26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)

[Bug ipa/103171] [12 Regression] ICE Segmentation fault since r12-2523-g13586172d0b70c9d

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

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

--- Comment #5 from Martin Jambor  ---
I have proposed a patch on the mailing list:
https://gcc.gnu.org/pipermail/gcc-patches/2022-January/589429.html

[Bug testsuite/70230] 11 test regressions when building GCC 6 with --enable-default-ssp

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

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

--- Comment #6 from CVS Commits  ---
The master branch has been updated by Jeff Law :

https://gcc.gnu.org/g:90c31ff339015ddd89ac519656fbd23a36ee6271

commit r12-6922-g90c31ff339015ddd89ac519656fbd23a36ee6271
Author: Allan McRae 
Date:   Fri Jan 28 12:44:08 2022 -0500

testsuite/70230 - fix failures with default SSP\

Configuring with --enable-default-ssp triggers various testsuite
failures.  These contain asm statements that are not compatible with
-fstack-protector.  Adding -fno-stack-protector to dg-options to
work around this issue.

Tested on x86_64-linux.

PR testsuite/70230
* gcc.dg/asan/use-after-scope-4.c (dg-options): Add
-fno-stack-protector.
* gcc.dg/stack-usage-1.c: Likewise
* gcc.dg/superblock.c: Likewise
* gcc.target/i386/avx-vzeroupper-17.c: Likewise
* gcc.target/i386/cleanup-1.c: Likewise
* gcc.target/i386/cleanup-2.c: Likewise
* gcc.target/i386/interrupt-redzone-1.c: Likewise
* gcc.target/i386/interrupt-redzone-2.c: Likewise
* gcc.target/i386/pr79793-1.c: Likewise
* gcc.target/i386/pr79793-2.c: Likewise
* gcc.target/i386/shrink_wrap_1.c: Likewise
* gcc.target/i386/stack-check-11.c: Likewise
* gcc.target/i386/stack-check-18.c: Likewise
* gcc.target/i386/stack-check-19.c: Likewise
* gcc.target/i386/stackalign/pr88483-1.c: Likewise
* gcc.target/i386/stackalign/pr88483-2.c: Likewise
* gcc.target/i386/sw-1.c: Likewise

[Bug tree-optimization/104269] [12 Regression] Bogus -Wuse-after-free seen in xen

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||diagnostic
   Target Milestone|--- |12.0
Summary|Bogus -Wuse-after-free seen |[12 Regression] Bogus
   |in xen  |-Wuse-after-free seen in
   ||xen

[Bug testsuite/99175] FAIL: g++.dg/modules/bad-mapper-1.C -std=c++17 (test for errors, line )

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

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

John David Anglin  changed:

   What|Removed |Added

   Host|hppa2.0w-hp-hpux11.11   |hppa*-*-hpux*
  Build|hppa2.0w-hp-hpux11.11   |hppa*-*-hpux*
 Target|hppa2.0w-hp-hpux11.11   |hppa*-*-hpux*

--- Comment #1 from John David Anglin  ---
Similar:
FAIL: g++.dg/modules/bad-mapper-1.C -std=c++17  at line 3 (test for errors,
line )
FAIL: g++.dg/modules/bad-mapper-1.C -std=c++17 (test for excess errors)
FAIL: g++.dg/modules/bad-mapper-1.C -std=c++2a  at line 3 (test for errors,
line )
FAIL: g++.dg/modules/bad-mapper-1.C -std=c++2a (test for excess errors)
FAIL: g++.dg/modules/bad-mapper-1.C -std=c++2b  at line 3 (test for errors,
line )
FAIL: g++.dg/modules/bad-mapper-1.C -std=c++2b (test for excess errors)
FAIL: g++.dg/modules/bad-mapper-3.C -std=c++17  at line 3 (test for errors,
line )
FAIL: g++.dg/modules/bad-mapper-3.C -std=c++17 (test for excess errors)
FAIL: g++.dg/modules/bad-mapper-3.C -std=c++2a  at line 3 (test for errors,
line )
FAIL: g++.dg/modules/bad-mapper-3.C -std=c++2a (test for excess errors)
FAIL: g++.dg/modules/bad-mapper-3.C -std=c++2b  at line 3 (test for errors,
line )
FAIL: g++.dg/modules/bad-mapper-3.C -std=c++2b (test for excess errors)

[Bug tree-optimization/104269] [12 Regression] Bogus -Wuse-after-free seen in xen

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2022-01-28
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
Since the warning runs after uncprop, it is the diagnostics are all wrong.



Before uncprop:
  if (_6 == 0B)
goto ; [15.47%]
  else
goto ; [84.53%]

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

   [local count: 907633961]:
  ret_buf_8 = malloc (0);

   [local count: 1073741824]:
  # ret_buf_2 = PHI 
out:
  free (_6);
  dirent1.0_1 = dirent1;
  free (dirent1.0_1);
  dirent1 ={v} {CLOBBER};
  return ret_buf_2;

After:
  # ret_buf_2 = PHI 

The warning is still not flow sensitive enough to know that _6 from bb5 will be
0B. and that doing free(0) does not matter.

[Bug tree-optimization/104263] [10/11/12 Regression] '-fcompare-debug' failure (length) w/ -O2 -fnon-call-exceptions -fno-inline-small-functions since r10-3575-g629387a6586a7531

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

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

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

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

commit r12-6923-ga591c71b41e18e4ff86852a974592af4962aef57
Author: Jakub Jelinek 
Date:   Fri Jan 28 19:02:26 2022 +0100

store-merging: Fix up a -fcompare-debug bug in get_status_for_store_merging
[PR104263]

As mentioned in the PRthe following testcase fails, because the last
stmt of a bb with -g is a debug stmt and get_status_for_store_merging
uses gimple_seq_last_stmt (bb_seq (bb)) when testing if it is valid
for store merging.  The debug stmt isn't valid, while a stmt at that
position with -g0 is valid and so the divergence.

As we walk the whole bb already, this patch just remembers the last
non-debug stmt, so that we don't need to skip backwards debug stmts at the
end of the bb to find last real stmt.

2022-01-28  Jakub Jelinek  

PR tree-optimization/104263
* gimple-ssa-store-merging.cc (get_status_for_store_merging): For
cfun->can_throw_non_call_exceptions && cfun->eh test whether
last non-debug stmt in the bb is store_valid_for_store_merging_p
rather than last stmt.

* gcc.dg/pr104263.c: New test.

[Bug tree-optimization/104263] [10/11 Regression] '-fcompare-debug' failure (length) w/ -O2 -fnon-call-exceptions -fno-inline-small-functions since r10-3575-g629387a6586a7531

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

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[10/11/12 Regression]   |[10/11 Regression]
   |'-fcompare-debug' failure   |'-fcompare-debug' failure
   |(length) w/ -O2 |(length) w/ -O2
   |-fnon-call-exceptions   |-fnon-call-exceptions
   |-fno-inline-small-functions |-fno-inline-small-functions
   |since   |since
   |r10-3575-g629387a6586a7531  |r10-3575-g629387a6586a7531

--- Comment #11 from Jakub Jelinek  ---
Fixed on the trunk so far.

[Bug c++/99175] FAIL: g++.dg/modules/bad-mapper-1.C -std=c++17 (test for errors, line )

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|testsuite   |c++

--- Comment #2 from Andrew Pinski  ---
Looks like the interface between the c++ front-end and the c++ tools is not
working on hpux.

[Bug testsuite/99175] FAIL: g++.dg/modules/bad-mapper-1.C -std=c++17 (test for errors, line )

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|c++ |testsuite

--- Comment #3 from Andrew Pinski  ---
I take that back, it looks more like the testcase is not expecting some of the
error messages that happen on HPUX for this testcase.

It is only expecting:
// { dg-error "-:failed exec.*mapper.* .*this-will-not-work" "" { target *-*-*
} 0 }

But got:
cc1plus: error trying to exec 'this-will-not-work': execvp: No such file or
directory

A few other messages.

[Bug c++/102204] OpenMP offload map type restriction

[xw111luoye at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Ye Luo  ---
I tried today's main 3f0fcda37f58d4108feb67de08f181a32bcb6388.
This issue persists. Any chance this will be resolved in 12 release?

[Bug tree-optimization/104269] [12 Regression] Bogus -Wuse-after-free seen in xen

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
I think this might be the same as PR 104232.

[Bug tree-optimization/95424] Failure to optimize division with numerator of 1

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

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

--- Comment #7 from CVS Commits  ---
The master branch has been updated by Jeff Law :

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

commit r12-6924-gc2b610e7c6c89fd422c5c31f01023bcddf3cf4a5
Author: Zhao Wei Liew 
Date:   Fri Jan 28 13:36:39 2022 -0500

match.pd: Simplify 1 / X for integer X [PR95424]

This patch implements an optimization for the following C++ code:

int f(int x) {
return 1 / x;
}

int f(unsigned int x) {
return 1 / x;
}

Before this patch, x86-64 gcc -std=c++20 -O3 produces the following
assembly:

f(int):
xor edx, edx
mov eax, 1
idiv edi
ret
f(unsigned int):
xor edx, edx
mov eax, 1
div edi
ret

In comparison, clang++ -std=c++20 -O3 produces the following assembly:

f(int):
lea ecx, [rdi + 1]
xor eax, eax
cmp ecx, 3
cmovb eax, edi
ret
f(unsigned int):
xor eax, eax
cmp edi, 1
sete al
ret

Clang's output is more efficient as it avoids expensive div operations.

With this patch, GCC now produces the following assembly:

f(int):
lea eax, [rdi + 1]
cmp eax, 2
mov eax, 0
cmovbe eax, edi
ret
f(unsigned int):
xor eax, eax
cmp edi, 1
sete al
ret

which is virtually identical to Clang's assembly output. Any slight
differences
in the output for f(int) is possibly related to a different missed
optimization.

v2: https://gcc.gnu.org/pipermail/gcc-patches/2022-January/587751.html
Changes from v2:
1. Refactor from using a switch statement to using the built-in
if-else statement.

v1: https://gcc.gnu.org/pipermail/gcc-patches/2022-January/587634.html
Changes from v1:
1. Refactor common if conditions.
2. Use build_[minus_]one_cst (type) to get -1/1 of the correct type.
3. Match only for TRUNC_DIV_EXPR and TYPE_PRECISION (type) > 1.

gcc/ChangeLog:

PR tree-optimization/95424
* match.pd: Simplify 1 / X where X is an integer.

[Bug target/104253] libgcc missing __floatdiif

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

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

--- Comment #6 from Jakub Jelinek  ---
(In reply to Michael Meissner from comment #4)
> Created attachment 52306 [details]
> Patch to use the correct names for __ibm128 converts if long double is IEEE
> 128-bit
> 
> The problem was internally there are 3 types for 128-bit floating point:
> TFmode -- mode for the type long double
> IFmode -- mode for __ibm128 if long double is IEEE 128-bit
> KFmode -- mode for __float128
> 
> There was not a conversion function specified to convert between IFmode and
> other modes, so the machine independent portion of the compiler created a
> name with 'if' in it.
> 
> This patch specifies the names for the conversion functions to use the
> traditional TF modes.

None of these functions except for the DI <-> IF (called tf) functions actually
exist in libgcc though.

[Bug fortran/104272] New: finalizer gets called during allocate

[kai.germaschewski at gmail dot com via Gcc-bugs]

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

Bug ID: 104272
   Summary: finalizer gets called during allocate
   Product: gcc
   Version: 9.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kai.germaschewski at gmail dot com
  Target Milestone: ---

Created attachment 52310
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52310&action=edit
reproducer

This issue appears to be present in gfortran-9,10,11. A minimal reproducer is
provided.

I have an abstract base class, from which one class is derived which itself is
further derived one more time. When allocating an array of the most-derived
type, for some reason the finalizer of the intermediate class is called. This
does not happen with ifort or xlf, and I don't think it should happen.

output:

 allocating
 solver_gpu_final<-- this being called is a bug (IMHO)
 allocating done
 solver_sparse_gpu_final
 solver_sparse_gpu_final
 solver_gpu_final
 solver_gpu_final

[Bug tree-optimization/95424] Failure to optimize division with numerator of 1

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

--- Comment #8 from Jeffrey A. Law  ---
Fixed on the trunk.

[Bug middle-end/19987] [meta-bug] fold missing optimizations in general

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

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

Bug 95424 Summary: Failure to optimize division with numerator of 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95424

   What|Removed |Added

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

[Bug testsuite/70230] 11 test regressions when building GCC 6 with --enable-default-ssp

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

--- Comment #7 from Jeffrey A. Law  ---
Fixed on the trunk.

[Bug c++/104255] parsing function signature fails when it uses a function parameter outside of an unevaluated context

[nickhuang99 at hotmail dot com via Gcc-bugs]

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

--- Comment #3 from qingzhe huang  ---
(In reply to Patrick Palka from comment #2)
> The error message is obscure, but it seems what GCC has issue with here is
> the use of the function parameter seq2 in the trailing return type occurring
> outside of an unevaluated context.
> 
The error messages are issued in a cascading fashion, the "outside function
parameter" is issued much later which maybe far-fetched from core one, in my
guess.


> I'm not totally sure if the testcase is valid
> (https://eel.is/c++draft/basic.scope.param#note-1 might suggest it's not?),
> but one workaround is to replace the use of seq2 in the trailing return type
> with decltype(seq2){} (which works because index_sequence is an empty type).

This is about "parameter-declaration-clause" which is not our case, because
"f(e)" is not function declaration part, instead an invoking of function of
which "e" is not "declaration" at all, but an argument of function.


> Here's a minimal testcase demonstrating the issue
> 
>   struct empty { };
>   constexpr int f(empty) { return 0; }
>   template struct A { };
>   auto g(empty e) -> A;

Again, GCC is only one rejecting this code
(https://www.godbolt.org/z/1bvMavKKd) which makes me suspect that GCC may not
be correct.


> which is rejected with
> 
>   error: use of parameter outside function body before ‘)’ token
> 
> due to 'e' being used outside of an unevaluated context within the signature
> of the function.

BTW, this has nothing to do with c++20(no -std=c++20 is needed) which
eliminates potential issues of many c++20 new features. Thank you for your
simplified case which is a much clearer one to demonstrate the core issue.

[Bug analyzer/104273] New: FAIL: gcc.dg/analyzer/pr103526.c (test for bogus messages, line 31)

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

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

Bug ID: 104273
   Summary: FAIL: gcc.dg/analyzer/pr103526.c  (test for bogus
messages, line 31)
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: danglin at gcc dot gnu.org
  Target Milestone: ---
  Host: hppa*-*-*
Target: hppa*-*-*
 Build: hppa*-*-*

spawn -ignore SIGHUP /home/dave/gnu/gcc/objdir64/gcc/xgcc
-B/home/dave/gnu/gcc/o
bjdir64/gcc/ /home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/analyzer/pr103526.c
-fd
iagnostics-plain-output -fanalyzer -Wanalyzer-too-complex
-fanalyzer-call-summar
ies -S -o pr103526.s
/home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/analyzer/pr103526.c: In function
'game_new':
/home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/analyzer/pr103526.c:31:1: warning:
leak of 'tmp.word_state' [CWE-401] [-Wanalyzer-malloc-leak]
/home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/analyzer/pr103526.c:20:31: note:
(1) allocated here
/home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/analyzer/pr103526.c:20:12: note:
(2) assuming 'tmp.word_state' is non-NULL
/home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/analyzer/pr103526.c:20:12: note:
(3) following 'false' branch...
/home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/analyzer/pr103526.c:22:21: note:
(4) ...to here
/home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/analyzer/pr103526.c:22:12: note:
(5) following 'false' branch (when 'rval' is non-NULL)...
/home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/analyzer/pr103526.c:24:9: note: (6)
...to here
/home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/analyzer/pr103526.c:31:1: note: (7)
'tmp.word_state' leaks here; was allocated at (1)
FAIL: gcc.dg/analyzer/pr103526.c  (test for bogus messages, line 31)
PASS: gcc.dg/analyzer/pr103526.c (test for excess errors)

[Bug analyzer/104274] New: FAIL: gcc.dg/analyzer/pr97029.c (test for excess errors)

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

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

Bug ID: 104274
   Summary: FAIL: gcc.dg/analyzer/pr97029.c (test for excess
errors)
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: danglin at gcc dot gnu.org
  Target Milestone: ---
  Host: hppa*-*-hpux*
Target: hppa*-*-hpux*
 Build: hppa*-*-hpux*

spawn -ignore SIGHUP /home/dave/gnu/gcc/objdir64/gcc/xgcc
-B/home/dave/gnu/gcc/o
bjdir64/gcc/ /home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/analyzer/pr97029.c
-fdi
agnostics-plain-output -fanalyzer -Wanalyzer-too-complex
-fanalyzer-call-summari
es -S -o pr97029.s
/home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/analyzer/pr97029.c: In function
'set
jmp':
/home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/analyzer/pr97029.c:6:3: warning:
use
 of uninitialized value 'pl.0' [CWE-457]
[-Wanalyzer-use-of-uninitialized-value]
/home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/analyzer/pr97029.c:6:3: note: (1)
us
e of uninitialized value 'pl.0' here
FAIL: gcc.dg/analyzer/pr97029.c (test for excess errors)
Excess errors:
/home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/analyzer/pr97029.c:6:3: warning:
use of uninitialized value 'pl.0' [CWE-457]
[-Wanalyzer-use-of-uninitialized-value]

[Bug target/101891] Adjust -fzero-call-used-regs to always use XOR

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

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

qinzhao at gcc dot gnu.org changed:

   What|Removed |Added

   Last reconfirmed||2022-01-28
 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1

[Bug target/104253] libgcc missing __floatdiif

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

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

--- Comment #7 from Jakub Jelinek  ---
Conversion from __ibm128 to float/double etc. are done differently, and for si
<-> if named tf we want to use di instead.
So, shouldn't we just add
+  set_conv_libfunc (sfix_optab, DImode, mode, "__fixtfdi");
+  set_conv_libfunc (ufix_optab, DImode, mode, "__fixunstfdi");
+
+  set_conv_libfunc (sfloat_optab, mode, DImode, "__floatditf");
+  set_conv_libfunc (ufloat_optab, mode, DImode, "__floatunditf");
and nothing else?

[Bug c++/92752] [9/10/11/12 Regression] Bogus "ignored qualifiers" warning on const-qualified pointer-to-member-function objects

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

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Patrick Palka :

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

commit r12-6926-ge971990cbda091b4caf5e1a5bded5121068934e4
Author: Patrick Palka 
Date:   Fri Jan 28 15:41:15 2022 -0500

c++: bogus warning with value init of const pmf [PR92752]

Here we're emitting a -Wignored-qualifiers warning for an intermediate
compiler-generated cast of nullptr to 'method-type* const' as part of
value initialization of a const pmf.  This patch suppresses the warning
by instead casting to the corresponding unqualified type.

PR c++/92752

gcc/cp/ChangeLog:

* typeck.cc (build_ptrmemfunc): Cast a nullptr constant to the
unqualified pointer type not the qualified one.

gcc/testsuite/ChangeLog:

* g++.dg/warn/Wignored-qualifiers2.C: New test.

Co-authored-by: Jason Merrill 

[Bug c++/92752] [9/10/11 Regression] Bogus "ignored qualifiers" warning on const-qualified pointer-to-member-function objects

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

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

Patrick Palka  changed:

   What|Removed |Added

Summary|[9/10/11/12 Regression] |[9/10/11 Regression] Bogus
   |Bogus "ignored qualifiers"  |"ignored qualifiers"
   |warning on const-qualified  |warning on const-qualified
   |pointer-to-member-function  |pointer-to-member-function
   |objects |objects

--- Comment #3 from Patrick Palka  ---
Fixed for GCC 12 so far.

[Bug tree-optimization/104275] New: Os does not apply return value optimization while O2 and O3 does

[andij.cr at gmail dot com via Gcc-bugs]

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

Bug ID: 104275
   Summary: Os does not apply return value optimization while O2
and O3 does
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: andij.cr at gmail dot com
  Target Milestone: ---

tested from gcc 8 to gcc 11

an identity function (mark) interposed in a call stack that ends in a complex
type is reasonably elided in O2 and O3, but at Os it creates a somewhat strange
assembly.
tested on arm32 and x86_64. 
for a less artificial example, where the problem still appears:
https://gcc.godbolt.org/z/GbKrGKa6f

code:

https://godbolt.org/z/v95jEvvzc

// condensed result of a constexpr trasformation.
// in this form, it would be nice if it was transparent to the value
template 
auto mark(Ts&& head) noexcept -> decltype(auto) {
return static_cast(head);
}

#include 
// generic producer of a complex type
auto generate() -> std::vector;


// here is a stack of functions using mark
namespace {
// in an anonymous namespace to nudge the compiler to inline them
auto user_base() { return mark(generate()); }
auto user_mark() { return mark(user_base()); }
auto user_mark2() { return mark(user_mark()); }
auto user_mark3() { return mark(user_mark2()); }
}  // namespace

// this function has a normal assembly at O2 and O3
// but a silly one at Os
auto user_mark4() { return mark(user_mark3()); }


compiled with 
-std=c++17 -O2

user_mark4():
pushr12
mov r12, rdi
sub rsp, 32
mov rdi, rsp
callgenerate()
mov rax, QWORD PTR [rsp]
mov QWORD PTR [r12], rax
mov rax, QWORD PTR [rsp+8]
mov QWORD PTR [r12+8], rax
mov rax, QWORD PTR [rsp+16]
mov QWORD PTR [r12+16], rax
add rsp, 32
mov rax, r12
pop r12
ret

compiled with
-std=c++17 -Os 
user_mark4():
pushr13
pushr12
mov r12, rdi
pushrbp
pushrbx
sub rsp, 40
lea rdi, [rsp+8]
callgenerate()
lea rdi, [rsp+8]
mov r13, QWORD PTR [rsp+8]
mov rbp, QWORD PTR [rsp+16]
mov QWORD PTR [rsp+8], 0
mov rbx, QWORD PTR [rsp+24]
mov QWORD PTR [rsp+16], 0
mov QWORD PTR [rsp+24], 0
callstd::_Vector_base
>::~_Vector_base() [base object destructor]
lea rdi, [rsp+8]
mov QWORD PTR [rsp+24], 0
mov QWORD PTR [rsp+16], 0
mov QWORD PTR [rsp+8], 0
callstd::_Vector_base
>::~_Vector_base() [base object destructor]
lea rdi, [rsp+8]
mov QWORD PTR [rsp+24], 0
mov QWORD PTR [rsp+16], 0
mov QWORD PTR [rsp+8], 0
callstd::_Vector_base
>::~_Vector_base() [base object destructor]
lea rdi, [rsp+8]
mov QWORD PTR [rsp+24], 0
mov QWORD PTR [rsp+16], 0
mov QWORD PTR [rsp+8], 0
callstd::_Vector_base
>::~_Vector_base() [base object destructor]
mov QWORD PTR [r12], r13
lea rdi, [rsp+8]
mov QWORD PTR [r12+8], rbp
mov QWORD PTR [r12+16], rbx
mov QWORD PTR [rsp+24], 0
mov QWORD PTR [rsp+16], 0
mov QWORD PTR [rsp+8], 0
callstd::_Vector_base
>::~_Vector_base() [base object destructor]
add rsp, 40
mov rax, r12
pop rbx
pop rbp
pop r12
pop r13
ret

[Bug c++/104177] coroutine frame is not being allocated with the correct alignment

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

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

Iain Sandoe  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2022-01-28

--- Comment #13 from Iain Sandoe  ---

the design that is agreed (by the coroutine "ABI group", at least) is this:

If the frame requires greater than pointer alignment * 2, we should place the
padding **BEFORE** the (resume*)() and (destroy*)() members - and the frame
pointer will continue to point to the (resume*)() member.  So that, from the
point of view of a continuing caller - there is no difference between such
frames and ones less-aligned.

This requires:
1. keeping some accounting information on the side so that the correct memory
can be freed.

2. having an allocator that honours alignment > 2 * pointer (well. I'd guess
most do that, but we really need the aligned allocator change, however [as
noted in the thread referenced] that change did not make C++20).  We can, of
course, follow clang.

3. ensuring that excess and user alignments are honoured in the placement of
frame entries (I wonder if we actually need to honour anything larger than then
stack would allow).



Fro my part, I completely agree that GCC coroutines should support fields will
suitable alignment for larger vector objects.  It's just a question of finding
time to implement the changes, as with all projects 

The idea is that coroutines form different compilers should be inter-callable
(even though the frame layout might be completely different beyond that
specified for ABI).

[Bug ipa/104275] Os causes some functions which are no-ops not to be inlined in some cases

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|tree-optimization   |ipa
 CC||marxin at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2022-01-28
 Ever confirmed|0   |1
Summary|Os does not apply return|Os causes some functions
   |value optimization while O2 |which are no-ops not to be
   |and O3 does |inlined in some cases
   Severity|normal  |enhancement

--- Comment #1 from Andrew Pinski  ---
This has nothing to do with RVO but rather inlining differences causes the
issue.

So the function which does not get inlined starts with:
void std::_Vector_base >::~_Vector_base (struct
_Vector_base * const this)
{
  double * _1;
  double * _2;
  long int _3;
  long unsigned int _10;

   [local count: 1073741824]:
  _2 = this_7(D)->_M_impl.D.21368._M_start;
  if (_2 != 0B)
goto ; [53.47%]
  else
goto ; [46.53%]
...
   [local count: 499612072]:
  goto ; [100.00%]
...
   [local count: 1073741824]:
  return;
}

But right before the function call to the deconstructor we have:

  MEM[(struct _Vector_impl_data &)&D.22678]._M_end_of_storage = 0B;
  MEM[(struct _Vector_impl_data &)&D.22678]._M_finish = 0B;
  MEM[(struct _Vector_impl_data &)&D.22678]._M_start = 0B;
  std::_Vector_base >::~_Vector_base
(&D.22678.D.22061);

So the deconstructor will be basically gone when inlined.

[Bug target/104253] libgcc missing __floatdiif

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

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

--- Comment #8 from Michael Meissner  ---
Yes, you are right.  I didn't remember which functions were generated by the
compiler, but I just did all of the conversion functions.

[Bug c++/104177] coroutine frame is not being allocated with the correct alignment

[ldalessandro at gmail dot com via Gcc-bugs]

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

--- Comment #14 from Luke Dalessandro  ---
Thanks for the information Iain. 

Is there something short-term where gcc could provide an "unimplemented"
failure or warning diagnostic for requests for coroutine frames with extended
alignment?

This could save a lot of debugging angst.

[Bug fortran/104228] [9/10/11/12 Regression] ICE in df_install_ref, at df-scan.cc:2294 since r8-3589-g707905d0773e5a8e

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

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

Mikael Morin  changed:

   What|Removed |Added

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

--- Comment #6 from Mikael Morin  ---
The full typespec is copied from the associate target (x) to the associate
symbol (y) at parse.cc:4925.  This includes the character length object, which
starting from there is shared between x and y.  None of the various conditions
are met in resolve_assoc_var to overwrite the character length object.  So when
we create the length decl (.y) for y and store it in its character length
object, it also appears in that of x at the same time.  And from there it is
added to both functions along a path that I have lost.

Draft patch:

diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/resolve.cc
index 835a4783718..266e41e25b1 100644
--- a/gcc/fortran/resolve.cc
+++ b/gcc/fortran/resolve.cc
@@ -9227,7 +9227,6 @@ resolve_assoc_var (gfc_symbol* sym, bool resolve_target)
sym->ts.u.cl = target->ts.u.cl;

   if (sym->ts.deferred && target->expr_type == EXPR_VARIABLE
- && target->symtree->n.sym->attr.dummy
  && sym->ts.u.cl == target->ts.u.cl)
{
  sym->ts.u.cl = gfc_new_charlen (sym->ns, NULL);

[Bug testsuite/99175] FAIL: g++.dg/modules/bad-mapper-1.C -std=c++17 (test for errors, line )

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Host|hppa*-*-hpux*   |
  Build|hppa*-*-hpux*   |
 Target|hppa*-*-hpux*   |

--- Comment #4 from Andrew Pinski  ---
I see this now on aarch64 too:
FAIL: g++.dg/modules/bad-mapper-3.C -std=c++17  at line 3 (test for errors,
line )
FAIL: g++.dg/modules/bad-mapper-3.C -std=c++17 (test for excess errors)
FAIL: g++.dg/modules/bad-mapper-3.C -std=c++2a  at line 3 (test for errors,
line )
FAIL: g++.dg/modules/bad-mapper-3.C -std=c++2a (test for excess errors)
FAIL: g++.dg/modules/bad-mapper-3.C -std=c++2b  at line 3 (test for errors,
line )
FAIL: g++.dg/modules/bad-mapper-3.C -std=c++2b (test for excess errors)

[Bug tree-optimization/103514] Missing XOR-EQ-AND Optimization

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

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Jeff Law :

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

commit r12-6928-gcb3ac1985a5332fa811a62844adb33ca140bd4ba
Author: Navid Rahimi 
Date:   Fri Jan 28 17:11:30 2022 -0500

tree-optimization/103514 Missing XOR-EQ-AND Optimization

This patch will add the missed pattern described in bug 103514 [1] to the
match.pd. [1] includes proof of correctness for the patch too.

1) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103514

gcc/
PR tree-optimization/103514
* match.pd (a & b) ^ (a == b) -> !(a | b): New optimization.
(a & b) == (a ^ b) -> !(a | b): New optimization.

gcc/testsuite
* gcc.dg/tree-ssa/pr103514.c: Testcase for this optimization.

[Bug tree-optimization/103514] Missing XOR-EQ-AND Optimization

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

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

Navid Rahimi  changed:

   What|Removed |Added

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

--- Comment #4 from Navid Rahimi  ---
Thanks Jeff.

[Bug fortran/101135] Load of null pointer when passing absent assumed-shape array argument for an optional dummy argument

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

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

--- Comment #4 from anlauf at gcc dot gnu.org ---
Created attachment 52311
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52311&action=edit
Patch that regtests ok.

The patch suggested by the reporter is rather close to this one.

We need to special-case optional arguments of procedures with bind(c)
attribute.  I haven't understood the details yet, but excluding those
prevents regressions in the c-binding testsuite, e.g. bind-c-contiguous-4.*.

We need to fix the pattern for testcase
gfortran.dg/missing_optional_dummy_6a.f90
which would have failed with -fsanitize=undefined without this patch.

[Bug target/104253] libgcc missing __floatdiif

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

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

Michael Meissner  changed:

   What|Removed |Added

  Attachment #52306|0   |1
is obsolete||

--- Comment #9 from Michael Meissner  ---
Created attachment 52312
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52312&action=edit
Replacement patch for fixing the integer <-> __ibm128 conversions if long
double is IEEE 128-bit.

Replacement for patch #2 that only modifies the names that are used.

[Bug c++/104255] parsing function signature fails when it uses a function parameter outside of an unevaluated context

[nickhuang99 at hotmail dot com via Gcc-bugs]

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

--- Comment #4 from qingzhe huang  ---
(In reply to Patrick Palka from comment #2)

> 
>   error: use of parameter outside function body before ‘)’ token
> 
> due to 'e' being used outside of an unevaluated context within the signature
> of the function.

Sorry for my being unable to grasp your meaning before. Now I can see your
point that the "e" of A is from declaration of parameter of function "g".
Now that we agree the value from parameter clause should not be used in
trailing return type, then it should also not be used in requires clause etc. 
(https://eel.is/c++draft/basic.scope.param#1.3)
But this works:

template
auto f(int n) requires (n>0);

This is violating our assumption. So, I am not convinced that 
(https://eel.is/c++draft/basic.scope.param#note-1)
"A function parameter cannot be used for its value within the
parameter-declaration-clause" is really meaningful. Or I misunderstand it???


https://www.godbolt.org/z/759oGdr94

[Bug analyzer/104270] -Wanalyzer-use-of-uninitialized-value is incorrectly suppressed by -ftrivial-auto-var-init=

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2022-01-28
   Keywords||diagnostic

--- Comment #1 from Andrew Pinski  ---
Confirmed. I suspect it should be easy to treat DEFERRED_INIT as similar to ssa
names that are (D).

[Bug analyzer/104273] FAIL: gcc.dg/analyzer/pr103526.c (test for bogus messages, line 31)

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Dup of bug 103872. I suspect the strict alignment targets cause the difference.

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

[Bug analyzer/103872] testcase fail in gcc.dg/analyzer/pr103526.c on riscv64-unknown-elf-gcc

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||danglin at gcc dot gnu.org

--- Comment #1 from Andrew Pinski  ---
*** Bug 104273 has been marked as a duplicate of this bug. ***