[Bug tree-optimization/97964] New: Missed optimization opportunity for VRP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97964
Bug ID: 97964
Summary: Missed optimization opportunity for VRP
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: ishiura-compiler at ml dot kwansei.ac.jp
Target Milestone: ---
We compiled two programs (A1.c, A2.c) by gcc-10.2.0 with -O3 option.
The two programs are equivalent, but resulted in different assembly codes.
Although varialbe a is volatile, the value of variable t can be
determined at compile time via VRP optimization.
Note that gcc-7.5.0 or older versions compiled the both code into the
same minimum assebmly codes. For more precise:
gcc-10.2.0 diff
gcc-9.3.0 diff
gcc-8.0.1 diff
gcc-7.5.0 OK
gcc-6.5.0 OK
gcc-5.5.0 OK
+-+-+
|A1.c | A2.c |
+-+-+
|int main (void) |int main (void) |
|{|{|
| volatile int a = -1; | volatile int a = 1;|
| long b = -2; | |
| | |
| int c = a>0; | |
| int d = b*c; | |
| int e = 1-d; | a; |
| int t = (-1/(int)e)==1;| int t = 0; |
| | |
| if (t != 0) __builtin_abort(); | if (t != 0) __builtin_abort(); |
| | |
| return 0; | return 0; |
|}|}|
+-+-+
gcc-10.2.0
+---+--+
| A1.s (gcc-10.2.0 A1.c -O3 -S) | A2.s (gcc-10.2.0 A2.c -O3 -S)|
+---+--+
|main: |main: |
|.LFB0: |.LFB0:|
| .cfi_startproc | .cfi_startproc |
| subq$24, %rsp | movl$1, -4(%rsp) |
| .cfi_def_cfa_offset 32 | movl-4(%rsp), %eax |
| movl$1, 12(%ecx)| |
| movl$-1, 12(%rsp) | |
| movl12(%rsp), %eax | |
| testl %eax, %eax | |
| setle %al | |
| movzbl %al, %eax | |
| leal-2(%rax,%rax), %eax | |
| subl%eax, %ecx | |
| movl$-1, %eax | |
| cltd| |
| idiv%ecx| |
| cmpl$1, %eax| |
| je .L3 | |
| xorl%eax, %eax | xorl%eax, %eax |
| addq$24, %rsp | |
| .cfi_def_cfa_offset 8 | |
| ret | ret|
| .cfi_endproc| .cfi_endproc |
| .section .text.unlikely | |
| .cfi_startproc | |
| .type main.cold, @function| |
|main.cold: | |
|.LFSB0:| |
|.L3: | |
|.cfi_def_cfa_offset 32 | |
|callabort | |
|.cfi_endproc | |
|.LFE0: |.LFE0:|
|.section text.startup | |
|.size main, .-main | .size main, .-main |
|.section .text.unlikely | |
|.size main.cold, .-mai...| |
|.LCOLDE0: | |
|.section .text.startup| |
|.LHOTE0: |
[Bug c/97953] ICE (segfault) during GIMPLE pass: loopdone compiling libgcc/config/libbid/bid128_fma.c:190:1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97953 --- Comment #5 from Martin Liška --- (In reply to Chris Clayton from comment #4) > I've done a few more builds of snapshot releases of gcc-11. Using with > gcc-10-20201122, I get the ICE building 11-2020115, but 11-20201108 and > 20201101 both build successfully. Can you please mention the exact git revisions as using only a datestamp still leads to a bunch of commits?
[Bug target/96791] ICE in convert_mode_scalar, at expr.c:412
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96791
--- Comment #13 from Arseny Solokha ---
The testcase in comment 6 still ICEs when compiled w/ -m32:
% powerpc-e300c3-linux-gnu-gcc-11.0.0 -m32 -c wqugxu8a.c
wqugxu8a.c: In function 'test0':
wqugxu8a.c:8:1: error: insn does not satisfy its constraints:
8 | }
| ^
(insn 44 43 45 (set (mem/c:OO (reg/f:SI 9 9 [123]) [2 acc+0 S32 A512])
(reg:OO 32 0)) "wqugxu8a.c":6:3 2211 {*movoo}
(nil))
during RTL pass: shorten
wqugxu8a.c:8:1: internal compiler error: in extract_constrain_insn_cached, at
recog.c:2228
[Bug target/96791] ICE in convert_mode_scalar, at expr.c:412
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96791 --- Comment #12 from Arseny Solokha --- *** Bug 97963 has been marked as a duplicate of this bug. ***
[Bug target/97963] [11 Regression] ICE: in extract_constrain_insn_cached, at recog.c:2228 (error: insn does not satisfy its constraints)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97963 Arseny Solokha changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from Arseny Solokha --- Actually, it's PR96791 comment 6. *** This bug has been marked as a duplicate of bug 96791 ***
[Bug target/97963] New: [11 Regression] ICE: in extract_constrain_insn_cached, at recog.c:2228 (error: insn does not satisfy its constraints)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97963
Bug ID: 97963
Summary: [11 Regression] ICE: in extract_constrain_insn_cached,
at recog.c:2228 (error: insn does not satisfy its
constraints)
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
Target: powerpc-*-linux-gnu
gcc-11.0.0-alpha20201122 snapshot (g:e23f47ec4065e9eec53c4ad9db91bc36a4f90793)
ICEs when compiling the following testcase, extracted from
gcc/testsuite/gcc.target/powerpc/pr96125.c, w/ -m32:
void
__attribute__((target("cpu=power10")))
test0 (__vector_quad *dst)
{
__vector_quad acc;
__builtin_mma_xxsetaccz ();
*dst = acc;
}
% powerpc-e300c3-linux-gnu-gcc-11.0.0 -m32 -c wqugxu8a.c
wqugxu8a.c: In function 'test0':
wqugxu8a.c:8:1: error: insn does not satisfy its constraints:
8 | }
| ^
(insn 44 43 45 (set (mem/c:OO (reg/f:SI 9 9 [123]) [2 acc+0 S32 A512])
(reg:OO 32 0)) "wqugxu8a.c":6:3 2211 {*movoo}
(nil))
during RTL pass: shorten
wqugxu8a.c:8:1: internal compiler error: in extract_constrain_insn_cached, at
recog.c:2228
0x67ed88 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20201122/work/gcc-11-20201122/gcc/rtl-error.c:108
0x67edb4 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20201122/work/gcc-11-20201122/gcc/rtl-error.c:118
0x67d522 extract_constrain_insn_cached(rtx_insn*)
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20201122/work/gcc-11-20201122/gcc/recog.c:2228
0x14afb98 insn_default_length(rtx_insn*)
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20201122/work/gcc-11-20201122/gcc/config/rs6000/rs6000.md:8226
0xa7d031 shorten_branches(rtx_insn*)
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20201122/work/gcc-11-20201122/gcc/final.c:1119
0xa7d073 rest_of_handle_shorten_branches
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20201122/work/gcc-11-20201122/gcc/final.c:4771
0xa7d073 execute
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20201122/work/gcc-11-20201122/gcc/final.c:4800
[Bug tree-optimization/97849] [10/11 Regression] aarch64: ICE (segfault) during GIMPLE pass: ifcvt since r10-3543-gf30b3d28
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97849 --- Comment #3 from prathamesh3492 at gcc dot gnu.org --- Fixed on trunk.
[Bug tree-optimization/97849] [10/11 Regression] aarch64: ICE (segfault) during GIMPLE pass: ifcvt since r10-3543-gf30b3d28
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97849 --- Comment #2 from CVS Commits --- The master branch has been updated by Prathamesh Kulkarni : https://gcc.gnu.org/g:5700973f4a30762b4fc21687bb5f7843e55da2e4 commit r11-5268-g5700973f4a30762b4fc21687bb5f7843e55da2e4 Author: Prathamesh Kulkarni Date: Tue Nov 24 06:50:53 2020 +0530 tree-opt: Fix segfault in tree-if-conv.c with -march=armv8.2-a+sve [PR97849] The issue here is that rpo vn may eliminate target ssa_name referred to in redundant_ssa_names, and thus ifcvt_local_dce may replace candidate ssa_name with invalid ssa_name resulting in incorrect IR. The patch simply does ssa_name replacement before calling do_rpo_vn, which fixes the issue. gcc/ 2020-11-24 Prathamesh Kulkarni PR tree-optimization/97849 * tree-if-conv.c (tree_if_conversion): Move ssa_name replacement code from ifcvt_local_dce to this function before calling do_rpo_vn. gcc/testsuite/ 2020-11-24 Prathamesh Kulkarni PR tree-optimization/97849 * gcc.dg/tree-ssa/pr97849.c: New test.
[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639 Bug 24639 depends on bug 97840, which changed state. Bug 97840 Summary: [11 regression] Bogus -Wmaybe-uninitialized https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97840 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug middle-end/97840] [11 regression] Bogus -Wmaybe-uninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97840 Martin Sebor changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #17 from Martin Sebor --- With r11-5073 I think this can now be considered fixed (right?) Resolving as such.
[Bug c/97548] bogus -Wvla-parameter on a bound expression involving a parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97548 Martin Sebor changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Last reconfirmed||2020-11-24
[Bug middle-end/97931] missing -Wuninitialized initializing an aggregate member with itself
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97931 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #2 from Eric Gallager --- Shouldn't this go under -Winit-self?
[Bug jit/97867] FAIL: test-combination.c.exe test-functions.c.exe test-pr66779.c.exe test-threads.c.exe killed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97867 --- Comment #2 from Martin Sebor --- The backtrace from test-combination.c.exe shows the SEGV does happen in thunk_info::release (). Ditto for test-functions.c.exe. Program received signal SIGSEGV, Segmentation fault. 0x75d74153 in free () from /lib64/libc.so.6 Missing separate debuginfos, use: dnf debuginfo-install gmp-6.1.2-9.fc29.x86_64 libmpc-1.1.0-2.fc29.x86_64 mpfr-3.1.6-2.fc29.x86_64 (gdb) bt #0 0x75d74153 in free () from /lib64/libc.so.6 #1 0x7654bd62 in thunk_info::release () at /ssd/test/src/gcc/dump-type-attr/gcc/cgraph.c:4024 #2 cgraph_c_finalize () at /ssd/test/src/gcc/dump-type-attr/gcc/cgraph.c:4017 #3 0x769b2229 in toplev::finalize (this=this@entry=0x7fffdd4e) at /ssd/test/src/gcc/dump-type-attr/gcc/toplev.c:2508 #4 0x764a31b0 in gcc::jit::playback::context::compile (this=this@entry=0x7fffdde0) at /ssd/test/src/gcc/dump-type-attr/gcc/jit/jit-playback.c:2124 #5 0x76498bc6 in gcc::jit::recording::context::compile (this=this@entry=0x47b3f0) at /ssd/test/src/gcc/dump-type-attr/gcc/jit/jit-recording.c:1397 #6 0x7648a3bb in gcc_jit_context_compile (ctxt=0x47b3f0) at /ssd/test/src/gcc/dump-type-attr/gcc/jit/libgccjit.c:2827 #7 0x0041be40 in test_jit ( argv0=0x7fffe2fe "/ssd/test/build/gcc-gcc-dump-type-attr/gcc/testsuite/jit/test-combination.c.exe", user_data=0x0) at /ssd/test/src/gcc/dump-type-attr/gcc/testsuite/jit.dg/harness.h:371 #8 0x0041bf30 in main (argc=1, argv=0x7fffdfe8) at /ssd/test/src/gcc/dump-type-attr/gcc/testsuite/jit.dg/harness.h:419
[Bug c/95630] rejects-valid on comparison of pointers to complete vs incomplete types in C11 mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95630 Joseph S. Myers changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Target Milestone|--- |11.0 --- Comment #2 from Joseph S. Myers --- Fixed for GCC 11.
[Bug c/95630] rejects-valid on comparison of pointers to complete vs incomplete types in C11 mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95630 --- Comment #1 from CVS Commits --- The master branch has been updated by Joseph Myers : https://gcc.gnu.org/g:ed431431e069b59a1cfdd877134873248d8c93a6 commit r11-5265-ged431431e069b59a1cfdd877134873248d8c93a6 Author: Joseph Myers Date: Mon Nov 23 23:28:58 2020 + c: Allow comparison of pointers to complete and incomplete types for C11 [PR95630] As noted in bug 95630, C11 removed a restriction in C99 on comparing pointers to compatible complete and incomplete types (this was one of the changes in N1439, which was largely a terminological change to make incomplete types a subset of object types rather than a different kind of type). Implement that change by using pedwarn_c99 with OPT_Wpedantic for this diagnostic. Bootstrapped with no regressions for x86_64-pc-linux-gnu. gcc/c/ 2020-11-23 Joseph Myers PR c/95630 * c-typeck.c (build_binary_op): Use pedwarn_c99 with OPT_Wpedantic for comparisons of complete and incomplete pointers. gcc/testsuite/ 2020-11-23 Joseph Myers PR c/95630 * gcc.dg/c11-compare-incomplete-1.c, gcc.dg/c11-compare-incomplete-2.c, gcc.dg/c99-compare-incomplete-1.c, gcc.dg/c99-compare-incomplete-2.c: New tests.
[Bug c/97953] ICE (segfault) during GIMPLE pass: loopdone compiling libgcc/config/libbid/bid128_fma.c:190:1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97953 --- Comment #4 from Chris Clayton --- I've done a few more builds of snapshot releases of gcc-11. Using with gcc-10-20201122, I get the ICE building 11-2020115, but 11-20201108 and 20201101 both build successfully.
[Bug target/97205] arm: Compiler fails with an ICE for -O0 on Trunk and GCC-10 for _Generic feature.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97205 --- Comment #16 from Bernd Edlinger --- (In reply to SRINATH PARVATHANENI from comment #15) > (In reply to Bernd Edlinger from comment #14) > > fixed on trunk. > > Thanks Bernd for fixing this on trunk, would you mind backporting this to > GCC-10 as well? > > Thanks you. > > Regards, > Srinath. Since it is a gcc_checking_assert that triggers the ICE, I assumed that does not affect a release build, is that correct?
[Bug middle-end/97943] [11 Regression] ICE with __builtin_clear_padding on flexible array member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97943 --- Comment #6 from Jason Merrill --- I think we should reject trying to clear the padding of a flexible/zero-length array, with error rather than sorry. And handle an array at the end of a struct like any other array. Nobody should be using this builtin with the struct hack, it's impossible for it to do anything sensible.
[Bug c++/97951] Template specialization of function template fails for fixed-sized SVE vector types.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97951 David Tellenbach changed: What|Removed |Added Resolution|--- |WORKSFORME Status|WAITING |RESOLVED --- Comment #2 from David Tellenbach --- Thanks, I can confirm this is fixed in GCC 10.2 and works as expected.
[Bug fortran/85796] ICE: Floating point exception
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85796 anlauf at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #7 from anlauf at gcc dot gnu.org --- Patch submitted: https://gcc.gnu.org/pipermail/fortran/2020-November/055325.html Thus taking.
[Bug libstdc++/97949] Recursive calls of std::call_once together with cout leads to deadlock under mingw64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97949 --- Comment #2 from Jonathan Wakely --- Oh, and I think the cout calls just slow things down and introduce some serialization (in stdio) so that the threads run concurrently.
[Bug c++/97962] New: [10/11] ICE in build_over_call, at cp/call.c:8976
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97962
Bug ID: 97962
Summary: [10/11] ICE in build_over_call, at cp/call.c:8976
Product: gcc
Version: 10.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: doko at debian dot org
Target Milestone: ---
Created attachment 49616
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49616=edit
preprocessed source
seen with the gcc-10 branch and the trunk, compiler configured with
--enable-checking=yes,extra,rtl
works with gcc-9, configured with --enable-checking=release.
$ g++ -c -std=c++17 pool-prj-mgr-app_win_download.ii
pool-prj-mgr-app_win_download.ii: In instantiation of ‘struct
__result_of_memfun_deref’:
pool-prj-mgr-app_win_download.ii:13:60: required from ‘struct
conditional<__result_of_memfun_deref >’
pool-prj-mgr-app_win_download.ii:27:75: required from ‘struct
__result_of_memfun’
pool-prj-mgr-app_win_download.ii:32:8: required from ‘struct
__result_of_impl’
pool-prj-mgr-app_win_download.ii:44:8: recursively required by substitution
of ‘template struct __is_invocable_impl<_Result,
_Ret, __void_t > [with _Result = __invoke_result; _Ret =
void]’
pool-prj-mgr-app_win_download.ii:44:8: required from ‘struct
__is_invocable’
pool-prj-mgr-app_win_download.ii:62:41: required from
‘thread::thread(_Callable, _Args ...) [with _Callable = void
(PoolProjectManagerAppWindow::*)(Trans_NS___cxx11_basic_string); _Args =
{PoolProjectManagerAppWindow*, ustring, Trans_NS___cxx11_basic_string}]’
pool-prj-mgr-app_win_download.ii:68:57: required from here
pool-prj-mgr-app_win_download.ii:17:55: internal compiler error: in
build_over_call, at cp/call.c:8976
17 | static __result_of_success
_S_test;
| ^~~~
0x5de01a build_over_call
../../src/gcc/cp/call.c:8976
0xaa30fe build_new_method_call_1
../../src/gcc/cp/call.c:10385
0xaa429e build_new_method_call(tree_node*, tree_node*, vec**, tree_node*, int, tree_node**, int)
../../src/gcc/cp/call.c:10460
0xaa429e build_special_member_call(tree_node*, tree_node*, vec**, tree_node*, int, int)
../../src/gcc/cp/call.c:9861
0xa94458 build_temp
../../src/gcc/cp/call.c:7128
0xa94458 convert_like_real_1
../../src/gcc/cp/call.c:7705
0xa95b3d perform_implicit_conversion_flags(tree_node*, tree_node*, int, int)
../../src/gcc/cp/call.c:11921
0xca79f5 convert_arguments
../../src/gcc/cp/typeck.c:4197
0xca79f5 cp_build_function_call_vec(tree_node*, vec**, int, tree_node*)
../../src/gcc/cp/typeck.c:4031
0xb4c4d0 build_offset_ref_call_from_tree(tree_node*, vec**, int)
../../src/gcc/cp/decl2.c:5276
0xc28b46 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../src/gcc/cp/pt.c:20073
0xc2b204 tsubst(tree_node*, tree_node*, int, tree_node*)
../../src/gcc/cp/pt.c:15946
0xc2db88 tsubst_template_args(tree_node*, tree_node*, int, tree_node*)
../../src/gcc/cp/pt.c:13193
0xc3331b tsubst_aggr_type
../../src/gcc/cp/pt.c:13396
0xc22b01 tsubst_decl
../../src/gcc/cp/pt.c:14604
0xc33a29 instantiate_template_1
../../src/gcc/cp/pt.c:20871
0xc340ba instantiate_template(tree_node*, tree_node*, int)
../../src/gcc/cp/pt.c:20928
0xc340ba finish_template_variable(tree_node*, int)
../../src/gcc/cp/pt.c:10167
0xc3420a lookup_and_finish_template_variable(tree_node*, tree_node*, int)
../../src/gcc/cp/pt.c:10180
0xc28af8 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../src/gcc/cp/pt.c:19306
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
[Bug rtl-optimization/92294] alias attribute generates incorrect code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92294 rsandifo at gcc dot gnu.org changed: What|Removed |Added URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2020-Februar ||y/539763.html --- Comment #9 from rsandifo at gcc dot gnu.org --- Oops, I never linked the patch, it's: https://gcc.gnu.org/pipermail/gcc-patches/2020-February/539763.html (following on from an earlier discussion in January). Reading the thread back now, the reception wasn't as negative as I'd remembered. I'd been vaguely hoping to find time to try removing find_base_term & co. for GCC 11, but that obviously never happened. (Turns out that writing new code is more fun. ;-)) Maybe we could consider going for the linked patch for GCC 11.
[Bug libstdc++/97949] Recursive calls of std::call_once together with cout leads to deadlock under mingw64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97949 --- Comment #1 from Jonathan Wakely --- This isn't specific to mingw, it's a bug in the std::call_once implementation for non-TLS targets. t2 runs outerDoOnce() and tries to acquire a mutex lock before running innerDoOnce(), but that mutex is held by t3 while it waits to try to run outerDoOnce(). t3 won't proceed until t2 finishes, which is blocked by t3.
[Bug target/97950] Unoptimal code generation with __builtin_*_overflow{,_p} for short and __int128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97950 Jakub Jelinek changed: What|Removed |Added Attachment #49613|0 |1 is obsolete|| Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Last reconfirmed||2020-11-23 --- Comment #4 from Jakub Jelinek --- Created attachment 49615 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49615=edit gcc11-pr97950.patch Updated patch.
[Bug target/97950] Unoptimal code generation with __builtin_*_overflow{,_p} for short and __int128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97950 --- Comment #3 from Uroš Bizjak --- Comment on attachment 49613 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49613 gcc11-pr97950.patch >+(define_insn_and_split "*setcc_hi_1" >+ [(set (match_operand:HI 0 "register_operand" "=q") >+ (match_operator:HI 1 "ix86_comparison_operator" >+[(reg FLAGS_REG) (const_int 0)]))] >+ "!TARGET_PARTIAL_REG_STALL" >+ "#" >+ "&& reload_completed" >+ [(set (match_dup 2) (match_dup 1)) >+ (set (match_dup 0) (zero_extend:DI (match_dup 2)))] zero_extend:HI Perhaps you could apply SWI24 mode iterator to existing *setcc_si_1_and and *setcc_si_1_movzbl?
[Bug fortran/97927] gfortran: ICE in lookup_field_for_decl, at tree-nested.c:288
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97927 --- Comment #8 from Jakub Jelinek --- Can't reproduce with 20201005 10 branch or current trunk. The 10 branch changed tree-nested.c e.g. in r10-8663, but I don't really see any linear, lastprivate or reduction clauses in this.
[Bug c/97954] [11 Regression] ICE in maybe_record_trace_start, at dwarf2cfi.c:2360
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97954 Martin Liška changed: What|Removed |Added Target Milestone|--- |11.0 Known to fail||11.0 Last reconfirmed||2020-11-23 Ever confirmed|0 |1 Known to work||10.2.0 CC||marxin at gcc dot gnu.org, ||vmakarov at gcc dot gnu.org Status|UNCONFIRMED |NEW --- Comment #1 from Martin Liška --- Started with r11-5002-ge3b3b59683c1e7d3.
[Bug c++/97947] [11 Regression] ICE in digest_init_r, at cp/typeck2.c:1145
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97947 --- Comment #2 from Marek Polacek --- We crash here 1143 /* Come here only for aggregates: records, arrays, unions, complex numbers 1144 and vectors. */ 1145 gcc_assert (code == ARRAY_TYPE 1146 || VECTOR_TYPE_P (type) 1147 || code == RECORD_TYPE 1148 || code == UNION_TYPE 1149 || code == COMPLEX_TYPE); because code == OPAQUE_TYPE.
[Bug c/97955] [11 Regression] ICE in build_array_type_1, at tree.c:8264 since r11-3303-g6450f07388f9fe57
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97955 Martin Liška changed: What|Removed |Added Known to work||10.2.0 Last reconfirmed||2020-11-23 Summary|[11 Regression] ICE in |[11 Regression] ICE in |build_array_type_1, at |build_array_type_1, at |tree.c:8264 |tree.c:8264 since ||r11-3303-g6450f07388f9fe57 Target Milestone|--- |11.0 Ever confirmed|0 |1 CC||marxin at gcc dot gnu.org, ||msebor at gcc dot gnu.org Status|UNCONFIRMED |NEW Known to fail||11.0 --- Comment #1 from Martin Liška --- Started with r11-3303-g6450f07388f9fe57.
[Bug target/97950] Unoptimal code generation with __builtin_*_overflow{,_p} for short and __int128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97950 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement
[Bug tree-optimization/97956] [11 Regression] ICE in build2, at tree.c:4872 since r11-2709-g866626efd749ed3e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97956 Martin Liška changed: What|Removed |Added Known to work||10.2.0 Summary|[11 Regression] ICE in |[11 Regression] ICE in |build2, at tree.c:4872 |build2, at tree.c:4872 ||since ||r11-2709-g866626efd749ed3e Known to fail||11.0 Ever confirmed|0 |1 Priority|P3 |P1 Last reconfirmed||2020-11-23 CC||marxin at gcc dot gnu.org, ||msebor at gcc dot gnu.org Status|UNCONFIRMED |NEW Component|c |tree-optimization Target Milestone|--- |11.0 --- Comment #1 from Martin Liška --- Started with r11-2709-g866626efd749ed3e.
[Bug c++/97947] [11 Regression] ICE in digest_init_r, at cp/typeck2.c:1145
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97947 Marek Polacek changed: What|Removed |Added Last reconfirmed||2020-11-23 Status|UNCONFIRMED |NEW Target Milestone|--- |11.0 Ever confirmed|0 |1 CC||mpolacek at gcc dot gnu.org --- Comment #1 from Marek Polacek --- Confirmed with powerpc64le-unknown-linux-gnu cross.
[Bug c/97957] ICE in init_dynamic_diag_info, at c-family/c-format.c:5024
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97957 Martin Liška changed: What|Removed |Added Last reconfirmed||2020-11-23 CC||marxin at gcc dot gnu.org Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #2 from Martin Liška --- Confirmed, at least as old as GCC 4.8.0.
[Bug tree-optimization/97950] Unoptimal code generation with __builtin_*_overflow{,_p} for short and __int128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97950 --- Comment #2 from denis.campredon at gmail dot com --- Thanks for your fast patch. I've opened PR97961 for the __int128 problem
[Bug tree-optimization/97961] New: unnecessary moves with __builtin_{add,sub}_overflow_p and __int128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97961
Bug ID: 97961
Summary: unnecessary moves with __builtin_{add,sub}_overflow_p
and __int128
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: denis.campredon at gmail dot com
Target Milestone: ---
In #97950 Jackub told me to open a new bug for that.
The snippet bellow has the following problems
- f1 and f2 generate 4 unnecessary moves
mov r9, rdi
mov r8, rsi
mov rsi, r9
mov rdi, r8
- f4 has "only" 2 unnecessary moves
mov r9, rdi
mov rdi, rsi
- f3 should be identical to f4 except for the flag checking.
bool f1(unsigned __int128 a,unsigned __int128 b) {
return __builtin_add_overflow_p(a, b, (unsigned __int128)0);
}
bool f2(__int128 a,__int128 b) {
return __builtin_add_overflow_p(a, b, (__int128)0);
}
bool f3(unsigned __int128 a,unsigned __int128 b) {
return __builtin_sub_overflow_p(a, b, (unsigned __int128)0);
}
bool f4(__int128 a,__int128 b) {
return __builtin_sub_overflow_p(a, b, (__int128)0);
}
asm generated
f1(unsigned __int128, unsigned __int128):
mov r9, rdi
mov r8, rsi
mov rsi, r9
mov rdi, r8
add rsi, rdx
adc rdi, rcx
setcal
ret
f2(__int128, __int128):
mov r9, rdi
mov r8, rsi
mov rsi, r9
mov rdi, r8
add rsi, rdx
adc rdi, rcx
setoal
ret
f3(unsigned __int128, unsigned __int128):
mov r9, rdi
mov r8, rsi
mov rdi, r8
mov rax, r9
mov r8, rdx
sub rax, r8
mov rdx, rdi
sbb rdx, rcx
cmp r9, rax
mov rcx, rdi
sbb rcx, rdx
setcal
ret
f4(__int128, __int128):
mov r9, rdi
mov rdi, rsi
cmp r9, rdx
sbb rdi, rcx
setoal
ret
---
[Bug tree-optimization/97960] [8/9/10/11 Regression] Wrong code at -O3 since r8-6511-g3ae129323d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97960 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW CC||marxin at gcc dot gnu.org, ||rsandifo at gcc dot gnu.org Last reconfirmed||2020-11-23 Priority|P3 |P1 Ever confirmed|0 |1 Target Milestone|--- |8.5 Keywords||wrong-code --- Comment #2 from Martin Liška --- Confirmed!
[Bug tree-optimization/97960] [8/9/10/11 Regression] Wrong code at -O3 since r8-6511-g3ae129323d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97960
--- Comment #1 from Alex Coplan ---
C testcase:
const int *c(const int *p, const int *q)
{
if (*p < *q)
return q;
return p;
}
short a[575];
unsigned b[25];
unsigned char g;
int main()
{
for (int e = 0; e < 23; ++e)
a[e * 23] = 16137;
int t1 = g;
int t2 = 253;
signed char h = *c(, ) + 3;
for (; h < 24; h++)
b[h] = 1064739102;
for (int e = 0; e < 23; ++e)
if (a[e * 23] != 16137)
__builtin_abort();
}
[Bug c/97958] ICE in build2, at tree.c:4868
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97958 Jakub Jelinek changed: What|Removed |Added Last reconfirmed||2020-11-23 Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Created attachment 49614 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49614=edit gcc11-pr97958.patch Untested fix.
[Bug tree-optimization/97960] New: [8/9/10/11 Regression] Wrong code at -O3 since r8-6511-g3ae129323d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97960
Bug ID: 97960
Summary: [8/9/10/11 Regression] Wrong code at -O3 since
r8-6511-g3ae129323d
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: acoplan at gcc dot gnu.org
Target Milestone: ---
GCC miscompiles the following C++ testcase at -O3 (reproduced on both x86 and
aarch64):
const int (const int , const int ) {
if (d < f)
return f;
return d;
}
short a[575];
unsigned b[25];
unsigned char g;
int main()
{
for (int e = 0; e < 23; ++e)
a[e * 23] = 16137;
for (signed char h = c(g, 253) + 3; h < 24; h++)
b[h] = 1064739102;
for (int e = 0; e < 23; ++e)
if (a[e * 23] != 16137)
__builtin_abort();
}
When compiled with -O{0,g,s,1,2} (with or without -ftree-vectorize), the
program exits cleanly, but aborts when compiled with -O3 since the above
revision. The program also exits cleanly when compiled with clang on x86 and
aarch64 at various optimization levels.
[Bug lto/97959] New: Random FAIL: gcc.dg/lto/save-temps c_lto_save-temps_0.o-c_lto_save-temps_0.o link, -O -flto -save-temps
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97959
Bug ID: 97959
Summary: Random FAIL: gcc.dg/lto/save-temps
c_lto_save-temps_0.o-c_lto_save-temps_0.o link, -O
-flto -save-temps
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: hjl.tools at gmail dot com
CC: marxin at gcc dot gnu.org
Target Milestone: ---
On Linux/x86-64 with 96 cores, I got random:
Executing on host:
/export/gnu/import/git/gcc-test-master-intel64-native/bld/gcc/xgcc
-B/export/gnu/import/git/gcc-test-master-intel64-native/bld/gcc/
c_lto_save-temps_0.o -mx32 -fdiagnostics-plain-output -O -flto -save-temps
-o gcc-dg-lto-save-temps-01.exe(timeout = 300)
spawn -ignore SIGHUP
/export/gnu/import/git/gcc-test-master-intel64-native/bld/gcc/xgcc
-B/export/gnu/import/git/gcc-test-master-intel64-native/bld/gcc/
c_lto_save-temps_0.o -mx32 -fdiagnostics-plain-output -O -flto -save-temps -o
gcc-dg-lto-save-temps-01.exe
/usr/local/bin/ld: i386 architecture of input file
`./gcc-dg-lto-save-temps-01.ltrans0.ltrans.o' is incompatible with i386:x64-32
output
/usr/local/bin/ld: final link failed: file in wrong format
collect2: error: ld returned 1 exit status
compiler exited with status 1
FAIL: gcc.dg/lto/save-temps c_lto_save-temps_0.o-c_lto_save-temps_0.o link, -O
-flto -save-temps
with
$ make -j 56 check RUNTESTFLAGS="--target_board='unix{-m32,-mx32,}'"
The problem is that -m32, -mx32 and -m64 use the same filename,
gcc-dg-lto-save-temps-01.ltrans0.ltrans.o.
[Bug tree-optimization/96272] Failure to optimize overflow check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96272 --- Comment #5 from Jakub Jelinek --- It shouldn't be added to match.pd, the check as written in the source is certainly better for other optimization passes. For PR95853 I've added recently a widening_mul (i.e. very late pass, almost before expansion) pattern matching of another form (very lame in the source code) of the overflow check but in that case I've put a constraint that the overflow check and addition must be in the same bb (and not too far from each other). In this case it isn't in the same bb and again would be very undesirable if it is really too far (would increase register pressure).
[Bug c/97958] New: ICE in build2, at tree.c:4868
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97958
Bug ID: 97958
Summary: ICE in build2, at tree.c:4868
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
Affects versions down to at least r5 :
$ cat z1.c
int f ()
{
#pragma omp atomic
f = f + 1;
}
$ gcc-11-20201122 -c z1.c -fopenmp
z1.c: In function 'f':
z1.c:4:3: internal compiler error: in build2, at tree.c:4868
4 | f = f + 1;
| ^
0xdaaf2d build2(tree_code, tree_node*, tree_node*, tree_node*)
../../gcc/tree.c:4867
0x674105 c_parser_binary_expression
../../gcc/c/c-parser.c:8010
0x674b15 c_parser_conditional_expression
../../gcc/c/c-parser.c:7607
0x675071 c_parser_expr_no_commas
../../gcc/c/c-parser.c:7522
0x67ffd0 c_parser_omp_atomic
../../gcc/c/c-parser.c:17677
0x69045c c_parser_omp_construct
../../gcc/c/c-parser.c:21546
0x66dd07 c_parser_pragma
../../gcc/c/c-parser.c:12517
0x688206 c_parser_compound_statement_nostart
../../gcc/c/c-parser.c:5764
0x6885d3 c_parser_compound_statement
../../gcc/c/c-parser.c:5606
0x689e61 c_parser_declaration_or_fndef
../../gcc/c/c-parser.c:2543
0x690a47 c_parser_external_declaration
../../gcc/c/c-parser.c:1777
0x691569 c_parser_translation_unit
../../gcc/c/c-parser.c:1650
0x691569 c_parse_file()
../../gcc/c/c-parser.c:21882
0x6e0772 c_common_parse_file()
../../gcc/c-family/c-opts.c:1198
[Bug libstdc++/67791] [8/9/10/11 Regression] Crash using std::thread and iostream with dynamic loading of a shared library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67791 Jonathan Wakely changed: What|Removed |Added Summary|Crash using std::thread and |[8/9/10/11 Regression] |iostream with dynamic |Crash using std::thread and |loading of a shared library |iostream with dynamic ||loading of a shared library Known to work||4.9.4 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Status|NEW |ASSIGNED Known to fail||10.2.0, 11.0, 5.1.0, 8.4.0, ||9.3.0 Target Milestone|--- |8.5 --- Comment #8 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #7) > (In reply to nexyon from comment #4) > > In any case std::thread should not > > crash I guess, so just to fix that it would be necessary to check whether > > the standard library was inizialized without threads. > > We used to check for the pthread_create weak symbol, and throw an exception > instead of crashing. Since the fix for PR libstdc++/61841 we don't check it, > and crash instead of throwing. That should be fixed. Marking as a regression, because GCC 4.9 printed this error instead of crashing: terminate called after throwing an instance of 'std::system_error' what(): Enable multithreading to use std::thread: Operation not permitted Aborted (core dumped) That's better than segfaulting with no explanation. I incorrectly assumed that the use of _create added for PR 61841 would make checking __gthread_active_p unnecessary. As the examples here show, that's not true. The program calls __gthread_active_p() before main() runs, and at that time libpthread.so is not loaded. When libpthread.so is loaded later, it's too late for __gthread_active_p to notice.
[Bug c/97957] ICE in init_dynamic_diag_info, at c-family/c-format.c:5024
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97957
--- Comment #1 from G. Steinmetz ---
Another similar situation :
$ cat z2.c
typedef long __gcc_host_wide_int__;
typedef long __gcc_host_wide_int__;
__attribute__ ((__format__ (__asm_fprintf__, 1, 2)))
void f () {}
$ gcc-11-20201122 -c z2.c
z2.c:4:1: internal compiler error: in init_dynamic_asm_fprintf_info, at
c-family/c-format.c:4829
4 | void f () {}
| ^~~~
0x6d1b33 init_dynamic_asm_fprintf_info
../../gcc/c-family/c-format.c:4829
0x6d1b33 handle_format_attribute(tree_node**, tree_node*, tree_node*, int,
bool*)
../../gcc/c-family/c-format.c:5240
0x62a101 decl_attributes(tree_node**, tree_node*, int, tree_node*)
../../gcc/attribs.c:724
0x641eef start_function(c_declspecs*, c_declarator*, tree_node*)
../../gcc/c/c-decl.c:9410
0x689236 c_parser_declaration_or_fndef
../../gcc/c/c-parser.c:2444
0x690a47 c_parser_external_declaration
../../gcc/c/c-parser.c:1777
0x691569 c_parser_translation_unit
../../gcc/c/c-parser.c:1650
0x691569 c_parse_file()
../../gcc/c/c-parser.c:21882
0x6e0772 c_common_parse_file()
../../gcc/c-family/c-opts.c:1198
[Bug c/97957] New: ICE in init_dynamic_diag_info, at c-family/c-format.c:5024
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97957
Bug ID: 97957
Summary: ICE in init_dynamic_diag_info, at
c-family/c-format.c:5024
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
A doubled line affects versions down to at least r5 :
$ cat z1.c
typedef long __gcc_host_wide_int__;
typedef long __gcc_host_wide_int__;
__attribute__ ((__format__ (__gcc_diag__, 1, 2)))
void f () {}
$ gcc-11-20201122 -c z1.c
z1.c:4:1: internal compiler error: in init_dynamic_diag_info, at
c-family/c-format.c:5024
4 | void f () {}
| ^~~~
0x6d1b97 init_dynamic_diag_info
../../gcc/c-family/c-format.c:5024
0x6d1b97 handle_format_attribute(tree_node**, tree_node*, tree_node*, int,
bool*)
../../gcc/c-family/c-format.c:5252
0x62a101 decl_attributes(tree_node**, tree_node*, int, tree_node*)
../../gcc/attribs.c:724
0x641eef start_function(c_declspecs*, c_declarator*, tree_node*)
../../gcc/c/c-decl.c:9410
0x689236 c_parser_declaration_or_fndef
../../gcc/c/c-parser.c:2444
0x690a47 c_parser_external_declaration
../../gcc/c/c-parser.c:1777
0x691569 c_parser_translation_unit
../../gcc/c/c-parser.c:1650
0x691569 c_parse_file()
../../gcc/c/c-parser.c:21882
0x6e0772 c_common_parse_file()
../../gcc/c-family/c-opts.c:1198
[Bug c/97956] New: [11 Regression] ICE in build2, at tree.c:4872
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97956
Bug ID: 97956
Summary: [11 Regression] ICE in build2, at tree.c:4872
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
Changed between 20200823 and 20201004, derived from memchr.c :
$ cat z1.c
typedef __INT8_TYPE__ int8_t;
typedef __INT32_TYPE__ int32_t;
extern void* memchr (const void*, int, long);
struct SX
{
int32_t n;
int8_t a[];
};
const struct SX sx = { 0x1221 };
const char sx_rep[] = { };
void test_find (void)
{
int n = 0, nb = (const char*) - (const char*)
const char *p = (const char*), *q = sx_rep;
n += p + 1 == memchr (p, q[1], nb);
}
$ gcc-11-20201122 -c z1.c
$
$ gcc-11-20201122 -c z1.c -O2
during GIMPLE pass: forwprop
z1.c: In function 'test_find':
z1.c:16:1: internal compiler error: in build2, at tree.c:4872
16 | }
| ^
0xdaae9e build2(tree_code, tree_node*, tree_node*, tree_node*)
../../gcc/tree.c:4871
0x880b9f build2_loc
../../gcc/tree.h:4371
0x880b9f fold_build2_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*)
../../gcc/fold-const.c:13318
0xc3ad53 forward_propagate_into_comparison_1
../../gcc/tree-ssa-forwprop.c:434
0xc41900 forward_propagate_into_comparison
../../gcc/tree-ssa-forwprop.c:491
0xc41900 execute
../../gcc/tree-ssa-forwprop.c:3145
[Bug tree-optimization/97950] Unoptimal code generation with __builtin_*_overflow{,_p} for short and __int128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97950 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- Created attachment 49613 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49613=edit gcc11-pr97950.patch Untested fix for the short cases. As for __int128, I think it would be better if you filed a separate issue, because it has nothing to do with the short one, and mentioned which moves you find redundant. Generally, some redundant moves will be there with double-word arithmetics, it is a matter of when exactly it is the right time to lower double-word operations (and which) into word ones, doing it too early prevents e.g. STV from doing its job and e.g. doing for __int128 some operations in SSE registers, while doing it too late may result in the already assigning pairs of GP registers for the 128-bit pseudos and while some useless moves can be recovered afterwards, certainly not all of them. x86 doesn't really have instructions that would allow implementing the 128-bit multiplications with overflow efficiently.
[Bug c/97955] New: [11 Regression] ICE in build_array_type_1, at tree.c:8264
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97955
Bug ID: 97955
Summary: [11 Regression] ICE in build_array_type_1, at
tree.c:8264
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
Changed between 20200823 and 20201004 :
$ cat z1.c
void f (int n, int a[n]);
void f (int *b) {}
$ gcc-11-20201122 -c z1.c
z1.c:2:1: internal compiler error: Segmentation fault
2 | void f (int *b) {}
| ^~~~
0xb42eff crash_signal
../../gcc/toplev.c:330
0xdbbf5d build_array_type_1
../../gcc/tree.c:8264
0x62930b attr_access::array_as_string[abi:cxx11](tree_node*) const
../../gcc/attribs.c:2299
0x6ff9cd warn_parm_array_mismatch(unsigned int, tree_node*, tree_node*)
../../gcc/c-family/c-warn.c:3435
0x6421a4 start_function(c_declspecs*, c_declarator*, tree_node*)
../../gcc/c/c-decl.c:9591
0x689236 c_parser_declaration_or_fndef
../../gcc/c/c-parser.c:2444
0x690a47 c_parser_external_declaration
../../gcc/c/c-parser.c:1777
0x691569 c_parser_translation_unit
../../gcc/c/c-parser.c:1650
0x691569 c_parse_file()
../../gcc/c/c-parser.c:21882
0x6e0772 c_common_parse_file()
../../gcc/c-family/c-opts.c:1198
[Bug c/97954] New: [11 Regression] ICE in maybe_record_trace_start, at dwarf2cfi.c:2360
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97954
Bug ID: 97954
Summary: [11 Regression] ICE in maybe_record_trace_start, at
dwarf2cfi.c:2360
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
Changed between 20201108 and 20201115 :
$ cat z1.c
int
foo (void)
{
int x;
lab:
asm goto ("": "=a" (x) : : : lab);
return x;
}
$ gcc-11-20201122 -c z1.c -O2
during RTL pass: dwarf2
z1.c: In function 'foo':
z1.c:8:1: internal compiler error: in maybe_record_trace_start, at
dwarf2cfi.c:2360
8 | }
| ^
0x7c9c43 maybe_record_trace_start
../../gcc/dwarf2cfi.c:2360
0x7ca18a create_trace_edges
../../gcc/dwarf2cfi.c:2501
0x7cc163 scan_trace
../../gcc/dwarf2cfi.c:2732
0x7cca31 create_cfi_notes
../../gcc/dwarf2cfi.c:2758
0x7cca31 execute_dwarf2_frame
../../gcc/dwarf2cfi.c:3122
0x7cca31 execute
../../gcc/dwarf2cfi.c:3610
---
z1.c: In function 'foo':
z1.c:8:1: error: too many outgoing branch edges from bb 4
8 | }
| ^
during RTL pass: loop2_invariant
z1.c:8:1: internal compiler error: verify_flow_info failed
0x814164 verify_flow_info()
../../gcc/cfghooks.c:269
0xb3c87b checking_verify_flow_info
../../gcc/cfghooks.h:212
0xb3c87b move_loop_invariants()
../../gcc/loop-invariant.c:2304
0xb384f0 execute
../../gcc/loop-init.c:530
[Bug c/97953] ICE (segfault) during GIMPLE pass: loopdone compiling libgcc/config/libbid/bid128_fma.c:190:1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97953 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org Last reconfirmed||2020-11-23 Status|UNCONFIRMED |WAITING Ever confirmed|0 |1 --- Comment #3 from Martin Liška --- Can't reproduce that with c2ac0d1a66e03279.
[Bug libstdc++/97948] C++2a synchronization tests fail to link on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97948 Jonathan Wakely changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #3 from Jonathan Wakely --- This *should* be fixed now. Please reopen if not.
[Bug libstdc++/97948] C++2a synchronization tests fail to link on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97948 --- Comment #2 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:fd62daea40e09c1e6d599a6171db6b298d6c362e commit r11-5255-gfd62daea40e09c1e6d599a6171db6b298d6c362e Author: Jonathan Wakely Date: Mon Nov 23 15:46:24 2020 + libstdc++: Link tests to libatomic as required [PR 97948] libstdc++-v3/ChangeLog: PR libstdc++/97948 * testsuite/29_atomics/atomic_float/wait_notify.cc: Add options for libatomic. * testsuite/29_atomics/atomic_integral/wait_notify.cc: Likewise. * testsuite/29_atomics/atomic_ref/wait_notify.cc: Likewise.
[Bug libstdc++/60662] simple use of call_once throws a system_error exception, but not if sleep_for is called beforehand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60662 --- Comment #6 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #5) > I'm not sure why this_thread::sleep_for (which just calls nanosleep) causes > libpthread.so to get linked in, but ldd shows that there is a libpthread.so > dependency with it. nanosleep used to be defined in both libc.so and libpthread.so, so if you link with -lpthread then the definition in libpthread.so will be found (because of the order of libraries gcc passes to the linker) and you get a dependency on libpthread.so Recent versions of glibc only define it in libc.so
[Bug libstdc++/97949] Recursive calls of std::call_once together with cout leads to deadlock under mingw64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97949 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-11-23 Ever confirmed|0 |1
[Bug libstdc++/97948] C++2a synchronization tests fail to link on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97948 Jonathan Wakely changed: What|Removed |Added Target Milestone|--- |11.0 Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Last reconfirmed||2020-11-23 Status|UNCONFIRMED |ASSIGNED
[Bug fortran/95038] Not treating function result name as a variable.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95038 --- Comment #5 from Bill Long --- Original submitter asking for a fixed-in version number.
[Bug libgcc/89714] allow for overriding the thread-detection mechanism
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89714 --- Comment #4 from Jonathan Wakely --- That wouldn't help when people link directly with -lpthread rather than -pthread. _REENTRANT is not required for pthreads, so I don't think we should depend on it.
[Bug target/97928] -fstack-clash-protection probe miss
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97928 Jeffrey A. Law changed: What|Removed |Added Last reconfirmed||2020-11-23 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW CC||law at redhat dot com --- Comment #2 from Jeffrey A. Law --- I took a peek when Serge pointed me at the issue. I think there's a window where a signal handler could clash. It'd be hard to exploit, but we should fix it. It's on my TODO list.
[Bug c++/97951] Template specialization of function template fails for fixed-sized SVE vector types.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97951 rsandifo at gcc dot gnu.org changed: What|Removed |Added CC||rsandifo at gcc dot gnu.org Status|UNCONFIRMED |WAITING Ever confirmed|0 |1 Last reconfirmed||2020-11-23 --- Comment #1 from rsandifo at gcc dot gnu.org --- Could you try GCC 10.2? I believe this was fixed by g:ecd56bc41563a84808fe4e1a2c7341bf8a621c92.
[Bug c/97953] ICE (segfault) during GIMPLE pass: loopdone compiling libgcc/config/libbid/bid128_fma.c:190:1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97953 --- Comment #2 from Chris Clayton --- Created attachment 49612 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49612=edit Full build log
[Bug c/97953] ICE (segfault) during GIMPLE pass: loopdone compiling libgcc/config/libbid/bid128_fma.c:190:1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97953 --- Comment #1 from Chris Clayton --- Created attachment 49611 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49611=edit Preprocessed source
[Bug bootstrap/97933] [11 Regression] Bootstrap failure on s390x-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97933 --- Comment #3 from Vladimir Makarov --- (In reply to Jakub Jelinek from comment #1) > Started with r11-5034-g253c415a1acba50711c82693426391743ac18040 Sorry for causing this error. It is clearly my mistake. I've started to work on this. The fix will be ready tomorrow.
[Bug c/97953] New: ICE (segfault) during GIMPLE pass: loopdone compiling libgcc/config/libbid/bid128_fma.c:190:1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97953
Bug ID: 97953
Summary: ICE (segfault) during GIMPLE pass: loopdone compiling
libgcc/config/libbid/bid128_fma.c:190:1
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: chris2553 at googlemail dot com
Target Milestone: ---
Building 11-20201122 (with gcc-10-20201121 or gcc-10-20201114) results in an
ICE as follows:
/home/chris/rpm/BUILD/gcc-obj-x86_64-pc-linux-gnu/./gcc/xgcc
-B/home/chris/rpm/BUILD/gcc-obj-x86_64-pc-linux-gnu/./gcc/
-B/usr/x86_64-pc-linux-gnu/bin/ -B/usr/x86_64-pc-linux-gnu/lib/ -isystem
/usr/x86_64-pc-linux-gnu/include -isystem /usr/x86_64-pc-linux-gnu/sys-include
-fno-checking -g -O2 -O2 -g -O2 -DIN_GCC-W -Wall -Wno-narrowing
-Wwrite-strings -Wcast-qual -Wno-error=format-diag -Wstrict-prototypes
-Wmissing-prototypes -Wno-error=format-diag -Wold-style-definition -isystem
./include -fpic -mlong-double-80 -DUSE_ELF_SYMVER -fcf-protection -mshstk -g
-DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -fpic -mlong-double-80
-DUSE_ELF_SYMVER -fcf-protection -mshstk -I. -I. -I../.././gcc
-I../../../gcc-11-20201122/libgcc -I../../../gcc-11-20201122/libgcc/.
-I../../../gcc-11-20201122/libgcc/../gcc
-I../../../gcc-11-20201122/libgcc/../include
-I../../../gcc-11-20201122/libgcc/config/libbid -DENABLE_DECIMAL_BID_FORMAT
-DHAVE_CC_TLS -DUSE_TLS -o bid128_fma.o -MT bid128_fma.o -MD -MP -MF
bid128_fma.dep -c ../../../gcc-11-20201122/libgcc/config/libbid/bid128_fma.c
during GIMPLE pass: loopdone
../../../gcc-11-20201122/libgcc/config/libbid/bid128_fma.c: In function
'nr_digits256':
../../../gcc-11-20201122/libgcc/config/libbid/bid128_fma.c:190:1: internal
compiler error: Segmentation fault
190 | nr_digits256 (UINT256 R256) {
| ^~~~
A log of the full build (using rpmbuild) and the preprocessed source are
attached.
[Bug target/97940] [11 Regression] ICE: in extract_insn, at recog.c:2306 (error: impossible constraint in 'asm'; error: unrecognizable insn)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97940
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P4
Keywords||error-recovery
CC||jakub at gcc dot gnu.org,
||vmakarov at gcc dot gnu.org
--- Comment #1 from Jakub Jelinek ---
The test has
/* { dg-do compile { target i?86-*-* x86_64-*-* } } */
so it isn't meant for other arches, uses x86 specific constraints.
So this is just an IRA error recovery ICE on random garbage code.
[Bug target/97928] -fstack-clash-protection probe miss
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97928 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org --- Comment #1 from Martin Liška --- @Jeff: Can you please take a look?
[Bug c++/97952] Poor optimization of closure-like construct in C++ as compared to C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97952
--- Comment #1 from eric-gcc at omnifarious dot org ---
Because you might not like Godbolt links, here is the C code:
//---cut here---
/*** core string search routine ***/
typedef char *String;
typedef unsigned longIndex, Count, Size, Length, Limit, Extent, Mask, Bits;
typedef struct {
const String string;
const Length length;
const Index *const table;
} SearchString_data;
typedef SearchString_data *SearchString, SearchString_object[1];
enum {
IAC = (char) 255,
WILL= (char) 251,
WONT= (char) 252,
DO = (char) 253,
DONT= (char) 254,
};
static Length command_length( String s, String sn );
static Length command_length_unknown( String s, String sn );
String
skip_past( String input, String sn, SearchString ss ){
const Index *walkback = ss->table;
const Index kn = ss->length;
const String w= ss->string;
typedef String Skip_f( String, Index );
auto Skip_f
skip_zero, skip_one_half, skip_one,
command_skip_zero, command_skip,skip;
return skip_zero( input, 0 );
String
skip_zero( String s, Index k ){
return k == kn ? s : skip_one_half( s, k );
}
String
skip_one_half( String s, Index k ){
return s == sn ? 0 : skip_one( s, k );
}
String
skip_one( String s, Index k ){
return 0[s] == IAC ? command_skip_zero( s+1, k ) : skip( s, k );
}
String
command_skip_zero( String s, Index k ){
return s == sn ? 0
: 0[s] != IAC ? command_skip( s, k )
: /** IAC IAC **/skip( s, k );
}
String
command_skip( String s, Index k ){
Count m = command_length( s, sn );
Count n = sn - s;
return m > n ? 0 : skip_one_half( s+m, k );
}
String
skip( String s, Index k ){
return 0[s] == w[k]? skip_zero( s+1, k+1 )
: k == 0 ? skip_one_half( s+1, 0 )
: /** !=, k > 0 **/ skip( s, walkback[k] );
}
}
Length
command_length( String s, String sn ){
return *s == IAC ? 1
: *s == WILL ? 2
: *s == WONT ? 2
: *s == DO? 2
: *s == DONT ? 2
: /*** otherwise ***/command_length_unknown( s, sn )
;
}
Length
command_length_unknown( String s, String sn ){
return 1; // TBD - is there something better here?
}
//---cut here---
and here is the C++ code:
//---cut here---
/*** core string search routine ***/
typedef char *String;
typedef unsigned longIndex, Count, Size, Length, Limit, Extent, Mask, Bits;
typedef struct {
const String string;
const Length length;
const Index *const table;
} SearchString_data;
typedef SearchString_data *SearchString, SearchString_object[1];
enum : char {
IAC = (char) 255,
WILL= (char) 251,
WONT= (char) 252,
DO = (char) 253,
DONT= (char) 254,
};
static Length command_length( String s, String sn );
static Length command_length_unknown( String s, String sn );
String
skip_past3( String input, String sn, SearchString ss ) {
class search_closure {
public:
search_closure( String input, String sn, SearchString ss )
: input(input), sn(sn), ss(ss),
walkback(ss->table), kn(ss->length), w(ss->string)
{}
String operator ()() const { return skip_zero( input, 0); }
private:
const String input;
const String sn;
const SearchString ss;
const Index *walkback;
const Index kn;
const String w;
String
skip_zero( String s, Index k ) const {
return k == kn ? s : skip_one_half( s, k );
}
String
skip_one_half( String s, Index k ) const {
return s == sn ? 0 : skip_one( s, k );
}
String
skip_one( String s, Index k ) const {
return 0[s] == IAC ? command_skip_zero( s+1, k ) : skip( s, k );
}
String
command_skip_zero( String s, Index k ) const {
return s == sn ? 0
: 0[s] != IAC ? command_skip( s, k )
: /** IAC IAC **/skip( s, k );
}
String
command_skip( String s, Index k ) const {
Count m = command_length( s, sn );
Count n = sn - s;
return m > n ? 0 : skip_one_half( s+m, k );
}
String
skip( String s, Index k ) const {
return 0[s] == w[k]? skip_zero( s+1, k+1 )
: k == 0 ? skip_one_half( s+1, 0 )
: /** !=, k > 0 **/ skip( s,
[Bug c++/97952] New: Poor optimization of closure-like construct in C++ as compared to C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97952 Bug ID: 97952 Summary: Poor optimization of closure-like construct in C++ as compared to C Product: gcc Version: 10.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: eric-gcc at omnifarious dot org Target Milestone: --- This code generates about 400+ lines of assembly: https://gcc.godbolt.org/z/s9s9Mx and this essentially equivalent C code generates only 100+ lines: https://gcc.godbolt.org/z/5abWEe This seems like poor optimization in C++. The C code makes use of nested functions, a GCC specific feature. And the C++ code uses a class to simulate a closure, thereby accomplishing essentially the same goal.
[Bug target/96607] GCC feeds SPARC/Solaris linker with unrecognized TLS sequences
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96607 --- Comment #8 from Eric Botcazou --- Sorry for dropping the ball, I'll get back to it momentarily.
[Bug target/96607] GCC feeds SPARC/Solaris linker with unrecognized TLS sequences
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96607
--- Comment #7 from Petr Sumbera ---
Just to confirm that '-fno-delayed-branch' as workaround seems to work (at
least based on provided test case).
Probably better is to modify the code like this:
--- gcc-10.2.0/gcc/config/sparc/sparc.c
+++ gcc-10.2.0/gcc/config/sparc/sparc.c
@@ -3963,6 +3963,8 @@
if ((TARGET_GNU_TLS && HAVE_GNU_LD) || !TARGET_TLS)
return 1;
+ return 0;
+
pat = PATTERN (trial);
/* We must reject tgd_add{32|64}, i.e.
---
Of course proper fix is needed. Any suggestion to the condition (in code)
below?
[Bug c++/97951] New: Template specialization of function template fails for fixed-sized SVE vector types.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97951
Bug ID: 97951
Summary: Template specialization of function template fails for
fixed-sized SVE vector types.
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: david.tellenbach at arm dot com
Target Milestone: ---
Following the ACLE for SVE Version 00bet6, fixed-length types can be declared
by using the
__attribute__((arm_sve_vector_bits(N)))
type attribute. However, the following snippet fails using g++-10 (Ubuntu
10.1.0-2ubuntu1~18.04) 10.1.0:
g++-10 -march=armv8-a+sve -msve-vector-bits=512 main.cc -c
main.cc:
#include
typedef svfloat32_t PacketXf __attribute__((arm_sve_vector_bits(512)));
template
T func(const float& f)
{
return f;
}
template<>
PacketXf func(const float& f)
{
return svdup_n_f32(f);
}
producing the following diagnostics:
main.cc:9:10: error: template-id 'func<>' for 'PacketXf func(const float&)'
does not match any template declaration
9 | PacketXf func(const float& f) { return svdup_n_f32(f); }
| ^~~~
main.cc:6:3: note: candidate is: 'template T func(const float&)'
6 | T func(const float& f) { return f; }
| ^~~~
[Bug libstdc++/67791] Crash using std::thread and iostream with dynamic loading of a shared library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67791 Jonathan Wakely changed: What|Removed |Added Last reconfirmed||2020-11-23 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #7 from Jonathan Wakely --- (In reply to nexyon from comment #4) > Thanks for the quick responses! I already expected some sort of side effect > like this. Maybe it's possible to reevaluate whether pthread is linked or > not during the first use of std::thread? No, because the result is cached in a static const variable, which can't be changed after its first use. > In any case std::thread should not > crash I guess, so just to fix that it would be necessary to check whether > the standard library was inizialized without threads. We used to check for the pthread_create weak symbol, and throw an exception instead of crashing. Since the fix for PR libstdc++/61841 we don't check it, and crash instead of throwing. That should be fixed. > Or shouldn't there be > locks in any case? What if another threading library is used but pthreads, > that libstdc++ is not expecting? (Not sure though, how practical that is, or > how likely that's going to happen) That's not supported. The only supported way to create new threads is via pthreads. > As the problem seems to be known, I wonder if I can expect this to be solved > any time soon? For now I guess my options are to tell the users of my > library and it's plugins to always link pthread to their main program or Right. > maybe artificially add a function in my library that uses std::thread so > that my library gets linked against pthread. Then linking dynamically with > it in the executable should not cause problems, only symloading the library > would still cause the same problem. Or do you have other ideas? If the main executable is not linked to libpthread, using dlopen to load a library that depends on libpthread doesn't work. This is currently unsupported, and unsupportable on GNU/Linux. If your library depends on libpthread.so and the main executable links to your library that should be fine. You don't need to use std::thread for that, just link to it without using --as-needed e.g. -Wl,--no-as-needed -lpthread -Wl,--as-needed Late-loading of libpthread.so via dlopen should start working with a future version of glibc, when this is implemented: https://sourceware.org/legacy-ml/libc-alpha/2019-10/msg00080.html
[Bug libstdc++/60662] simple use of call_once throws a system_error exception, but not if sleep_for is called beforehand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60662 Jonathan Wakely changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED Target Milestone|--- |11.0 --- Comment #5 from Jonathan Wakely --- I am able to reproduce this on Ubuntu 13.10, and it can be fixed by using -Wl,--no-as-needed before -lpthread which ensures the executable is linked to libpthread.so even though the linker thinks it's not needed. I'm not sure why this_thread::sleep_for (which just calls nanosleep) causes libpthread.so to get linked in, but ldd shows that there is a libpthread.so dependency with it. This should be fixed in GCC 11 which no longer uses pthread_once for std::call_once.
[Bug tree-optimization/97950] New: Unoptimal code generation with __builtin_*_overflow{,_p} for short and __int128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97950
Bug ID: 97950
Summary: Unoptimal code generation with
__builtin_*_overflow{,_p} for short and __int128
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: denis.campredon at gmail dot com
Target Milestone: ---
For the following code, the generation is unoptimal on x86-64.
For most of the functions with `short` a jump is generated.
For the functions with `__int128` all but `mul_overflow_{,un}signed___int128`
seems to have extra `mov` produced.
The same problems apply to all the `__builtin_*_overflow_p`
-
#define TEST_OVERFLOW(type) \
bool mul_overflow_signed_##type(signed type a, signed type b, signed type c)
{return __builtin_mul_overflow(a,b,);} \
bool add_overflow_signed_##type(signed type a, signed type b, signed type c)
{return __builtin_add_overflow(a,b,);} \
bool sub_overflow_signed_##type(signed type a, signed type b, signed type c)
{return __builtin_sub_overflow(a,b,);} \
bool mul_overflow_unsigned_##type(unsigned type a, unsigned type b, unsigned
type c) {return __builtin_mul_overflow(a,b,);} \
bool add_overflow_unsigned_##type(unsigned type a, unsigned type b, unsigned
type c) {return __builtin_add_overflow(a,b,);} \
bool sub_overflow_unsigned_##type(unsigned type a, unsigned type b, unsigned
type c) {return __builtin_sub_overflow(a,b,);} \
TEST_OVERFLOW(short)
TEST_OVERFLOW(__int128)
-
[Bug middle-end/97943] [11 Regression] ICE with __builtin_clear_padding on flexible array member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97943 --- Comment #5 from Jakub Jelinek --- (In reply to Jakub Jelinek from comment #4) > value and the expected argument, which while it is passed by value is also Sorry, meant passed by reference.
[Bug middle-end/97943] [11 Regression] ICE with __builtin_clear_padding on flexible array member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97943 --- Comment #4 from Jakub Jelinek --- BTW, for all the 3 cases __builtin_clear_padding will be called on, i.e. the constructor of std::atomic for the type, the desired argument passed by value and the expected argument, which while it is passed by value is also stored by the implementation (copied from the atomic memory), one can't effectively have any flexible (or poor man's flexible) array members except those that fit into the tail padding of the structures. So in many cases nothing at all. So for the flexible array members, if we don't sorry on them, we could also clear the tail padding spot for partial elements, because one really can't have there half of an element.
[Bug libgcc/78017] weak reference usage in gthr-posix.h (__gthread*) is broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78017 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-11-23 CC||redi at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #6 from Jonathan Wakely --- (In reply to Ben Longbons from comment #5) > I just hit this in my testsuite, and it's worse than described for the > dynamic case: > > if libpthread.so is dlopen'ed after libstdc++, __gthread_active_p() will > *not* become true - weak symbols are not rebound. The problem isn't that weak symbols are not rebound (they are), it's that __gthread_active_p stores the result of the first check in a static variable which is initialized once and then it's value doesn't change: static void *const __gthread_active_ptr = __extension__ (void *) _ACTIVE_PROXY; > Note that plugins that indirectly pull in pthreads are very common in the > wild. At the time of writing, the main executable needs to link to libpthread, not just the plugins. Otherwise libstdc++ won't work. Glibc also has a history of bugs with libpthread only being loaded via dlopen. > Further, LD_PRELOAD=libpthread.so.0 does NOT help. > > Thus, all C++ locks will do nothing despite the presence of multiple > threads. Correct code will experience race conditions. > > Do note that, nowadays, all of the *other* symbols you're making weak are in > libc.so (for GLIBC at least, which AFAIK is the only dlopen'able pthread > implementation) I don't think that's true at all. It's planned for a future version of glibc though, see https://sourceware.org/legacy-ml/libc-alpha/2019-10/msg00080.html When that happens, __gthread_active_p will always be true for glibc (and the weak symbols won't be needed anyway).
[Bug libstdc++/67116] incorrect detection of thread model when cross-compiling the tool chain
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67116 Jonathan Wakely changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #9 from Jonathan Wakely --- (In reply to Cezary Śliwa from comment #6) > Created attachment 36131 [details] > config.log > > libstdc++v3 config.log This shows: CXX=' x86_64-w64-mingw32-c++ -L/mingw64/x86_64-w64-mingw32/lib -L/mingw64/mingw/lib -isystem /mingw64/x86_64-w64-mingw32/include -isystem /mingw64/mingw/include ' CXXCPP=' x86_64-w64-mingw32-c++ -L/mingw64/x86_64-w64-mingw32/lib -L/mingw64/mingw/lib -isystem /mingw64/x86_64-w64-mingw32/include -isystem /mingw64/mingw/include-E' That means you're building libstdc++ with the wrong compiler.
[Bug libstdc++/63829] _Lock_policy used in thread.cc can cause incompatibilities with binaries using different -mcpu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63829 Jonathan Wakely changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|--- |9.0 Status|NEW |RESOLVED --- Comment #9 from Jonathan Wakely --- This was fixed in gcc-9 by the patch for PR libstdc++/67843
[Bug libstdc++/94996] jthread should stop and join the associated thread before being assigned.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94996 Jonathan Wakely changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|--- |10.3 Status|UNCONFIRMED |RESOLVED --- Comment #2 from Jonathan Wakely --- Fixed by g:08b4d325711d5c6f68ac29443aba3fd7aa173ac8 and g:7c44b67d83b34e56a4f65afd70754c5e30280247
[Bug libstdc++/97948] C++2a synchronization tests fail to link on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97948 --- Comment #1 from Andreas Schwab --- See also PR81358.
[Bug libstdc++/87679] std::this_thread::sleep_until sleeps too much for clocks faster than system_clock
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87679 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-11-23 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- A faster clock can be considered to be constantly being adjusted slightly forwards, which means this wording from the standard applies: Recommended practice: Implementations should decrease the duration of the wait when the clock is adjusted forwards. I'm not really sure how to do that other than sleeping for smaller durations, so that we keep waking up to see if the time has been reached. That adds overhead due to the extra calls to the _Clock::now() function. We could do something like sleep for a maximum for N seconds when using a user-defined clock. For very small durations we wouldn't bother, and so there wouldn't be extra overhead. For longer durations, we'd periodically wake up and recheck the time.
[Bug sanitizer/97941] [HWASAN] use After free not working as per expectation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97941
--- Comment #1 from Matthew Malcomson ---
Hi Akhilesh,
No that's certainly not a known issue -- thanks for reporting it!
I'm having trouble reproducing your issue, do you mind giving a little more
information on your command line and the machine you're running on etc?
One point that seems worth looking into is that the line numbers on your
backtrace don't seem to match up with the line numbers in my source tree.
(e.g. GetAccessInfo is given line number 383 of hwasan_linux.cpp, while in my
source tree that function spans lines 328-376). Have you made any
modifications to the source? Or maybe you're running a different libsanitizer
version?
For reference I'm using libsanitizer from LLVM hash
6e7dd1e3e1170080b76b5dcc5716bdd974343233, and the sha256sum of hwasan_linux.cpp
in my source tree is
3986e9f4e519409e7c73a7b97722125300afc4dc1f44a3f966fedf679329fd0a.
Based on what line number `HwasanOnSIGTRAP` calls `GetAccessInfo` in my source
tree, and assuming the offset between our line numbers are the same for the
GetAccessInfo line in your stack trace, it seems that the SEGV happens when
dereferencing the address that caused the signal.
That value should be the address of the `brk` instruction in __hwasan_load1
(having been inlined from `SigTrap` in hwasan_checks.h) which caught the bad
access, but the value of 0x30 which caused this SEGV is clearly not that value.
If the offset between our line numbers is a bit different, then getting that
address might make a bit more sense. There are various struct member accesses
via pointers that `GetAccessInfo` recieves.
However, those arguments are just taken from the siginfo_t and ucontext_t
pointers that the kernel provides on receipt of a deadly signal.
I haven't found any access in that function which look like they would have an
offset of 0x30 from a NULL pointer, although I guess different kernel versions
would have different offsets.
What kernel are you running on? Is there any chance the signal handler
HwasanOnDeadlySignal is getting a NULL pointer as one of its arguments?
For reference I happen to be running on a linux kernel based off of commit
585e5b17b9 (but with some modifications that should not affect anything -- just
config changes so I can build the kernel itself with -fsanitize=hwaddress).
Just for reference -- what I see when compiling your testcase:
ubuntu@ubuntu:~/working-directory/temp/pr97941$
../../gcc-hwasan-install/bin/gcc -fsanitize=hwaddress ./test.c -o test
./test.c: In function ‘main’:
./test.c:2:20: warning: implicit declaration of function ‘malloc’
[-Wimplicit-function-declaration]
2 | char *x = (char*)malloc(10 * sizeof(char*));
|^~
./test.c:1:1: note: include ‘’ or provide a declaration of ‘malloc’
+++ |+#include
1 | int main() {
./test.c:2:20: warning: incompatible implicit declaration of built-in function
‘malloc’ [-Wbuiltin-declaration-mismatch]
2 | char *x = (char*)malloc(10 * sizeof(char*));
|^~
./test.c:2:20: note: include ‘’ or provide a declaration of ‘malloc’
./test.c:3:3: warning: implicit declaration of function ‘free’
[-Wimplicit-function-declaration]
3 | free(x);
| ^~~~
./test.c:3:3: note: include ‘’ or provide a declaration of ‘free’
./test.c:3:3: warning: incompatible implicit declaration of built-in function
‘free’ [-Wbuiltin-declaration-mismatch]
./test.c:3:3: note: include ‘’ or provide a declaration of ‘free’
ubuntu@ubuntu:~/working-directory/temp/pr97941$
LD_LIBRARY_PATH=~/working-directory/gcc-hwasan-install/lib64 ./test
==8600==ERROR: HWAddressSanitizer: tag-mismatch on address 0xefe00005 at pc
0xa828be70
READ of size 1 at 0xefe00005 tags: e2/d5 (ptr/mem) in thread T0
#0 0xa828be6c in SigTrap<0>
../../../../gcc-source/libsanitizer/hwasan/hwasan_checks.h:27
#1 0xa828be6c in CheckAddress<(__hwasan::ErrorAction)0,
(__hwasan::AccessType)0, 0>
../../../../gcc-source/libsanitizer/hwasan/hwasan_checks.h:88
#2 0xa828be6c in __hwasan_load1
../../../../gcc-source/libsanitizer/hwasan/hwasan.cpp:375
#3 0x400944 in main
(/home/ubuntu/working-directory/temp/pr97941/test+0x400944)
#4 0xa81598dc in __libc_start_main
(/lib/aarch64-linux-gnu/libc.so.6+0x1f8dc)
[0xefe0,0xefe00060) is a small unallocated heap chunk; size: 96
offset: 5
0xefe00005 is located 5 bytes inside of 80-byte region
[0xefe0,0xefe00050)
freed by thread T0 here:
#0 0xa828d64c in __sanitizer_free
../../../../gcc-source/libsanitizer/hwasan/hwasan_interceptors.cpp:108
#1 0x400934 in main
(/home/ubuntu/working-directory/temp/pr97941/test+0x400934)
#2 0xa81598dc in __libc_start_main
(/lib/aarch64-linux-gnu/libc.so.6+0x1f8dc)
#3 0x400814 (/home/ubuntu/working-directory/temp/pr97941/test+0x400814)
previously allocated here:
#0 0xa828db30 in __sanitizer_malloc
[Bug libgcc/89714] allow for overriding the thread-detection mechanism
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89714 --- Comment #3 from Thomas Neumann --- Perhaps the header files could be changed to react to _REENTRANT, as that seems to be the define that is set by gcc when requesting threading support. The redundant checks within the shared library are less of an issue. Of course they waste a few cycles, too, but the unnecessary checks in the header files are far worse as they are inlined all over the place when using, e.g., shared_ptr.
[Bug libstdc++/80992] libstdc++ cross-build on solaris is missing GCC_CHECK_TLS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80992 --- Comment #1 from Jonathan Wakely --- I think crossconfig.m4 for mingw32* should use GCC_CHECK_TLS too.
[Bug libstdc++/80992] libstdc++ cross-build on solaris is missing GCC_CHECK_TLS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80992 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-11-23 Ever confirmed|0 |1
[Bug ipa/96734] gcc 10.2.0 fails to compile on mips64 due to crash in IPA SRA pass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96734
--- Comment #10 from Martin Liška ---
All right, I have a reduced test-case (with the failing stage1 compiler):
$ cat method.ii
typedef union tree_node *tree;
struct tree_typed {
tree type;
};
struct tree_type_non_common {
tree lang_1;
};
union tree_node {
tree_typed typed;
tree_type_non_common type_non_common;
};
;
struct comp_info {
bool noex;
comp_info(tree fndecl, int ) {
if (noex) {
if ((fndecl)->typed.type)))->type_non_common.lang_1) )
noex = false;
}
}
};
tree build_comparison_op_fndecl;
int build_comparison_op_complain;
void synthesize_method() {
{
{
comp_info (build_comparison_op_fndecl, build_comparison_op_complain);
}
}
}
[Bug libstdc++/97944] 30_threads/jthread/95989.cc fails randomly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97944 Christophe Lyon changed: What|Removed |Added Version|11.0|10.2.1 --- Comment #1 from Christophe Lyon --- This is also affects gcc-10
[Bug libstdc++/97949] New: Recursive calls of std::call_once together with cout leads to deadlock under mingw64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97949
Bug ID: 97949
Summary: Recursive calls of std::call_once together with cout
leads to deadlock under mingw64
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: fiesh at zefix dot tv
Target Milestone: ---
Host: x86_64-pc-linux-gnu
Target: x86_64-w64-mingw32.static
The following code locks under Windows 10:
-
#include
#include
#include
#include
std::once_flag flag0;
std::once_flag flag1;
void innerDoOnce()
{
std::call_once(flag0, []() {
using namespace std::chrono_literals;
std::cout << "innerDoOnce() called...\n";
std::this_thread::sleep_for(1s);
});
}
void outerDoOnce()
{
std::call_once(flag1, []() {
std::cout << "outerDoOnce() called...\n";
innerDoOnce();
});
}
int main()
{
std::thread t0(innerDoOnce);
std::thread t1(innerDoOnce);
std::thread t2(outerDoOnce);
std::thread t3(outerDoOnce);
t0.join();
t1.join();
t2.join();
t3.join();
std::cout << "aggi\n";
}
-
Removing the `std::cout` calls seems to make the issue go away.
[Bug libstdc++/97948] New: C++2a synchronization tests fail to link on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97948 Bug ID: 97948 Summary: C++2a synchronization tests fail to link on arm Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: clyon at gcc dot gnu.org Target Milestone: --- These new tests fails to link on arm: 29_atomics/atomic_float/wait_notify.cc (test for excess errors) 29_atomics/atomic_integral/wait_notify.cc (test for excess errors) 29_atomics/atomic_ref/wait_notify.cc (test for excess errors) Excess errors: /aci-gcc-fsf/builds/gcc-fsf-gccsrc/tools/arm-none-linux-gnueabi/bin/ld: /ccytYIXt.o: in function `std::remove_volatile::type std::__atomic_impl::load(double const*, std::memory_order)': /aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-linux-gnueabi/gcc3/arm-none-linux-gnueabi/libstdc++-v3/include/bits/atomic_base.h:976: undefined reference to `__atomic_load_8' /aci-gcc-fsf/builds/gcc-fsf-gccsrc/tools/arm-none-linux-gnueabi/bin/ld: /aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-linux-gnueabi/gcc3/arm-none-linux-gnueabi/libstdc++-v3/include/bits/atomic_base.h:976: undefined reference to `__atomic_load_8' /aci-gcc-fsf/builds/gcc-fsf-gccsrc/tools/arm-none-linux-gnueabi/bin/ld: /aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-linux-gnueabi/gcc3/arm-none-linux-gnueabi/libstdc++-v3/include/bits/atomic_base.h:976: undefined reference to `__atomic_load_8' /aci-gcc-fsf/builds/gcc-fsf-gccsrc/tools/arm-none-linux-gnueabi/bin/ld: /ccytYIXt.o: in function `void std::__atomic_impl::store(double*, std::remove_volatile::type, std::memory_order)': /aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-linux-gnueabi/gcc3/arm-none-linux-gnueabi/libstdc++-v3/include/bits/atomic_base.h:968: undefined reference to `__atomic_store_8' /aci-gcc-fsf/builds/gcc-fsf-gccsrc/tools/arm-none-linux-gnueabi/bin/ld: /ccytYIXt.o: in function `std::remove_volatile::type std::__atomic_impl::load(double const*, std::memory_order)': /aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-linux-gnueabi/gcc3/arm-none-linux-gnueabi/libstdc++-v3/include/bits/atomic_base.h:976: undefined reference to `__atomic_load_8' /aci-gcc-fsf/builds/gcc-fsf-gccsrc/tools/arm-none-linux-gnueabi/bin/ld: /ccytYIXt.o: in function `void std::__atomic_impl::store(double*, std::remove_volatile::type, std::memory_order)': /aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-linux-gnueabi/gcc3/arm-none-linux-gnueabi/libstdc++-v3/include/bits/atomic_base.h:968: undefined reference to `__atomic_store_8' /aci-gcc-fsf/builds/gcc-fsf-gccsrc/tools/arm-none-linux-gnueabi/bin/ld: /aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-linux-gnueabi/gcc3/arm-none-linux-gnueabi/libstdc++-v3/include/bits/atomic_base.h:968: undefined reference to `__atomic_store_8' /aci-gcc-fsf/builds/gcc-fsf-gccsrc/tools/arm-none-linux-gnueabi/bin/ld: /ccytYIXt.o: in function `std::remove_volatile::type std::__atomic_impl::load(double const*, std::memory_order)': /aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-linux-gnueabi/gcc3/arm-none-linux-gnueabi/libstdc++-v3/include/bits/atomic_base.h:976: undefined reference to `__atomic_load_8' /aci-gcc-fsf/builds/gcc-fsf-gccsrc/tools/arm-none-linux-gnueabi/bin/ld: /ccytYIXt.o: in function `void std::__atomic_impl::store(double*, std::remove_volatile::type, std::memory_order)': /aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-linux-gnueabi/gcc3/arm-none-linux-gnueabi/libstdc++-v3/include/bits/atomic_base.h:968: undefined reference to `__atomic_store_8' /aci-gcc-fsf/builds/gcc-fsf-gccsrc/tools/arm-none-linux-gnueabi/bin/ld: /ccytYIXt.o: in function `std::remove_volatile::type std::__atomic_impl::load(double const*, std::memory_order)': /aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-linux-gnueabi/gcc3/arm-none-linux-gnueabi/libstdc++-v3/include/bits/atomic_base.h:976: undefined reference to `__atomic_load_8' collect2: error: ld returned 1 exit status This happens for instance with arm-none-linux-gnueabi-gcc and compiling with -march=armv5t
[Bug c++/97947] New: [11 Regression] ICE in digest_init_r, at cp/typeck2.c:1145
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97947
Bug ID: 97947
Summary: [11 Regression] ICE in digest_init_r, at
cp/typeck2.c:1145
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
Target: powerpc-*-linux-gnu
gcc-11.0.0-alpha20201122 snapshot (g:e23f47ec4065e9eec53c4ad9db91bc36a4f90793)
ICEs when compiling the following testcase, reduced from
gcc/testsuite/gcc.target/powerpc/mma-builtin-2.c:
void
x1 (__vector_pair *ur)
{
__vector_pair dd = *ur;
}
% powerpc-e300c3-linux-gnu-g++-11.0.0 -c lv5swte0.c
lv5swte0.c: In function 'void x1(__vector_pair*)':
lv5swte0.c:4:23: internal compiler error: in digest_init_r, at
cp/typeck2.c:1145
4 | __vector_pair dd = *ur;
| ^~
0x69162f digest_init_r
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20201122/work/gcc-11-20201122/gcc/cp/typeck2.c:1145
0xae37ed store_init_value(tree_node*, tree_node*, vec**, int)
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20201122/work/gcc-11-20201122/gcc/cp/typeck2.c:729
0x930ab0 check_initializer
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20201122/work/gcc-11-20201122/gcc/cp/decl.c:6923
0x956e52 cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20201122/work/gcc-11-20201122/gcc/cp/decl.c:7841
0xa0b1e7 cp_parser_init_declarator
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20201122/work/gcc-11-20201122/gcc/cp/parser.c:21380
0x9e7801 cp_parser_simple_declaration
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20201122/work/gcc-11-20201122/gcc/cp/parser.c:13962
0xa053da cp_parser_declaration_statement
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20201122/work/gcc-11-20201122/gcc/cp/parser.c:13362
0x9e97b4 cp_parser_statement
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20201122/work/gcc-11-20201122/gcc/cp/parser.c:11586
0x9ea902 cp_parser_statement_seq_opt
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20201122/work/gcc-11-20201122/gcc/cp/parser.c:11952
0x9ea9e0 cp_parser_compound_statement
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20201122/work/gcc-11-20201122/gcc/cp/parser.c:11902
0xa0554f cp_parser_function_body
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20201122/work/gcc-11-20201122/gcc/cp/parser.c:23569
0xa0554f cp_parser_ctor_initializer_opt_and_function_body
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20201122/work/gcc-11-20201122/gcc/cp/parser.c:23620
0xa0a360 cp_parser_function_definition_after_declarator
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20201122/work/gcc-11-20201122/gcc/cp/parser.c:29510
0xa0b7ed cp_parser_function_definition_from_specifiers_and_declarator
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20201122/work/gcc-11-20201122/gcc/cp/parser.c:29426
0xa0b7ed cp_parser_init_declarator
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20201122/work/gcc-11-20201122/gcc/cp/parser.c:21142
0x9e7801 cp_parser_simple_declaration
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20201122/work/gcc-11-20201122/gcc/cp/parser.c:13962
0xa15e84 cp_parser_declaration
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20201122/work/gcc-11-20201122/gcc/cp/parser.c:13659
0xa16730 cp_parser_translation_unit
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20201122/work/gcc-11-20201122/gcc/cp/parser.c:4806
0xa16730 c_parse_file()
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20201122/work/gcc-11-20201122/gcc/cp/parser.c:44613
0xb46fb9 c_common_parse_file()
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20201122/work/gcc-11-20201122/gcc/c-family/c-opts.c:1198
[Bug tree-optimization/22326] promotions (from float to double) are not removed when they should be able to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=22326 --- Comment #11 from rguenther at suse dot de --- On Mon, 23 Nov 2020, luoxhu at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=22326 > > --- Comment #10 from luoxhu at gcc dot gnu.org --- > Even we could optimize fabs to fabsf, it doesn't help here as y and z are > already promoted to double, then we still need a large pattern to match the > MUL expression in match.pd, so fabs to fabsf seems not a reasonable > direction... The larger expressions should be subject to a propagation pass and not arbitrarily complex static pattern matching. Maybe backprop is a suitable one to wire this in.
[Bug libgcc/89714] allow for overriding the thread-detection mechanism
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89714 --- Comment #2 from Jonathan Wakely --- -D_GLIBCXX_GTHREAD_USE_WEAK=0 appears to work, but is not officially supported. It also only affects the code in the libstdc++ headers, not the code inside libstdc++.so that checks __gthread_active_p.
[Bug c++/97946] New: passing templated function without template argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97946
Bug ID: 97946
Summary: passing templated function without template argument
Product: gcc
Version: 10.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: niklas at nolte dot dev
Target Milestone: ---
The compiler accepts the following code.
`fun` without template arguments should not be accepted, should it?
```
template
void fun() {}
template
void higher_order_fun( const F & f) {
f();
}
int main () {
//higher_order_fun(fun<>); //works
higher_order_fun(fun);
}
```
The related stackoverflow question:
https://stackoverflow.com/questions/64872397/passing-function-template-prototype-as-argument
[Bug libstdc++/97362] [8/9/10 Regression] `__deref` in in debug mode clashes with internal macro in Windows system header
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97362 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|WAITING --- Comment #7 from Jonathan Wakely --- ping
[Bug c/97945] undefined reference err when a function defined inline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97945 Jakub Jelinek changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED Component|ipa |c CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- That is a user error. The C99 and later standards mandate this behavior. Either use static inline, or in one TU you need to use extern inline, or use the GNU inline semantics.
[Bug libstdc++/97944] 30_threads/jthread/95989.cc fails randomly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97944 Jonathan Wakely changed: What|Removed |Added Last reconfirmed||2020-11-23 Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED
[Bug libstdc++/58929] condition_variable does not wait without -pthread
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58929 --- Comment #11 from Jonathan Wakely --- (In reply to Victor Mataré from comment #10) > OK, thanks for the clarification. But I feel I need to point out that that's > just a huge WTF. How is a C++ dev supposed to know from the standard docs > they work with all day that a condition_variable has any relation to > libpthread? You're not compiling with the standard, you're using GCC. The requirement to use libpthread is documented by the implementation (although it could be easier to find): https://gcc.gnu.org/onlinedocs/libstdc++/manual/using.html#manual.intro.using.flags
[Bug ipa/97945] New: undefined reference err when a function defined inline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97945
Bug ID: 97945
Summary: undefined reference err when a function defined inline
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: dongjianqiang2 at huawei dot com
CC: marxin at gcc dot gnu.org
Target Milestone: ---
$ cat z1.c
#define likely(x) __builtin_expect((x), 1)
#define unlikely(x) __builtin_expect((x), 0)
int a=10;
inline void test() {
__builtin_puts("hot");
a++;
__builtin_puts("hot");
}
void main() {
__builtin_puts("hot");
if (unlikely(a==2)) {
test();
}
__builtin_puts("hot");
}
gcc test.c -O2
in function `main':
test.c:(.text.startup+0x38): undefined reference to `test'
collect2: error: ld returned 1 exit status
But succeed when compiling with -fgnu89-inline.
[Bug middle-end/97943] [11 Regression] ICE with __builtin_clear_padding on flexible array member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97943
Jakub Jelinek changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment #3 from Jakub Jelinek ---
(In reply to Richard Biener from comment #2)
> > Which raises the question what to do for the real-world case which won't
> > use char b[] since that's not C++ but would use char b[1] ...
>
> To answer my own question, array_at_struct_end_p () covered padding must not
> be cleared.
If we do that, we'll violate C++20 I'd think.
For flexible array members we can choose what exactly we want to do, because we
are outside of the standard. But when one uses:
#include
struct S { char a; short b; };
struct T { char a; char b alignas (32); S c[1]; };
std::atomic t;
then we can't pretend one can store meaningful values in c[3].b and expect it
to work.
