[Bug tree-optimization/107505] New: [13 Regression] ICE: verify_flow_info failed (error: returns_twice call is not first in basic block 2)

[asolokha at gmx dot com via Gcc-bugs]

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

Bug ID: 107505
   Summary: [13 Regression] ICE: verify_flow_info failed (error:
returns_twice call is not first in basic block 2)
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: ice-checking, ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

An obligatory abnormal edge issue of the week.

gcc 13.0.0 20221030 snapshot (g:f36bba013361d8d4f9c7237c3307630de0cc0416) ICEs
when compiling the following testcase w/ -O2 -fno-guess-branch-probability:

int n;

void
bar (void);

__attribute__ ((noinline, returns_twice)) int
zero (void)
{
  return 0;
}

void
foo (void)
{
  int a = zero ();

  for (n = 0; n < 2; ++n)
{
}

  if (a)
bar ();
}

% gcc-13 -O2 -fno-guess-branch-probability -c u9i2um01.c
u9i2um01.c: In function 'foo':
u9i2um01.c:13:1: error: returns_twice call is not first in basic block 2
   13 | foo (void)
  | ^~~
_7 = zero ();
during GIMPLE pass: cddce
u9i2um01.c:13:1: internal compiler error: verify_flow_info failed
0xa10ebd verify_flow_info()
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221030/work/gcc-13-20221030/gcc/cfghooks.cc:284
0xf529c4 checking_verify_flow_info
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221030/work/gcc-13-20221030/gcc/cfghooks.h:214
0xf529c4 cleanup_tree_cfg_noloop
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221030/work/gcc-13-20221030/gcc/tree-cfgcleanup.cc:1161
0xf529c4 cleanup_tree_cfg(unsigned int)
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221030/work/gcc-13-20221030/gcc/tree-cfgcleanup.cc:1212
0xe0b79c execute_function_todo
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221030/work/gcc-13-20221030/gcc/passes.cc:2057
0xe0bbfe execute_todo
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221030/work/gcc-13-20221030/gcc/passes.cc:2145

[Bug target/107506] New: [regression] cross-xtensa-esp32s2-elf/gcc-13.0.0_pre20221023: stack smashing detected during RTL pass: expand in function __absvdi2 (gen_movdi)

[triffid.hunter at gmail dot com via Gcc-bugs]

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

Bug ID: 107506
   Summary: [regression]
cross-xtensa-esp32s2-elf/gcc-13.0.0_pre20221023: stack
smashing detected during RTL pass: expand in function
__absvdi2 (gen_movdi)
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: triffid.hunter at gmail dot com
  Target Milestone: ---

While compiling xtensa-esp32s2-elf-gcc-13.0.0_pre20221023 (via Gentoo ebuild,
further info at https://bugs.gentoo.org/879049 ):

/var/tmp/portage/cross-xtensa-esp32s2-elf/gcc-13.0.0_pre20221023/work/build/xtensa-esp32s2-elf/libgcc
[1] #
/var/tmp/portage/cross-xtensa-esp32s2-elf/gcc-13.0.0_pre20221023/work/build/./gcc/xgcc
-freport-bug
-B/var/tmp/portage/cross-xtensa-esp32s2-elf/gcc-13.0.0_pre20221023/work/build/./gcc/
-B/usr/xtensa-esp32s2-elf/bin/ -B/usr/xtensa-esp32s2-elf/lib/ -isystem
/usr/xtensa-esp32s2-elf/include -isystem /usr/xtensa-esp32s2-elf/sys-include   
-g -O2 -O2  -g -O2 -DIN_GCC  -DCROSS_DIRECTORY_STRUCTURE  -W -Wall
-Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes
-Wmissing-prototypes -Wold-style-definition  -isystem ./include  -mlongcalls -g
-DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -fno-stack-clash-protection
-Dinhibit_libc -mlongcalls -I. -I. -I../.././gcc
-I/var/tmp/portage/cross-xtensa-esp32s2-elf/gcc-13.0.0_pre20221023/work/gcc-13-20221023/libgcc
-I/var/tmp/portage/cross-xtensa-esp32s2-elf/gcc-13.0.0_pre20221023/work/gcc-13-20221023/libgcc/.
-I/var/tmp/portage/cross-xtensa-esp32s2-elf/gcc-13.0.0_pre20221023/work/gcc-13-20221023/libgcc/../gcc
-I/var/tmp/portage/cross-xtensa-esp32s2-elf/gcc-13.0.0_pre20221023/work/gcc-13-20221023/libgcc/../include
 -DHAVE_CC_TLS   -o _absvdi2.o -MT _absvdi2.o -MD -MP -MF _absvdi2.dep
-DL_absvdi2 -c
/var/tmp/portage/cross-xtensa-esp32s2-elf/gcc-13.0.0_pre20221023/work/gcc-13-20221023/libgcc/libgcc2.c
-fvisibility=hidden -DHIDE_EXPORTS
*** stack smashing detected ***: terminated
during RTL pass: expand
/var/tmp/portage/cross-xtensa-esp32s2-elf/gcc-13.0.0_pre20221023/work/gcc-13-20221023/libgcc/libgcc2.c:
In function '__absvdi2':
/var/tmp/portage/cross-xtensa-esp32s2-elf/gcc-13.0.0_pre20221023/work/gcc-13-20221023/libgcc/libgcc2.c:244:22:
internal compiler error: Aborted
244 |   const DWtype v = 0 - (a < 0);
|~~^
0x139ab2a diagnostic_impl(rich_location*, diagnostic_metadata const*, int, char
const*, __va_list_tag (*) [1], diagnostic_t)
???:0
0x139ba08 internal_error(char const*, ...)
???:0
0xb167ef crash_signal(int)
???:0
0x7fc8c6e4c731 raise
???:0
0x7fc8c6e37468 abort
???:0
0x7fc8c6f279a1 __fortify_fail
???:0
0x7fc8c6f2797f __stack_chk_fail
???:0
0x115effa gen_movdi(rtx_def*, rtx_def*)
???:0
0x7dcd97 emit_move_insn_1(rtx_def*, rtx_def*)
???:0
0x7e41dc gen_move_insn(rtx_def*, rtx_def*)
???:0
0x7c782f canonicalize_comparison(machine_mode, rtx_code*, rtx_def**)
???:0
0x7c7bd4 emit_store_flag_1(rtx_def*, rtx_code, rtx_def*, rtx_def*,
machine_mode, int, int, machine_mode)
???:0
0x7c8114 emit_store_flag(rtx_def*, rtx_code, rtx_def*, rtx_def*, machine_mode,
int, int)
???:0
0x7c8c3d emit_store_flag_force(rtx_def*, rtx_code, rtx_def*, rtx_def*,
machine_mode, int, int)
???:0
0x7d3d4f do_store_flag(separate_ops*, rtx_def*, machine_mode)
???:0
0x7d49b4 expand_expr_real_2(separate_ops*, rtx_def*, machine_mode,
expand_modifier)
???:0
0x7db5b5 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
???:0
0x7d4ca1 expand_expr_real_2(separate_ops*, rtx_def*, machine_mode,
expand_modifier)
???:0
0x7db5b5 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
???:0
0x7d5abe expand_expr_real_2(separate_ops*, rtx_def*, machine_mode,
expand_modifier)
???:0
Please submit a full bug report, with preprocessed source.
Please include the complete backtrace with any bug report.
See  for instructions.
The bug is not reproducible, so it is likely a hardware or OS problem.

---

Despite the output saying "this bug is not reproducible", I seem to be able to
reliably reproduce it at the moment.

Even after a cold reboot, it dies at __subvdi3 but the backtrace still
implicates gen_movdi - race condition on the compile target or something I
guess?

After reboot terminal output:

make[2]: Entering directory
'/var/tmp/portage/cross-xtensa-esp32s2-elf/gcc-13.0.0_pre20221023/work/build/xtensa-esp32s2-elf/libgcc'
/var/tmp/portage/cross-xtensa-esp32s2-elf/gcc-13.0.0_pre20221023/work/build/./gcc/xgcc
-B/var/tmp/portage/cross-xtensa-esp32s2-elf/gcc-13.0.0_pre20221023/work/build/./gcc/
-B/usr/xtensa-esp32s2-elf/bin/ -B/usr/xtensa-esp32s2-elf/lib/ -isystem
/usr/xtensa-esp32s2-elf/include -isystem /usr/xtensa-esp32s2-elf/sys-include   
-g -O2 -O2  -g -O2 -DIN_GCC  -DCROSS_DIRECTOR

[Bug target/100866] PPC: Inefficient code for vec_revb(vector unsigned short) < P9

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

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

--- Comment #15 from CVS Commits  ---
The master branch has been updated by HaoChen Gui :

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

commit r13-3603-geaba55ffef961c28f6a15d845a4d6b77b8a8bab1
Author: Xionghu Luo 
Date:   Wed Oct 12 10:43:38 2022 +0800

rs6000: Byte reverse V8HI on Power8 by vector rotation.

gcc/
PR target/100866
* config/rs6000/altivec.md: (*altivec_vrl): Named to...
(altivec_vrl): ...this.
* config/rs6000/vsx.md (revb_): Call vspltish and vrlh when
target is Power8 and mode is V8HI.

gcc/testsuite/
PR target/100866
* gcc.target/powerpc/pr100866-2.c: New.

[Bug rtl-optimization/90259] ICE: verify_flow_info failed (error: missing REG_EH_REGION note at the end of bb 4)

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

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

Kewen Lin  changed:

   What|Removed |Added

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

--- Comment #7 from Kewen Lin  ---
The function copyprop_hardreg_forward_1 of pass cprop_hardreg has the code:

  /* Detect obviously dead sets (via REG_UNUSED notes) and remove them.  */
  if (set
  && !RTX_FRAME_RELATED_P (insn)
  && NONJUMP_INSN_P (insn)
  && !may_trap_p (set)
  && find_reg_note (insn, REG_UNUSED, SET_DEST (set))
  && !side_effects_p (SET_SRC (set))
  && !side_effects_p (SET_DEST (set)))
{
  bool last = insn == BB_END (bb);
  delete_insn (insn);
  if (last)
break;
  continue;
}

it removes the insn 109

(insn 109 117 79 6 (set (reg:DF 33 1 [orig:134+8 ] [134])
(mem:DF (plus:SI (reg/f:SI 31 31)
(const_int 40 [0x28])) [11  S8 A64])) "pr90259_test.cc":5:53
584 {*movdf_hardfloat32}
 (expr_list:REG_UNUSED (reg:DF 33 1 [orig:134+8 ] [134])
(expr_list:REG_EH_REGION (const_int 2 [0x2])
(nil

as DF 33 is unused and it meets the above conditions. The case can pass if we
purge dead edges after this removal, such as the below diff. But I need more
investigation to see if we can purge these kinds of dead edges when they are
created (it should make more senses).

===

diff --git a/gcc/regcprop.cc b/gcc/regcprop.cc
index ce9d32a4fb7..afcfc0bf252 100644
--- a/gcc/regcprop.cc
+++ b/gcc/regcprop.cc
@@ -36,6 +36,7 @@
 #include "cfgrtl.h"
 #include "target.h"
 #include "function-abi.h"
+#include "cfgcleanup.h"

 /* The following code does forward propagation of hard register copies.
The object is to eliminate as many dependencies as possible, so that
@@ -74,6 +75,7 @@ struct value_data
   struct value_data_entry e[FIRST_PSEUDO_REGISTER];
   unsigned int max_value_regs;
   unsigned int n_debug_insn_changes;
+  bool need_purge_dead_edge;
 };

 static object_allocator
queued_debug_insn_change_pool
@@ -818,7 +820,11 @@ copyprop_hardreg_forward_1 (basic_block bb, struct
value_data *vd)
  bool last = insn == BB_END (bb);
  delete_insn (insn);
  if (last)
-   break;
+   {
+ if (find_reg_note (insn, REG_EH_REGION, NULL_RTX))
+   vd->need_purge_dead_edge = true;
+ break;
+   }
  continue;
}

@@ -1405,6 +1411,7 @@ pass_cprop_hardreg::execute (function *fun)

   FOR_EACH_BB_FN (bb, fun)
 {
+  all_vd[bb->index].need_purge_dead_edge = false;
   if (cprop_hardreg_bb (bb, all_vd, visited))
curr->safe_push (bb->index);
   if (all_vd[bb->index].n_debug_insn_changes)
@@ -1444,6 +1451,10 @@ pass_cprop_hardreg::execute (function *fun)
   std::swap (curr, next);
 }

+  FOR_EACH_BB_FN (bb, fun)
+if (all_vd[bb->index].need_purge_dead_edge)
+  purge_dead_edges (bb);
+
   free (all_vd);
   return 0;
 }

[Bug middle-end/106811] GENERIC and GIMPLE IL undefined behavior needs documenting

[nunoplopes at sapo dot pt via Gcc-bugs]

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

Nuno Lopes  changed:

   What|Removed |Added

 CC||nunoplopes at sapo dot pt

--- Comment #1 from Nuno Lopes  ---
I suggest adopting the concept of poison that LLVM has. It allows operations to
have undefined behavior, while still allow them to be moved freely.
I have some slides that may serve as an introduction to the topic:
https://web.ist.utl.pt/nuno.lopes/pres/ub-vmcai19.pdf

Happy to discuss further.

[Bug target/107506] [regression] cross-xtensa-esp32s2-elf/gcc-13.0.0_pre20221023: stack smashing detected during RTL pass: expand in function __absvdi2 (gen_movdi)

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

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

jcmvbkbc at gcc dot gnu.org changed:

   What|Removed |Added

 CC||jcmvbkbc at gcc dot gnu.org

--- Comment #1 from jcmvbkbc at gcc dot gnu.org ---
I cannot figure the exact gcc source version from this report, but looks like
it's the issue introduced in commit 4f3f0296acbb ("xtensa: Prepare the
transition from Reload to LRA") and fixed in commit f896c13489d2 ("xtensa: Fix
out-of-bounds array access in the movdi pattern").

[Bug target/107506] [regression] cross-xtensa-esp32s2-elf/gcc-13.0.0_pre20221023: stack smashing detected during RTL pass: expand in function __absvdi2 (gen_movdi)

[triffid.hunter at gmail dot com via Gcc-bugs]

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

Triffid Hunter  changed:

   What|Removed |Added

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

--- Comment #2 from Triffid Hunter  ---
(In reply to jcmvbkbc from comment #1)
> fixed in commit f896c13489d2 ("xtensa: Fix out-of-bounds array access in the 
> movdi pattern").

That does sound entirely relevant, I'll try git head

Grabbed c3299cde4f33121f82a7a25d10c152ac96d2b035 and it successfully compiled.

Sorry for reporting something that's already been fixed

[Bug c++/104872] Memory corruption in Coroutine with POD type

[benni.buch at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Benjamin Buch  ---
Can you please increase the priority? P3 seems too low for the wrong code. With
ICE I could understand that, but here the code seems to be compiled
successfully and then crashes when running the program. This is security
relevant!

Bug is still present in GCC 12.2 and current trunk.

[Bug c++/104872] Memory corruption in Coroutine with POD type

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

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

--- Comment #5 from Jonathan Wakely  ---
P2 is used to mark regressions that already exist on released versions, P1 is
for regressions that are new on trunk and not in any release yet. Everything
else is P3.

Changing it would serve no real purpose, it wouldn't make it any more or less
likely for somebody to work on it.

[Bug c++/107239] Coroutine code generation bug

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #3 from Jonathan Wakely  ---
Possibly another dup of PR 98401

[Bug c++/102217] co_awaiting a temporary produced by ternary operator crashes (double-free)

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
   Last reconfirmed||2022-11-02
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #4 from Jonathan Wakely  ---
=
==624580==ERROR: AddressSanitizer: heap-use-after-free on address
0x60600028 at pc 0x004042b1 bp 0x7ffe18357490 sp 0x7ffe18357488
READ of size 8 at 0x60600028 thread T0
#0 0x4042b0 in std::__n4861::coroutine_handle > >::destroy() const
/home/jwakely/gcc/12.1.0/include/c++/12.1.0/coroutine:246
#1 0x403cb7 in Co::UniqueHandle >
>::~UniqueHandle() /tmp/cocrash.cxx:37
#2 0x403767 in Co::Task::~Task() /tmp/cocrash.cxx:135
#3 0x402a47 in FooC /tmp/cocrash.cxx:171
#4 0x4018c2 in FooA /tmp/cocrash.cxx:160
#5 0x402c11 in FooC /tmp/cocrash.cxx:168
#6 0x403501 in std::__n4861::coroutine_handle::resume() const
/home/jwakely/gcc/12.1.0/include/c++/12.1.0/coroutine:135
#7 0x402f84 in main /tmp/cocrash.cxx:177
#8 0x7f66323e750f in __libc_start_call_main (/lib64/libc.so.6+0x2950f)
#9 0x7f66323e75c8 in __libc_start_main_impl (/lib64/libc.so.6+0x295c8)
#10 0x4011b4 in _start (/tmp/a.out+0x4011b4)

0x60600028 is located 8 bytes inside of 56-byte region
[0x60600020,0x60600058)
freed by thread T0 here:
#0 0x7f66329bcbb8 in operator delete(void*)
../../../../gcc-12.1.0/libsanitizer/asan/asan_new_delete.cpp:152
#1 0x401981 in FooA /tmp/cocrash.cxx:162
#2 0x401a38 in FooA /tmp/cocrash.cxx:160
#3 0x4042b9 in std::__n4861::coroutine_handle > >::destroy() const
/home/jwakely/gcc/12.1.0/include/c++/12.1.0/coroutine:246
#4 0x403cb7 in Co::UniqueHandle >
>::~UniqueHandle() /tmp/cocrash.cxx:37
#5 0x403767 in Co::Task::~Task() /tmp/cocrash.cxx:135
#6 0x4029ff in FooC /tmp/cocrash.cxx:171
#7 0x4018c2 in FooA /tmp/cocrash.cxx:160
#8 0x402c11 in FooC /tmp/cocrash.cxx:168
#9 0x403501 in std::__n4861::coroutine_handle::resume() const
/home/jwakely/gcc/12.1.0/include/c++/12.1.0/coroutine:135
#10 0x402f84 in main /tmp/cocrash.cxx:177
#11 0x7f66323e750f in __libc_start_call_main (/lib64/libc.so.6+0x2950f)

previously allocated by thread T0 here:
#0 0x7f66329bc178 in operator new(unsigned long)
../../../../gcc-12.1.0/libsanitizer/asan/asan_new_delete.cpp:95
#1 0x40129f in FooA() /tmp/cocrash.cxx:162
#2 0x4027c2 in FooC /tmp/cocrash.cxx:171
#3 0x403501 in std::__n4861::coroutine_handle::resume() const
/home/jwakely/gcc/12.1.0/include/c++/12.1.0/coroutine:135
#4 0x402f84 in main /tmp/cocrash.cxx:177
#5 0x7f66323e750f in __libc_start_call_main (/lib64/libc.so.6+0x2950f)

SUMMARY: AddressSanitizer: heap-use-after-free
/home/jwakely/gcc/12.1.0/include/c++/12.1.0/coroutine:246 in
std::__n4861::coroutine_handle > >::destroy()
const
Shadow bytes around the buggy address:
  0x0c0c7fff7fb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c0c7fff7fc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c0c7fff7fd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c0c7fff7fe0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c0c7fff7ff0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x0c0c7fff8000: fa fa fa fa fd[fd]fd fd fd fd fd fa fa fa fa fa
  0x0c0c7fff8010: fd fd fd fd fd fd fd fa fa fa fa fa fa fa fa fa
  0x0c0c7fff8020: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c0c7fff8030: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c0c7fff8040: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c0c7fff8050: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
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:   f2
  Stack right redzone: f3
  Stack after return:  f5
  Stack use after scope:   f8
  Global redzone:  f9
  Global init order:   f6
  Poisoned by user:f7
  Container overflow:  fc
  Array cookie:ac
  Intra object redzone:bb
  ASan internal:   fe
  Left alloca redzone: ca
  Right alloca redzone:cb
==624580==ABORTING

[Bug c++/102217] co_awaiting a temporary produced by ternary operator crashes (double-free)

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

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

--- Comment #5 from Jonathan Wakely  ---
I also see the ICE on trunk (but not the release branches) so I suspect it's
related to --enable-checking 

cocrash.cxx: In function 'Co::Task FooC(bool)':
cocrash.cxx:171:1: internal compiler error: in flatten_await_stmt, at
cp/coroutines.cc:2891
  171 | }
  | ^
0x6a8242 flatten_await_stmt
/home/jwakely/src/gcc/gcc/gcc/cp/coroutines.cc:2891
0x9d7d57 flatten_await_stmt
/home/jwakely/src/gcc/gcc/gcc/cp/coroutines.cc:2920
0x9d7d57 flatten_await_stmt
/home/jwakely/src/gcc/gcc/gcc/cp/coroutines.cc:2920
0x9d9dee maybe_promote_temps
/home/jwakely/src/gcc/gcc/gcc/cp/coroutines.cc:3105
0x9d9dee await_statement_walker
/home/jwakely/src/gcc/gcc/gcc/cp/coroutines.cc:3749
0x14b54d3 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
/home/jwakely/src/gcc/gcc/gcc/tree.cc:11270
0x9d9f30 await_statement_walker
/home/jwakely/src/gcc/gcc/gcc/cp/coroutines.cc:3420
0x14b54d3 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
/home/jwakely/src/gcc/gcc/gcc/tree.cc:11270
0x9d975f await_statement_walker
/home/jwakely/src/gcc/gcc/gcc/cp/coroutines.cc:3697
0x14b54d3 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
/home/jwakely/src/gcc/gcc/gcc/tree.cc:11270
0x9da03c await_statement_walker
/home/jwakely/src/gcc/gcc/gcc/cp/coroutines.cc:3409
0x14b54d3 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
/home/jwakely/src/gcc/gcc/gcc/tree.cc:11270
0x9d9f30 await_statement_walker
/home/jwakely/src/gcc/gcc/gcc/cp/coroutines.cc:3420
0x14b54d3 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
/home/jwakely/src/gcc/gcc/gcc/tree.cc:11270
0x14b56dd walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
/home/jwakely/src/gcc/gcc/gcc/tree.cc:11501
0x9d9f30 await_statement_walker
/home/jwakely/src/gcc/gcc/gcc/cp/coroutines.cc:3420
0x14b54d3 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
/home/jwakely/src/gcc/gcc/gcc/tree.cc:11270
0x9da03c await_statement_walker
/home/jwakely/src/gcc/gcc/gcc/cp/coroutines.cc:3409
0x14b54d3 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
/home/jwakely/src/gcc/gcc/gcc/tree.cc:11270
0x9db8e5 morph_fn_to_coro(tree_node*, tree_node**, tree_node**)
/home/jwakely/src/gcc/gcc/gcc/cp/coroutines.cc:4496
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 c++/104872] Memory corruption in Coroutine with POD type

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #6 from Jonathan Wakely  ---
   view: 0x60f00050 default
   view: 0x60f000a0 generate
move-assign: 0x60f00050 <= 0x60f00080 default <= generate
   destruct: 0x60f00080 
   destruct: 0x60f000a0 generate
   destruct: 0x60f00050 generate
=
==624938==ERROR: AddressSanitizer: attempting free on address which was not
malloc()-ed: 0x60f000b0 in thread T0
#0 0x7f559baa6898 in operator delete(void*)
/home/jwakely/src/gcc/gcc/libsanitizer/asan/asan_new_delete.cpp:152
#1 0x403260 in logging_string::~logging_string() /tmp/coro.C:21
#2 0x4034e9 in wrapper::~wrapper() /tmp/coro.C:33
#3 0x403695 in generator::promise_type::~promise_type() /tmp/coro.C:44
#4 0x402b60 in generate /tmp/coro.C:81
#5 0x402d90 in generate /tmp/coro.C:79
#6 0x403815 in
std::__n4861::coroutine_handle::destroy() const
/home/jwakely/gcc/13/include/c++/13.0.0/coroutine:242
#7 0x4034cd in generator::~generator() /tmp/coro.C:72
#8 0x402e45 in main /tmp/coro.C:87
#9 0x7f559b4b850f in __libc_start_call_main (/lib64/libc.so.6+0x2950f)
(BuildId: 85c438f4ff93e21675ff174371c9c583dca00b2c)
#10 0x7f559b4b85c8 in __libc_start_main_impl (/lib64/libc.so.6+0x295c8)
(BuildId: 85c438f4ff93e21675ff174371c9c583dca00b2c)
#11 0x402294 in _start (/tmp/a.out+0x402294)

0x60f000b0 is located 112 bytes inside of 168-byte region
[0x60f00040,0x60f000e8)
allocated by thread T0 here:
#0 0x7f559baa5e58 in operator new(unsigned long)
/home/jwakely/src/gcc/gcc/libsanitizer/asan/asan_new_delete.cpp:95
#1 0x40237f in generate /tmp/coro.C:81
#2 0x402e2d in main /tmp/coro.C:85
#3 0x7f559b4b850f in __libc_start_call_main (/lib64/libc.so.6+0x2950f)
(BuildId: 85c438f4ff93e21675ff174371c9c583dca00b2c)

SUMMARY: AddressSanitizer: bad-free
/home/jwakely/src/gcc/gcc/libsanitizer/asan/asan_new_delete.cpp:152 in operator
delete(void*)
==624938==ABORTING


Probably another dup of PR 98401 or one of the other similar coro bugs.

[Bug c++/107504] Debugger jumps back to structured binding declaration

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

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

--- Comment #3 from Jonathan Wakely  ---
I'm also seeing similar jumps back and forth in the debugger for the bodies of
lambda expressions, where the debugger keeps jumping back to the capture list
of the lambda:


$ cat lambda.cc 
int main(int argc, char**)
{
  int x = 1;
  auto f = [&x, &argc](const char* i) {
i += x;
i -= argc;
i += argc - x;
return i;
  };
  f("  ");
}
$ g++ -g lambda.cc -o lambda
$ gdb -q -ex start -ex 'py [gdb.execute("step") for n in range(14)]' ./lambda
Reading symbols from ./lambda...
Temporary breakpoint 1 at 0x40117a: file lambda.cc, line 3.
Starting program: /tmp/lambda 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".

Temporary breakpoint 1, main (argc=1) at lambda.cc:3
3 int x = 1;
9 };
10f("  ");
operator() (__closure=0x7fffda60, i=0x402004 "  ") at lambda.cc:5
5   i += x;
4 auto f = [&x, &argc](const char* i) {
5   i += x;
6   i -= argc;
4 auto f = [&x, &argc](const char* i) {
6   i -= argc;
7   i += argc - x;
4 auto f = [&x, &argc](const char* i) {
7   i += argc - x;
4 auto f = [&x, &argc](const char* i) {
7   i += argc - x;
8   return i;

We keep returning to line 4 (the capture) every time the captured variiable is
odr-used.

[Bug libstdc++/107500] Useless atexit entry for ~constant_init in eh_globals.cc

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
(In reply to R. Diez from comment #0)
> The check above fails with GCC 12.2. Apparently, a destructor called
> constant_init::~constant_init() gets added to the atexit table on start-up.

This was done to make the global object in that file immortal. The
constant_init wrapper gets destroyed, but its subobject doesn't, so code that
refers to it later is ... slightly less undefined.

> Because of the way that Newlib works, that wastes 400 bytes of SRAM, which
> corresponds to sizeof( _global_atexit0 ). The structure has room for 32
> atexit calls (because of some ANSI conformance), but we are only using 1
> entry.
> 
> The interesting thing is that the destructor is supposed to be empty, see:
> 
> https://github.com/gcc-mirror/gcc/blob/master/libstdc%2B%2B-v3/libsupc%2B%2B/
> eh_globals.cc
> 
> ~constant_init() { /* do nothing, union member is not destroyed */ }
> 
> GCC generates the following code for that empty destructor:
> 
> 0008da68 <(anonymous namespace)::constant_init::~constant_init()>:
>   8da68:  b580  push  {r7, lr}
>   8da6a:  af00  add   r7, sp, #0
>   8da6c:  bd80  pop   {r7, pc}
> 
> That does not make any sense. Is there a way to prevent GCC from registering
> such an empty atexit function? Failing that, is there a way to prevent GCC
> from registering a particular atexit function, even if it is not empty?

If we had clang's no_destroy attribute then we could use that on those
constant_init wrappers:
https://clang.llvm.org/docs/AttributeReference.html#no-destroy


> I find surprising that GCC emits such code. My project is building its own
> GCC/Newlib toolchain with optimisation level "-Os", so I would expect at
> least the "add r7, sp, #0" to be optimised away.

Agreed, I don't think we should be emitting cleanup if it's a no-op. But I
don't know if the compiler is able to tell it's a no-op at the point where it
emits that code. The attribute would tell the compiler it's OK to do that.

[Bug c++/107500] Useless atexit entry for ~constant_init in eh_globals.cc

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

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

Jonathan Wakely  changed:

   What|Removed |Added

  Component|libstdc++   |c++
   Keywords||missed-optimization

--- Comment #2 from Jonathan Wakely  ---
I don't think this is a libstdc++ bug. We really do want that no-op destructor
to be in the library. It just shouldn't generate any code, but that's a
compiler problem.

[Bug c++/107507] New: Conversion function templates are not sometimes not considered if the return type is type dependent

[dangelog at gmail dot com via Gcc-bugs]

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

Bug ID: 107507
   Summary: Conversion function templates are not sometimes not
considered if the return type is type dependent
   Product: gcc
   Version: 12.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dangelog at gmail dot com
  Target Milestone: ---

Testcase:

template 
struct Test {
template 
operator T();
};

int main() {
Test t;

int *x = t; // OK
int *y = t + 42; // ERROR
}



: In function 'int main()':
:20:16: error: no match for 'operator+' (operand types are 'Test'
and 'int')
  228 | int *y = t + 42;
  |  ~ ^ ~~
  |  |   |
  |  |   int
  |  Test




This seems to depend on whether the conversion operators themselves are
function templates that return a type dependend on T. For instance, this works:


template 
struct Test {
template 
operator int *(); // don't return a type that depends on T
};

int main() {
Test t;

int *x = t; 
int *y = t + 42; // OK
}



And also this works:



template 
struct Test {
operator T(); // not a template
};

int main() {
Test t;

int *x = t;
int *y = t + 42;
}



I see that conversion function templates are treated in a special way in a
couple of places in the Standard but I'm not sure -- e.g. does
https://eel.is/c++draft/over.ics.user#3 apply here?. For comparison, Clang also
rejects this, while MSVC (in C++latest mode) accepts it.

[Bug c++/107500] Useless atexit entry for ~constant_init in eh_globals.cc

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

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

--- Comment #3 from Jonathan Wakely  ---
N.B. making the dtor constexpr doesn't change anything. Unsurprising, since
that just says it's usable in constant expressions, it doesn't mean the
destructor is trivial and can be elided. Worth a try though.

[Bug c++/107500] Useless atexit entry for ~constant_init in eh_globals.cc

[rdiezmail-gcc at yahoo dot de via Gcc-bugs]

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

--- Comment #4 from R. Diez  ---
The 'constant_init' wrapper with the 'union' inside is a contrived hack, isn't
it? We may as well use a different hack then.

How about a combination of '__attribute__ constructor' and 'placement new' like
this?

uint8_t some_buffer[ sizeof( __cxa_eh_globals ) ];

// All objects with an init_priority attribute are constructed before any
// object with no init_priority attribute.
#define SOME_INIT_PRIORITY  200  // Priority range [101, 65535].

static __attribute__ ((constructor (SOME_INIT_PRIORITY))) void
MyHackForInitWithoutAtExitDestructor ( void ) throw()
{
  // Placement new.
  new ( some_buffer ) __cxa_eh_globals();
}

You would then need a 'get_eh_globals()' wrapper to return a pointer or a
reference to a '__cxa_eh_globals' object from 'some_buffer', by doing a type
cast. Everybody should then use the wrapper to access that singleton object.

[Bug c++/107492] Unhelpful -Wignored-qualifiers warning in template specialization

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

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

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

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

commit r13-3607-gcf35818a390e7cb4b1a4fa70c243ede59d6cbbac
Author: Jonathan Wakely 
Date:   Tue Nov 1 11:17:35 2022 +

libstdc++: Ignore -Wignored-qualifiers warning in 

The warning is wrong here, the qualifier serves a purpose and is not
ignored (c.f. PR c++/107492).

libstdc++-v3/ChangeLog:

* include/std/variant (__variant::_Multi_array::__untag_result):
Use pragma to suppress warning.

[Bug c++/107500] Useless atexit entry for ~constant_init in eh_globals.cc

[rdiezmail-gcc at yahoo dot de via Gcc-bugs]

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

--- Comment #5 from R. Diez  ---
I know very little about GCC, but it is a very smart compiler, so I am having a
hard time understanding how GCC could miss so many optimisations. After all,
even when compiling with little optimisation, GCC seems able to discard unused
code rather well.

In my project, I am building my own toolchain with this makefile:

https://github.com/rdiez/DebugDue/blob/master/Toolchain/Makefile

I haven't verified it this time around, but I believe that Newlib is being
built with '-Os' optimisation. Search for COMMON_CFLAGS_FOR_TARGET in that
makefile, which eventually gets passed to Newlib in CFLAGS_FOR_TARGET.

First of all, GCC seems unable to generate an empty routine or destructor, or
at least flag it as being effectively empty. The caller should then realise
that it is empty, so it is not worth generating an atexit call for it.

Secondly, I am not ARM Thumb assembly expert either, but shouldn't "add r7, sp,
#0" be optimised away? After all, nobody is really using R7 in that routine.

And finally, what is the point of generating a function prolog and epilog which
saves and restores context from the stack? If the routine is pretty much empty,
but cannot be really empty, shouldn't some kind of RET instruction suffice?

[Bug c++/107500] Useless atexit entry for ~constant_init in eh_globals.cc

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

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

--- Comment #6 from Jonathan Wakely  ---
You can't use placement new in a constexpr constructor, so it can't be
constinit, which means it is susceptible to the static initialization order
fiasco. init priority attributes are also a hack, and less portable.

The whole point of this is to ensure the global is accessible *before* any user
code runs, and still accessible *after* static destructors run. Saving a few
bytes is less important than correctness.

If you really need to avoid it, you can provide a dummy atexit that doesn't
register the destructor, or wait for a possible compiler improvement to
optimize it away. I'm not going to change libstdc++ to stop doing this.

[Bug c++/107500] Useless atexit entry for ~constant_init in eh_globals.cc

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

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

--- Comment #7 from Jonathan Wakely  ---
(In reply to R. Diez from comment #5)
> First of all, GCC seems unable to generate an empty routine or destructor,
> or at least flag it as being effectively empty. The caller should then
> realise that it is empty, so it is not worth generating an atexit call for
> it.

The object has a user-provided destructor, which is necessary for the
immortalization trick to work. Being user-provided means it's non-trivial and
that means the destructor must be run. To destroy a gobal object, atexit it
used.

Now if the compiler can tell that the destructor actually has no side effects,
it's unobservable whether the atexit call ever happens. But that takes
non-trivial analysis of the destructor body and hard-coded knowledge that
atexit has no *other* observable side effects except registering the destructor
This all requires special case handling in the compiler, not just "turn on -Os
and all the code gets removed".

[Bug fortran/107508] New: Invalid bounds due to bogus reallocation on assignment with KIND=4 characters

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

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

Bug ID: 107508
   Summary: Invalid bounds due to bogus reallocation on assignment
with KIND=4 characters
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: burnus at gcc dot gnu.org
  Target Milestone: ---

In the following code, the bounds change during the assignment
but I believe the RHS and the LHS have the same shape and length parameters.

As it works with kind=4, I assume that there is a missing '*4' in the size
calculation.

! --

implicit none
character(len=:,kind=4), allocatable :: a4str(:), a4str2
allocate(character(len=7,kind=4) :: a4str(-2:3))

if (lbound(a4str,1) /= -2) error stop
if (ubound(a4str,1) /= 3) error stop

a4str = [4_"sf456aq", 4_"3dtzu24", 4_"_4fh7sm", 4_"=ff85s7", 4_"j=8af4d",
4_".,A%Fsz"]

print *, lbound(a4str), ubound(a4str)  ! expected (-2:3) - actually: (1:6)

if (lbound(a4str,1) /= -2) error stop
if (ubound(a4str,1) /= 3) error stop
end

[Bug go/107491] Gccgo stack not resizing on Solaris

[jakub.kulik at oracle dot com via Gcc-bugs]

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

--- Comment #4 from Jakub Kulik  ---
Thanks for the confirmation.

-fsplit-stack on Solaris would be nice, but it's as simple as designating a TLS
accessible slot, right? We have our own linker on Solaris and don't use gold,
and I am not how feasible it would be to add functionality similar to that of
gold.

I do like the idea of adjustable min size with an environment variable because
that should not be a big change, and all platforms can use it. It's not really
the best solution, but better than nothing, I guess.

[Bug c++/107509] New: wrong ambiguous overloaded function error if argument class is undefined

[fchelnokov at gmail dot com via Gcc-bugs]

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

Bug ID: 107509
   Summary: wrong ambiguous overloaded function error if argument
class is undefined
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fchelnokov at gmail dot com
  Target Milestone: ---

In the next program, struct B is only declared so foo(const B &) cannot be
called via foo({}):

struct A {};
struct B;

void foo(const A &) {}
void foo(const B &) {}

int main() {
foo({});
}

Clang and MSVC correctly call foo(const A &) here, but GCC prints the error:
call of overloaded 'foo()' is ambiguous

Online demo: https://godbolt.org/z/6fxYoxjc1

[Bug c++/107500] Useless atexit entry for ~constant_init in eh_globals.cc

[rdiezmail-gcc at yahoo dot de via Gcc-bugs]

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

--- Comment #8 from R. Diez  ---
Why does this 'eh_globals' object have to use a constexpr constructor?

How does the current code avoid the "static initialization order fiasco"? If
the user defines his/her own static C++ objects, how is it guaranteed now that
'eh_globals' is initialised before all other user code?

Isn't using the "__attribute__ constructor" trick safer anyway? With it, you
can document what priority levels libstdc++ uses. The user may even want to run
a few routines before libstdc++ initialises. Flexibility in the initialisation
order is often important in embedded environments.

Portability is not really an issue. You can just "#ifdef GCC" around the
"better" hack. Is GCC not using "__attribute__ constructor" internally anyway
to implement such static constructors? So anybody using C++ with GCC must
support that mechanism already.

And about saving a few bytes, 400 bytes is no small amount in tightly-embedded
environments. But it is not just the amount of memory. As I mentioned, my code
is checking that nothing unexpected registers an atexit() destructor. If
libstdc++ does that on start-up, it becomes hard to tell whether something
unexpected has been added recently.

I can surely put up with yet another little annoyance with this new GCC
version. But bear in mind that flexibility and attention to detail in the
embedded world is one of GCC's few remaining bastions. If GCC starts dropping
the ball here too, even more people will consider moving to clang.

[Bug c++/107500] Useless atexit entry for ~constant_init in eh_globals.cc

[rdiezmail-gcc at yahoo dot de via Gcc-bugs]

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

--- Comment #9 from R. Diez  ---
> [...]
> not just "turn on -Os and all the code gets removed".

I am sure that the solution is not as trivial as "turn on -Os". But, as an
outsider, it is hard to believe that it "takes non-trivial analysis of the
destructor body". The destructor is empty!

I am not talking about the GCC optimiser realising afterwards that the code is
generating an atexit() entry that does nothing. I am saying that GCC should not
generate so much code for an empty function for starters, and that GCC should
not generate the destructor registration at all if the destructor is empty. I
would imagine that those steps come before the optimiser gets to see the
generated code.

[Bug c++/107504] Debugger jumps back to structured binding declaration

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

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

--- Comment #4 from Andrew Pinski  ---
(In reply to Jonathan Wakely from comment #3)
> I'm also seeing similar jumps back and forth in the debugger for the bodies
> of lambda expressions, where the debugger keeps jumping back to the capture
> list of the lambda:

Yes see PR 84471 for the lambda issue.

[Bug libstdc++/105880] eh_globals_init destructor not setting _M_init to false

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

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

--- Comment #16 from Jonathan Wakely  ---
For the record, r12-8589-gade3197134cc9e was needed to fix something in the
commits above, and was also backported to gcc-12.

[Bug c++/107500] Useless atexit entry for ~constant_init in eh_globals.cc

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

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

--- Comment #10 from Jonathan Wakely  ---
(In reply to R. Diez from comment #8)
> Why does this 'eh_globals' object have to use a constexpr constructor?

So it can be constinit.

> How does the current code avoid the "static initialization order fiasco"? If
> the user defines his/her own static C++ objects, how is it guaranteed now
> that 'eh_globals' is initialised before all other user code?

Because that's what constinit means.
https://en.cppreference.com/w/cpp/language/constinit

> Isn't using the "__attribute__ constructor" trick safer anyway? With it, you
> can document what priority levels libstdc++ uses. The user may even want to
> run a few routines before libstdc++ initialises. Flexibility in the
> initialisation order is often important in embedded environments.
> 
> Portability is not really an issue. You can just "#ifdef GCC" around the
> "better" hack. Is GCC not using "__attribute__ constructor" internally
> anyway to implement such static constructors? So anybody using C++ with GCC
> must support that mechanism already.

No, it doesn't work on all targets supported by GCC and libstdc++.

> And about saving a few bytes, 400 bytes is no small amount in
> tightly-embedded environments. But it is not just the amount of memory. As I
> mentioned, my code is checking that nothing unexpected registers an atexit()
> destructor. If libstdc++ does that on start-up, it becomes hard to tell
> whether something unexpected has been added recently.
> 
> I can surely put up with yet another little annoyance with this new GCC
> version. But bear in mind that flexibility and attention to detail in the
> embedded world is one of GCC's few remaining bastions. If GCC starts
> dropping the ball here too, even more people will consider moving to clang.

The "if you don't fix this people will switch to clang" threat is not as
motivating as you might think. It gets tedious after the thousandth time you
hear it.

I've confirmed the bug as a missed-optimization, and suggested ways the
compiler might be able to solve it. I am not going to reintroduce race
conditions in libstdc++ to work around your needs here.

If you think GCC (and libstdc++ in particular) doesn't care about embedded then
you're not paying attention. The changes to eh_globals.cc were introduced for
PR105880 specifically to solve a bug on embedded targets using newlib. And
there have been more than a dozen commits in the past month making huge parts
of libstdc++ more usable on bare metal.

If you think the codegen for empty functions can be improved, please file a
separate bug as that's not the same topic as optimizing away atexit calls for
empty destructors.

[Bug c++/84471] Debugger jumps back to lambda capture location every time a captured variable is odr-used

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

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

Jonathan Wakely  changed:

   What|Removed |Added

Summary|Instruction reordering  |Debugger jumps back to
   |happens in lambdas even |lambda capture location
   |with -O0|every time  a captured
   ||variable is odr-used

--- Comment #4 from Jonathan Wakely  ---
Every time a captured variable is odr-used in the lambda body, the debugger
jumps back to the location of the capture list:

$ cat lambda.cc 
int main(int argc, char**)
{
  int x = 1;
  auto f = [&x, &argc](const char* i) {
i += x;
i -= argc;
i += argc - x;
return i;
  };
  f("  ");
}
$ g++ -g lambda.cc -o lambda
$ gdb -q -ex start -ex 'py [gdb.execute("step") for n in range(14)]' ./lambda
Reading symbols from ./lambda...
Temporary breakpoint 1 at 0x40117a: file lambda.cc, line 3.
Starting program: /tmp/lambda 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".

Temporary breakpoint 1, main (argc=1) at lambda.cc:3
3 int x = 1;
9 };
10f("  ");
operator() (__closure=0x7fffda60, i=0x402004 "  ") at lambda.cc:5
5   i += x;
4 auto f = [&x, &argc](const char* i) {
5   i += x;
6   i -= argc;
4 auto f = [&x, &argc](const char* i) {
6   i -= argc;
7   i += argc - x;
4 auto f = [&x, &argc](const char* i) {
7   i += argc - x;
4 auto f = [&x, &argc](const char* i) {
7   i += argc - x;
8   return i;

We keep returning to line 4 (the capture) every time the captured variiable is
odr-used.


I've updated the summary. There is no instruction reordering, the debuginfo
just contains line info that causes the debugger to jump around. That has
nothing to do with the actual instructions being executed.

[Bug c++/107500] Useless atexit entry for ~constant_init in eh_globals.cc

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

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

--- Comment #11 from Jonathan Wakely  ---
Reduced:

extern "C" int puts(const char*);

struct A
{
  constexpr A()  { }
  ~A() { puts("bye"); }
};

namespace
{
  struct constant_init
  {
union {
  A obj;
};
constexpr constant_init() : obj() { }

~constant_init() { /* do nothing, union member is not destroyed */ }
  };


  // Single-threaded fallback buffer.
  constinit constant_init global;
}

extern "C" A* get() { return &global.obj; }

With -std=c++20 -Os GCC emits a call to atexit:

(anonymous namespace)::constant_init::~constant_init() [base object
destructor]:
ret
get:
mov eax, OFFSET FLAT:_ZN12_GLOBAL__N_16globalE
ret
_GLOBAL__sub_I_get:
mov edx, OFFSET FLAT:__dso_handle
mov esi, OFFSET FLAT:_ZN12_GLOBAL__N_16globalE
mov edi, OFFSET FLAT:_ZN12_GLOBAL__N_113constant_initD1Ev
jmp __cxa_atexit


With the same options, Clang doesn't:

get:# @get
lea rax, [rip + (anonymous namespace)::global]
ret

[Bug libstdc++/105880] eh_globals_init destructor not setting _M_init to false

[rdiezmail-gcc at yahoo dot de via Gcc-bugs]

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

R. Diez  changed:

   What|Removed |Added

 CC||rdiezmail-gcc at yahoo dot de

--- Comment #17 from R. Diez  ---
For the record, this fix introduces a call to atexit() for a static destructor,
see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107500

[Bug target/106602] riscv: suboptimal codegen for zero_extendsidi2_shifted w/o bitmanip

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

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

--- Comment #17 from Jeffrey A. Law  ---
Vineet: I don't know your priorities and such, but I've got a junior engineer
starting in a bit under two weeks and this would actually be a good issue for
them to tackle as part of learning about GCC.  So if you want to set it aside,
I can have someone poking at it fairly soon.

[Bug analyzer/106302] RFE: provide a way for -fanalyzer to use target flags

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

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #1 from David Malcolm  ---
Patch posted here:
  https://gcc.gnu.org/pipermail/gcc-patches/2022-October/604739.html

Waiting on review for C frontend parts.

[Bug analyzer/107486] [13 Regression] ICE when pipe's argument is not a pointer type

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

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

David Malcolm  changed:

   What|Removed |Added

Summary|[13 Regression] ICE in  |[13 Regression] ICE when
   |deref_rvalue, at|pipe's argument is not a
   |analyzer/region-model.cc:33 |pointer type
   |17  |
   Last reconfirmed||2022-11-02
 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1

--- Comment #1 from David Malcolm  ---
Thanks for filing this bug.

I'm testing a fix.

[Bug tree-optimization/19661] unnecessary atexit calls emitted for static objects with empty destructors

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||rdiezmail-gcc at yahoo dot de

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

[Bug c++/107500] Useless atexit entry for ~constant_init in eh_globals.cc

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #12 from Andrew Pinski  ---
(In reply to Jonathan Wakely from comment #11)
> Reduced:

And that is a dup of bug 19661.

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

[Bug tree-optimization/19661] unnecessary atexit calls emitted for static objects with empty destructors

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Last reconfirmed|2006-02-05 21:10:26 |2022-11-2

--- Comment #12 from Jonathan Wakely  ---
Reduced from the code in libstdc++:

extern "C" int puts(const char*);

struct A
{
  constexpr A()  { }
  ~A() { puts("bye"); }
};

namespace
{
  struct constant_init
  {
union {
  A obj;
};
constexpr constant_init() : obj() { }

~constant_init() { /* do nothing, union member is not destroyed */ }
  };


  // Single-threaded fallback buffer.
  constinit constant_init global;
}

extern "C" A* get() { return &global.obj; }

With -std=c++20 -Os GCC emits a call to atexit:

(anonymous namespace)::constant_init::~constant_init() [base object
destructor]:
ret
get:
mov eax, OFFSET FLAT:_ZN12_GLOBAL__N_16globalE
ret
_GLOBAL__sub_I_get:
mov edx, OFFSET FLAT:__dso_handle
mov esi, OFFSET FLAT:_ZN12_GLOBAL__N_16globalE
mov edi, OFFSET FLAT:_ZN12_GLOBAL__N_113constant_initD1Ev
jmp __cxa_atexit


With the same options, Clang doesn't:

get:# @get
lea rax, [rip + (anonymous namespace)::global]
ret

[Bug driver/93371] -ffile-prefix-map ignored with assembly files

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

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

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

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

commit r13-3611-gabaa32c7384edef065c79741764bc112dd18f32d
Author: Rasmus Villemoes 
Date:   Wed Nov 2 10:01:22 2022 -0600

gcc: honour -ffile-prefix-map in ASM_MAP [PR93371]

-ffile-prefix-map is supposed to be a superset of -fmacro-prefix-map
and -fdebug-prefix-map. However, when building .S or .s files, gas is
not called with the appropriate --debug-prefix-map option when
-ffile-prefix-map is used.

While the user can specify -fdebug-prefix-map when building assembly
files via gcc, it's more ergonomic to also support -ffile-prefix-map;
especially since for .S files that could contain the __FILE__ macro,
one would then also have to specify -fmacro-prefix-map.

gcc:
PR driver/93371
* gcc.cc (ASM_MAP): Honour -ffile-prefix-map.

[Bug c++/107500] Useless atexit entry for ~constant_init in eh_globals.cc

[rdiezmail-gcc at yahoo dot de via Gcc-bugs]

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

R. Diez  changed:

   What|Removed |Added

 Resolution|DUPLICATE   |FIXED

--- Comment #13 from R. Diez  ---
>From your comments about "constexpr constructor" and "constinit", I gather that
the "eh_globals" singleton is guaranteed then to be initialised very early,
earlier than anything else that might use it, right? But that does not
guarantee that it will be destroyed later than anything that wants to use it,
is that correct? That is why we need the hack, to make it outlive all potential
users.

I am now trying to understand the implications of not destroying
"__cxa_eh_globals obj" inside the "eh_globals" singleton, at least in the case
of single-threaded (bare metal) embedded software. Hopefully, I can learn a
little more along the way about how C++ exception handling works.

As far as I can see, "struct __cxa_eh_globals" in unwind-cxx.h has 1 or 2
pointers and no destructor:

struct __cxa_eh_globals
{
  __cxa_exception *caughtExceptions;
  unsigned int uncaughtExceptions;
#ifdef __ARM_EABI_UNWINDER__
  __cxa_exception* propagatingExceptions;
#endif
};

Therefore, destroying this object should have real no effect. I wonder why
there was a problem to fix in 'eh_globals' then.

I am guessing that some static analyser, or checker instrumentation, may now
complain that static object 'eh_globals', or at least its member 'obj', has not
been properly destroyed upon termination. Normally, that would mean a risk of
leaking some memory, but I am guessing that the last thread can never have any
such 'caughtExceptions' or 'propagatingExceptions' left upon termination,
right?

So, theoretically, instead of leaving the destructor for the singleton empty,
we could add asserts that those 2 pointers are nullptr. Or am I missing
something?

This all feels iffy. If I understand this correctly, it is impossible for GCC
to guarantee the correct construction and destruction order of such global
objects, and that is why we are hacking our way out. The reason is mainly, that
not all targets support "__attribute__ constructor", so there is no way to
implement a deterministic initialisation and destruction order for everybody.
Is that right?

[Bug tree-optimization/105532] [11/12/13 Regression] UBSAN: gcc/hwint.h:293:61: runtime error: shift exponent 64 is too large for 64-bit type 'long unsigned int'

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

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

--- Comment #4 from Andrew Pinski  ---
Created attachment 53820
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53820&action=edit
Patch which is under test

This is patch 1 of 2. The 2nd patch adds the assert to catch this earlier on.

[Bug tree-optimization/107505] [13 Regression] ICE: verify_flow_info failed (error: returns_twice call is not first in basic block 2)

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |13.0

[Bug tree-optimization/105532] [11/12/13 Regression] UBSAN: gcc/hwint.h:293:61: runtime error: shift exponent 64 is too large for 64-bit type 'long unsigned int'

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

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

--- Comment #5 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #2)
> Confirmed.
> The bug is either in tree_nonzero_bits and should not be doing:
>   return wi::shwi (-1, TYPE_PRECISION (TREE_TYPE (t)));

Just FYI, TYPE_PRECISION for vectors is a log2 of the number of elements, see
TYPE_VECTOR_SUBPARTS. Which is why you get 0 here since we have 1 element.

[Bug go/107491] Gccgo stack not resizing on Solaris

[ian at airs dot com via Gcc-bugs]

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

--- Comment #5 from Ian Lance Taylor  ---
Good point, I did forget about using gold or lld.  Sorry.

[Bug target/106602] riscv: suboptimal codegen for zero_extendsidi2_shifted w/o bitmanip

[vineetg at rivosinc dot com via Gcc-bugs]

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

--- Comment #18 from Vineet Gupta  ---
(In reply to Jeffrey A. Law from comment #17)
> Vineet: I don't know your priorities and such, but I've got a junior
> engineer starting in a bit under two weeks and this would actually be a good
> issue for them to tackle as part of learning about GCC.  So if you want to
> set it aside, I can have someone poking at it fairly soon.

Seem slike I've spent way too much time on this than warranted so might as well
complete it :-)

[Bug target/106602] riscv: suboptimal codegen for zero_extendsidi2_shifted w/o bitmanip

[vineetg at rivosinc dot com via Gcc-bugs]

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

--- Comment #19 from Vineet Gupta  ---
(In reply to Jeffrey A. Law from comment #13)
> Trying 7, 8, 9 -> 10:
> 7: r140:DI=0x1
> 8: r141:DI=r140:DI<<0x26
>   REG_DEAD r140:DI
>   REG_EQUAL 0x40
> 9: r139:DI=r141:DI-0x40
>   REG_DEAD r141:DI
>   REG_EQUAL 0x3fffc0
>10: r137:DI=r138:DI&r139:DI
>   REG_DEAD r139:DI
>   REG_DEAD r138:DI
> Failed to match this instruction:
> (set (reg:DI 137)
> (and:DI (reg:DI 138)
> (const_int 274877906880 [0x3fffc0])))
> 
> 
> That's what we're looking for.  I think I had a wrong switch somewhere. 
> Match that with a define_split and you should be good to go.

I experimented with a define_split and initially saw it generate 

sllia5,a0,32
srlia0,a5,6 

but realized for both leading and trailing zeroes (either of arbitrary length)
we'll need 3 shifts ?

[Bug c++/107500] Useless atexit entry for ~constant_init in eh_globals.cc

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Resolution|FIXED   |DUPLICATE

--- Comment #14 from Jonathan Wakely  ---
Not FIXED, nothing was fixed here, it's a dup.

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

[Bug c++/105483] [10/11/12/13 Regression] injected-class-name and constructors diagnostic

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Known to work||7.1.0
 Ever confirmed|0   |1
   Last reconfirmed||2022-11-02
Summary|injected-class-name and |[10/11/12/13 Regression]
   |constructors diagnostic |injected-class-name and
   ||constructors diagnostic
   Target Milestone|--- |10.5
  Known to fail||8.1.0
   Keywords||needs-bisection
 Status|UNCONFIRMED |NEW

--- Comment #1 from Andrew Pinski  ---
GCC 7 produces:
: In function 'void g()':
:6:3: error: 'X::X' names the constructor, not the type
   X::X x;
   ^
:6:8: error: expected ';' before 'x'
   X::X x;
^
:6:9: error: statement cannot resolve address of overloaded function
   X::X x;
 ^

While GCC 8 produces the __ct diagnostic. At least that part is a regression.

[Bug target/106602] riscv: suboptimal codegen for zero_extendsidi2_shifted w/o bitmanip

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

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

--- Comment #20 from Jeffrey A. Law  ---
Yea, I think so (3 shifts).  Two for masking, one to put the bits in the right
position.  Then we just have to figure out how to combine the initial shift
with the 3 for the masking and ultimately result with just two :-)

[Bug tree-optimization/19661] unnecessary atexit calls emitted for static objects with empty destructors

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

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

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

[Bug c++/107500] Useless atexit entry for ~constant_init in eh_globals.cc

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

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

--- Comment #15 from Jonathan Wakely  ---
(In reply to R. Diez from comment #13)
> From your comments about "constexpr constructor" and "constinit", I gather
> that the "eh_globals" singleton is guaranteed then to be initialised very
> early, earlier than anything else that might use it, right? But that does

At compile time, before any code executes.

> not guarantee that it will be destroyed later than anything that wants to
> use it, is that correct? That is why we need the hack, to make it outlive
> all potential users.

Yes, the destruction is dynamic, and so not ordered relative to destructors in
other translation units.

> Therefore, destroying this object should have real no effect. I wonder why
> there was a problem to fix in 'eh_globals' then.

Read the bug. There was another global with a non-trivial destructor, which had
problems due to destructor ordering.

Without using the constant_init type to make the eh_globals variable immortal,
its destructor would still logically "run" at some point before or after
destruction of the other globals in that translation unit. That is true even if
the destructor is trivial and no code actually "runs". The current solution
avoids that, because its destructor never runs. Its lifetime would end when the
storage is reused, but it's a global so that doesn't happen. The object is
effectively immortal, and we don't run foul of optimizers making assumptions
about object lifetime.

> This all feels iffy. If I understand this correctly, it is impossible for
> GCC to guarantee the correct construction and destruction order of such
> global objects, and that is why we are hacking our way out. The reason is
> mainly, that not all targets support "__attribute__ constructor", so there
> is no way to implement a deterministic initialisation and destruction order
> for everybody. Is that right?

I don't consider this a hack, unlike using init priority.

Constant initialization is better than dynamic initialization where possible,
so I see no reason to forego constant initialization for dynamic initialization
that then needs init priority to make it work reliably. Constant init is always
reliable.

[Bug target/104118] gcc11 fails to build R for ppc64 on 10.5.8

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|11.4|11.3
 Status|WAITING |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #5 from Andrew Pinski  ---
No feedback in 7 months so closing as worksforme.

[Bug analyzer/105382] Support for coroutines in -fanalyzer

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/107505] [13 Regression] ICE: verify_flow_info failed (error: returns_twice call is not first in basic block 2)

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

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

Alexander Monakov  changed:

   What|Removed |Added

 CC||amonakov at gcc dot gnu.org

--- Comment #1 from Alexander Monakov  ---
Thanks. This is tree-ssa-sink relocating the call after 'zero' is discovered to
be const, so I think the fix may be as simple as

diff --git a/gcc/tree-ssa-sink.cc b/gcc/tree-ssa-sink.cc
index 921305201..631fc88c3 100644
--- a/gcc/tree-ssa-sink.cc
+++ b/gcc/tree-ssa-sink.cc
@@ -266,11 +266,11 @@ statement_sink_location (gimple *stmt, basic_block
frombb,
   /* We only can sink assignments and non-looping const/pure calls.  */
   int cf;
   if (!is_gimple_assign (stmt)
   && (!is_gimple_call (stmt)
  || !((cf = gimple_call_flags (stmt)) & (ECF_CONST|ECF_PURE))
- || (cf & ECF_LOOPING_CONST_OR_PURE)))
+ || (cf & (ECF_LOOPING_CONST_OR_PURE|ECF_RETURNS_TWICE
 return false;

   /* We only can sink stmts with a single definition.  */
   def_p = single_ssa_def_operand (stmt, SSA_OP_ALL_DEFS);
   if (def_p == NULL_DEF_OPERAND_P)

[Bug c/107510] New: gcc/config/gcn/gcn.cc:4930:9: style: Same expression on both sides of '||'. [duplicateExpression]

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 107510
   Summary: gcc/config/gcn/gcn.cc:4930:9: style: Same expression
on both sides of '||'. [duplicateExpression]
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

Source code is

  bool use_moves = (((unspec == UNSPEC_SMIN_DPP_SHR
  || unspec == UNSPEC_SMIN_DPP_SHR

Another small problem found by static analyser cppcheck.

[Bug target/107510] gcc/config/gcn/gcn.cc:4930:9: style: Same expression on both sides of '||'. [duplicateExpression]

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Target|gcn |amdgcn-*-*
   Last reconfirmed||2022-11-02
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
Confirmed.
It just looks like a copy and pasto and not really causing any issues:
  bool use_moves = (((unspec == UNSPEC_SMIN_DPP_SHR
  || unspec == UNSPEC_SMIN_DPP_SHR
  || unspec == UNSPEC_SMAX_DPP_SHR
  || unspec == UNSPEC_UMIN_DPP_SHR
  || unspec == UNSPEC_UMAX_DPP_SHR)
 && (scalar_mode == DImode
 || scalar_mode == DFmode))
|| (unspec == UNSPEC_PLUS_DPP_SHR
&& scalar_mode == DFmode));
  rtx_code code = (unspec == UNSPEC_SMIN_DPP_SHR ? SMIN
   : unspec == UNSPEC_SMIN_DPP_SHR ? SMIN
   : unspec == UNSPEC_SMAX_DPP_SHR ? SMAX
   : unspec == UNSPEC_UMIN_DPP_SHR ? UMIN
   : unspec == UNSPEC_UMAX_DPP_SHR ? UMAX
   : unspec == UNSPEC_PLUS_DPP_SHR ? PLUS
   : UNKNOWN);
  bool use_extends = ((unspec == UNSPEC_SMIN_DPP_SHR
   || unspec == UNSPEC_SMAX_DPP_SHR
   || unspec == UNSPEC_UMIN_DPP_SHR
   || unspec == UNSPEC_UMAX_DPP_SHR)
  && (scalar_mode == QImode
  || scalar_mode == HImode));


It was added afterwards too: r13-3574-gf539029c1ce6fb

[Bug target/105480] Vectorized `isnan` appears to trigger FPE on ppc64le

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

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

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

[Bug libgomp/106643] [gfortran + OpenACC] Allocate in module causes refcount error

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

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Thomas Schwinge :

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

commit r13-3616-gda8e0e1191c5512244a752b30dea0eba83e3d10c
Author: Thomas Schwinge 
Date:   Thu Oct 27 21:52:07 2022 +0200

Support OpenACC 'declare create' with Fortran allocatable arrays, part I
[PR106643]

PR libgomp/106643
libgomp/
* oacc-mem.c (goacc_enter_data_internal): Support
OpenACC 'declare create' with Fortran allocatable arrays, part I.
*
testsuite/libgomp.oacc-fortran/declare-allocatable-1-directive.f90:
New.
*
testsuite/libgomp.oacc-fortran/declare-allocatable-array_descriptor-1-directive.f90:
New.

[Bug libgomp/106643] [gfortran + OpenACC] Allocate in module causes refcount error

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

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Thomas Schwinge :

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

commit r13-3617-gf6ce1e77bbf5d3a096f52e674bfd7354c6537d10
Author: Thomas Schwinge 
Date:   Fri Oct 28 15:06:45 2022 +0200

Support OpenACC 'declare create' with Fortran allocatable arrays, part II
[PR106643, PR96668]

PR libgomp/106643
PR fortran/96668
libgomp/
* oacc-mem.c (goacc_enter_data_internal): Support
OpenACC 'declare create' with Fortran allocatable arrays, part II.
*
testsuite/libgomp.oacc-fortran/declare-allocatable-array_descriptor-1-directive.f90:
Adjust.
* testsuite/libgomp.oacc-fortran/pr106643-1.f90: New.

[Bug fortran/96668] [OpenMP] Re-mapping allocated but previously unallocated allocatable does not work

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

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

--- Comment #9 from CVS Commits  ---
The master branch has been updated by Thomas Schwinge :

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

commit r13-3617-gf6ce1e77bbf5d3a096f52e674bfd7354c6537d10
Author: Thomas Schwinge 
Date:   Fri Oct 28 15:06:45 2022 +0200

Support OpenACC 'declare create' with Fortran allocatable arrays, part II
[PR106643, PR96668]

PR libgomp/106643
PR fortran/96668
libgomp/
* oacc-mem.c (goacc_enter_data_internal): Support
OpenACC 'declare create' with Fortran allocatable arrays, part II.
*
testsuite/libgomp.oacc-fortran/declare-allocatable-array_descriptor-1-directive.f90:
Adjust.
* testsuite/libgomp.oacc-fortran/pr106643-1.f90: New.

[Bug target/105480] Vectorized `isnan` appears to trigger FPE on ppc64le

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Target|powerpc64le-linux   |powerpc64*-linux-*

--- Comment #4 from Andrew Pinski  ---
During expand:
(insn 20 19 21 (set (reg:V2DF 149)
(unordered:V2DF (reg:V2DF 128 [ vect__7.7 ])
(reg:V2DF 128 [ vect__7.7 ]))) -1
 (nil))

Which is correct.

after combine:
(insn 26 21 27 3 (set (reg:V2DF 154)
(unordered:V2DF (reg:V2DF 144 [ vect__7.8 ])
(reg:V2DF 144 [ vect__7.8 ]))) 1138 {vector_unorderedv2df}
 (expr_list:REG_DEAD (reg:V2DF 144 [ vect__7.8 ])
(nil)))

So basically the splitter here goes wrong:
; For ltgt/uneq/ordered/unordered:
; ltgt: gt(a,b) | gt(b,a)
; uneq: ~(gt(a,b) | gt(b,a))
; ordered: ge(a,b) | ge(b,a)
; unordered: ~(ge(a,b) | ge(b,a))
(define_insn_and_split

Someone else needs to look into making sure these are valid for trapping math
case ...

[Bug c++/107511] New: [13 Regression] gcc-13-20221030 failure to build on Cygwin due to lack of secure_getenv

[mckelvey at maskull dot com via Gcc-bugs]

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

Bug ID: 107511
   Summary: [13 Regression] gcc-13-20221030 failure to build on
Cygwin due to lack of secure_getenv
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mckelvey at maskull dot com
  Target Milestone: ---

Created attachment 53822
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53822&action=edit
Build log

libtool: compile: 
/home/McKelvey/gcc-13-20221030/host-x86_64-pc-cygwin/gcc/xgcc -shared-libgcc
-B/home/McKelvey/gcc-13-20221030/host-x86_64-pc-cygwin/gcc -nostdinc++
-L/home/McKelvey/gcc-13-20221030/x86_64-pc-cygwin/libstdc++-v3/src
-L/home/McKelvey/gcc-13-20221030/x86_64-pc-cygwin/libstdc++-v3/src/.libs
-L/home/McKelvey/gcc-13-20221030/x86_64-pc-cygwin/libstdc++-v3/libsupc++/.libs
-B/usr/local/x86_64-pc-cygwin/bin/ -B/usr/local/x86_64-pc-cygwin/lib/ -isystem
/usr/local/x86_64-pc-cygwin/include -isystem
/usr/local/x86_64-pc-cygwin/sys-include -fno-checking
-I/home/McKelvey/gcc-13-20221030/libstdc++-v3/../libgcc
-I/home/McKelvey/gcc-13-20221030/x86_64-pc-cygwin/libstdc++-v3/include/x86_64-pc-cygwin
-I/home/McKelvey/gcc-13-20221030/x86_64-pc-cygwin/libstdc++-v3/include
-I/home/McKelvey/gcc-13-20221030/libstdc++-v3/libsupc++ -D_GLIBCXX_SHARED
-fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi=2
-fdiagnostics-show-location=once -ffunction-sections -fdata-sections
-frandom-seed=eh_alloc.lo -g -O2 -c
../../.././libstdc++-v3/libsupc++/eh_alloc.cc -o eh_alloc.o
../../.././libstdc++-v3/libsupc++/eh_alloc.cc: In constructor
‘{anonymous}::pool::pool()’:
../../.././libstdc++-v3/libsupc++/eh_alloc.cc:190:27: error: ‘::secure_getenv’
has not been declared
  190 |   const char* str = ::secure_getenv("GLIBCXX_TUNABLES");

$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-pc-cygwin/13.0.0/lto-wrapper.exe
Target: x86_64-pc-cygwin
Configured with: ./configure --enable-languages=c,c++ --enable-threads=posix
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.0.0 20221030 (experimental) (GCC)

$ uname
CYGWIN_NT-10.0-19044

Windows 10

See 105540 and 104217 for gcc-11 and 12 fixes.

[Bug c++/105344] std::source_location::curent() seemingly treated as a pure function in template specializations

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

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

--- Comment #1 from Andrew Pinski  ---
(In reply to Jan Polasek from comment #0) 
> https://godbolt.org/z/ozf1MbG3n shows this code works fine under MSVC.

You don't try to use foo afterwards.
Once you do, MSVC will have an ICE.
try:
```
#include 
#include 

template  struct foo;

// Two following two specializations are different, yet gcc errors out,
// claiming they are the same.
#line 9
template 
struct foo> {
static constexpr int num = i;
};

#line 14
template 
struct foo> {
static constexpr int num = i;
};


int main(void)
{
foo<9> t;
foo<14> t;
}
```

So I don't know if this is valid or not.

[Bug libstdc++/107511] [13 Regression] gcc-13-20221030 failure to build on Cygwin due to lack of secure_getenv

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |13.0

[Bug libstdc++/107511] [13 Regression] gcc-13-20221030 failure to build on Cygwin due to lack of secure_getenv

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

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

--- Comment #1 from Andrew Pinski  ---
I suspect adding:
#ifndef _GNU_SOURCE
// Cygwin needs this for secure_getenv
# define _GNU_SOURCE 1
#endif

at the beginging of eh_alloc.cc fixes the issue; just like what was done for
src/c++17/fs_ops.cc, src/filesystem/dir.cc, etc.

[Bug libstdc++/107511] [13 Regression] gcc-13-20221030 failure to build on Cygwin due to lack of secure_getenv

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2022-11-02
   Keywords||build
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

[Bug libstdc++/107511] [13 Regression] gcc-13-20221030 failure to build on Cygwin due to lack of secure_getenv

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

[Bug c++/107512] New: Defaulted virtual destructor not considered in constexpr context

[kacper.slominski72 at gmail dot com via Gcc-bugs]

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

Bug ID: 107512
   Summary: Defaulted virtual destructor not considered in
constexpr context
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kacper.slominski72 at gmail dot com
  Target Milestone: ---

The following code causes a compiler error on GCC 12.2 and godbolt's trunk
(compiled with "-std=c++20 -Wall -Wextra -Wpedantic"):

struct base {
constexpr virtual ~base() = default;
};

struct derived final : base {
constexpr virtual ~derived() = default;
};

constexpr derived der;

The reported error is:

:9:19: error: 'virtual constexpr derived::~derived()' used before its
definition
9 | constexpr derived der;
  |   ^~~

Changing the destructor to the following makes the error go away:

constexpr virtual ~derived() { }

As does making the variable not constexpr. Clang seems to accept this without
any problems.

[Bug c++/107512] Defaulted virtual destructor not considered in constexpr context

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Duplicate of PR 93413.

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

[Bug c++/93413] Destructor definition not found during constant evaluation

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||kacper.slominski72 at gmail 
dot co
   ||m

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

[Bug c++/107513] New: [Feature Request] Implement __attribute__((__nodebug__))

[roi.jacobson1 at gmail dot com via Gcc-bugs]

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

Bug ID: 107513
   Summary: [Feature Request] Implement
__attribute__((__nodebug__))
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: roi.jacobson1 at gmail dot com
  Target Milestone: ---

Clang has __attribute__((__nodebug__)). When applied for types and functions it
suppresses generation of debug information for those types or functions. This
can greatly reduce binary sizes when compiling with debug symbols.

As a very non representative measure: in a library I'm currently working on, by
applying this attribute to some uninteresting 'forwarding' functions I see a
40% reduction in size (uncompressed and unrepresentative, but still).

It is worth noting that this attribute is already used in libc++ and in some
other libraries (for example Apple SIMD).

[Bug c++/107513] [Feature Request] Implement __attribute__((__nodebug__))

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

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

--- Comment #1 from Andrew Pinski  ---
GCC's artificial attribute should be similar for functions:
https://gcc.gnu.org/onlinedocs/gcc-12.2.0/gcc/Common-Function-Attributes.html#index-artificial-function-attribute

Which was added in GCC 4.3.0 by r0-83503-gd752cfdb114944.

types GCC does not have one.

I suspect for your usage artificial is enough.

[Bug c++/107513] [Feature Request] Implement __attribute__((__nodebug__))

[roi.jacobson1 at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Roy Jacobson  ---
I might be using it wrong? But it doesn't seem to do anything:
https://godbolt.org/z/9bdKhz4E7

It would be nice to at least avoid having the function's name in the binary,
clang does it with nodebug.

[Bug libgomp/106643] [gfortran + OpenACC] Allocate in module causes refcount error

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

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

Thomas Schwinge  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |tschwinge at gcc dot 
gnu.org
 Resolution|--- |FIXED
 CC||tschwinge at gcc dot gnu.org
 Status|UNCONFIRMED |RESOLVED

--- Comment #4 from Thomas Schwinge  ---
(In reply to Henry Le Berre from comment #0)
> ```
> /nethome/hberre3/USERSCRATCH/build-gcc-amdgpu//gcc/libgomp/oacc-mem.c:1153:
> goacc_enter_data_internal: Assertion `n->refcount != REFCOUNT_INFINITY &&
> n->refcount != REFCOUNT_LINK' failed.
> ```

ACK, and thanks for your detailed report.

> In order to generate this error, I had to create and dynamically allocate
> the array in another module. I initially wrote this in a single F90 file but
> the executable ran as expected.

Maybe the difference was that the '!$acc declare create(valls)' was in a
different scope?  Global scope (Fortran 'module' scope) is important here; then
"the associated region is the implicit region for the whole program" (as you
also had noted), which triggers this code path.

There are cases where it's relevant, but here, the separate module/main program
files are not necessary for demonstrating the issue.

On the other hand, it's helpful to include an OpenACC compute construct where
for 'valls' there is no explicit or implicit data clause due to "exposed
variable access" (OpenACC 3.2 term).  That means, in a separate 'subroutine'
accessing 'valls' in '!$acc declare create(valls)' instead of dummy argument. 
(... as I've implemented in the test case.)

So this is now fixed for GCC 13; not planning on backporting to current GCC
release branches.


> Our main code currently doesn't call `!$acc enter data create` for
> dynamically allocated arrays since it relies on NVIDIA (/PGI) hooking into
> the `allocate` call on the CPU. I ran into the above error when converting
> our allocation/deallocation routines.

ACK, GCC release branches and master branch are still missing support for
OpenACC "Changes from Version 2.0 to 2.5": "The 'declare create' directive with
a Fortran 'allocatable' has new behavior".  Preliminary support exists on the
devel/omp/gcc-12 branch (and earlier development branches), but needs to be
revised for upstream submission.

[Bug c++/107513] [Feature Request] Implement __attribute__((__nodebug__))

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

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

--- Comment #3 from Andrew Pinski  ---
(In reply to Roy Jacobson from comment #2)
> I might be using it wrong? But it doesn't seem to do anything:
> https://godbolt.org/z/9bdKhz4E7
> 
> It would be nice to at least avoid having the function's name in the binary,
> clang does it with nodebug.

because it does something different really.
It is not used to reduce debug info but rather to make the debugging experience
better.

It marks the inlined function with DW_AT_artificial.


.byte   0x1   # DW_AT_decl_file (/app/example.cpp)
.byte   0x2   # DW_AT_decl_line
.long   0x35  # DW_AT_type
.byte   0x3   # DW_AT_inline
.byte   0x1   # DW_AT_artificial

That is it is actually better than Clang's nodebug for debuggability reasons.

In my view nodebug is a hack rather than actually use DW_AT_artificial
correctly.

[Bug tree-optimization/105532] [11/12/13 Regression] UBSAN: gcc/hwint.h:293:61: runtime error: shift exponent 64 is too large for 64-bit type 'long unsigned int'

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

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

--- Comment #6 from Andrew Pinski  ---
Patch submitted here:
https://gcc.gnu.org/pipermail/gcc-patches/2022-November/604914.html

[Bug c++/107513] [Feature Request] Implement __attribute__((__nodebug__))

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

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

--- Comment #4 from Jonathan Wakely  ---
But what does DW_AT_artificial do? Does gdb just ignore it? I've never noticed
it helping at all.

[Bug target/105328] [x86] Failure to optimize out test instruction after add

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Most likely a dup of bug 3507.

[Bug tree-optimization/107413] Perf loss ~14% on 519.lbm_r SPEC cpu2017 benchmark with r8-7132-gb5b33e113434be

[rvmallad at amazon dot com via Gcc-bugs]

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

--- Comment #9 from Rama Malladi  ---
(In reply to Rama Malladi from comment #8)
> (In reply to Wilco from comment #7)
> > The revert results in about 0.5% loss on Neoverse N1, so it looks like the
> > reassociation pass is still splitting FMAs into separate MUL and ADD (which
> > is bad for narrow cores).
> 
> Thank you for checking on N1. Did you happen to check on V1 too to reproduce
> the perf results I had? Any other experiments/ tests I can do to help on
> this filing? Thanks again for the debug/ fix.

I ran SPEC cpu2017 fprate 1-copy benchmark built with the patch reverted and
using option 'neoverse-n1' on the Graviton 3 processor (which has support for
SVE). The performance was up by 0.4%, primary contributor being 519.lbm_r which
was up 13%.

[Bug c++/93413] Defaulted constexpr Destructor not being found during constant evaluation

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

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

Patrick Palka  changed:

   What|Removed |Added

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

[Bug c++/105300] [10/11/12/13 Regression] segfault from static_assert with user-defined string suffix argument

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |10.5
  Known to fail||6.1.0
Summary|segfault from static_assert |[10/11/12/13 Regression]
   |with user-defined string|segfault from static_assert
   |suffix argument |with user-defined string
   ||suffix argument
   Keywords||diagnostic
  Known to work||5.5.0

--- Comment #2 from Andrew Pinski  ---
MSVC produces a decent error message:

(2): error C3690: expected a string literal, but found a user-defined
string literal instead

Note best definition of the operator is just:
void operator""_x(const char *, decltype(sizeof(0)));
static_assert(false, "foo"_x);


Oh we started to ICE between GCC 5 and 6. Most likely when we started to print
out the message too.

[Bug c++/106829] [12/13 Regression] OpenMP offload internal compiler error: in gimplify_expr, at gimplify.cc:16222 since r12-5835

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

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

--- Comment #6 from CVS Commits  ---
The releases/gcc-12 branch has been updated by Jakub Jelinek
:

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

commit r12-8883-gf755e367117ca43c96235ef47d4915c3746a3483
Author: Jakub Jelinek 
Date:   Wed Sep 7 08:54:13 2022 +0200

openmp: Fix handling of target constructs in static member functions
[PR106829]

Just calling current_nonlambda_class_type in static member functions
returns
non-NULL, but something that isn't *this and if unlucky can match part of
the
IL and can be added to target clauses.
  if (DECL_NONSTATIC_MEMBER_P (decl)
  && current_class_ptr)
is a guard used elsewhere (in check_accessibility_of_qualified_id).

2022-09-07  Jakub Jelinek  

PR c++/106829
* semantics.cc (finish_omp_target_clauses): If
current_function_decl
isn't a nonstatic member function, don't set data.current_object to
non-NULL.

* g++.dg/gomp/pr106829.C: New test.

(cherry picked from commit e90af965e5c858ba02c0cdfbac35d0a19da1c2f6)

[Bug c/106981] [10/11/12 Regression][OpenACC][OpenMP] ICE in decompose, at wide-int.h:984 with '#pragma omp/acc atomic capture'

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

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

--- Comment #11 from CVS Commits  ---
The releases/gcc-12 branch has been updated by Jakub Jelinek
:

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

commit r12-8884-ga46f71c1a5c286b8cc4802fffe235909016cd34f
Author: Jakub Jelinek 
Date:   Sat Sep 24 09:19:26 2022 +0200

openmp, c: Tighten up c_tree_equal [PR106981]

This patch changes c_tree_equal to work more like cp_tree_equal, be
more strict in what it accepts.  The ICE on the first testcase was
due to INTEGER_CST wi::wide (t1) == wi::wide (t2) comparison which
ICEs if the two constants have different precision, but as the second
testcase shows, being too lenient in it can also lead to miscompilation
of valid OpenMP programs where we think certain expression is the same
even when it isn't and can be guaranteed at runtime to represent different
memory location.  So, the patch looks through only NON_LVALUE_EXPRs
and for constants as well as casts requires that the types match before
actually comparing the constant values or recursing on the cast operands.

2022-09-24  Jakub Jelinek  

PR c/106981
gcc/c/
* c-typeck.cc (c_tree_equal): Only strip NON_LVALUE_EXPRs at the
start.  For CONSTANT_CLASS_P or CASE_CONVERT: return false if t1
and
t2 have different types.
gcc/testsuite/
* c-c++-common/gomp/pr106981.c: New test.
libgomp/
* testsuite/libgomp.c-c++-common/pr106981.c: New test.

(cherry picked from commit 3c5bccb608c665ac3f62adb1817c42c845812428)

[Bug c++/107358] [13 Regression] i686-linux: Since r13-3290-g98e341130f8798 code fails to build libjxl-0/7.0 (vector float code)

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

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

--- Comment #6 from CVS Commits  ---
The releases/gcc-12 branch has been updated by Jakub Jelinek
:

https://gcc.gnu.org/g:31f25cf4ef9a0a0ccc0b0f9158773c5a71e74cc5

commit r12-8889-g31f25cf4ef9a0a0ccc0b0f9158773c5a71e74cc5
Author: Jakub Jelinek 
Date:   Mon Oct 24 17:53:16 2022 +0200

c, c++: Fix up excess precision handling of scalar_to_vector conversion
[PR107358]

As mentioned earlier in the C++ excess precision support mail, the
following
testcase is broken with excess precision both in C and C++ (though just in
C++
it was triggered in real-world code).
scalar_to_vector is called in both FEs after the excess precision
promotions
(or stripping of EXCESS_PRECISION_EXPR), so we can then get invalid
diagnostics that say float vector + float involves truncation (on ia32
from long double to float).

The following patch fixes that by calling scalar_to_vector on the operands
before the excess precision promotions, let scalar_to_vector just do the
diagnostics (it does e.g. fold_for_warn so it will fold
EXCESS_PRECISION_EXPR around REAL_CST to constants etc.) but will then
do the actual conversions using the excess precision promoted operands
(so say if we have vector double + (float + float) we don't actually do
vector double + (float) ((long double) float + (long double) float)
but
vector double + (double) ((long double) float + (long double) float)

2022-10-24  Jakub Jelinek  

PR c++/107358
gcc/c/
* c-typeck.cc (build_binary_op): Pass operands before excess
precision
promotions to scalar_to_vector call.
gcc/testsuite/
* c-c++-common/pr107358.c: New test.

(cherry picked from commit 65e3274e363cb2c6bfe6b5e648916eb7696f7e2f)

[Bug c/107001] ICE in expand_gimple_stmt_1, at cfgexpand.cc:4017 since r9-3941-g28567c40e2c7c88e

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

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

--- Comment #4 from CVS Commits  ---
The releases/gcc-12 branch has been updated by Jakub Jelinek
:

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

commit r12-8885-gc8dc6b06daf910b758bb964116ada2c5070de764
Author: Jakub Jelinek 
Date:   Sat Sep 24 09:24:26 2022 +0200

openmp: Fix ICE with taskgroup at -O0 -fexceptions [PR107001]

The following testcase ICEs because with -O0 -fexceptions
GOMP_taskgroup_end
call isn't directly followed by GOMP_RETURN statement, but there are some
conditionals to handle exceptions and we fail to find the correct
GOMP_RETURN.

The fix is to treat taskgroup similarly to target data, both of these
constructs
emit a try { body } finally { end_call } around the construct's body during
gimplification and we need to see proper construct nesting during
gimplification
and omp lowering (including nesting of regions checks), but during omp
expansion
we don't really need their nesting anymore, all we need is emit something
at
the start of the region and the end of the region is the end API call we've
already emitted during gimplification.  For target data, we weren't adding
GOMP_RETURN statement during omp lowering, so after that pass it is treated
merely like stand-alone omp directives.  This patch does the same for
taskgroup too.

2022-09-24  Jakub Jelinek  

PR c/107001
* omp-low.cc (lower_omp_taskgroup): Don't add GOMP_RETURN statement
at the end.
* omp-expand.cc (build_omp_regions_1): Clarify
GF_OMP_TARGET_KIND_DATA
is not stand-alone directive.  For GIMPLE_OMP_TASKGROUP, also don't
update parent.
(omp_make_gimple_edges) : Reset
cur_region back after new_omp_region.

* c-c++-common/gomp/pr107001.c: New test.

(cherry picked from commit ad2aab5c816a6fd56b46210c0a4a4c6243da1de9)

[Bug tree-optimization/107121] DEFERRED_INIT misspelled in error message

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

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

--- Comment #3 from CVS Commits  ---
The releases/gcc-12 branch has been updated by Jakub Jelinek
:

https://gcc.gnu.org/g:7d5e6cd2d3f00d463705a5046b2920680a0ab7a9

commit r12-8886-g7d5e6cd2d3f00d463705a5046b2920680a0ab7a9
Author: Jakub Jelinek 
Date:   Sun Oct 2 16:42:32 2022 +0200

tree-cfg: Fix a verification diagnostic typo [PR107121]

Obvious typo in diagnostics.

2022-10-02  Jakub Jelinek  

PR tree-optimization/107121
* tree-cfg.cc (verify_gimple_call): Fix a typo in diagnostics,
DEFFERED_INIT -> DEFERRED_INIT.

(cherry picked from commit d01bd0b0f3b8f4c33c437ff10f0b949200627f56)

[Bug c++/105774] Bogus overflow in constant expression with signed char++

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

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

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

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

commit r12--g20ef7d7c578dab0585d70fbea571a74e8e8d4b47
Author: Jakub Jelinek 
Date:   Mon Oct 24 16:25:29 2022 +0200

c++: Fix up constexpr handling of char/signed char/short pre/post
inc/decrement [PR105774]

signed char, char or short int pre/post inc/decrement are represented by
normal {PRE,POST}_{INC,DEC}REMENT_EXPRs in the FE and only gimplification
ensures that the {PLUS,MINUS}_EXPR is done in unsigned version of those
types:
case PREINCREMENT_EXPR:
case PREDECREMENT_EXPR:
case POSTINCREMENT_EXPR:
case POSTDECREMENT_EXPR:
  {
tree type = TREE_TYPE (TREE_OPERAND (*expr_p, 0));
if (INTEGRAL_TYPE_P (type) && c_promoting_integer_type_p (type))
  {
if (!TYPE_OVERFLOW_WRAPS (type))
  type = unsigned_type_for (type);
return gimplify_self_mod_expr (expr_p, pre_p, post_p, 1, type);
  }
break;
  }
This means during constant evaluation we need to do it similarly (either
using unsigned_type_for or using widening to integer_type_node).
The following patch does the latter.

2022-10-24  Jakub Jelinek  

PR c++/105774
* constexpr.cc (cxx_eval_increment_expression): For signed types
that promote to int, evaluate PLUS_EXPR or MINUS_EXPR in int type.

* g++.dg/cpp1y/constexpr-105774.C: New test.

(cherry picked from commit da8c362c4c18cff2f2dfd5c4706bdda7576899a4)

[Bug c++/105300] [10/11/12/13 Regression] segfault from static_assert with user-defined string suffix argument

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

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

--- Comment #3 from Andrew Pinski  ---
Something like:
diff --git a/gcc/cp/semantics.cc b/gcc/cp/semantics.cc
index 7c5f90b5127..185e0ac53f7 100644
--- a/gcc/cp/semantics.cc
+++ b/gcc/cp/semantics.cc
@@ -11203,6 +11203,13 @@ finish_static_assert (tree condition, tree message,
location_t location,
   if (check_for_bare_parameter_packs (condition))
 condition = error_mark_node;

+  if (TREE_CODE (message) != STRING_CST)
+{
+  location_t mloc = cp_expr_loc_or_loc (message, location);
+  error_at (mloc, "user defined suffix not expected here");
+  return;
+}
+
   if (instantiation_dependent_expression_p (condition))
 {
   /* We're in a template; build a STATIC_ASSERT and put it in


Should fix this I think 

[Bug target/105305] ARM32: gcc does not pass all library directories to linker

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

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

--- Comment #2 from Andrew Pinski  ---
>The code to explicitly exclude "obvious" directories is here

That code has been there since before 1993. So I wonder if all other ld's
always included /usr and /usr/lib by default. It is only the newer ones which
don't.

Does POSIX say anything about ld behavior?

[Bug target/106602] riscv: suboptimal codegen for zero_extendsidi2_shifted w/o bitmanip

[vineetg at rivosinc dot com via Gcc-bugs]

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

--- Comment #21 from Vineet Gupta  ---

I've been experimenting with 

(define_predicate "consecutive_bits_operand"
  (match_code "const_int")
{
unsigned HOST_WIDE_INT val = UINTVAL (op);
if (exact_log2 ((val >> ctz_hwi (val)) + 1) < 0)
return false;

return true;
})

(define_split
  [(set (match_operand:DI 0 "register_operand")
(and:DI (match_operand:DI 1 "register_operand")
(match_operand:DI 2 "consecutive_bits_operand")))
   (clobber (match_operand:DI 3 "register_operand"))]
  "TARGET_64BIT"
 [(set (match_dup 3)
   (lshiftrt:DI (match_dup 1) (match_dup 4)))
  (set (match_dup 3)
   (ashift:DI (match_dup 3) (match_dup 5)))
  (set (match_dup 0)
   (lshiftrt:DI (match_dup 3) (match_dup 6)))]
{
  unsigned HOST_WIDE_INT mask = UINTVAL (operands[2]);
  int r = ctz_hwi (mask);
  int l = clz_hwi (mask);
  operands[4] = GEN_INT (r);
  operands[5] = GEN_INT (r+l);
  operands[6] = GEN_INT (l);
})

However 
 try_combine
recog_for_combine
  recog_for_combine_1
 recog( )

is failing and we get "Failed to recognize..."

(gdb) call debug_rtx(x1)
(set (reg:DI 75)
(and:DI (reg:DI 76)
(const_int 274877906880 [0x3fffc0])))

I can't step through recog() cpp code since gen* insert #line for md file and
gdb steps through unrelated md code. FWIW cc1 is being built with -g3 -O0

[Bug target/105305] ARM32: gcc does not pass all library directories to linker

[rui314 at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Rui Ueyama  ---
By other ld's, what linkers did you have in your mind? If lld, mold and gold
don't hard code /usr and /usr/lib, then the only remaining linker is GNU ld.

It doesn't seem like POSIX says about the default library search paths. I don't
believe POSIX even mandates the existence of /usr and /usr/lib. macOS doesn't
have such directories, but IIUC macOS at least one point in the past certified
as POSIX compliant.

[Bug testsuite/106806] [13 regression] gcc.dg/tree-ssa/gen-vect-34.c fails after r13-2333-gca8f4e8af14869

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

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Kewen Lin :

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

commit r13-3621-g20d5dca80b82df9b1295359edb44eb08c45c4334
Author: Kewen Lin 
Date:   Thu Nov 3 01:22:45 2022 -0500

testsuite: Fix gen-vect-34.c with vect_masked_load [PR106806]

This is to fix the failure on powerpc as reported in PR106806,
the test case requires tree ifcvt pass to perform on that loop,
and it relies on masked_load support.  The fix is to guard the
expected scan with vect_masked_load effective target.

As tested on powerpc64{,le}-linux-gnu and aarch64-linux-gnu
(cfarm machine), the failures were gone.  But on
x86_64-redhat-linux (cfarm machine) the result becomes from
PASS to N/A.  I think it's expected since that machine doesn't
support AVX by default so both check_avx_available and
vect_masked_load fail, it should work fine on machines with
default AVX support, or if we adjust the current
check_avx_available with current_compiler_flags.

PR testsuite/106806

gcc/testsuite/ChangeLog:

* gcc.dg/tree-ssa/gen-vect-34.c: Adjust with vect_masked_load
effective target.

[Bug testsuite/106806] [13 regression] gcc.dg/tree-ssa/gen-vect-34.c fails after r13-2333-gca8f4e8af14869

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

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

Kewen Lin  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED
   Assignee|unassigned at gcc dot gnu.org  |linkw at gcc dot gnu.org
 CC||linkw at gcc dot gnu.org
 Target|powerpc64le-linux-gnu   |powerpc64le-linux-gnu
   |powerpc64-linux-gnuhppa-lin |powerpc64-linux-gnu
   |ux-gnu  |hppa-linux-gnu

--- Comment #4 from Kewen Lin  ---
Should be fixed on trunk.