[Bug target/106228] [13 regression] r13-1457-g10b502fb78351a causes bootstrap failure

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

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

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

https://gcc.gnu.org/g:79f18ac6b7ab7744fcf8937ea4bc0c40f3efc629

commit r13-1599-g79f18ac6b7ab7744fcf8937ea4bc0c40f3efc629
Author: Richard Biener 
Date:   Mon Jul 11 09:23:50 2022 +0200

tree-optimization/106228 - fix vect_setup_realignment virtual SSA handling

The following adds missing assignment of a virtual use operand to a
created load to vect_setup_realignment which shows as bootstrap
failure on powerpc64-linux and extra testsuite fails for targets
when misaligned loads are not supported or not optimal.

PR tree-optimization/106228
* tree-vect-data-refs.cc (vect_setup_realignment): Properly
set a VUSE operand on the emitted load.

[Bug target/106228] [13 regression] r13-1457-g10b502fb78351a causes bootstrap failure

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

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/106246] [13 Regression] powerpc-darwin9 bootstrap fails after r13-1575-gcf3a120084e946 ICE vect_transform_loops, at tree-vectorizer.cc:1032

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

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

--- Comment #4 from Richard Biener  ---
I've now pushed the fix for PR106228, so maybe you can re-try.

[Bug tree-optimization/106249] [13 Regression] ICE in check_loop_closed_ssa_def, at tree-ssa-loop-manip.cc:645

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

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

Richard Biener  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2022-07-11

--- Comment #1 from Richard Biener  ---
Confirmed.  The issue is that __builtin_unreachable () is 'const' while
__builtin_trap () is neither 'const' nor 'pure'.  Passes inserting
__builtin_unreachable () rightfully expect 'unreachable' semantics.

IMHO changing __builtin_unreachable to __builtin_trap under-the-hood was a
very wrong thing to do.

Can we reconsider that please?

[Bug tree-optimization/106249] [13 Regression] ICE in check_loop_closed_ssa_def, at tree-ssa-loop-manip.cc:645

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

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

--- Comment #2 from Richard Biener  ---
DEF_GCC_BUILTIN(BUILT_IN_TRAP, "trap", BT_FN_VOID,
ATTR_NORETURN_NOTHROW_LEAF_COLD_LIST)
DEF_GCC_BUILTIN(BUILT_IN_UNREACHABLE, "unreachable", BT_FN_VOID,
ATTR_CONST_NORETURN_NOTHROW_LEAF_COLD_LIST)

[Bug tree-optimization/106249] [13 Regression] ICE in check_loop_closed_ssa_def, at tree-ssa-loop-manip.cc:645

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

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

--- Comment #3 from Richard Biener  ---
Maybe just make frontend / user inserted __builtin_unreachable ()s trap but not
middle-end inserted ones which are generally only to aid DCE?  Thus, rewrite
them at gimplification time instead of hacking the delcs to be the same?

[Bug tree-optimization/106234] [13 Regression] stack overflow from range_from_dom

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

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

--- Comment #3 from Richard Biener  ---
(In reply to Andrew Macleod from comment #2)
> Created attachment 53281 [details]
> proposed patch
> 
> we're having some connection issues, but I am in the process of trying to
> test the  attached patch.
> 
> basically, when we were ensuring the range was set in the immediate
> dominator, I was *suppose* to first check to see if it was already set and
> not make the call... like the other call sites... Doh!
> 
> Without that, it was possible for this to be quadratic when the correct
> circumstances were presented.. as in this case.  It walks the dominator
> chain all the way to the top, not utilizing the cache.
> 
> this should make it linear again.   speedup in your testcase for VRP was
> noticable.
> 
> Let me know if it resolves your problem..   and I wil continue the test cycle

Yes, that resolves my problem with the deep recursion.

Thanks!

[Bug c++/106251] New: gcov indicates actually executed line as not covered by the test

[olgierd.sobinski at nokia dot com via Gcc-bugs]

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

Bug ID: 106251
   Summary: gcov indicates actually executed line as not covered
by the test
   Product: gcc
   Version: 9.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: olgierd.sobinski at nokia dot com
  Target Milestone: ---

Created attachment 53285
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53285&action=edit
false miscoverage

Hello,

Using gcov we found an incorrect detection of 'missing line coverage':
If the "return std::tie(" is separate line it is not detected as covered by the
test(even though it is in fact).
It the "return std::tie(" is followed by arguments in the same line then all is
fine. Please also see the attachment.

// false 'miscoverage' case:
inline bool operator==(const DrbInfo& lhs, const DrbInfo& rhs)
{
return std::tie(
lhs.drbIdentity, lhs.pduSessionFwdTunnelStatus, lhs.bearerIndex,
lhs.pdcpBearerGroup, lhs.defaultDrb) ==
std::tie(rhs.drbIdentity, rhs.pduSessionFwdTunnelStatus,
rhs.bearerIndex, rhs.pdcpBearerGroup, rhs.defaultDrb);
}

// OK case
inline bool operator==(const DrbInfo& lhs, const DrbInfo& rhs)
{
return std::tie(lhs.drbIdentity, lhs.pduSessionFwdTunnelStatus,
lhs.bearerIndex, lhs.pdcpBearerGroup, lhs.defaultDrb) ==
std::tie(rhs.drbIdentity, rhs.pduSessionFwdTunnelStatus,
rhs.bearerIndex, rhs.pdcpBearerGroup, rhs.defaultDrb);
}

Thx in advance for checking/info if fixed in subsequent gcc versions!

br,
Olgierd

[Bug tree-optimization/106246] [13 Regression] powerpc-darwin9 bootstrap fails after r13-1575-gcf3a120084e946 ICE vect_transform_loops, at tree-vectorizer.cc:1032

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

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

Iain Sandoe  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #5 from Iain Sandoe  ---
actually fails sooner - Ada and libstdc++ stage1 fail to build (constraint/bus
errors).

this is from a cross (which I realise you will not be able to replicate,
without the sysroot etc.)  If the reason is non-obvious, I'll try a reduction
later..

/scratch/10-15-cat/gcc-master-x-powerpc/./gcc/cc1plus -fpreprocessed
cxx11-locale-inst.ii -feliminate-unused-debug-symbols -fPIC -quiet -dumpbase
cxx11-locale-inst.cc -dumpbase-ext .cc -mmacosx-version-min=10.5 -g -O2 -Wall
-Wextra -Wwrite-strings -Wcast-qual -Wabi=2 -std=gnu++11 -version
-fno-implicit-templates -fdiagnostics-show-location=once -ffunction-sections
-fdata-sections -frandom-seed=cxx11-locale-inst.lo -fno-common -o
cxx11-locale-inst.s

* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS
(code=1, address=0x8)
frame #0: 0x000101ca6d94
cc1plus`vect_setup_realignment(vinfo=0x000106fb50e0,
stmt_info=0x000106fb3aa0, gsi=0x7ffeefbfe720,
realignment_token=0x7ffeefbfdc70,
alignment_support_scheme=dr_explicit_realign, init_addr=0x00010aa73e58,
at_loop=0x7ffeefbfdc60) at tree-vect-data-refs.cc:5784:32
   5781 pe = loop_preheader_edge (loop_for_initial_load);
   5782 
   5783   tree vuse;
-> 5784   gphi *vphi = get_virtual_phi (loop_for_initial_load->header);
   5785   if (vphi)
   5786 vuse = PHI_ARG_DEF_FROM_EDGE (vphi, pe);
   5787   else


  * frame #0: 0x000101ca6d94
cc1plus`vect_setup_realignment(vinfo=0x000106fb50e0,
stmt_info=0x000106fb3aa0, gsi=0x7ffeefbfe720,
realignment_token=0x7ffeefbfdc70,
alignment_support_scheme=dr_explicit_realign, init_addr=0x00010aa73e58,
at_loop=0x7ffeefbfdc60) at tree-vect-data-refs.cc:5784:32
frame #1: 0x000101cd5882
cc1plus`::vectorizable_load(vinfo=0x000106fb50e0,
stmt_info=0x000106fb3aa0, gsi=0x7ffeefbfe720,
vec_stmt=0x7ffeefbfe648, slp_node=0x000109488098,
cost_vec=0x) at tree-vect-stmts.cc:9608:34
frame #2: 0x000101cdbe66
cc1plus`vect_transform_stmt(vinfo=0x000106fb50e0,
stmt_info=0x000106fb3aa0, gsi=0x7ffeefbfe720,
slp_node=0x000109488098, slp_node_instance=0x000106830140) at
tree-vect-stmts.cc:11332:32
frame #3: 0x000101d40be4
cc1plus`::vect_schedule_slp_node(vinfo=0x000106fb50e0,
node=0x000109488098, instance=0x000106830140) at
tree-vect-slp.cc:7438:25
frame #4: 0x000101d41725
cc1plus`::vect_schedule_scc(vinfo=0x000106fb50e0, node=0x000109488098,
instance=0x000106830140, scc_info=0x7ffeefbfea40,
maxdfs=0x7ffeefbfea3c, stack=0x7ffeefbfea28) at
tree-vect-slp.cc:7633:30
frame #5: 0x000101d415e3
cc1plus`::vect_schedule_scc(vinfo=0x000106fb50e0, node=0x000109488010,
instance=0x000106830140, scc_info=0x7ffeefbfea40,
maxdfs=0x7ffeefbfea3c, stack=0x7ffeefbfea28) at
tree-vect-slp.cc:7614:22
frame #6: 0x000101d41e03
cc1plus`vect_schedule_slp(vinfo=0x000106fb50e0,
slp_instances=0x000106830170) at tree-vect-slp.cc:7750:20
frame #7: 0x000101d3b97c
cc1plus`::vect_slp_region(bbs=vec @
0x7ffeefbfebe8, datarefs=vec @
0x7ffeefbfebe0, dataref_groups=0x7ffeefbff050, n_stmts=98,
orig_loop=0x) at tree-vect-slp.cc:6056:26
frame #8: 0x000101d3c26a cc1plus`::vect_slp_bbs(bbs=0x7ffeefbff0d8,
orig_loop=0x) at tree-vect-slp.cc:6168:26
frame #9: 0x000101d3c752
cc1plus`vect_slp_function(fun=0x00010aa8a678) at tree-vect-slp.cc:6256:23
frame #10: 0x000101d5c847
cc1plus`pass_slp_vectorize::execute(this=0x000106b113e0,
fun=0x00010aa8a678) const at tree-vectorizer.cc:1532:21
frame #11: 0x0001016e3116
cc1plus`execute_one_pass(pass=0x000106b113e0) at passes.cc:2644:30
frame #12: 0x0001016e34fd
cc1plus`::execute_pass_list_1(pass=0x000106b113e0) at passes.cc:2744:28
frame #13: 0x0001016e352e
cc1plus`::execute_pass_list_1(pass=0x000106b11380) at passes.cc:2745:22
frame #14: 0x0001016e352e
cc1plus`::execute_pass_list_1(pass=0x000106b0f250) at passes.cc:2745:22
frame #15: 0x0001016e3594
cc1plus`execute_pass_list(fn=0x00010aa8a678, pass=0x000106b0ef50) at
passes.cc:2755:23
frame #16: 0x000100efdf96
cc1plus`cgraph_node::expand(this=0x00010a752110) at cgraphunit.cc:1834:21
frame #17: 0x000100efe76f cc1plus`::expand_all_functions() at
cgraphunit.cc:1998:17
frame #18: 0x000100eff4b4
cc1plus`symbol_table::compile(this=0x000106c06000) at cgraphunit.cc:2348:24
frame #19: 0x000100eff921
cc1plus`symbol_table::finalize_compilation_unit(this=0x000106c06000) at
cgraphunit.cc:2529:11
frame #20: 0x0001018af3ef cc1pl

[Bug tree-optimization/106246] [13 Regression] powerpc-darwin9 bootstrap fails after r13-1575-gcf3a120084e946 ICE vect_transform_loops, at tree-vectorizer.cc:1032

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

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

--- Comment #6 from Iain Sandoe  ---
as noted on IRC, of course this could be unrelated, since other changes have
been committed in the meantime.

[Bug lto/106170] [13 Regression] x86_64-w64-mingw32 host GCC with win32 thread model does not provide pthread.h. lto-plugin fails with canadian compilation

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

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #15 from Martin Liška  ---
Feel free to provide Windows implementation of the critical section.

[Bug rtl-optimization/105459] [12/13 Regression] ICE: Segmentation fault (in record_operand_costs) since r12-3721-g63c6446f77b9001d

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

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

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

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

commit r13-1600-g4c94382a132a4b2b9d020806549a006fa6764d1b
Author: Richard Biener 
Date:   Fri Jul 1 14:11:35 2022 +0200

target/105459 - allow delayed target option node fixup

The following avoids the need to massage the target optimization
node at WPA time when we fixup the optimization node, copying
FP related flags from callee to caller.  The target is already
set up to fixup, but that only works when not switching between
functions.  After fixing that the fixup is then done at LTRANS
time when materializing the function.

2022-07-01  Richard Biener  

PR target/105459
* config/i386/i386-options.cc (ix86_set_current_function):
Rebuild the target optimization node whenever necessary,
not only when the optimization node didn't change.

* gcc.dg/lto/pr105459_0.c: New testcase.

[Bug rtl-optimization/105459] [12 Regression] ICE: Segmentation fault (in record_operand_costs) since r12-3721-g63c6446f77b9001d

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

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

Richard Biener  changed:

   What|Removed |Added

   Assignee|linkw at gcc dot gnu.org   |rguenth at gcc dot 
gnu.org
  Known to work||13.0
Summary|[12/13 Regression] ICE: |[12 Regression] ICE:
   |Segmentation fault (in  |Segmentation fault (in
   |record_operand_costs) since |record_operand_costs) since
   |r12-3721-g63c6446f77b9001d  |r12-3721-g63c6446f77b9001d

--- Comment #14 from Richard Biener  ---
Fixed on trunk, mine for backporting.

[Bug preprocessor/106252] New: [13 Regression] AddressSanitizer: global-buffer-overflow on address since r13-1544-ge46f4d7430c521

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

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

Bug ID: 106252
   Summary: [13 Regression] AddressSanitizer:
global-buffer-overflow on address since
r13-1544-ge46f4d7430c521
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: preprocessor
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: lhyatt at gcc dot gnu.org
  Target Milestone: ---

Since the revision the following ASAN error is reported:

/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-asan/objdir/gcc/xgcc
-B/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-asan/objdir/gcc/
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-asan/build/gcc/testsuite/c-c++-common/pragma-diag-13.c
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-asan/build/gcc/testsuite/c-c++-common/pragma-diag-13.c:2:54:
warning: missing ‘error’, ‘warning’, ‘ignored’, ‘push’, ‘pop’, or
‘ignored_attributes’ after ‘#pragma GCC diagnostic’ [-Wpragmas]
2 | #pragma GCC diagnostic /* { dg-warning "missing" } */
  |  ^
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-asan/build/gcc/testsuite/c-c++-common/pragma-diag-13.c:3:24:
warning: expected ‘error’, ‘warning’, ‘ignored’, ‘push’, ‘pop’,
‘ignored_attributes’ after ‘#pragma GCC diagnostic’ [-Wpragmas]
3 | #pragma GCC diagnostic warn /* { dg-warning "24:expected" } */
  |^~~~
=
==4798==ERROR: AddressSanitizer: global-buffer-overflow on address
0x05e9d1fc at pc 0x00a5903c bp 0x7fffc310 sp 0x7fffc308
READ of size 4 at 0x05e9d1fc thread T0
#0 0xa5903b in handle_pragma_diagnostic_impl
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-asan/build/gcc/c-family/c-pragma.cc:1013
#1 0xa5903b in handle_pragma_diagnostic
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-asan/build/gcc/c-family/c-pragma.cc:1070
#2 0x8d77d1 in c_parser_pragma
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-asan/build/gcc/c/c-parser.cc:12640
#3 0x960b55 in c_parser_external_declaration
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-asan/build/gcc/c/c-parser.cc:1768
#4 0x962040 in c_parser_translation_unit
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-asan/build/gcc/c/c-parser.cc:1660
#5 0x962040 in c_parse_file()
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-asan/build/gcc/c/c-parser.cc:23540
#6 0xa4dcee in c_common_parse_file()
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-asan/build/gcc/c-family/c-opts.cc:1235
#7 0x1bc699f in compile_file
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-asan/build/gcc/toplev.cc:452
#8 0x70ebb9 in do_compile
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-asan/build/gcc/toplev.cc:2146
#9 0x70ebb9 in toplev::main(int, char**)
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-asan/build/gcc/toplev.cc:2298
#10 0x719203 in main
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-asan/build/gcc/main.cc:39
#11 0x778405af in __libc_start_call_main
../sysdeps/nptl/libc_start_call_main.h:58
#12 0x77840678 in __libc_start_main_impl ../csu/libc-start.c:392
#13 0x71a624 in _start
(/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-asan/objdir/gcc/cc1+0x71a624)

0x05e9d1fc is located 36 bytes to the left of global variable 'cl_enums'
defined in 'options.cc:1282:22' (0x5e9d220) of size 2976
0x05e9d1fc is located 20 bytes to the right of global variable 'lang_names'
defined in 'options.cc:3187:20' (0x5e9d180) of size 104
SUMMARY: AddressSanitizer: global-buffer-overflow
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-asan/build/gcc/c-family/c-pragma.cc:1013
in handle_pragma_diagnostic_impl
Shadow bytes around the buggy address:
  0x80bcb9e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x80bcb9f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x80bcba00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x80bcba10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x80bcba20: 00 00 00 00 00 00 00 00 00 00 00 00 f9 f9 f9 f9
=>0x80bcba30: 00 00 00 00 00 00 00 00 00 00 00 00 00 f9 f9[f9]
  0x80bcba40: f9 f9 f9 f9 00 00 00 00 00 00 00 00 00 00 00 00
  0x80bcba50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x80bcba60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x80bcba70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x80bcba80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:   00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:   fa
  Freed heap region:   fd
  Stack left redzone:  f1
  Stack mid redzone: 

[Bug tree-optimization/106246] [13 Regression] powerpc-darwin9 bootstrap fails after r13-1575-gcf3a120084e946 ICE vect_transform_loops, at tree-vectorizer.cc:1032

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

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

--- Comment #7 from Richard Biener  ---
OK, indeed this is caused by my most recent change.  The following should fix
this, I'm going to test this on x86_64-linux (no convenient ppc testing machine
available for me right now)

diff --git a/gcc/tree-vect-data-refs.cc b/gcc/tree-vect-data-refs.cc
index 53e52cb58cb..609cacc4971 100644
--- a/gcc/tree-vect-data-refs.cc
+++ b/gcc/tree-vect-data-refs.cc
@@ -5777,14 +5777,14 @@ vect_setup_realignment (vec_info *vinfo, stmt_vec_info
stmt_info,
   if (at_loop)
 *at_loop = loop_for_initial_load;

+  tree vuse = NULL_TREE;
   if (loop_for_initial_load)
-pe = loop_preheader_edge (loop_for_initial_load);
-
-  tree vuse;
-  gphi *vphi = get_virtual_phi (loop_for_initial_load->header);
-  if (vphi)
-vuse = PHI_ARG_DEF_FROM_EDGE (vphi, pe);
-  else
+{
+  pe = loop_preheader_edge (loop_for_initial_load);
+  if (gphi *vphi = get_virtual_phi (loop_for_initial_load->header))
+   vuse = PHI_ARG_DEF_FROM_EDGE (vphi, pe);
+}
+  if (!vuse)
 vuse = gimple_vuse (gsi_stmt (*gsi));

   /* 3. For the case of the optimized realignment, create the first vector

[Bug preprocessor/106252] [13 Regression] AddressSanitizer: global-buffer-overflow on address since r13-1544-ge46f4d7430c521

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

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

Martin Liška  changed:

   What|Removed |Added

   Last reconfirmed||2022-07-11
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Target Milestone|--- |13.0

[Bug tree-optimization/106250] [13 Regression] ICE in optab_for_tree_code, at optabs-tree.cc:96

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

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

Martin Liška  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 CC||marxin at gcc dot gnu.org
   Last reconfirmed||2022-07-11
 Status|UNCONFIRMED |NEW

[Bug preprocessor/106252] [13 Regression] AddressSanitizer: global-buffer-overflow on address since r13-1544-ge46f4d7430c521

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug tree-optimization/106250] [13 Regression] ICE in optab_for_tree_code, at optabs-tree.cc:96

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |13.0
   Keywords||needs-reduction

[Bug target/106228] [13 regression] r13-1457-g10b502fb78351a causes bootstrap failure

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

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

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

https://gcc.gnu.org/g:415d2c38edadf97950eb14b8d7e6b1491c98cdd5

commit r13-1603-g415d2c38edadf97950eb14b8d7e6b1491c98cdd5
Author: Richard Biener 
Date:   Mon Jul 11 12:07:05 2022 +0200

tree-optimization/106228 - fixup last change

The following fixes the last commit to honor the case we are not
vectorizing a loop.

PR tree-optimization/106228
* tree-vect-data-refs.cc (vect_setup_realignment): Adjust
VUSE compute for the non-loop case.

[Bug tree-optimization/106253] New: [13 Regression] ICE in vect_transform_loops, at tree-vectorizer.cc:1032x

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

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

Bug ID: 106253
   Summary: [13 Regression] ICE in vect_transform_loops, at
tree-vectorizer.cc:1032x
   Product: gcc
   Version: 13.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: rguenth at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-linux-gnu
Target: aarch64-linux-gnu

Created attachment 53286
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53286&action=edit
Reduced test-case

The following crashes (reduced from polyhedron/rnflow):

$ aarch64-linux-gnu-gcc rnflow.f90 -O3 -c
during GIMPLE pass: vect
rnflow.f90:33:24:

   33 |   end program rnflow
  |^
internal compiler error: in vect_transform_loops, at tree-vectorizer.cc:1032
0x7028cc vect_transform_loops
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/tree-vectorizer.cc:1032
0xf9e433 try_vectorize_loop_1
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/tree-vectorizer.cc:1153
0xf9e433 try_vectorize_loop
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/tree-vectorizer.cc:1183
0xf9e964 execute
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/tree-vectorizer.cc:1299
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/106253] [13 Regression] ICE in vect_transform_loops, at tree-vectorizer.cc:1032

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

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

Martin Liška  changed:

   What|Removed |Added

   Last reconfirmed||2022-07-11
   Target Milestone|--- |13.0
 Status|UNCONFIRMED |NEW
Summary|[13 Regression] ICE in  |[13 Regression] ICE in
   |vect_transform_loops, at|vect_transform_loops, at
   |tree-vectorizer.cc:1032x|tree-vectorizer.cc:1032
 Ever confirmed|0   |1

[Bug gcov-profile/106251] gcov indicates actually executed line as not covered by the test

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

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
 Ever confirmed|0   |1
   Last reconfirmed||2022-07-11

--- Comment #1 from Martin Liška  ---
Please provide a self-contained test case I can run.

[Bug tree-optimization/106250] [13 Regression] ICE in optab_for_tree_code, at optabs-tree.cc:96 since r13-1468-g76c3041b856cb0

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

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

Martin Liška  changed:

   What|Removed |Added

 CC||rsandifo at gcc dot gnu.org
Summary|[13 Regression] ICE in  |[13 Regression] ICE in
   |optab_for_tree_code, at |optab_for_tree_code, at
   |optabs-tree.cc:96   |optabs-tree.cc:96 since
   ||r13-1468-g76c3041b856cb0
   Keywords|needs-bisection |

--- Comment #1 from Martin Liška  ---
Started with r13-1468-g76c3041b856cb0.

[Bug c++/106241] compiler can't handle large array of strings

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

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

--- Comment #7 from Jonathan Wakely  ---
(In reply to Robert Durkacz from comment #3)
> So I guess the compiler just does not address this particular kind of use
> case but it seems to me that, on the contrary, there should be a compilation
> capability to do this kind of thing.

The problem is that "this kind of thing" is completely unreasonable. The
element type of the array (Form_map) has a non-trivial destructor that needs to
deallocate the strings' memory. That means that the initializer for the array
compiles to code like:

try {
  form_array[0] = {"ADP", {"ADP", "s{NGDAILV}|mq_"}};
  try {
form_array[1] = {"ADP", {"ADP", "s{NGDAILV}|mq_"}};
try {
  form_array[2] = {"ADP", {"ADP", "s{NGDAILV}|mq_"}};
  // ... 5.2 million more try-catch blocks
} catch (...) {
  form_array[2].~Form_map();
  throw;
}
  } catch (...) {
form_array[1].~Form_map();
throw;
  }
} catch (...) {
  form_array[0].~Form_map();
  throw;
}

The code to do that 5.2 million times is not easy to compile. And it's not
really a sensible thing to try to compile. Just because all the construction
and destruction is hidden inside std::string ctors and dtors doesn't make it a
good idea. You're still asking for all that work to be done in a global
initializer before main() even starts.

Creating a trivial type that just holds a const char* is easy, there is no
allocation, no non-trivial destructor, so no exceptions possible and so nothing
needs to be caught or rethrown.

[Bug libstdc++/106248] operator>>std::basic_istream at boundary condition behave differently in different opt levels

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

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

--- Comment #2 from Jonathan Wakely  ---
I haven't analyzed it yet but this is probably due to r11-2581-g17abcc77341584

[Bug tree-optimization/106250] [13 Regression] ICE in optab_for_tree_code, at optabs-tree.cc:96 since r13-1468-g76c3041b856cb0

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

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

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

--- Comment #2 from rsandifo at gcc dot gnu.org  
---
Oops, seems that optab_vector was needed after all.

[Bug tree-optimization/106253] [13 Regression] ICE in vect_transform_loops, at tree-vectorizer.cc:1032

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

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

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 libstdc++/106248] [11/12/13 Regression] operator>>std::basic_istream at boundary condition behave differently in different opt levels

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Last reconfirmed||2022-07-11
 Status|UNCONFIRMED |NEW
Summary|operator>>std::basic_istrea |[11/12/13 Regression]
   |m at boundary condition |operator>>std::basic_istrea
   |behave differently in   |m at boundary condition
   |different opt levels|behave differently in
   ||different opt levels
  Known to fail||11.1.0
 Ever confirmed|0   |1
  Known to work||10.4.0

--- Comment #3 from Jonathan Wakely  ---
In C++20 mode the operator>> overload has changed to one that binds to char
(&)[10] and so knows the size of the output buffer. The loop stops reading when
it has written as many chars as will fit in the buffer, and does not set
eofbit:

  if (__extracted < __num - 1
  && __traits_type::eq_int_type(__c, __eof))
__err |= ios_base::eofbit;

In pre-C++20 modes, operator>> just binds to a const char* and will overflow it
if the buffer is not big enough. However, libstdc++ now uses
__builtin_object_size to detect the size of the buffer, and so will stop
writing when the buffer is full. That detection using __builtin_object_size
only works when optimization is enabled, which is why we stop before setting
the eofbit when optimizing.

I don't want to just remove the size detection, because it prevents undefined
behaviour. But we need a way to prevent overflow without altering the
observable behaviour for C++17 and earlier.

[Bug libstdc++/106248] [11/12/13 Regression] operator>>std::basic_istream at boundary condition behave differently in different opt levels

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

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

--- Comment #4 from Jonathan Wakely  ---
To put it another way, in C++17 and earlier, writing the buffer stops because
we reach EOF when reading from the istream. If it *didn't* stop there, it would
overflow the buffer and have undefined behaviour. But luckily the program used
the correct buffer size, and EOF happens at just the right time to prevent
overflow. This is the behaviour required by the C++17 standard.

In C++20, writing to the buffer stops because we know the buffer is full and
will not allow it to overflow. That means we don't detect that the input stream
reached EOF, because we don't even try to read any more characters. This is the
behaviour required by the C++20 standard.

The "bug" is that for C++17 mode we use GCC's ability to detect buffer sizes to
provide the safer C++20 behaviour, but that's only possible when optimizing.

[Bug libstdc++/106248] [11/12/13 Regression] operator>>std::basic_istream at boundary condition behave differently in different opt levels

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

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

--- Comment #5 from Jonathan Wakely  ---
(In reply to Andrew Pinski from comment #1)
> This is interesting because I get the same behavior in clang with LLVM's
> libc++.

Are you sure? I do not see any dependency on optimization level when using
libc++.

> Also with -std=c++20 I get the value 0 for all optimization levels.

I *do* see a change in behaviour for C++17 vs C++20 when using libc++, which is
expected for the reasons already given.

[Bug preprocessor/106252] [13 Regression] AddressSanitizer: global-buffer-overflow on address since r13-1544-ge46f4d7430c521

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

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

Lewis Hyatt  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |lhyatt at gcc dot 
gnu.org

--- Comment #1 from Lewis Hyatt  ---
Thanks, and sorry about that, I will fix it now. BTW, am I missing an argument
to configure or something such that I would have seen this? Or this is
something external to the main testsuite?

[Bug libstdc++/106248] [11/12/13 Regression] operator>>std::basic_istream at boundary condition behave differently in different opt levels

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

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

--- Comment #6 from Jonathan Wakely  ---
I think this would restore the previous behaviour without losing the overflow
prevention:

--- a/libstdc++-v3/include/std/istream
+++ b/libstdc++-v3/include/std/istream
@@ -813,8 +813,17 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   else
{
  if (__n == (size_t)-1)
-   __n = __gnu_cxx::__numeric_traits::__max;
- std::__istream_extract(__in, __s, __n / sizeof(_CharT));
+   {
+ __n = __gnu_cxx::__numeric_traits::__max;
+ std::__istream_extract(__in, __s, __n / sizeof(_CharT));
+   }
+ else
+   {
+ std::__istream_extract(__in, __s, __n / sizeof(_CharT));
+ if (__in.good() && _Traits::eq_int_type(__in.rdbuf()->snextc(),
+ _Traits::eof()))
+   __in.setstate(ios_base::eofbit);
+   }
}
   return __in;
 }

[Bug preprocessor/106252] [13 Regression] AddressSanitizer: global-buffer-overflow on address since r13-1544-ge46f4d7430c521

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

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

--- Comment #2 from Martin Liška  ---
It's a ASAN bootstrap that needs the following configure option:
--with-build-config=bootstrap-asan

[Bug target/106253] [13 Regression] ICE in vect_transform_loops, at tree-vectorizer.cc:1032

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

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|NEW
   Assignee|rguenth at gcc dot gnu.org |unassigned at gcc dot 
gnu.org
  Component|tree-optimization   |target
 CC||rsandifo at gcc dot gnu.org

--- Comment #2 from Richard Biener  ---
# .MEM = VDEF <.MEM>
vect__19.49_45 = __builtin_aarch64_lroundv4sfv4si (vect__18.48_44);

aarch64 lround vectorized builtin does not have the same guarantees
as the builtin.def one.  It's good that those cases are now uncovered
(I've already fixed a similar case in the x86 backend).

Can a target maintainer please take this?

[Bug target/106253] [13 Regression] ICE in vect_transform_loops, at tree-vectorizer.cc:1032

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

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

--- Comment #3 from Richard Biener  ---
aarch64_builtin_vectorized_function is what returns these, but the decls
seem to be generated elsewhere.

[Bug libstdc++/106248] [11/12/13 Regression] operator>>std::basic_istream at boundary condition behave differently in different opt levels

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
 Status|NEW |ASSIGNED
   Target Milestone|--- |11.4

[Bug target/106240] [13 Regression] missed vectorization opportunity (cond move) on mips since r13-707-g68e0063397ba82

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

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

Richard Biener  changed:

   What|Removed |Added

   Last reconfirmed||2022-07-11
 Ever confirmed|0   |1
  Component|tree-optimization   |target
 CC||mfortune at gmail dot com
 Status|UNCONFIRMED |NEW

--- Comment #1 from Richard Biener  ---
So we're going

t.c:9:17: note:   using normal nonmask vectors for _11 = _1 == _3;
t.c:9:17: note:   can narrow to unsigned:5 without loss of precision: i_9 =
i_12 + 1;
t.c:9:17: note:   vect_recog_bool_pattern: detected: iftmp.0_5 = _11 ? _1 : _2;
t.c:9:17: note:   bool pattern recognized: patt_10 = _11 != 0 ? _1 : _2;
..
t.c:9:17: note:   ==> examining statement: _11 = _1 == _3;
t.c:10:36: missed:   not vectorized: relevant stmt not supported: _11 = _1 ==
_3;
t.c:9:17: missed:  bad operation or unsupported loop bound.

> grep 'vcond\|vec_cmp' *.md
mips-msa.md:;; Same as MSA.  Used by vcond to iterate two modes.
mips-msa.md:(define_expand "vcondu"
mips-msa.md:(define_expand "vcond"
mips-msa.md:(define_expand "vec_cmp"
mips-msa.md:  mips_expand_vec_cmp_expr (operands);
mips-msa.md:(define_expand "vec_cmpu"
mips-msa.md:  mips_expand_vec_cmp_expr (operands);
mips-ps-3d.md:(define_expand "vcondv2sfv2sf"
mips-ps-3d.md:  mips_expand_vcondv2sf (operands[0], operands[1], operands[2],
mips-ps-3d.md:  mips_expand_vcondv2sf (operands[0], operands[1], operands[2],
mips-ps-3d.md:  mips_expand_vcondv2sf (operands[0], operands[1], operands[2],

so we have limited support for vec_cmp and no support for vcond_mask.

Generally I'd blame it on the target to not provide optabs that map to the
actual ISA.  Before the rev. we produced

$L2:
ldc1$f1,0($4)
ldc1$f0,0($2)
addiu   $3,$3,8
add.ps  $f2,$f1,$f3
addiu   $2,$2,8
addiu   $4,$4,8
c.eq.ps $fcc0,$f0,$f2
movf.ps $f0,$f1,$fcc0
.setnoreorder
.setnomacro
bne $2,$5,$L2

I think

c.eq.ps $fcc0,$f0,$f2
movf.ps $f0,$f1,$fcc0

corresponds to

  _34 = vect__1.8_28 == vect__3.12_33;
  vect_iftmp.13_35 = VEC_COND_EXPR <_34, vect__1.8_28, vect__2.11_31>;

and ISEL makes

  vect_iftmp.13_35 = .VCOND (vect__1.8_28, vect__3.12_33, vect__1.8_28,
vect__2.11_31, 113);

so while the target supports vcond the actual ISA has vec_cmp plus
vcond_mask instead which would map to the new GIMPLE IL constraints
nicely.

But indeed for targets where the ISA can do VCOND we mess this up
during pattern recognition, making "fixup" in vectorizable_*
difficult.  It would possibly be best to emulate ISEL here and
pattern-recog iftmp.0_5 = _1 == _3 ? _1 : _2; instead (yeah,
embedded GENERIC cond - patterns still have those - they probably
should use "unchecked" .VCOND but with scalar ops ...).

I'm not sure how likely is a MIPS maintainer modernizing the vectorizer
patterns here?  What's the "modern" parts?  mips-msa.md or mips-ps-3d.md?

[Bug target/106253] [13 Regression] ICE in vect_transform_loops, at tree-vectorizer.cc:1032

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

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

--- Comment #4 from rsandifo at gcc dot gnu.org  
---
I guess we'll need different patterns in that case.  These builtins
are also used to expand ACLE intrinsics, and I think for those we
have to honour the prevailing flush-to-zero mode, which makes the
functions at best pure rather than const.

[Bug c/106254] New: [suboptinal] llvm uses instructions with larger access bit width

[zhongyunde at huawei dot com via Gcc-bugs]

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

Bug ID: 106254
   Summary: [suboptinal] llvm uses instructions with larger access
bit width
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zhongyunde at huawei dot com
  Target Milestone: ---

llvm uses memory access instructions with larger access bit width base on
following case, both on x86 and arm, see detail
https://gcc.godbolt.org/z/c9ja9zWEE
```
#define N 1
void
__attribute__((noipa))
foo_pd (_Complex double* a, _Complex double* b)
{
  for (int i = 0; i != N; i++)
a[i] = b[i];
}
```

[Bug c/106255] New: [suboptinal] llvm uses instructions with larger access bit width

[zhongyunde at huawei dot com via Gcc-bugs]

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

Bug ID: 106255
   Summary: [suboptinal] llvm uses instructions with larger access
bit width
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zhongyunde at huawei dot com
  Target Milestone: ---

llvm uses memory access instructions with larger access bit width base on
following case, both on x86 and arm, see detail
https://gcc.godbolt.org/z/c9ja9zWEE
```
#define N 1
void
__attribute__((noipa))
foo_pd (_Complex double* a, _Complex double* b)
{
  for (int i = 0; i != N; i++)
a[i] = b[i];
}
```

[Bug tree-optimization/99416] s211 benchmark of TSVC is vectorized by icc and not by gcc

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #2 from Richard Biener  ---
Note after "fixing" (disabling) the costing issue we get to

Fuse partitions because they are in the same dependence scc:
  Part 1: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 17, 18, 20, 21
  Part 2: 1, 2, 3, 7, 11, 12, 13, 14, 15, 16, 17, 18, 20, 21
Loop nest 1 not distributed.

still a[i] = b[i - 1] can be performed separately but second while
b[i] = b[i + 1] needs to be performed first.  That means the
dependence analysis interpretation needs improvement.

[Bug tree-optimization/99416] s211 benchmark of TSVC is vectorized by icc and not by gcc

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

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

--- Comment #3 from Richard Biener  ---
Note it's only the outer loop that confuses us here.  With that removed we have
the following because of yet another "heuristic" to disable distribution.

Possible alias data dependence to break:
Fuse partitions because there is no point to distribute loop:
  Part 1: 0, 1, 5, 9, 10, 11, 12, 13, 14, 15, 16
  Part 2: 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 15, 16

[Bug libstdc++/106248] [11/12/13 Regression] operator>>std::basic_istream at boundary condition behave differently in different opt levels

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

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

--- Comment #7 from Jonathan Wakely  ---
Comment 6 isn't right (it should be sgetc not snextc, and it needs to consider
the stream's field width) but I'm testing a working patch now.

[Bug c/106255] [suboptinal] llvm uses instructions with larger access bit width

[schwab--- via Gcc-bugs]

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

Andreas Schwab  changed:

   What|Removed |Added

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

--- Comment #1 from Andreas Schwab  ---
dup

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

[Bug c/106254] [suboptinal] llvm uses instructions with larger access bit width

[schwab--- via Gcc-bugs]

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

--- Comment #1 from Andreas Schwab  ---
*** Bug 106255 has been marked as a duplicate of this bug. ***

[Bug preprocessor/106252] [13 Regression] AddressSanitizer: global-buffer-overflow on address since r13-1544-ge46f4d7430c521

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

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Lewis Hyatt :

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

commit r13-1605-gcb7b01db7a1979a45fd1dce87a8738e80568520e
Author: Lewis Hyatt 
Date:   Mon Jul 11 08:12:33 2022 -0400

c-family: Fix option check in handle_pragma_diagnostic [PR106252]

In r13-1544, handle_pragma_diagnostic was refactored to support processing
early pragmas. During that process the part looking up option arguments was
inadvertenly moved too early, prior to checking the option was valid,
causing
PR106252. Fixed by moving the check back where it goes.

gcc/c-family/ChangeLog:

PR preprocessor/106252
* c-pragma.cc (handle_pragma_diagnostic_impl): Don't look up the
option argument prior to verifying the option was found.

[Bug preprocessor/106252] [13 Regression] AddressSanitizer: global-buffer-overflow on address since r13-1544-ge46f4d7430c521

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

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

Lewis Hyatt  changed:

   What|Removed |Added

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

--- Comment #4 from Lewis Hyatt  ---
(In reply to Martin Liška from comment #2)
> It's a ASAN bootstrap that needs the following configure option:
> --with-build-config=bootstrap-asan

I see, thank you. It is fixed now.

[Bug libstdc++/105616] Using regex_replace throws "maybe-uninitialized" warnings

[christian.morales.vega at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Cristian Morales Vega  ---
I don't think so.
Supposedly it was fixed 2 months ago in trunk
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105562#c14). But in
https://godbolt.org/z/8a979Gha8 the warnings are still present (even if the
full compilation doesn't complete because it takes too long for compiler
explorer).

[Bug tree-optimization/106250] [13 Regression] ICE in optab_for_tree_code, at optabs-tree.cc:96 since r13-1468-g76c3041b856cb0

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

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

--- Comment #3 from CVS Commits  ---
The trunk branch has been updated by Richard Sandiford :

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

commit r13-1606-ge7a7fed818d238d45b18dfd927cde93b4711052d
Author: Richard Sandiford 
Date:   Mon Jul 11 15:59:00 2022 +0100

vect: Restore optab_vector argument [PR106250]

In g:76c3041b856cb0 I'd removed a "C ? optab_vector : optab_mixed_sign"
argument from a call to directly_supported_p, thinking that the argument
only existed because of the condition (which I was removing).  But the
difference between the scalar and vector forms matters for shifts,
so we do still need the argument.

gcc/
PR tree-optimization/106250
* tree-vect-loop.cc (vectorizable_reduction): Reinstate final
argument to directly_supported_p.

[Bug tree-optimization/106250] [13 Regression] ICE in optab_for_tree_code, at optabs-tree.cc:96 since r13-1468-g76c3041b856cb0

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

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/106237] [13 regression] serveral tests begin ICEing starting with r13-1575-gcf3a120084e946

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

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

--- Comment #2 from seurer at gcc dot gnu.org ---
They use whichever mcpu matches the machine.

The ICEs are fixed but there is a different problem introduced with your fix
g:79f18ac6b7ab7744fcf8937ea4bc0c40f3efc629, r13-1599-g79f18ac6b7ab77

make  -k check-gcc RUNTESTFLAGS="powerpc.exp=gcc.target/powerpc/pr56605.c"
FAIL: gcc.target/powerpc/pr56605.c scan-rtl-dump-times combine "\\(compare:CC
\\((?:and|zero_extend):(?:[SD]I) \\((?:sub)?reg:[SD]I" 1

which might just be the test case needing updating I suppose.  It occurs on the
same machines as the original problem.  It still fails with current trunk.

[Bug c++/105838] [10/11/12/13 Regression] g++ 12.1.0 runs out of memory or time when building const std::vector of std::strings

[luydorarko at vusra dot com via Gcc-bugs]

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

luydorarko at vusra dot com  changed:

   What|Removed |Added

 CC||luydorarko at vusra dot com

--- Comment #9 from luydorarko at vusra dot com  
---
Comment re Bug #106241 being marked as a duplicate of this bug #105838. This
bug #105838 is marked as affecting only gcc versions 10/11/12/13 and is
triggered only on -O1 or higher optimization due to quadratic behavior seen
with "only" 21K strings. Bug #106241 refers to gcc 7.5.0 and is triggered even
without -O1 but needs millions (!!) of strings to do so. Acknowledging that
both result in OOM, they do not resemble each other beyond that.

[Bug tree-optimization/106238] Inline optimization causes dangling pointer on "include/c++/12.1.0/bits/stl_tree.h"

[rogerio.souza at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Rogério de Souza Moraes  ---
Created attachment 53287
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53287&action=edit
C++ code to reproduce the issue.

C++ code to reproduce the issue.

[Bug c++/106256] New: Custom diagnostics for unsatisified standard concepts

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

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

Bug ID: 106256
   Summary: Custom diagnostics for unsatisified standard concepts
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

Sy Brand's https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2429r0.pdf
"Concepts Error Messages for Humans" suggests that we should not expand the
definitions of standard concepts. For example, given:


#include 

template 
void f(N n);

int main() {
  f(nullptr);
}


Compiling with -std=c++20 gives:

: In function 'int main()':
:7:6: error: no matching function for call to 'f(std::nullptr_t)'
7 | f(nullptr);
  | ~^
:4:6: note: candidate: 'template  requires  integral void
f(N)'
4 | void f(N n);
  |  ^
:4:6: note:   template argument deduction/substitution failed:
:4:6: note: constraints not satisfied
In file included from :1:
/opt/compiler-explorer/gcc-12.1.0/include/c++/12.1.0/concepts: In substitution
of 'template  requires  integral void f(N) [with N =
std::nullptr_t]':
:7:6:   required from here
/opt/compiler-explorer/gcc-12.1.0/include/c++/12.1.0/concepts:100:13:  
required for the satisfaction of 'integral' [with N = std::nullptr_t]
/opt/compiler-explorer/gcc-12.1.0/include/c++/12.1.0/concepts:100:24: note: the
expression 'is_integral_v<_Tp> [with _Tp = std::nullptr_t]' evaluated to
'false'
  100 | concept integral = is_integral_v<_Tp>;
  |^~


Sy suggested that showing the definition of std::integral is not helpful.
Saying that std::is_integral_v is false is no more helpful than saying that
std::integral is unsatisified. I agree.

We could skip showing the definition if it's a concept defined in the std::lib,
and could provide custom diagnostics for specific standard concepts e.g. Sy
suggests

Hint: 'integral' is only satisfied if 'T' is an integral type, see


I'm not sure about showing the third-party URL (maybe a URL to a doc on
gcc.gnu.org instead) but I like the idea as the default behaviour. We could add
a switch to show all the gory details of the std::lib concept implementation,
but that shouldn't be the default. 



Other problems with this diagnostic:

:4:6: note: candidate: 'template  requires  integral void
f(N)'

This should say std::integral not integral. This becomes even more
important if we do decide to elide the details of standard concepts, we really
need to be clear it's std::integral.


:4:6: note:   template argument deduction/substitution failed:
:4:6: note: constraints not satisfied

1. Why is the second note indented less than the first?

2. Do we need both lines? Could we customize the first line when substitution
failed because of unsatisfied constraints? Maybe change that first line to say
whether deduction failed, or substitution failed, and in the latter case
combine it with "contraints not satisfied" if that was the reason for
substitution failure. It might be nice to be less succinct e.g. "this candidate
cannot be used because its template arguments could not be deduced", "this
candidate cannot be used because substituting the template arguments failed",
"this candidate cannot be used because its constraints are not satisfied".

Continuing ...

In file included from :1:
/opt/compiler-explorer/gcc-12.1.0/include/c++/12.1.0/concepts: In substitution
of 'template  requires  integral void f(N) [with N =
std::nullptr_t]':
:7:6:   required from here
/opt/compiler-explorer/gcc-12.1.0/include/c++/12.1.0/concepts:100:13:  
required for the satisfaction of 'integral' [with N = std::nullptr_t]
/opt/compiler-explorer/gcc-12.1.0/include/c++/12.1.0/concepts:100:24: note: the
expression 'is_integral_v<_Tp> [with _Tp = std::nullptr_t]' evaluated to
'false'
  100 | concept integral = is_integral_v<_Tp>;
  |^~

1. The second line should say std::integral as well.

2. Why is its location the std::lib  header? That line refers to the
function template specialization f which is defined in the user
code, not in the  header. Why do we have "In file included from ..."
when we're referring to something not defined in a header?

3. Why are we even naming that candidate again? We've already said the
candidate didn't match and we're now printing the reasons it wasn't viable. I
don't think we need to repeat which candidate we're talking about.


Taken together, these suggestions would give us:

: In function 'int main()':
:7:6: error: no matching function for call to 'f(std::nullptr_t)'
7 | f(nullptr);
  | ~^
:4:6: note: candidate: 'template  requires  std::integral
void f(N)'
4 | void f(N n);
  |  ^
:4:6: note:   th

[Bug tree-optimization/105860] [10/11/12/13 Regression] Miscompilation causing clobbered union contents since r10-918-gc56c86024f8fba0c

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

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

--- Comment #8 from CVS Commits  ---
The releases/gcc-12 branch has been updated by Martin Jambor
:

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

commit r12-8564-g1a78fffb3845f879e36ba33b4d15e75b3df8d5a7
Author: Martin Jambor 
Date:   Mon Jul 11 18:43:23 2022 +0200

tree-sra: Fix union handling in build_reconstructed_reference

As the testcase in PR 105860 shows, the code that tries to re-use the
handled_component chains in SRA can be horribly confused by unions,
where it thinks it has found a compatible structure under which it can
chain the references, but in fact it found the type it was looking
for elsewhere in a union and generated a write to a completely wrong
part of an aggregate.

I don't remember whether the plan was to support unions at all in
build_reconstructed_reference but it can work, to an extent, if we
make sure that we start the search only outside the outermost union,
which is what the patch does (and the extra testcase verifies).

Additionally, this commit also contains sqashed in it a backport of
b984b84cbe4bf026edef2ba37685f3958a1dc1cf which fixes the testcase
gcc.dg/tree-ssa/alias-access-path-13.c for many 32-bit targets.

gcc/ChangeLog:

2022-07-01  Martin Jambor  

PR tree-optimization/105860
* tree-sra.cc (build_reconstructed_reference): Start expr
traversal only just below the outermost union.

gcc/testsuite/ChangeLog:

2022-07-01  Martin Jambor  

PR tree-optimization/105860
* gcc.dg/tree-ssa/alias-access-path-13.c: New test.
* gcc.dg/tree-ssa/pr105860.c: Likewise.

(cherry picked from commit b110e5283e368b5377e04766e4ff82cd52634208)

[Bug tree-optimization/106238] Inline optimization causes dangling pointer on "include/c++/12.1.0/bits/stl_tree.h"

[rogerio.souza at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Rogério de Souza Moraes  ---
Created attachment 53288
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53288&action=edit
Second example to reproduce the issue

[Bug tree-optimization/106238] Inline optimization causes dangling pointer on "include/c++/12.1.0/bits/stl_tree.h"

[rogerio.souza at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Rogério de Souza Moraes  ---
Hi Andrew,

thank you for the quick reply. The "getLocalCopy" on this example is just to
provide a quick way to reproduce the issue. Here is the getLocalCopy function
of this example.

extern void getLocalCopy(std::map&);

I added the file bug2.cpp which is another way to reproduce the issue.

The issue only happens when the compiler uses inline, which triggers the error
on "stl_tree.h:2090:32".

I could not find any condition that would consider the example codes as invalid
or that leads to "undefined behavior", do you see any?

Considering that this warning only happens on GCC 12.1, the testcases are valid
wouldn´t it be an issue on this compiler version? Wouldn´t it require a fix on
"stl_tree.h" to prevent this warning?

Regards,
Rogerio

[Bug tree-optimization/106254] complex float copy loop is not vectorized

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

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

--- Comment #2 from Andrew Pinski  ---

/app/example.c:6:21: note:   === vect_analyze_data_refs ===
/app/example.c:6:21: missed:   not vectorized: no vectype for stmt: _5 = *_3;
 scalar_type: complex double
/app/example.c:7:13: missed:   not vectorized: no vectype for stmt: _5 = *_3;
 scalar_type: complex double
/app/example.c:6:21: missed:  bad data references.

[Bug middle-end/106010] Miss vectorization for complex type copy.

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||zhongyunde at huawei dot com

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

[Bug tree-optimization/106254] complex float copy loop is not vectorized

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #3 from Andrew Pinski  ---
Dup of bug 106010.

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

[Bug tree-optimization/106234] [13 Regression] stack overflow from range_from_dom

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

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Andrew Macleod :

https://gcc.gnu.org/g:12a9b98ac574bc8092a75849b5c462135d35c31d

commit r13-1608-g12a9b98ac574bc8092a75849b5c462135d35c31d
Author: Andrew MacLeod 
Date:   Fri Jul 8 13:30:49 2022 -0400

Avoid calling range_from_dom when dominator is already resolved.

range_from_dom makes a recursive call to resolve the immediate dominator
when there are multiple incoming edges to a block.  This is not necessary
when the dominator already has an on-entry cache value.

PR tree-optimization/106234
* gimple-range-cache.cc (ranger_cache::range_from_dom): Check
dominator
cache value before recursively resolving it.

[Bug tree-optimization/106234] [13 Regression] stack overflow from range_from_dom

[amacleod at redhat dot com via Gcc-bugs]

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

Andrew Macleod  changed:

   What|Removed |Added

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

--- Comment #5 from Andrew Macleod  ---
fixed.

[Bug c/106257] New: [13 Regression] ICE in expand_builtin_unreachable, at builtins.cc:5189

[gscfq--- via Gcc-bugs]

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

Bug ID: 106257
   Summary: [13 Regression] ICE in expand_builtin_unreachable, at
builtins.cc:5189
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Started between 20220619 and 20220626,
with file gcc.c-torture/compile/pr84136.c :


$ gcc-13-20220710 -c pr84136.c -O2 -fno-early-inlining -fsanitize=unreachable
during RTL pass: expand
pr84136.c: In function 'main':
pr84136.c:12:5: internal compiler error: in expand_builtin_unreachable, at
builtins.cc:5189
   12 | int main() {
  | ^~~~
0x873309 expand_builtin_unreachable
../../gcc/builtins.cc:5189
0x873309 expand_builtin(tree_node*, rtx_def*, rtx_def*, machine_mode, int)
../../gcc/builtins.cc:7540
0x9eddfe expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../gcc/expr.cc:11689
0x89e2df expand_expr
../../gcc/expr.h:310
0x89e2df expand_call_stmt
../../gcc/cfgexpand.cc:2831
0x89e2df expand_gimple_stmt_1
../../gcc/cfgexpand.cc:3880
0x89e2df expand_gimple_stmt
../../gcc/cfgexpand.cc:4044
0x8a520f expand_gimple_basic_block
../../gcc/cfgexpand.cc:6096
0x8a7866 execute
../../gcc/cfgexpand.cc:6822

[Bug c++/106258] New: ICE in ipa_verify_edge_has_no_modifications, at ipa-param-manipulation.cc:139

[gscfq--- via Gcc-bugs]

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

Bug ID: 106258
   Summary: ICE in ipa_verify_edge_has_no_modifications, at
ipa-param-manipulation.cc:139
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Started between 20220619 and 20220626,
with file g++.dg/ipa/ipa-sra-4.C :


$ gcc-13-20220710 -c ipa-sra-4.C -O2 -funreachable-traps
during IPA pass: inline
In function 'void check_allocate_max_size() [with Alloc =
throw_allocator_base]',
inlined from 'int main()' at ipa-sra-4.C:37:59:
ipa-sra-4.C:35:13: internal compiler error: in
ipa_verify_edge_has_no_modifications, at ipa-param-manipulation.cc:139
   35 |   a.allocate(__trans_tmp_1 + 1);
  |   ~~^~~
0xe9b1d5 ipa_verify_edge_has_no_modifications(cgraph_edge*)
../../gcc/ipa-param-manipulation.cc:139
0xbc2c9f cgraph_edge::redirect_call_stmt_to_callee(cgraph_edge*)
../../gcc/cgraph.cc:1553
0x118dcaf redirect_all_calls(copy_body_data*, basic_block_def*)
../../gcc/tree-inline.cc:3002
0x1191363 copy_cfg_body
../../gcc/tree-inline.cc:3157
0x1191363 copy_body
../../gcc/tree-inline.cc:3338
0x1194628 expand_call_inline
../../gcc/tree-inline.cc:5123
0x11966a9 gimple_expand_calls_inline
../../gcc/tree-inline.cc:5318
0x11966a9 optimize_inline_calls(tree_node*)
../../gcc/tree-inline.cc:5490
0xe59ceb inline_transform(cgraph_node*)
../../gcc/ipa-inline-transform.cc:790
0xff0400 execute_one_ipa_transform_pass
../../gcc/passes.cc:2336
0xff0400 execute_all_ipa_transforms(bool)
../../gcc/passes.cc:2399
0xbca145 cgraph_node::expand()
../../gcc/cgraphunit.cc:1827
0xbcbae6 expand_all_functions
../../gcc/cgraphunit.cc:1998
0xbcbae6 symbol_table::compile()
../../gcc/cgraphunit.cc:2348
0xbcf1bf symbol_table::compile()
../../gcc/cgraphunit.cc:2532
0xbcf1bf symbol_table::finalize_compilation_unit()
../../gcc/cgraphunit.cc:2529

[Bug c++/106259] New: ICE in diag_mismatched_tags, at cp/parser.cc:33896

[gscfq--- via Gcc-bugs]

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

Bug ID: 106259
   Summary: ICE in diag_mismatched_tags, at cp/parser.cc:33896
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Started with r10 and file g++.dg/template/dependent-name11.C :


$ gcc-13-20220710 -c dependent-name11.C -Wmismatched-tags
dependent-name11.C:15:1: internal compiler error: in diag_mismatched_tags, at
cp/parser.cc:33896
   15 | }
  | ^
0x904c4d class_decl_loc_t::diag_mismatched_tags(tree_node*)
../../gcc/cp/parser.cc:33896
0x90b465 class_decl_loc_t::diag_mismatched_tags()
../../gcc/cp/parser.cc:34018
0x9550cd c_parse_file()
../../gcc/cp/parser.cc:48482
0xae8181 c_common_parse_file()
../../gcc/c-family/c-opts.cc:1235

[Bug c++/106260] New: [10/11/12/13 Regression] ICE in initialize_node_lattices, at ipa-cp.cc:1289

[gscfq--- via Gcc-bugs]

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

Bug ID: 106260
   Summary: [10/11/12/13 Regression] ICE in
initialize_node_lattices, at ipa-cp.cc:1289
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Started with r8 and file g++.dg/lto/pr69589_1.C :


$ gcc-13-20220710 -c pr69589_1.C -O2 -fwhole-program -fno-unit-at-a-time
during IPA pass: cp
pr69589_1.C:60:1: internal compiler error: in initialize_node_lattices, at
ipa-cp.cc:1289
   60 | }
  | ^
0x1fa42bf initialize_node_lattices
../../gcc/ipa-cp.cc:1289
0x1facd69 ipcp_propagate_stage
../../gcc/ipa-cp.cc:4024
0x1facd69 ipcp_driver
../../gcc/ipa-cp.cc:6590

[Bug c++/106261] New: ICE in output_call_frame_info, at dwarf2out.cc:943

[gscfq--- via Gcc-bugs]

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

Bug ID: 106261
   Summary: ICE in output_call_frame_info, at dwarf2out.cc:943
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Affects versions down to at least r5,
with file g++.dg/torture/pr60871.C :


$ gcc-13-20220710 -c pr60871.C -dx -fno-dwarf2-cfi-asm
pr60871.C:33:28: internal compiler error: Segmentation fault
   33 | void fn1 () { F::m_fn2 (); }
  |^
0x10ecfef crash_signal
../../gcc/toplev.cc:322
0xc33a42 vec::iterate(unsigned int,
dw_cfi_node**) const
../../gcc/vec.h:930
0xc33a42 output_call_frame_info
../../gcc/dwarf2out.cc:943

[Bug c++/106259] [10/11/12/13 Regression] ICE in diag_mismatched_tags, at cp/parser.cc:33896

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

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

Marek Polacek  changed:

   What|Removed |Added

Summary|ICE in  |[10/11/12/13 Regression]
   |diag_mismatched_tags, at|ICE in
   |cp/parser.cc:33896  |diag_mismatched_tags, at
   ||cp/parser.cc:33896
   Target Milestone|--- |10.5
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
 CC||mpolacek at gcc dot gnu.org,
   ||msebor at gcc dot gnu.org
   Priority|P3  |P2
   Last reconfirmed||2022-07-11

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

commit 04dd734b52de121853e1ea6b3c197a598b294e23
Author: Martin Sebor 
Date:   Fri Mar 27 12:07:45 2020 -0400

c++: avoid -Wredundant-tags on a first declaration in use [PR 93824]

[Bug c++/106259] [10/11/12/13 Regression] ICE in diag_mismatched_tags, at cp/parser.cc:33896

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

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

--- Comment #2 from Marek Polacek  ---
Looks like
struct A::W
isn't in the class2loc hash table so we crash here:

33894   tree spec = specialization_of (type);
33895   cdlguide = class2loc.get (spec);
33896   gcc_assert (cdlguide != NULL);

[Bug testsuite/106262] New: [13 regression] test case g++.dg/modules/loc-prune-4.C fails

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

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

Bug ID: 106262
   Summary: [13 regression] test case g++.dg/modules/loc-prune-4.C
fails
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

g:069f46c71e9432eda3d48a366e5c2a750cf8d612, r13-1506-g069f46c71e9432

I am only seeing it on power 7 BE with -mcpu=power7 and for both 32 and 64 bit.

That is the commit where this test case was added but it was during a time when
the build failed for me on power 7 from r13-1457-g10b502fb78351a through
r13-1603-g415d2c38edadf9 so I am not absolutely sure that is where it started. 
>From the test results mailing list it is failing on other architectures, too.


make  -k check-c++ RUNTESTFLAGS="--target_board=unix'{-m64}'
modules.exp=loc-prune-4.C"
FAIL: g++.dg/modules/loc-prune-4.C -std=c++17  scan-lang-dump module " Span:0
ordinary \\[2.\\+12288,\\+4096\\)->\\[0,\\+4096\\)"
FAIL: g++.dg/modules/loc-prune-4.C -std=c++17  scan-lang-dump module " Span:1
ordinary \\[2.\\+40960,\\+8192\\)->\\[4096,\\+8192\\)"
FAIL: g++.dg/modules/loc-prune-4.C -std=c++2a  scan-lang-dump module " Span:0
ordinary \\[2.\\+12288,\\+4096\\)->\\[0,\\+4096\\)"
FAIL: g++.dg/modules/loc-prune-4.C -std=c++2a  scan-lang-dump module " Span:1
ordinary \\[2.\\+40960,\\+8192\\)->\\[4096,\\+8192\\)"
FAIL: g++.dg/modules/loc-prune-4.C -std=c++2b  scan-lang-dump module " Span:0
ordinary \\[2.\\+12288,\\+4096\\)->\\[0,\\+4096\\)"
FAIL: g++.dg/modules/loc-prune-4.C -std=c++2b  scan-lang-dump module " Span:1
ordinary \\[2.\\+40960,\\+8192\\)->\\[4096,\\+8192\\)"


commit 069f46c71e9432eda3d48a366e5c2a750cf8d612
Author: Nathan Sidwell 
Date:   Fri Jun 24 05:57:42 2022 -0700

c++: Prune ordinary locations

[Bug ipa/106258] [13 Regression] ICE in ipa_verify_edge_has_no_modifications, at ipa-param-manipulation.cc:139 since r13-1204-gd68d366425369649

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

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

Martin Liška  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2022-07-11
Summary|ICE in  |[13 Regression] ICE in
   |ipa_verify_edge_has_no_modi |ipa_verify_edge_has_no_modi
   |fications, at   |fications, at
   |ipa-param-manipulation.cc:1 |ipa-param-manipulation.cc:1
   |39  |39 since
   ||r13-1204-gd68d366425369649
 CC||jason at gcc dot gnu.org
 Status|UNCONFIRMED |NEW

--- Comment #1 from Martin Liška  ---
Started with r13-1204-gd68d366425369649.

[Bug middle-end/106257] [13 Regression] ICE in expand_builtin_unreachable, at builtins.cc:5189 since r13-1204-gd68d366425369649

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

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

Martin Liška  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
   Last reconfirmed||2022-07-11
Summary|[13 Regression] ICE in  |[13 Regression] ICE in
   |expand_builtin_unreachable, |expand_builtin_unreachable,
   |at builtins.cc:5189 |at builtins.cc:5189 since
   ||r13-1204-gd68d366425369649
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Also started with r13-1204-gd68d366425369649.

[Bug ipa/106258] [13 Regression] ICE in ipa_verify_edge_has_no_modifications, at ipa-param-manipulation.cc:139 since r13-1204-gd68d366425369649

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |13.0

[Bug ipa/106260] [10/11/12/13 Regression] ICE in initialize_node_lattices, at ipa-cp.cc:1289 since r8-1887-g0eaf0bfe94ff5a7c

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

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

Martin Liška  changed:

   What|Removed |Added

   Last reconfirmed||2022-07-11
 Status|UNCONFIRMED |NEW
Summary|[10/11/12/13 Regression]|[10/11/12/13 Regression]
   |ICE in  |ICE in
   |initialize_node_lattices,   |initialize_node_lattices,
   |at ipa-cp.cc:1289   |at ipa-cp.cc:1289 since
   ||r8-1887-g0eaf0bfe94ff5a7c
 CC||hubicka at gcc dot gnu.org,
   ||jamborm at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Started with r8-1887-g0eaf0bfe94ff5a7c.

[Bug debug/106261] ICE in output_call_frame_info, at dwarf2out.cc:943

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

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2022-07-11
 Ever confirmed|0   |1
 CC||marxin at gcc dot gnu.org

[Bug middle-end/106257] [13 Regression] ICE in expand_builtin_unreachable, at builtins.cc:5189 since r13-1204-gd68d366425369649

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |13.0

[Bug debug/106263] New: BTF_KIND_FUNC type does not encode linkage

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

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

Bug ID: 106263
   Summary: BTF_KIND_FUNC type does not encode linkage
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ibhagat at gcc dot gnu.org
  Target Milestone: ---

GCC generates BTF_KIND_FUNC with vlen set to 0.  libbpf expects the vlen field
to include the linkage information.

The issue was reported here:

https://lore.kernel.org/bpf/8735fbcv3x@oracle.com/

Although GCC is currently generating the BTF_KIND_FUNC as per the BTF format
documentation (see excerpt below), this needs to be changed to allow the tools
to work well with each other.

[Source: https://www.kernel.org/doc/Documentation/bpf/btf.rst]

...
2.2.12 BTF_KIND_FUNC


``struct btf_type`` encoding requirement:
  * ``name_off``: offset to a valid C identifier
  * ``info.kind_flag``: 0
  * ``info.kind``: BTF_KIND_FUNC
  * ``info.vlen``: 0
  * ``type``: a BTF_KIND_FUNC_PROTO type
...

[Bug target/106240] [13 Regression] missed vectorization opportunity (cond move) on mips since r13-707-g68e0063397ba82

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

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

--- Comment #2 from Jeffrey A. Law  ---
I don't mind deferring this -- I *think* the .ps variants are deprecated in
newer versions of the ISA.  So we could easily move this to P4 and let the MIPS
folks take care of it if/when they feel the need.

[Bug target/106240] [13 Regression] missed vectorization opportunity (cond move) on mips since r13-707-g68e0063397ba82

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

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

--- Comment #3 from Andrew Pinski  ---
(In reply to Jeffrey A. Law from comment #2)
> I don't mind deferring this -- I *think* the .ps variants are deprecated in
> newer versions of the ISA.  So we could easily move this to P4 and let the
> MIPS folks take care of it if/when they feel the need.

I don't even know if anyone cares about the MIPS port any more, especially
either MSA or PS. I don't even know of implementations that have either MSA or
PS in it. That could be used for testing either.

[Bug ipa/106260] [10/11/12/13 Regression] ICE in initialize_node_lattices, at ipa-cp.cc:1289 since r8-1887-g0eaf0bfe94ff5a7c

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |10.5

[Bug c/106264] New: spurious -Wunused-value on a folded frexp, modf, and remquo calls with unused result

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

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

Bug ID: 106264
   Summary: spurious -Wunused-value on a folded frexp, modf, and
remquo calls with unused result
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

In C mode only the following test case triggers the invalid (or at least poorly
worded and so confusing) instances of -Wunused-value.  Each instance goes away
when the call is not folded or when its result is used.  The C++ front end
doesn't warn.

$ cat a.c && gcc -O -Wall -S -Wall a.c
double frexp (double, int*);
double modf (double, double*);
double remquo (double, double, int*);

int f (void)
{
  int y;
  frexp (1.0, &y);
  return y;
}

double g (void)
{
  double y;
  modf (1.0, &y);
  return y;
}

int h (void)
{
  int y;
  remquo (1.0, 1.0, &y);
  return y;
}

a.c: In function ‘f’:
a.c:8:3: warning: right-hand operand of comma expression has no effect
[-Wunused-value]
8 |   frexp (1.0, &y);
  |   ^~~
a.c: In function ‘g’:
a.c:15:3: warning: right-hand operand of comma expression has no effect
[-Wunused-value]
   15 |   modf (1.0, &y);
  |   ^~
a.c: In function ‘h’:
a.c:22:3: warning: right-hand operand of comma expression has no effect
[-Wunused-value]
   22 |   remquo (1.0, 1.0, &y);
  |   ^

[Bug c/106264] [10/11/12/13 Regression] spurious -Wunused-value on a folded frexp, modf, and remquo calls with unused result

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|spurious -Wunused-value on  |[10/11/12/13 Regression]
   |a folded frexp, modf, and   |spurious -Wunused-value on
   |remquo calls with unused|a folded frexp, modf, and
   |result  |remquo calls with unused
   ||result
   Target Milestone|--- |10.5
  Known to fail||9.1.0
  Known to work||8.1.0, 8.5.0

[Bug c/106264] [10/11/12/13 Regression] spurious -Wunused-value on a folded frexp, modf, and remquo calls with unused result

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2022-07-11
 Status|UNCONFIRMED |NEW

--- Comment #1 from Andrew Pinski  ---
Confirmed, started sometime between GCC 8 and GCC 9. It was folded even in GCC
8.

[Bug debug/106261] ICE in output_call_frame_info, at dwarf2out.cc:943

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

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

--- Comment #1 from Andrew Pinski  ---
Created attachment 53289
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53289&action=edit
testcase

[Bug c/106264] [10/11/12/13 Regression] spurious -Wunused-value on a folded frexp, modf, and remquo calls with unused result

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

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

--- Comment #2 from Martin Sebor  ---
The most likely culprit is r261705.

[Bug debug/106261] [10/11/12/13 Regression] ICE in output_call_frame_info, at dwarf2out.cc:943

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |10.5
  Known to fail||4.8.0
  Known to work||4.7.4
Summary|ICE in  |[10/11/12/13 Regression]
   |output_call_frame_info, at  |ICE in
   |dwarf2out.cc:943|output_call_frame_info, at
   ||dwarf2out.cc:943

[Bug c/106264] [10/11/12/13 Regression] spurious -Wunused-value on a folded frexp, modf, and remquo calls with unused result

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

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

--- Comment #3 from Andrew Pinski  ---
(In reply to Martin Sebor from comment #2)
> The most likely culprit is r261705.

Yes this part:

(fold_builtin_n): Avoid setting TREE_NO_WARNING.

[Bug c++/66290] wrong location for -Wunused-macros

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

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

Lewis Hyatt  changed:

   What|Removed |Added

 CC||lhyatt at gcc dot gnu.org

--- Comment #3 from Lewis Hyatt  ---
(https://gcc.gnu.org/pipermail/gcc-patches/2022-July/598188.html)
This testcase, hopefully soon to be committed as c-c++-common/pragma-diag-15.c:

---
/* { dg-do compile } */
/* { dg-additional-options "-Wunused-macros" } */
#define X /* { dg-warning "-:-Wunused-macros" {} { xfail c++ } } */
#pragma GCC diagnostic ignored "-Wunused-macros"
---

fails for C++, I believe it's the same thing pointed out in this PR. The reason
is because of this in c_cpp_diagnostic() in c-common.cc:

---
  if (done_lexing)
richloc->set_range (0, input_location, SHOW_RANGE_WITH_CARET);
---

This warning is issued at the end of compilation, when done_lexing is true.
However, input_location is not the right thing to use here, the location
provided was remembered from the time the macro was lexed, and that's the one
that needs to be used. The way it is now, input_location is at the end of the
file, and so the macro is deemed to have been defined after the #pragma.

I think this done_lexing concept was added to solve PR17964 many years ago.
Does anyone know if it's still needed, are there still cases where libcpp can
generate a diagnostic while C++ is parsing the already-lexed tokens? I have
checked anyway, that the particular testcase on PR17964 passes if done_lexing
is kept always false. I am trying the full testsuite now as well. If it can't
be removed, then I think we need some way to tell c_cpp_diagnostic not to
override a location for instances like this. Or paradoxically, we could set
done_lexing=false in c_common_finish(), which would fix it as well. It fixes
both my testcase, and the one in this original PR. Could be a reasonable fix,
perhaps combined with renaming done_lexing to something more like
override_libcpp_locations, but would be nice if it could just be removed as
well. I can look into that but perhaps Joseph knows the details here already?

diff --git a/gcc/c-family/c-opts.cc b/gcc/c-family/c-opts.cc
index b9f01a65ed7..25a3c50de8e 100644
--- a/gcc/c-family/c-opts.cc
+++ b/gcc/c-family/c-opts.cc
@@ -1283,6 +1283,7 @@ c_common_finish (void)

   /* For performance, avoid tearing down cpplib's internal structures
  with cpp_destroy ().  */
+  done_lexing = false;
   cpp_finish (parse_in, deps_stream);

   if (deps_stream && deps_stream != out_stream && deps_stream != stdout

[Bug target/106253] [13 Regression] ICE in vect_transform_loops, at tree-vectorizer.cc:1032

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

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

--- Comment #5 from Andrew Pinski  ---
(In reply to rsand...@gcc.gnu.org from comment #4)
> I think for those we have to honour the prevailing
> flush-to-zero mode, which makes the
> functions at best pure rather than const.

GCC does handle changing of the rounding mode or change of the denormalized
flush to zero mode even in general floating point code. So the question becomes
should  wait for the infrastructure to be added to fix that case or add another
builtin?

[Bug tree-optimization/106119] [12/13 Regression] Bogus use-after-free warning triggered by optimizer

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|Bogus use-after-free|[12/13 Regression] Bogus
   |warning triggered by|use-after-free warning
   |optimizer   |triggered by optimizer
   Target Milestone|--- |12.2
  Component|c   |tree-optimization

[Bug middle-end/106123] ICE in walk_tree_1, at tree.cc:11243

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2022-07-11
  Component|c++ |middle-end

[Bug target/106146] a redundant movprfx insn compare to llvm

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

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

--- Comment #1 from Andrew Pinski  ---
-march=armv8-a+sve2 -O3 -ffast-math

[Bug target/106146] a redundant movprfx insn compare to llvm

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2022-07-11
 Ever confirmed|0   |1
   Severity|normal  |enhancement

--- Comment #2 from Andrew Pinski  ---
Looks like:
(insn 26 25 31 (set (reg/v:VNx4SF 32 v0 [orig:100 res ] [100])
(unspec:VNx4SF [
(reg:VNx4BI 68 p0 [orig:95 pg ] [95])
(unspec:VNx4SF [
(reg:VNx4BI 68 p0 [orig:95 pg ] [95])
(const_int 1 [0x1])
(reg/v:VNx4SF 32 v0 [orig:100 res ] [100])
(reg/v:VNx4SF 33 v1 [orig:97 a0v ] [97])
] UNSPEC_COND_FADD)
(const_vector:VNx4SF repeat [
(const_double:SF 0.0 [0x0.0p+0])
])
] UNSPEC_SEL)) "/app/example.cpp":19:38 7127
{*cond_addvnx4sf_any_strict}
 (nil))

Prints out two asm instructions.

[Bug target/106265] New: RISC-V SPEC2017 507.cactu code bloat due to address generation

[vineet.gupta at linux dot dev via Gcc-bugs]

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

Bug ID: 106265
   Summary: RISC-V SPEC2017 507.cactu code bloat due to address
generation
   Product: gcc
   Version: 12.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vineet.gupta at linux dot dev
  Target Milestone: ---

SPEC2017 FP benchmark 507.cactu: ML_BSSN_RHS.cc:ML_BSSN_RHS_Body() has terrible
codegen. A recurring pattern which shows up in hotspot analysis is

  380a1a:   lui a6,0x1 # LI 4096 before linker relaxation
  380a1c:   addit2,sp,32
  380a20:   addia6,a6,-1192 # b58
  380a24:   add a6,a6,t2
  380a26:   sd  t4,0(a6)

The first 4 instructions help calculate the destination of the last SD
instruction. There were 27 such distinct instances in the hottest top block.

Part of this is the ISA not having a single instruction to do set a reg with
32-bit const and/or the limited addressing modes. However the compiler is not
helping either. All those 27 instances have the first instruction to set
register with 4096, sometimes with the register still being live with the exact
same value.

Using creduce I was able to create a small'ish (not ideal small) test case
which shows 14 instances of li ,4096

Built as riscv64-unknown-linux-gnu-g++ -O3 -static -ffast-math -funroll-loops
-march=rv64gc_zba_zbb_zbc_zbs -c  -std=c++03 

This is with trunk as of June 14 (commit 6abe341558ab)

--->8-
void *a();
int b, c, d, l, o, q;
double *e, *f, *p, *r, *s = 0;
long g, h, k;
double m, n, aa;
void y() {
  double ag, ai, aj, ap, ar, at, aw(01.0 / 0);
  double *am((double *)a);
  double *an;
  double *ao((double *)a());
  long av = sizeof(double) * g;
  for (; l; ++l)
for (int j = d; j < q; ++j)
  for (int i = 1; i < o; i++) {
long az = i * j + l;
double ba, bb, bc, bd, be, bf, bg, bh, bi, bj, bk, bl, bm, bn, bo, bp,
bq, br, bs, bv(-ar);
switch (b)
case 4: {
  *(double *)((char *)0)[2] = ((char *)0)[2];
  ba = ((char *)0)[k + av] + ((char *)0)[2] + ((char *)0)[k] +
   *(double *)((char *)0)[av] +
   ((char *)0)[av * 2] * ((char *)0)[k * av];
  bb = (&am[az])[h] + ((char *)0)[k * h] +
   ((char *)&am[az])[1] *
   (((char *)&am[az])[h] + *(&am)[h] + (&am[az])[k]) +
   (&am[az])[2] - ((char *)0)[h] + (&am[az])[k * av];
  bc = 4 * 8 + *(double *)&((char *)0)[2];
  bd = 4 * ((char *)0)[k + 1] +
   (&an[az])[k * h] * (((char *)0)[-1] + (&an[az])[k + h]) +
   8 * ((&an[az])[k * 2] + (&an[az])[av + h * -2] + (&an[az])[av] +
(&an[az])[av * 2 + h]) -
   8 * ((&an[az])[av * 2] + (&an[az])[k] + (&an[az])[av * 21] +
(&an[az])[av + h]) +
   *(&an)[h] - (&an[az])[av * 22] * (&an[az])[h] +
   (&an[az])[av * 2 * 2];
  bf = (&az)[0] * (((char *)&ao[az])[0] + ao[av] + (&ao[az])[av * 2] +
   *(double *)((char *)ao)[k]);
  bg = (&ao[az])[0] * *(&ao)[av] + *(&ao)[2];
  bh = *((char **)0)[av] * (&ao[az])[av - h] +
   ((char *)0)[1] * *(double *)((char *)0)[1] *
   (*(double *)((char *)&ao)[k] + *(double *)((char *)0)[12] +
((char *)&ao[az])[av]) +
   *(&ao)[av * 2] - *(&ao)[k] - (&ao[az])[2] +
   (&ao[az])[k * av * 2];
  bi = *(&ao)[av * h] *
   (ao[h] + ((char *)0)[k * 2] + (&ao[az])[k * av] +
((char *)0)[21]) *
   (((char *)0)[h] + *(double *)((char *)0)[h * 2] +
*(double *)((char *)&ao[az])[k] + *(&ao)[h]) +
   *(&ao)[av * 22] - (&ao[az])[2 * h * 2] + ((char *)0)[22];
  bj = 4 * ((&ao[az])[av] + (&ao[az])[k * av * h] * (&ao[az])[av * -1]
+
(&ao[az])[av * h]) +
   ((&ao[az])[av * 12] + (&ao[az])[k] + ((char *)&ao)[h] +
(&ao[az])[av * 2 + h * 0]) *
   (((char *)0)[2] + *(double *)((char *)&ao[az])[av * 2] +
(&ao[az])[h] + (&ao[az])[av + h]) +
   (&ao[az])[av * 22] - ((char *)&ao[az])[h] - (&ao[az])[av * -2] +
   (&ao[az])[av + h * 2];
  bk = 8 * (&ap)[1];
  bm = ((char *)0)[1] * (&e[az])[2];
  bn = -(&az)[0];
  bo = (&e[az])[h] - (&e[az])[h * 2] * aw;
  bq = (&at)[h];
  br = 8 * 8 * ((&az)[1] + (&f[az])[-2] - (&f[az])[2]);
  bs = (&f[az])[h * -2] - (&f[az])[h * 2];
  n = ((char *)&s)[h * 2];
}
  double bt(e[az] * f[az] - at * at);
double bu(p[az] * at * az);
double bw(f[az] - p[az]);
double bx = 01.0 / 0;
double by = 01.0 / 0 * 0;
double ca;
double cb = -

[Bug target/106265] RISC-V SPEC2017 507.cactu code bloat due to address generation

[vineet.gupta at linux dot dev via Gcc-bugs]

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

--- Comment #1 from Vineet Gupta  ---
Analyzed a section of -dP dump where reg a2 is setup with exact same value
while being live.

rhs-cred.cc:42: (*(double *)((char *)&ao)[k] + *(double *)((char *)0)[12] +
#(insn 2662 1711 76 (set (reg:DI 12 a2 [2816])
#(const_int 4096 [0x1000])) "rhs-cred.cc":42:47 139 {*movdi_64bit}
# (nil))
li  a2,4096 # tmp2816,  # 2662  [c=4 l=4] 
*movdi_64bit/1


rhs-cred.cc:39: bg = (&ao[az])[0] * *(&ao)[av] + *(&ao)[2];
#(insn 76 2662 2663 (set (reg/f:DI 20 s4 [orig:193 _239 ] [193])
#(plus:DI (reg:DI 13 a3 [1865])
#(reg:DI 20 s4 [orig:181 _224 ] [181]))) "rhs-cred.cc":39:40 4
{adddi3}
# (expr_list:REG_DEAD (reg:DI 13 a3 [1865])
#(nil)))
add s4,a3,s4# _224, _239, tmp1865   # 76[c=4 l=4] 
adddi3/0


rhs-cred.cc:42: (*(double *)((char *)&ao)[k] + *(double *)((char *)0)[12] +
#(insn 2663 76 2660 (set (reg:DI 13 a3 [2815])
#(plus:DI (reg:DI 12 a2 [2816])
#(const_int -2024 [0xf818]))) "rhs-cred.cc":42:47 4
{adddi3}
# (expr_list:REG_DEAD (reg:DI 12 a2 [2816])
#(expr_list:REG_EQUAL (const_int 2072 [0x818])
#(nil
addia3,a2,-2024 #, tmp2815, tmp2816 # 2663  [c=4 l=4] 
adddi3/1

rhs-cred.cc:44: *(&ao)[av * 2] - *(&ao)[k] - (&ao[az])[2] +
#(insn 2660 2663 1710 (set (reg:DI 12 a2 [2814])
#(const_int 4096 [0x1000])) "rhs-cred.cc":44:29 139 {*movdi_64bit}
# (nil))
li  a2,4096 # tmp2814,  # 2660  [c=4 l=4] 
*movdi_64bit/1

[Bug target/106265] RISC-V SPEC2017 507.cactu code bloat due to address generation

[vineet.gupta at linux dot dev via Gcc-bugs]

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

--- Comment #2 from Vineet Gupta  ---
I've experimented with riscv_rtx_costs() setting cost of const to 1 as
discussed in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98596. This does
reduce the number of li 4096 instances to 10 (from 14), but the fragment pasted
above generates the same code.

# rhs-cred.cc:42: (*(double *)((char *)&ao)[k] + *(double *)((char *)0)[12] +
#(insn 2660 1703 76 (set (reg:DI 28 t3 [2817])
#(const_int 4096 [0x1000])) "rhs-cred.cc":42:47 139 {*movdi_64bit}
# (nil))
li  t3,4096 # tmp2817,  # 2660  [c=1 l=4] 
*movdi_64bit/1


# rhs-cred.cc:39: bg = (&ao[az])[0] * *(&ao)[av] + *(&ao)[2];
#(insn 76 2660 2661 (set (reg/f:DI 16 a6 [orig:193 _239 ] [193])
#(plus:DI (reg:DI 12 a2 [1860])
#(reg:DI 16 a6 [orig:181 _224 ] [181]))) "rhs-cred.cc":39:40 4
{adddi3}
# (expr_list:REG_DEAD (reg:DI 12 a2 [1860])
#(nil)))
add a6,a2,a6# _224, _239, tmp1860   # 76[c=4 l=4] 
adddi3/0


# rhs-cred.cc:42: (*(double *)((char *)&ao)[k] + *(double *)((char *)0)[12] +
#(insn 2661 76 2658 (set (reg:DI 12 a2 [2816])
#(plus:DI (reg:DI 28 t3 [2817])
#(const_int -2040 [0xf808]))) "rhs-cred.cc":42:47 4
{adddi3}
# (expr_list:REG_DEAD (reg:DI 28 t3 [2817])
#(expr_list:REG_EQUAL (const_int 2056 [0x808])
#(nil
addia2,t3,-2040 #, tmp2816, tmp2817 # 2661  [c=4 l=4] 
adddi3/1

# rhs-cred.cc:44: *(&ao)[av * 2] - *(&ao)[k] - (&ao[az])[2] +
#(insn 2658 2661 1702 (set (reg:DI 28 t3 [2815])
#(const_int 4096 [0x1000])) "rhs-cred.cc":44:29 139 {*movdi_64bit}
# (nil))

li  t3,4096 # tmp2815,  # 2658  [c=1 l=4] 
*movdi_64bit/1

[Bug target/106265] RISC-V SPEC2017 507.cactu code bloat due to address generation

[vineet.gupta at linux dot dev via Gcc-bugs]

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

--- Comment #3 from Vineet Gupta  ---
Digging into RTL dumps, the li instructions are introduced by 300r reload.

[Bug target/106265] RISC-V SPEC2017 507.cactu code bloat due to address generation

[vineet.gupta at linux dot dev via Gcc-bugs]

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

--- Comment #4 from Vineet Gupta  ---
Going back to first dump (upstream 6abe341558a w/o riscv_rtx_costs() adj): the
3rd instruction addi is marking a2 REG_DEAD at 315 cprop.hardreg

--->8 314r.rnreg

(insn 2663 2662 1714 3 (set (reg:DI 13 a3 [2815])
(plus:DI (reg:DI 12 a2 [2816])
(const_int -2024 [0xf818]))) "rhs-cred.cc":42:47 4
{adddi3}
 (expr_list:REG_EQUAL (const_int 2072 [0x818])
(nil)))


--->8 315r.cprop_hardreg

(insn 2663 2662 1714 3 (set (reg:DI 13 a3 [2815])
(plus:DI (reg:DI 12 a2 [2816])
(const_int -2024 [0xf818]))) "rhs-cred.cc":42:47 4
{adddi3}
 (expr_list:REG_DEAD (reg:DI 12 a2 [2816])
(expr_list:REG_EQUAL (const_int 2072 [0x818])
(nil

Not sure if that is the issue or the compiler just deducing that a2 is dead
given that the next instruction sets it up again was introduced much earlier in
300r.reload

[Bug rtl-optimization/42612] post-increment addressing not used

[bd at mail dot ru via Gcc-bugs]

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

Dmitry Baksheev  changed:

   What|Removed |Added

 CC||bd at mail dot ru

--- Comment #6 from Dmitry Baksheev  ---
Please consider fixing this issue. Here is another example where not using
post-increment for loops produces suboptimal code on AArch64. The code is 4x
slower than LLVM-generated code for dot-product function:

double dotprod(std::size_t n, 
 const double* __restrict__ a, 
 const double* __restrict__ b) 
{
double ans = 0;
#if __clang__
#pragma clang loop vectorize(assume_safety)
#else
#pragma GCC ivdep
#endif  
for (std::size_t i = 0; i < n; ++i) {
ans += a[i] * b[i];
}
return ans;
}


Compile with: $(CXX) -march=armv8.2-a -O3 dp.cpp

GCC-generated loop does not have post-increment loads:
.L3:
ldr d2, [x1, x3, lsl 3] 
ldr d1, [x2, x3, lsl 3] 
add x3, x3, 1   
fmadd   d0, d2, d1, d0  
cmp x0, x3  
bne .L3 

Clang emits this:
.LBB0_4:
ldr d1, [x10], #8   
ldr d2, [x8], #8
subsx9, x9, #1
fmadd   d0, d1, d2, d0  
b.ne.LBB0_4