[Bug debug/100541] [12 Regression] -fcompare-debug failure (length) with -O3 -fno-expensive-optimizations -fno-tree-dce -fno-tree-dominator-opts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100541
--- Comment #1 from Zdenek Sojka ---
Created attachment 50833
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50833&action=edit
another testcase (needs less compiler flags)
$ x86_64-pc-linux-gnu-gcc -O2 -fno-tree-dce -fno-tree-dominator-opts
-fcompare-debug aircraft_cmd.ii -save-temps
x86_64-pc-linux-gnu-gcc: error: aircraft_cmd.ii: '-fcompare-debug' failure
(length)
$ diff -u *gkd
--- a-aircraft_cmd.gk.ii.gkd2021-05-18 08:56:42.271670788 +0200
+++ a-aircraft_cmd.ii.gkd 2021-05-18 08:56:42.191670787 +0200
@@ -65,7 +65,7 @@
(mult:HI (reg:HI 0 ax [orig:89 pretmp_31 ] [89])
(const_int -21845 [0xaaab])))
(clobber (reg:CC 17 flags))
-]) "aircraft_cmd.ii":18:19# {*mulhi3_1}
+])# {*mulhi3_1}
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil)))
(insn:TI # 0 0 4 (parallel [
@@ -73,7 +73,7 @@
(plus:HI (reg:HI 0 ax [101])
(const_int 10922 [0x2aaa])))
(clobber (reg:CC 17 flags))
-]) "aircraft_cmd.ii":18:19# {*addhi_1}
+])# {*addhi_1}
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil)))
(insn:TI # 0 0 4 (set (reg:CC 17 flags)
[Bug c/100547] ICE with "-g -O1": stack overflow in expand with a very large vector_size attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100547 --- Comment #4 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:4054472b3fa15e11ccd48190f5e3ecfc89d65af9 commit r12-859-g4054472b3fa15e11ccd48190f5e3ecfc89d65af9 Author: Richard Biener Date: Wed May 12 09:20:17 2021 +0200 c/100547 - reject overly large vector_size attributes This rejects a number of vector components that does not fit an 'int' which is an internal limitation of RTVEC. This requires adjusting gcc.dg/attr-vector_size.c which checks for much larger supported vectors. Note that the RTVEC limitation is a host specific limitation (unless we change this 'int' to int32_t), but should be 32bits in practice everywhere. 2021-05-12 Richard Biener PR c/100547 gcc/c-family/ * c-attribs.c (type_valid_for_vector_size): Reject too large nunits. Reword existing nunit diagnostic. gcc/testsuite/ * gcc.dg/pr100547.c: New testcase. * gcc.dg/attr-vector_size.c: Adjust.
[Bug c/100547] ICE with "-g -O1": stack overflow in expand with a very large vector_size attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100547 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Richard Biener --- Fixed for GCC 12.
[Bug tree-optimization/88240] [9 Regression] Potential optimization bug: invalid pre-load of floating-point value could cause SIGFPE-underflow if value is integer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88240 --- Comment #21 from CVS Commits --- The releases/gcc-9 branch has been updated by Richard Biener : https://gcc.gnu.org/g:009a8566d8ac5cc6ab1604716ba43d3c0bd99b64 commit r9-9537-g009a8566d8ac5cc6ab1604716ba43d3c0bd99b64 Author: Richard Biener Date: Tue Aug 4 14:10:45 2020 +0200 tree-optimization/88240 - stopgap for floating point code-hoisting issues This adds a stopgap measure to avoid performing code-hoisting on mixed type loads when the load we'd insert in the hoisting position would be a floating point one. This is because certain targets (hello x87) cannot perform floating point loads without possibly altering the bit representation and thus cannot be used in place of integral loads. 2020-08-04 Richard Biener PR tree-optimization/88240 * tree-ssa-sccvn.h (vn_reference_s::punned): New flag. * tree-ssa-sccvn.c (vn_reference_insert): Initialize punned. (vn_reference_insert_pieces): Likewise. (visit_reference_op_call): Likewise. (visit_reference_op_load): Track whether a ref was punned. * tree-ssa-pre.c (do_hoist_insertion): Refuse to perform hoist insertion on punned floating point loads. * gcc.target/i386/pr88240.c: New testcase.
[Bug tree-optimization/96597] valgrind error in do_hoist_insertion during O3 build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96597 --- Comment #12 from CVS Commits --- The releases/gcc-9 branch has been updated by Richard Biener : https://gcc.gnu.org/g:f5f932214bf73bbe3334d67a07c632e4fca351f4 commit r9-9538-gf5f932214bf73bbe3334d67a07c632e4fca351f4 Author: Martin Liska Date: Thu Aug 13 13:05:12 2020 +0200 Add missing vn_reference_t::punned initialization gcc/ChangeLog: PR tree-optimization/96597 * tree-ssa-sccvn.c (vn_reference_lookup_call): Add missing initialization of ::punned. (vn_reference_insert): Use consistently false instead of 0. (vn_reference_insert_pieces): Likewise.
[Bug tree-optimization/96513] [9 Regression] ICE in vect_get_vec_def_for_operand_1, at tree-vect-stmts.c:1475 since r9-3644-g4dd7c0dcd87c86aa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96513 --- Comment #11 from CVS Commits --- The releases/gcc-9 branch has been updated by Richard Biener : https://gcc.gnu.org/g:88f14ec71e3cd2bc1973177ec180aa5605866358 commit r9-9539-g88f14ec71e3cd2bc1973177ec180aa5605866358 Author: Richard Biener Date: Wed Mar 25 14:41:51 2020 +0100 tree-optimization/96513 - rewrite hybrid SLP detection This rewrites hybrid SLP detection to be simpler and cope with group size changes in the SLP graph. In particular detection works starting from non-SLP stmts following use->def chains rather than walking the SLP graph and following def->use chains. This picks a rewrite from GCC 11 for the old code didn't handle pattern sequences correctly. 2020-05-05 Richard Biener PR tree-optimization/96513 * tree-vect-slp.c (struct vdhs_data): New. (vect_detect_hybrid_slp): New walker. (vect_detect_hybrid_slp): Rewrite. * gcc.dg/torture/pr96513.c: New testcase.
[Bug rtl-optimization/80960] [9 Regression] Huge memory use when compiling a very large test case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80960 --- Comment #31 from CVS Commits --- The releases/gcc-9 branch has been updated by Richard Biener : https://gcc.gnu.org/g:6cb5edbf7e6724ff014954863989d7444ee84c6a commit r9-9540-g6cb5edbf7e6724ff014954863989d7444ee84c6a Author: Richard Biener Date: Wed Jan 27 15:35:52 2021 +0100 rtl-optimization/80960 - avoid creating garbage RTL in DSE The following avoids repeatedly turning VALUE RTXen into sth useful and re-applying a constant offset through get_addr via DSE check_mem_read_rtx. Instead perform this once for all stores to be visited in check_mem_read_rtx. This avoids allocating 1.6GB of garbage PLUS RTXen on the PR80960 testcase, fixing the memory usage regression from old GCC. 2021-01-27 Richard Biener PR rtl-optimization/80960 * dse.c (check_mem_read_rtx): Call get_addr on the offsetted address. (cherry picked from commit a523add327c6cfdd68cf9b788ea808068d0f508c)
[Bug tree-optimization/96513] [9 Regression] ICE in vect_get_vec_def_for_operand_1, at tree-vect-stmts.c:1475 since r9-3644-g4dd7c0dcd87c86aa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96513 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #12 from Richard Biener --- Fixed.
[Bug tree-optimization/96457] PRE gets confused by punned load handling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96457 Bug 96457 depends on bug 88240, which changed state. Bug 88240 Summary: [9 Regression] Potential optimization bug: invalid pre-load of floating-point value could cause SIGFPE-underflow if value is integer https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88240 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/88240] [9 Regression] Potential optimization bug: invalid pre-load of floating-point value could cause SIGFPE-underflow if value is integer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88240 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED Known to fail||9.3.0 Known to work||9.3.1 --- Comment #22 from Richard Biener --- Fixed.
[Bug rtl-optimization/80960] [9 Regression] Huge memory use when compiling a very large test case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80960 Richard Biener changed: What|Removed |Added Known to work||9.3.1 Resolution|--- |FIXED Status|ASSIGNED|RESOLVED Known to fail||9.3.0 --- Comment #32 from Richard Biener --- Fixed.
[Bug c++/100646] [11/12 Regression] gcc -E -fdirectives-only causes "error: unterminated comment" when no new line at the end of file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100646 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2021-05-18 Known to work||10.3.1 Target Milestone|--- |11.2 Priority|P3 |P2 Summary|gcc -E -fdirectives-only|[11/12 Regression] gcc -E |causes "error: unterminated |-fdirectives-only causes |comment" when no new line |"error: unterminated |at the end of file |comment" when no new line ||at the end of file --- Comment #1 from Richard Biener --- Confirmed.
[Bug c++/100646] [11/12 Regression] gcc -E -fdirectives-only causes "error: unterminated comment" when no new line at the end of file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100646 Eric Gallager changed: What|Removed |Added Keywords||diagnostic, error-recovery, ||ice-on-invalid-code CC||egallager at gcc dot gnu.org --- Comment #2 from Eric Gallager --- It took a bit of effort to get a text editor to save the file without a newline at EOF, but once I did that, the error for me was an ICE instead of a regular error: 100646.c:1: internal compiler error: in cpp_directive_only_process, at libcpp/lex.c:3950 1 | int main() | I'll attach the full output as an attachment. This happens regardless of whether I compile it as plain C, or C++. (although it has been awhile since I last rebuilt GCC, so that could be the issue...) Here's my version and configuration info: $ /usr/local/bin/gcc -v Using built-in specs. COLLECT_GCC=/usr/local/bin/gcc COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-apple-darwin19.6.0/11.0.0/lto-wrapper Target: x86_64-apple-darwin19.6.0 Configured with: ../configure --disable-werror --disable-werror-always --enable-languages=all,c,c++,objc,obj-c++,lto --enable-stage1-checking=release,rtl -C --with-system-libunwind --enable-secureplt --enable-frame-pointer --enable-debug --without-isl --disable-host-shared --disable-maintainer-mode --disable-default-pie --with-ld64 --without-pic --enable-target-optspace --disable-nls --with-system-zlib --with-libiconv-prefix=/opt/local --with-gmp=/opt/local --with-mpfr=/opt/local --with-mpc=/opt/local --enable-lto --with-build-config=bootstrap-debug --enable-objc-gc --enable-libada --enable-libssp --disable-libsanitizer --with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk --disable-gcov : (reconfigured) ../configure --disable-werror --disable-werror-always --enable-languages=all,c,c++,objc,obj-c++,lto --enable-stage1-checking=release,rtl -C --with-system-libunwind --enable-secureplt --enable-frame-pointer --enable-debug --without-isl --disable-host-shared --disable-maintainer-mode --disable-default-pie --with-ld64 --without-pic --enable-target-optspace --disable-nls --with-system-zlib --with-libiconv-prefix=/opt/local --with-gmp=/opt/local --with-mpfr=/opt/local --with-mpc=/opt/local --enable-lto --with-build-config=bootstrap-debug --disable-objc-gc --enable-libada --enable-libssp --disable-libsanitizer --with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk --disable-gcov Thread model: posix Supported LTO compression algorithms: zlib gcc version 11.0.0 20200920 (experimental) (GCC) $
[Bug c++/100646] [11/12 Regression] gcc -E -fdirectives-only causes "error: unterminated comment" when no new line at the end of file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100646 --- Comment #3 from Eric Gallager --- Created attachment 50834 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50834&action=edit terminal output from attempting to compile testcase
[Bug tree-optimization/100512] [12 Regression] ICE during GIMPLE pass: cddce in mark_operand_necessary, at tree-ssa-dce.c:173 (under -O2 to -Os) since r12-623-g1416a1434c43de0b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100512 Martin Liška changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #9 from Martin Liška --- I guess it's fixed now.
[Bug fortran/100633] ICE: gfc_trans_omp_workshare(): Bad statement code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100633 Tobias Burnus changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #4 from Tobias Burnus --- FIXED on mainline (GCC 12) and on the GCC 11 branch. Thanks for the report!
Mail delivery failed: returning message to sender
This message was created automatically by mail delivery software. A message that you sent could not be delivered to one or more of its recipients. This is a permanent error. The following address(es) failed: gcc-bugs@gcc.gnu.org Domain shankarelectricals.com has exceeded the max emails per hour (2200/2000 (110%)) allowed. Message discarded. Reporting-MTA: dns; host.adsinmedia.co.in Action: failed Final-Recipient: rfc822;gcc-bugs@gcc.gnu.org Status: 5.0.0 Return-path: Received: from static.177.67.69.159.clients.your-server.de ([159.69.67.177]:52980 helo=eim.ae) by host.adsinmedia.co.in with esmtpa (Exim 4.94.2) (envelope-from ) id 1liuEc-00073x-9H for gcc-bugs@gcc.gnu.org; Tue, 18 May 2021 13:03:45 +0530 From: "gcc-bugs@gcc.gnu.org webmas...@gcc.gnu.org" To: gcc-bugs@gcc.gnu.org Subject: Cancel Deactivation - gcc-bugs@gcc.gnu.org Date: 18 May 2021 00:36:57 -0700 Message-ID: <20210518003657.e54ffd2e698e9...@gcc.gnu.org> MIME-Version: 1.0 Content-Type: multipart/related; boundary="=_NextPart_000_0012_27772EA1.885D061D" X-Exim-DSN-Information: Due to administrative limits only headers are returned
[Bug rtl-optimization/100647] New: ICE during sms pass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100647
Bug ID: 100647
Summary: ICE during sms pass
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: kito at gcc dot gnu.org
Target Milestone: ---
Host: x86_64-linux-gnu
Target: riscv64-unknown-elf
Flags: -Ofast -fno-gcse -fmodulo-sched -freorder-blocks-and-partition
-fno-tree-dce -march=rv64gc -mabi=lp64
Testcase:
char c;
char *d;
char *e();
char *f(char *h) {
int a = *h;
return *h == 7 ? h : h + a;
}
char i() {
char *g, *b;
g = e();
for (; g; b = f(b))
if (c)
*d = 0;
return 0;
}
ICE Message:
during RTL pass: sms
sms.crash.c: In function 'i':
sms.crash.c:15:1: internal compiler error: in
cfg_layout_redirect_edge_and_branch_force, at cfgrtl.c:4651
15 | }
| ^
0x82a8a8 cfg_layout_redirect_edge_and_branch_force
../../../../riscv-gnu-toolchain-trunk/riscv-gcc/gcc/cfgrtl.c:4651
0x8102d3 redirect_edge_and_branch_force(edge_def*, basic_block_def*)
../../../../riscv-gnu-toolchain-trunk/riscv-gcc/gcc/cfghooks.c:490
0x810de5 make_forwarder_block(basic_block_def*, bool (*)(edge_def*), void
(*)(basic_block_def*))
../../../../riscv-gnu-toolchain-trunk/riscv-gcc/gcc/cfghooks.c:903
0x81a88d merge_latch_edges
../../../../riscv-gnu-toolchain-trunk/riscv-gcc/gcc/cfgloop.c:780
0x81a88d disambiguate_multiple_latches
../../../../riscv-gnu-toolchain-trunk/riscv-gcc/gcc/cfgloop.c:831
0x81a88d disambiguate_loops_with_multiple_latches()
../../../../riscv-gnu-toolchain-trunk/riscv-gcc/gcc/cfgloop.c:844
0xb35484 apply_loop_flags
../../../../riscv-gnu-toolchain-trunk/riscv-gcc/gcc/loop-init.c:55
0xb3605c loop_optimizer_init(unsigned int)
../../../../riscv-gnu-toolchain-trunk/riscv-gcc/gcc/loop-init.c:124
0x15b8039 sms_schedule
../../../../riscv-gnu-toolchain-trunk/riscv-gcc/gcc/modulo-sched.c:1362
0x15bac1f execute
../../../../riscv-gnu-toolchain-trunk/riscv-gcc/gcc/modulo-sched.c:3359
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug c/100522] ICE: in extract_ops_from_tree, at gimple-expr.c:556
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100522 --- Comment #2 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:414fe08a352eac69168f4fb3671246c84a1ac5aa commit r12-860-g414fe08a352eac69168f4fb3671246c84a1ac5aa Author: Richard Biener Date: Tue May 18 08:41:43 2021 +0200 c/100522 - avoid invalid GIMPLE in GIMPLE parsing This plugs a few easy holes avoiding ICEs down the route. 2021-05-18 Richard Biener PR c/100522 gcc/c/ * gimple-parser.c (c_parser_gimple_postfix_expression_after_primary): Diagnose calls to non-functions. (c_parser_gimple_statement): Diagnose unexpected assignment RHS. gcc/testsuite/ * gcc.dg/gimplefe-error-10.c: New testcase.
[Bug c/100522] ICE: in extract_ops_from_tree, at gimple-expr.c:556
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100522 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #3 from Richard Biener --- Fixed.
[Bug libgomp/100573] [OpenMP] 'omp target teams' fails with nvptx and GCN offloading: FAIL libgomp.c-c++-common/for-3.c + for-9.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100573 --- Comment #2 from Tom de Vries --- (In reply to Tobias Burnus from comment #1) > Created attachment 50803 [details] > Reduced testcase - works with hostfall back but fails with GCN and nvptx Is this not an invalid test-case? The semantics of omp teams is: ... The teams construct creates a league of thread teams and the master thread of each team executes the region. ... So, given that there is no distribution of the work over all the teams, the master thread of each team updates the entire array. That is, is this not just a question of missing distribution keyword?
[Bug fortran/100642] [12 Regression] ICE in omp_code_to_statement, at fortran/openmp.c:6907 since r12-20-ga61c4964cd714462
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100642 Martin Liška changed: What|Removed |Added Last reconfirmed||2021-05-18 CC||burnus at gcc dot gnu.org, ||marxin at gcc dot gnu.org Summary|ICE in |[12 Regression] ICE in |omp_code_to_statement, at |omp_code_to_statement, at |fortran/openmp.c:6907 |fortran/openmp.c:6907 since ||r12-20-ga61c4964cd714462 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Started with r12-20-ga61c4964cd714462.
[Bug target/100643] [11/12 Regression] ICE in ix86_mangle_function_version_assembler_name, at config/i386/i386-features.c:2809 since r11-7693-g1c7bec8bfbc5457c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100643 Martin Liška changed: What|Removed |Added Summary|[11/12 Regression] ICE in |[11/12 Regression] ICE in |ix86_mangle_function_versio |ix86_mangle_function_versio |n_assembler_name, at|n_assembler_name, at |config/i386/i386-features.c |config/i386/i386-features.c |:2809 |:2809 since ||r11-7693-g1c7bec8bfbc5457c CC||marxin at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org --- Comment #1 from Martin Liška --- Started with my r11-7693-g1c7bec8bfbc5457c.
[Bug tree-optimization/94589] Optimize (i<=>0)>0 to i>0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94589 --- Comment #22 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:65061ea287a80cfb214e402cfd2373a14bfec95a commit r12-864-g65061ea287a80cfb214e402cfd2373a14bfec95a Author: Jakub Jelinek Date: Tue May 18 10:08:51 2021 +0200 phiopt: Optimize partial_ordering spaceship >= 0 -ffinite-math-only [PR94589] As mentioned earlier, spaceship_replacement didn't optimize partial_ordering >= 0 comparisons, because the possible values are -1, 0, 1, 2 and the >= comparison is implemented as (res & 1) == res to choose the 0 and 1 cases from that. As we optimize that only with -ffinite-math-only, the 2 case is assumed not to happen and my earlier match.pd change optimizes (res & 1) == res into (res & ~1) == 0, so this patch pattern matches that case and handles it like res >= 0. 2021-05-18 Jakub Jelinek PR tree-optimization/94589 * tree-ssa-phiopt.c (spaceship_replacement): Pattern match phi result used in (res & ~1) == 0 comparison as res >= 0 as res == 2 would be UB with -ffinite-math-only. * g++.dg/opt/pr94589-2.C: Adjust scan-tree-dump count from 14 to 12.
[Bug c++/100580] [10/11/12 Regression] ICE with -fdump-passes since r10-6837-g2473c81cb2d4627f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100580 --- Comment #3 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:978b62e554ffb4b34844c72d259ce71fcbd87591 commit r12-865-g978b62e554ffb4b34844c72d259ce71fcbd87591 Author: Jakub Jelinek Date: Tue May 18 10:10:17 2021 +0200 function: Set dummy DECL_ASSEMBLER_NAME in push_dummy_function [PR100580] Last year I've added cgraph_node::get_create calls for the dummy functions used for -fdump-passes, so that it interacts well with pass disabling/enabling which is cgraph uid based. Unfortunately, as the following testcase shows, when assembler hash is present, that wants to compute DECL_ASSEMBLER_NAME and the C++ FE is unprepared to handle it on the dummy functions which don't have DECL_NAME etc. The following patch fixes it by setting up a dummy DECL_ASSEMBLER_NAME on these, so that the FEs don't need to compute it. 2021-05-18 Jakub Jelinek PR c++/100580 * function.c (push_dummy_function): Set DECL_ARTIFICIAL and DECL_ASSEMBLER_NAME on the fn_decl. * g++.dg/other/pr100580.C: New test.
[Bug tree-optimization/94589] Optimize (i<=>0)>0 to i>0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94589 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #23 from Jakub Jelinek --- Fixed.
[Bug c++/100580] [10/11 Regression] ICE with -fdump-passes since r10-6837-g2473c81cb2d4627f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100580 Jakub Jelinek changed: What|Removed |Added Summary|[10/11/12 Regression] ICE |[10/11 Regression] ICE with |with -fdump-passes since|-fdump-passes since |r10-6837-g2473c81cb2d4627f |r10-6837-g2473c81cb2d4627f --- Comment #4 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug rtl-optimization/100590] [11/12 Regression] ICE: verify_flow_info failed (error: too many outgoing branch edges from bb 2) since r11-5002-ge3b3b59683c1e7d3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100590 --- Comment #3 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:c81704b359283bb54696755ead881ab04136da94 commit r12-866-gc81704b359283bb54696755ead881ab04136da94 Author: Jakub Jelinek Date: Tue May 18 10:26:45 2021 +0200 regcprop: Avoid DCE of asm goto [PR100590] The following testcase ICEs, because copyprop_hardreg_forward_1 decides to DCE asm goto with REG_UNUSED notes (because the output is unused and asm isn't volatile). But that DCE just removes the asm goto, leaving a bb with two successors and no insn at the end that would allow that. The following patch makes sure we drop that way only INSNs and not JUMP_INSNs or CALL_INSNs. 2021-05-18 Jakub Jelinek PR rtl-optimization/100590 * regcprop.c (copyprop_hardreg_forward_1): Only DCE dead sets if they are NONJUMP_INSN_P. * gcc.dg/pr100590.c: New test.
[Bug rtl-optimization/100590] [11 Regression] ICE: verify_flow_info failed (error: too many outgoing branch edges from bb 2) since r11-5002-ge3b3b59683c1e7d3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100590 Jakub Jelinek changed: What|Removed |Added Summary|[11/12 Regression] ICE: |[11 Regression] ICE: |verify_flow_info failed |verify_flow_info failed |(error: too many outgoing |(error: too many outgoing |branch edges from bb 2) |branch edges from bb 2) |since |since |r11-5002-ge3b3b59683c1e7d3 |r11-5002-ge3b3b59683c1e7d3 --- Comment #4 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug libgomp/100573] [OpenMP] 'omp target teams' fails with nvptx and GCN offloading: FAIL libgomp.c-c++-common/for-3.c + for-9.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100573
--- Comment #3 from Tom de Vries ---
Hmm, I reproduced the problem on the original test-case:
libgomp.c-c++-common/for-3.c, and minimized from there:
...
$ cat libgomp/testsuite/libgomp.c-c++-common/for-3.c
/* { dg-additional-options "-std=gnu99" { target c } } */
#include
extern void abort ();
#define N 1500
int a[N];
int
main (void)
{
int err = 0;
#pragma omp target map(tofrom: err) map (tofrom: a)
#pragma omp teams num_teams (15) reduction(|:err)
{
int i;
for (i = 0; i < N; i++)
a[i] = 0;
do {} while (0);
#pragma omp distribute
for (i = 0; i < N; i++)
a[i] += 2;
do {} while (0);
for (i = 0; i < N; i++)
if (a[i] != 2)
err |= 1;
}
int i;
for (i = 0; i < N; i++)
if (a[i] != 2)
printf ("a[%d]: %d\n", i, a[i]);
if (err)
abort ();
return 0;
}
...
Again, I think there's a problem with the test-case.
There's no implicit barrier at the end of a distribute construct, so we can
have:
- team 0 updates part of array
- team 0 checks entire array, finds that only it's part is done, sets error
flag
- team 1 updates part of array ...
I wonder whether there's an implicit barrier at the start of the distribute
construct. If not, then the same problem exists for the initialization.
[Bug c++/100644] [11/12 regression] Deleted move constructor prevents templated constructor from being used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100644 Jonathan Wakely changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #1 from Jonathan Wakely --- Rejected since r11-7287 c++: Tuple of self-dependent classes [PR96926] When compiling this testcase, trying to resolve the initialization for the tuple member ends up recursively considering the same set of tuple constructor overloads, and since two of them separately depend on is_constructible, the one we try second fails to instantiate is_constructible because we're still in the middle of instantiating it the first time. Fixed by implementing an optimization that someone suggested we were already doing: if we see a non-template candidate that is a perfect match for all arguments, we can skip considering template candidates at all. It would be enough to do this only when LOOKUP_DEFAULTED, but it shouldn't hurt in other cases. gcc/cp/ChangeLog: PR c++/96926 * call.c (perfect_conversion_p): New. (perfect_candidate_p): New. (add_candidates): Ignore templates after a perfect non-template.
[Bug rtl-optimization/100647] ICE during sms pass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100647 --- Comment #1 from Roman Zhuykov --- Thanks, I'll take a closer look in a few days, but this should be a dup of PR93264 (see also PR90040), which doesn't have any easy solution...
[Bug target/100648] New: Optimize away x<0 as mask argument of a blend for AVX512 mask
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100648 Bug ID: 100648 Summary: Optimize away x<0 as mask argument of a blend for AVX512 mask Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: crazylht at gmail dot com CC: hjl.tools at gmail dot com Target Milestone: --- Host: x86_64-pc-linux-gnu Target: x86_64-*-* i?86-*-* Similar to PR target/54700, but for AVX512 mask
[Bug target/100369] crash after error in gcc.target/aarch64/simd/vgetq_lane_s64_indices_1.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100369
Alex Coplan changed:
What|Removed |Added
Known to fail||12.0
CC||acoplan at gcc dot gnu.org
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
Keywords||error-recovery
Last reconfirmed||2021-05-18
--- Comment #3 from Alex Coplan ---
Confirmed. Here is a reduced testcase:
$ cat neon.c
#include
int64x2_t v;
void f() { vgetq_lane_s64(v, 2); }
$ ./arm-eabi-gcc -c neon.c -march=armv8-a+simd
In file included from neon.c:1:
In function 'vgetq_lane_s64',
inlined from 'f' at neon.c:3:12:
/home/alecop01/toolchain/build-arm-eabi-armv8.1-m.main+mve.fp+fp.dp/install/lib/gcc/arm-eabi/12.0.0/include/arm_neon.h:6313:10:
error: lane 2 out of range 0 - 1
6313 | return (int64_t)__builtin_neon_vget_lanev2di (__a, __b);
| ^~~~
during RTL pass: expand
/home/alecop01/toolchain/build-arm-eabi-armv8.1-m.main+mve.fp+fp.dp/install/lib/gcc/arm-eabi/12.0.0/include/arm_neon.h:
In function 'f':
/home/alecop01/toolchain/build-arm-eabi-armv8.1-m.main+mve.fp+fp.dp/install/lib/gcc/arm-eabi/12.0.0/include/arm_neon.h:6313:10:
internal compiler error: in gen_neon_vget_lanev2di, at config/arm/neon.md:3288
0x15f54df gen_neon_vget_lanev2di(rtx_def*, rtx_def*, rtx_def*)
/home/alecop01/toolchain/src/gcc/gcc/config/arm/neon.md:3288
0x120c3e0 rtx_insn* insn_gen_fn::operator()(rtx_def*, rtx_def*, rtx_def*) const
/home/alecop01/toolchain/src/gcc/gcc/recog.h:407
0x120c3e0 arm_expand_builtin_args
/home/alecop01/toolchain/src/gcc/gcc/config/arm/arm-builtins.c:3160
0x120c3e0 arm_expand_builtin_1
/home/alecop01/toolchain/src/gcc/gcc/config/arm/arm-builtins.c:3309
0x120d082 arm_expand_neon_builtin
/home/alecop01/toolchain/src/gcc/gcc/config/arm/arm-builtins.c:3389
0x120d082 arm_expand_builtin(tree_node*, rtx_def*, rtx_def*, machine_mode, int)
/home/alecop01/toolchain/src/gcc/gcc/config/arm/arm-builtins.c:3469
0x7ca04f expand_builtin(tree_node*, rtx_def*, rtx_def*, machine_mode, int)
/home/alecop01/toolchain/src/gcc/gcc/builtins.c:9753
0x94984d expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
/home/alecop01/toolchain/src/gcc/gcc/expr.c:11405
0x94ad22 expand_expr_real(tree_node*, rtx_def*, machine_mode, expand_modifier,
rtx_def**, bool)
/home/alecop01/toolchain/src/gcc/gcc/expr.c:8621
0x9538c7 store_expr(tree_node*, rtx_def*, int, bool, bool)
/home/alecop01/toolchain/src/gcc/gcc/expr.c:5986
0x95554a expand_assignment(tree_node*, tree_node*, bool)
/home/alecop01/toolchain/src/gcc/gcc/expr.c:5721
0x80123b expand_call_stmt
/home/alecop01/toolchain/src/gcc/gcc/cfgexpand.c:2841
0x80123b expand_gimple_stmt_1
/home/alecop01/toolchain/src/gcc/gcc/cfgexpand.c:3847
0x80123b expand_gimple_stmt
/home/alecop01/toolchain/src/gcc/gcc/cfgexpand.c:4011
0x80a339 expand_gimple_basic_block
/home/alecop01/toolchain/src/gcc/gcc/cfgexpand.c:6053
0x80b546 execute
/home/alecop01/toolchain/src/gcc/gcc/cfgexpand.c:6737
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug libgomp/100573] [OpenMP] 'omp target teams' fails with nvptx and GCN offloading: FAIL libgomp.c-c++-common/for-3.c + for-9.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100573
--- Comment #4 from Jakub Jelinek ---
(In reply to Tom de Vries from comment #3)
> Hmm, I reproduced the problem on the original test-case:
> libgomp.c-c++-common/for-3.c, and minimized from there:
> ...
> $ cat libgomp/testsuite/libgomp.c-c++-common/for-3.c
> /* { dg-additional-options "-std=gnu99" { target c } } */
>
> #include
> extern void abort ();
>
> #define N 1500
>
> int a[N];
>
> int
> main (void)
> {
> int err = 0;
>
> #pragma omp target map(tofrom: err) map (tofrom: a)
> #pragma omp teams num_teams (15) reduction(|:err)
> {
> int i;
>
> for (i = 0; i < N; i++)
> a[i] = 0;
Even this loop is a problem because every initial thread in its team
clears the whole array.
>
> do {} while (0);
>
> #pragma omp distribute
> for (i = 0; i < N; i++)
> a[i] += 2;
>
> do {} while (0);
And this of course too.
>
> for (i = 0; i < N; i++)
> if (a[i] != 2)
> err |= 1;
> }
I think we want to fix both for-3.c and for-9.c similarly to
r11-2571-g916c7a201a9a1dc94f2c056a773826a26d1daca9
i.e.
#define DO_PRAGMA(x) _Pragma (#x)
#define OMPTEAMS DO_PRAGMA (omp target teams)
#define OMPFROM(v) DO_PRAGMA (omp target update from(v))
#define OMPTO(v) DO_PRAGMA (omp target update to(v))
and changing main not to do #pragma omp target teams reduction(|:err)
[Bug target/100369] crash after error in gcc.target/aarch64/simd/vgetq_lane_s64_indices_1.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100369 Alex Coplan changed: What|Removed |Added Known to fail||10.3.0, 11.1.0, 9.3.0 --- Comment #4 from Alex Coplan --- I can reproduce it back to GCC 8 (not a regression).
[Bug middle-end/100593] [ELF] -fno-pic: Use GOT to take address of an external default visibility function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100593
--- Comment #7 from Alexander Monakov ---
Thanks. I agree that inferring address significance on the linker side is
problematic.
Thinking about your original request, I was about to say that it would be very
reasonable to do under -fno-plt flag, but then I found it was already
implemented for x86-64 in gcc-7 and for 32-bit x86 in gcc-8. Compiling
int f();
void *g()
{
return f;
}
with -fno-pic -fno-plt yields
g:
movqf@GOTPCREL(%rip), %rax
ret
(yields GOTPCRELX relocation) and
g:
movlf@GOT, %eax
ret
on 32-bit (yields GOT32X relocation), so on x86 it's already implemented?
[Bug libgomp/100573] [OpenMP] 'omp target teams' fails with nvptx and GCN offloading: FAIL libgomp.c-c++-common/for-3.c + for-9.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100573 --- Comment #5 from Jakub Jelinek --- The intent of this particular test is to test how orphaned distribute works and was done before the host teams construct support has been added, which means we do not want the target teams visible in the individual functions.
[Bug tree-optimization/100499] Different results with -fpeel-loops -ftree-loop-vectorize options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100499 --- Comment #10 from Richard Biener --- (In reply to bin cheng from comment #9) > Seems we have a long standing bug in fold-const.c:multiple_of_p in case of > wrapping types. Take unsigned int as an example: > (0xfffc * 0x3) % 0x3 = 0x1 > But multiple_of_p returns true here. > > The same issue also stands for MINUS_EXPR and PLUS_EXPR. Given > multiple_of_p is used elsewhere, the fix might break existing optimizations. > Especially, number of loop iterations is computed in unsigned types multiple_of_p is mostly used in contexts where overflow "cannot happen" (in TYPE/DECL_SIZE computation context), and in niter analysis it seems to be guarded similarly. This restriction of multiple_of_p seems undocumented, so fixing that might be good. Now, you don't say what's the chain of events that lead to a multiple_of_p call eventually leading to the wrong answer, but I guess it's the code added under the + if (!niter->control.no_overflow + && (integer_onep (s) || multiple_of_p (type, c, s))) check as !niter->control.no_overflow seems to suggest that the multiple_of_p check is not properly guarded?
[Bug other/100598] [12 Regression] MinGW Canadian cross toolchain fails to build due to missing BASEVER in genversion.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100598
--- Comment #4 from CVS Commits ---
The master branch has been updated by Tobias Burnus :
https://gcc.gnu.org/g:5116b54e4644cb0d7b99891c76f8f015097f6530
commit r12-872-g5116b54e4644cb0d7b99891c76f8f015097f6530
Author: Tobias Burnus
Date: Tue May 18 11:56:05 2021 +0200
gcc/configure.ac: Fix cross build by using $(CFLAGS-$@) [PR100598]
BUILD_CFLAGS is set by configure; by default, BUILD_CFLAGS = $(ALL_CFLAGS)
is used. The latter contains (see gcc/Makefile.in) $(CFLAGS-$@), which is
used
to pass .o-file specific flags to the compiler.
For cross builds, BUILD_CFLAGS is constructed in configure{,.ac} and missed
the $(CFLAGS-$@) - despite the comment above ALL_CFLAGS that configure.ac
might have to kept in sync.
gcc/ChangeLog:
PR other/100598
* configure: Regenerate.
* configure.ac (BUILD_CFLAG, BUILD_CXXFLAGS): Add $(CFLAGS-$@).
[Bug tree-optimization/100499] Different results with -fpeel-loops -ftree-loop-vectorize options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100499
Richard Biener changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
||law at gcc dot gnu.org
--- Comment #11 from Richard Biener ---
But there's still
int
multiple_of_p (tree type, const_tree top, const_tree bottom)
{
...
case NOP_EXPR:
/* Can't handle conversions from non-integral or wider integral type. */
if ((TREE_CODE (TREE_TYPE (TREE_OPERAND (top, 0))) != INTEGER_TYPE)
|| (TYPE_PRECISION (type)
< TYPE_PRECISION (TREE_TYPE (TREE_OPERAND (top, 0)
return 0;
/* fall through */
case SAVE_EXPR:
return multiple_of_p (type, TREE_OPERAND (top, 0), bottom);
which makes guards like
|| (TYPE_OVERFLOW_UNDEFINED (type)
&& multiple_of_p (type, c, s)))
break for say multiple_of_p (int, (int)(unsigned)(x*s), s). So it's a bit
fishy in the end ... :/
Jeff originally introduced multiple_of_p, maybe he remembers something.
[Bug other/100598] [12 Regression] MinGW Canadian cross toolchain fails to build due to missing BASEVER in genversion.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100598 Martin Liška changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #5 from Martin Liška --- Should be fixed now.
[Bug tree-optimization/100499] Different results with -fpeel-loops -ftree-loop-vectorize options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100499 Richard Biener changed: What|Removed |Added CC||aldyh at gcc dot gnu.org --- Comment #12 from Richard Biener --- So in number_of_iterations_ne it looks like the step 's' is always constant which makes me wonder if we can somehow use ranger to tell multiple_of_p (type, c, s) or at least whether, if c is x * s, the multiplication could have overflowed?
[Bug tree-optimization/100499] Different results with -fpeel-loops -ftree-loop-vectorize options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100499 --- Comment #13 from bin cheng --- (In reply to Richard Biener from comment #10) > (In reply to bin cheng from comment #9) > > Seems we have a long standing bug in fold-const.c:multiple_of_p in case of > > wrapping types. Take unsigned int as an example: > > (0xfffc * 0x3) % 0x3 = 0x1 > > But multiple_of_p returns true here. > > > > The same issue also stands for MINUS_EXPR and PLUS_EXPR. Given > > multiple_of_p is used elsewhere, the fix might break existing optimizations. > > Especially, number of loop iterations is computed in unsigned types > > multiple_of_p is mostly used in contexts where overflow "cannot happen" > (in TYPE/DECL_SIZE computation context), and in niter analysis it seems to > be guarded similarly. This restriction of multiple_of_p seems undocumented, Oh, I am not aware of this. Actually my previous change to it seems broke this assumption already. Will see how to fix or revert the change. > so fixing that might be good. > > Now, you don't say what's the chain of events that lead to a multiple_of_p > call > eventually leading to the wrong answer, but I guess it's the code added > under the > > + if (!niter->control.no_overflow > + && (integer_onep (s) || multiple_of_p (type, c, s))) > > check as !niter->control.no_overflow seems to suggest that the multiple_of_p > check is not properly guarded?
[Bug tree-optimization/100499] Different results with -fpeel-loops -ftree-loop-vectorize options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100499 --- Comment #14 from bin cheng --- (In reply to Richard Biener from comment #12) > So in number_of_iterations_ne it looks like the step 's' is always constant > which makes me wonder if we can somehow use ranger to tell multiple_of_p > (type, c, s) > or at least whether, if c is x * s, the multiplication could have overflowed? Yeah, I am looking if "multiple of" can be feasibly checked in niter analysis, with help of some basic information from multiple_of_p. BTW, I am not following changes in "ranger", how should I used in analysis? or similar to value range info? Thanks
[Bug c++/100649] New: ICE in coerce_template_parms (releases) or cxx_eval_constant_expression (trunk)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100649
Bug ID: 100649
Summary: ICE in coerce_template_parms (releases) or
cxx_eval_constant_expression (trunk)
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ebotcazou at gcc dot gnu.org
Target Milestone: ---
The compiler ICEs either in coerce_template_parms for releases:
t.cpp: In member function 'void B::foo(const A<32>&)':
t.cpp:12:24: internal compiler error: in coerce_template_parms, at cp/pt.c:9082
12 | A<2 + mesg.size()> local_mesg;
|^
0x6267e6 coerce_template_parms
/home/eric/cvs/gcc-11/gcc/cp/pt.c:9082
or in cxx_eval_constant_expression on the trunk:
t.cpp: In member function 'void B::foo(const A<32>&)':
t.cpp:12:24: internal compiler error: in cxx_eval_constant_expression, at
cp/constexpr.c:6622
12 | A<2 + mesg.size()> local_mesg;
|^
0x651967 cxx_eval_constant_expression
/home/eric/cvs/gcc/gcc/cp/constexpr.c:6622
for the following testcase:
template
struct A
{
constexpr int size () const { return N; }
};
template
struct B
{
void foo (const A<32> &mesg)
{
A<2 + mesg.size()> local_mesg;
}
};
The code is correctly rejected when the 2nd template declaration is removed:
t.cpp: In member function 'void B::foo(const A<32>&)':
t.cpp:12:24: error: 'mesg' is not a constant expression
12 | A<2 + mesg.size()> local_mesg;
|^
t.cpp:12:11: note: in template argument for type 'int'
12 | A<2 + mesg.size()> local_mesg;
| ~~^
[Bug tree-optimization/100499] Different results with -fpeel-loops -ftree-loop-vectorize options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100499
--- Comment #15 from rguenther at suse dot de ---
On Tue, 18 May 2021, amker at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100499
>
> --- Comment #14 from bin cheng ---
> (In reply to Richard Biener from comment #12)
> > So in number_of_iterations_ne it looks like the step 's' is always constant
> > which makes me wonder if we can somehow use ranger to tell multiple_of_p
> > (type, c, s)
> > or at least whether, if c is x * s, the multiplication could have
> > overflowed?
>
> Yeah, I am looking if "multiple of" can be feasibly checked in niter analysis,
> with help of some basic information from multiple_of_p.
>
> BTW, I am not following changes in "ranger", how should I used in analysis? or
> similar to value range info?
I'm not sure - let's see if the ranger folks have any good idea here.
Btw, there's tree_ctz which looks more conservative and could be used
for power-of-two 's'. split_constant_offset also recently got
refactoring to avoid a plethora of overflow issues it ran into,
so we can eventually improve multiple_of_p to be correct without
pre-conditions. But I fear that for DECL_SIZE & friends where
we "know" that multiplications by 8 to get from byte to bit size
do not overflow we cannot be too conservative here. Maybe in the
end we need to distinguish those with new MULT_NO_OVERFLOW,
PLUS_NO_OVERFLOW, etc. When creating those expressions we should
already be using size_{bin,un}op. The conversion handling of course
still looks bogus to me even in this context.
[Bug libstdc++/100361] gcc-11 for msp430-elf fails to build: src/c++17/floating_to_chars.cc:107: d2fixed_full_table.h:1283:23: error: size of array ‘POW10_SPLIT_2’ exceeds maximum object size ‘32767’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100361 Jorn Wolfgang Rennecke changed: What|Removed |Added CC||amylaar at gcc dot gnu.org Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2021-05-18 --- Comment #1 from Jorn Wolfgang Rennecke --- I also see this for 16 bit eSi-RISC targets. This array can't fit into a 16 bit address space that addresses 8 bit units.
[Bug jit/95325] Support 128-bit integers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95325 --- Comment #1 from Antoni --- Created attachment 50835 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50835&action=edit Patch add support for sized integer types That patch not only add support for 128-bit integers, but also all other sized integers.
[Bug fortran/100650] New: Passing a derived-type array constructor to the reshape intrinsic gives incorrect results
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100650 Bug ID: 100650 Summary: Passing a derived-type array constructor to the reshape intrinsic gives incorrect results Product: gcc Version: 11.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: here.is.a.gcc.bug at gmail dot com Target Milestone: --- Created attachment 50836 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50836&action=edit A minimum broken example. Needs no special compiler flags. A type `String` has a `character(:), allocatable` component. When an array constructor of type `String` is passed to the reshape intrinsic, the components of the resulting array are incorrect. The bug does not trigger if the array constructor is used to create a named array and this named array is passed to the reshape intrinsic. This affects at least versions 7.4.0, 10.1.0 and 11.1.1 of gfortran.
[Bug libstdc++/100361] gcc-11 for msp430-elf fails to build: src/c++17/floating_to_chars.cc:107: d2fixed_full_table.h:1283:23: error: size of array ‘POW10_SPLIT_2’ exceeds maximum object size ‘32767’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100361 Jonathan Wakely changed: What|Removed |Added CC||ppalka at gcc dot gnu.org --- Comment #2 from Jonathan Wakely --- Patrick, is the table an optimization, or essential? We might be able to avoid it, but he functions would be much slower. Maybe we should just disable the floating-point to_chars for 16-bit targets.
[Bug analyzer/100546] -Wanayzer-null-dereference false positive through noreturn function pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100546 David Malcolm changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2021-05-18 Status|UNCONFIRMED |ASSIGNED --- Comment #1 from David Malcolm --- The "noreturn"-ness of the function pointer is affected by attributes. Hence if you add the attribute to the function pointer type, the warning goes away: void (*noReturnPtr)(const char *str) __attribute__((noreturn)) = &noReturn; That said, given that we're in "main", the analyzer ought to figure out that noReturnPtr can't have been changed by the point of the call, and for some reason it's not doing that; am investigating.
[Bug debug/78685] -Og generates too many ""s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78685 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org, ||fredrik at dolda2000 dot com, ||john.carter at taitradio dot com, ||marxin at gcc dot gnu.org, ||philipp.lucas at siemens dot com, ||yuxian.chen at intel dot com --- Comment #19 from Eric Gallager --- This bug came up on the gcc-help mailing list here: https://gcc.gnu.org/pipermail/gcc-help/2021-May/140304.html ...and, while I'm here, let me update a few things... (In reply to rsand...@gcc.gnu.org from comment #18) > (In reply to Eric Gallager from comment #17) > > Richard Sandiford had a series of patches radically overhauling how -Og > > works in general that might affect this bug: > > https://gcc.gnu.org/ml/gcc-patches/2019-06/msg01392.html > > cc-ing him so he can comment on if it does in fact affect this bug. > > Yeah, part 2 of the series fixes this PR: > https://gcc.gnu.org/ml/gcc-patches/2019-06/msg01394.html Has this series been merged yet? Or at least pinged recently? (also, I'm redoing some CCs that seem to have been accidentally removed from the CC list without showing up in the bug history as having been removed; presumably this was from the server migration...)
[Bug libstdc++/100361] gcc-11 for msp430-elf fails to build: src/c++17/floating_to_chars.cc:107: d2fixed_full_table.h:1283:23: error: size of array ‘POW10_SPLIT_2’ exceeds maximum object size ‘32767’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100361 --- Comment #3 from Patrick Palka --- (In reply to Jonathan Wakely from comment #2) > Patrick, is the table an optimization, or essential? We might be able to > avoid it, but he functions would be much slower. The tables are essential for Ryu's d2exp_buffered_n and d2fixed_buffered_n routines, which we use for fast explicit-precision formatting of float/double. > > Maybe we should just disable the floating-point to_chars for 16-bit targets. Agreed.. though in theory we could just go through printf as a fallback for d2exp_buffered_n and d2fixed_buffered_n on these targets. Btw, we already disable the floating-point to_chars on targets without a binary64 double. So is our test for detecting binary64 not accurate enough, or are these 16-bit targets whose double type really is binary64?
[Bug libstdc++/100361] gcc-11 for msp430-elf fails to build: src/c++17/floating_to_chars.cc:107: d2fixed_full_table.h:1283:23: error: size of array ‘POW10_SPLIT_2’ exceeds maximum object size ‘32767’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100361 --- Comment #4 from Jorn Wolfgang Rennecke --- Created attachment 50837 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50837&action=edit Proposed patch This patch fixes the problem for eSi-RISC and bootstraps on x86_64-pc-linux-gnu , with floating_to_chars.o properly built in each stage. Could you check that this also works for msp430?
[Bug target/100626] [11/12 Regression] ICE Segmentation fault (during RTL pass: split1) since r11-165-geb72dc663e9070b2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100626 --- Comment #6 from CVS Commits --- The master branch has been updated by Uros Bizjak : https://gcc.gnu.org/g:d39fbed75810fc7478842503ecb0268b85dc9c2e commit r12-878-gd39fbed75810fc7478842503ecb0268b85dc9c2e Author: Uros Bizjak Date: Tue May 18 15:45:54 2021 +0200 i386: Fix split_double_mode with paradoxical subreg [PR100626] split_double_mode calls simplify_gen_subreg, which fails for the high half of the paradoxical subreg. Return temporary register instead of NULL RTX in this case. 2021-05-18 Uroš Bizjak gcc/ PR target/100626 * config/i386/i386-expand.c (split_double_mode): Return temporary register when simplify_gen_subreg fails with the high half od the paradoxical subreg.
[Bug libstdc++/100631] ranges::elements_view:: _Sentinel is missing __distance_from() that can access _M_current of _Iterator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100631
--- Comment #8 from Patrick Palka ---
(In reply to 康桓瑋 from comment #7)
> (In reply to CVS Commits from comment #6)
> > The master branch has been updated by Patrick Palka :
> >
> > https://gcc.gnu.org/g:2e2eef80ac0c21f9533e6791ccf5e29458cbb77c
> >
> > commit r12-854-g2e2eef80ac0c21f9533e6791ccf5e29458cbb77c
> > Author: Patrick Palka
> > Date: Tue May 18 00:26:07 2021 -0400
> >
> > libstdc++: Fix miscellaneous issues with elements_view::_Sentinel
> > [PR100631]
> >
> > libstdc++-v3/ChangeLog:
> >
> > PR libstdc++/100631
> > * include/std/ranges (elements_view::_Iterator): Also befriend
> > _Sentinel.
> > (elements_view::_Sentinel::_M_equal): Templatize.
> > (elements_view::_Sentinel::_M_distance_from): Split out from ...
> > (elements_view::_Sentinel::operator-): ... here. Depend on
> > _Base2 instead of _Base in the return type.
> > * testsuite/std/ranges/adaptors/elements.cc (test06, test07):
> > New tests.
>
>
>
> Hey, Patrick, you missed the second one:
>
>
> template typename _Base2 = __detail::__maybe_const_t<_Const2, _Vp>>
> requires sized_sentinel_for, iterator_t<_Base2>>
> friend constexpr range_difference_t<_Base2>
> operator-(const _Iterator<_Const2>& __x, const _Sentinel& __y)
> { return __x._M_current - __y._M_end; }
>
>
> this should be return -__y._M_distance_from(__x).
Indeed, thanks for catching that. Fix incoming shortly..
[Bug libstdc++/100361] gcc-11 for msp430-elf fails to build: src/c++17/floating_to_chars.cc:107: d2fixed_full_table.h:1283:23: error: size of array ‘POW10_SPLIT_2’ exceeds maximum object size ‘32767’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100361 --- Comment #5 from Jorn Wolfgang Rennecke --- (In reply to Patrick Palka from comment #3) > Btw, we already disable the floating-point to_chars on targets without a > binary64 double. So is our test for detecting binary64 not accurate enough, > or are these 16-bit targets whose double type really is binary64? At least in the case of eSi-RISC, it is the latter.
[Bug libstdc++/100361] gcc-11 for msp430-elf fails to build: src/c++17/floating_to_chars.cc:107: d2fixed_full_table.h:1283:23: error: size of array ‘POW10_SPLIT_2’ exceeds maximum object size ‘32767’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100361 --- Comment #6 from Jonathan Wakely --- That patch isn't OK, because the declarations in would still be present, but using them would give linker errors. I think we should just check __SIZE_WIDTH__ < 32 (in that .cc file and in the header). If somebody wants to contribute an implementation that doesn't use the tables and trades off time for space then we can support them, but I don't think that's a good use of Patrick's time.
[Bug fortran/100651] New: Weird memory corruption with multiple triggers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100651 Bug ID: 100651 Summary: Weird memory corruption with multiple triggers Product: gcc Version: 11.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: matthew.thompson at nasa dot gov Target Milestone: --- Created attachment 50838 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50838&action=edit Reproducing program This is a bug that is tripped by GCC 9.3.0, 10.1.0, and 11.1.0 (at least, but I only have access to those) on Linux and macOS. For the rest of this bug report, I'll be using macOS (as it's my main workstation). First: ❯ gfortran -v Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/Users/mathomp4/installed/Core/gcc-gfortran/11.1.0/libexec/gcc/x86_64-apple-darwin19.6.0/11.1.0/lto-wrapper Target: x86_64-apple-darwin19.6.0 Configured with: ../gcc-11.1.0/configure --prefix=/Users/mathomp4/installed/Core/gcc-gfortran/11.1.0 --enable-languages=c,c++,fortran --with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk Thread model: posix Supported LTO compression algorithms: zlib gcc version 11.1.0 (GCC) If you compile and run (NOTE: the -g -O0 is not necessary, I only use it to make the traceback a bit better): ❯ gfortran -g -O0 opt_string.F90 ❯ ./a.out opt_string.F90 122 T opt_string.F90 123 542594713 a.out(15473,0x1129d4e00) malloc: can't allocate region :*** mach_vm_map(size=140733735985152, flags: 100) failed (error code=3) a.out(15473,0x1129d4e00) malloc: *** set a breakpoint in malloc_error_break to debug Operating system error: Cannot allocate memory Memory allocation failure in xrealloc Error termination. Backtrace: #0 0x103249de2 in ??? #1 0x10324aab5 in ??? #2 0x10324acb3 in ??? #3 0x10324939a in ??? #4 0x10347a455 in ??? #5 0x10346bb99 in ??? #6 0x1034740a7 in ??? #7 0x1034792be in ??? #8 0x10347a237 in ??? #9 0x103231c2d in __test_intnode_MOD_test_casting_fail at /Users/mathomp4/F90Files/TomOptStringGCCBug/opt_string.F90:124 #10 0x103231c5c in MAIN__ at /Users/mathomp4/F90Files/TomOptStringGCCBug/opt_string.F90:135 #11 0x103231c98 in main at /Users/mathomp4/F90Files/TomOptStringGCCBug/opt_string.F90:132 The (runtime) error disappears if *any* of the following 3 lines are commented out/deleted: * Line 31 (generic assignment) * Line 85 (unused component of a derived type) * Line 121 (unused local variable) On Linux the output is: $ ./a.out opt_string.F90 122 T opt_string.F90 123 -1431350024 Operating system error: Cannot allocate memory Memory allocation failure in xrealloc Error termination. Backtrace: #0 0x2af20a07 in write_character at ../../../gcc-11.1.0/libgfortran/io/write.c:1416 #1 0x2af25ba6 in list_formatted_write_scalar at ../../../gcc-11.1.0/libgfortran/io/write.c:1900 #2 0x400cef in __test_intnode_MOD_test_casting_fail at /home/mathomp4/F90Files/TomOptStringGCCBug/opt_string.F90:124 #3 0x400d1e in MAIN__ at /home/mathomp4/F90Files/TomOptStringGCCBug/opt_string.F90:135 #4 0x400d55 in main at /home/mathomp4/F90Files/TomOptStringGCCBug/opt_string.F90:132
[Bug libstdc++/100631] ranges::elements_view:: _Sentinel is missing __distance_from() that can access _M_current of _Iterator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100631 --- Comment #9 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:38751c4d5e15bd1c682ac4c868a2c4ce48ca5503 commit r12-880-g38751c4d5e15bd1c682ac4c868a2c4ce48ca5503 Author: Patrick Palka Date: Tue May 18 10:21:27 2021 -0400 libstdc++: Fix access issue in elements_view::_Sentinel [PR100631] In the earlier commit r12-854 I forgot to also rewrite the other operator- overload in terms of the split-out member function _M_distance_from. libstdc++-v3/ChangeLog: PR libstdc++/100631 * include/std/ranges (elements_view::_Sentinel::operator-): Use _M_distance_from in the other operator- overload too. * testsuite/std/ranges/adaptors/elements.cc (test06): Augment test.
[Bug libstdc++/100361] gcc-11 for msp430-elf fails to build: src/c++17/floating_to_chars.cc:107: d2fixed_full_table.h:1283:23: error: size of array ‘POW10_SPLIT_2’ exceeds maximum object size ‘32767’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100361 Jorn Wolfgang Rennecke changed: What|Removed |Added Attachment #50837|0 |1 is obsolete|| --- Comment #7 from Jorn Wolfgang Rennecke --- Created attachment 50839 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50839&action=edit Amended patch This patch also disables the affected tests.
[Bug fortran/100642] [12 Regression] ICE in omp_code_to_statement, at fortran/openmp.c:6907 since r12-20-ga61c4964cd714462
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100642 --- Comment #2 from CVS Commits --- The master branch has been updated by Tobias Burnus : https://gcc.gnu.org/g:cc193ac840d58ee0ffb57b14b542706cde3db0e7 commit r12-881-gcc193ac840d58ee0ffb57b14b542706cde3db0e7 Author: Tobias Burnus Date: Tue May 18 16:40:45 2021 +0200 Fortran/OpenMP: Add missing EXEC_OMP_DEPOBJ case val [PR100642] PR fortran/100642 gcc/fortran/ChangeLog: * openmp.c (omp_code_to_statement): Add missing EXEC_OMP_DEPOBJ. gcc/testsuite/ChangeLog: * gfortran.dg/goacc-gomp/depobj.f90: New test.
[Bug c++/100649] [9/10/11/12 Regression] ICE in coerce_template_parms (releases) or cxx_eval_constant_expression (trunk)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100649 Marek Polacek changed: What|Removed |Added Target Milestone|--- |9.4 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 Keywords||ice-on-invalid-code Last reconfirmed||2021-05-18 Summary|ICE in |[9/10/11/12 Regression] ICE |coerce_template_parms |in coerce_template_parms |(releases) or |(releases) or |cxx_eval_constant_expressio |cxx_eval_constant_expressio |n (trunk) |n (trunk) Status|UNCONFIRMED |NEW --- Comment #1 from Marek Polacek --- Confirmed. Compiled without errors with GCC 7.
[Bug c++/100649] [9/10/11/12 Regression] ICE in coerce_template_parms (releases) or cxx_eval_constant_expression (trunk)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100649 --- Comment #2 from Marek Polacek --- The ICE appeared with r251423.
[Bug c++/100649] [9/10/11/12 Regression] ICE in coerce_template_parms (releases) or cxx_eval_constant_expression (trunk)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100649 Marek Polacek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Marek Polacek --- Oh, it's a dup. *** This bug has been marked as a duplicate of bug 87765 ***
[Bug c++/87765] Internal compiler error: coerce_template_parms (8.2) or cxx_eval_constant_expression (trunk)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87765 Marek Polacek changed: What|Removed |Added CC||ebotcazou at gcc dot gnu.org --- Comment #7 from Marek Polacek --- *** Bug 100649 has been marked as a duplicate of this bug. ***
[Bug c++/100652] New: Uexpanded parameter pack in partial specialization of variable template not rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100652
Bug ID: 100652
Summary: Uexpanded parameter pack in partial specialization of
variable template not rejected
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ppalka at gcc dot gnu.org
Target Milestone: ---
template struct A { };
template inline constexpr bool is_a = false;
template inline constexpr bool is_a> = true;
GCC silently accepts the above testcase and doesn't diagnose the unexpanded
parameter pack Ts inside the partial specialization of 'is_a'.
[Bug fortran/100642] [12 Regression] ICE in omp_code_to_statement, at fortran/openmp.c:6907 since r12-20-ga61c4964cd714462
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100642 Tobias Burnus changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Tobias Burnus --- FIXED. Thanks for this and the many other reports!
[Bug c++/100649] [9/10/11/12 Regression] ICE in coerce_template_parms (releases) or cxx_eval_constant_expression (trunk)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100649 --- Comment #4 from Eric Botcazou --- > Confirmed. Compiled without errors with GCC 7. The error is properly issued in C++11 mode (-std=c++11): t.cpp: In member function 'void B::foo(const A<32>&)': t.cpp:12:23: error: 'mesg' is not a constant expression 12 | A<2 + mesg.size()> local_mesg; | ^
[Bug c++/100652] Unexpanded parameter pack in partial specialization of variable template not rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100652 Marek Polacek changed: What|Removed |Added Keywords||accepts-invalid Last reconfirmed||2021-05-18 Summary|Uexpanded parameter pack in |Unexpanded parameter pack |partial specialization of |in partial specialization |variable template not |of variable template not |rejected|rejected Status|UNCONFIRMED |NEW CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Confirmed.
[Bug tree-optimization/100653] New: usage of scalar_storage_order produces incorrect result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100653 Bug ID: 100653 Summary: usage of scalar_storage_order produces incorrect result Product: gcc Version: 11.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: jan.smets at nokia dot com Target Milestone: --- Created attachment 50840 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50840&action=edit scalar_storage_order test case Attached test case produces invalid results with -O2, good with -O1. Known to fail : 11.1 10.3 9.3 8.5 7.5 Known to work: 6.5 Target: x86_64-linux-gnu $ gcc test.c -o /tmp/test -O2 -Wall -Wextra && /tmp/test a0a1e01 EQ? 11e0a0a 0 $ gcc test.c -o /tmp/test -O1 -Wall -Wextra && /tmp/test a0a1e01 EQ? a0a1e01 1 Thank you
[Bug target/100637] [i386] Vectorize 4-byte vectors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100637 --- Comment #2 from CVS Commits --- The master branch has been updated by Uros Bizjak : https://gcc.gnu.org/g:46ca31d65092e5afcef292f807fcf14c5363280d commit r12-883-g46ca31d65092e5afcef292f807fcf14c5363280d Author: Uros Bizjak Date: Tue May 18 17:25:54 2021 +0200 i386: Implement 4-byte vector support [PR100637] Add infrastructure, logic and arithmetic support for 4-byte vectors. These can be used with SSE2 targets, where movd instructions from/to XMM registers are available. x86_64 ABI passes 4-byte vectors in integer registers, so also add logic operations with integer registers. 2021-05-18 Uroš Bizjak gcc/ PR target/100637 * config/i386/i386.h (VALID_SSE2_REG_MODE): Add V4QI and V2HI modes. (VALID_INT_MODE_P): Ditto. * config/i386/mmx.md (VI_32): New mode iterator. (mmxvecsize): Handle V4QI and V2HI. (Yv_Yw): Ditto. (mov): New expander. (*mov_internal): New insn pattern. (movmisalign): New expander. (neg): New expander. (3): New expander. (*3): New insn pattern. (mulv2hi3): New expander. (*mulv2hi3): New insn pattern. (one_cmpl2): New expander. (*andnot3): New insn pattern. (3): New expander. (*3): New insn pattern. gcc/testsuite/ PR target/100637 * gcc.target/i386/pr100637-1b.c: New test. * gcc.target/i386/pr100637-1w.c: Ditto. * gcc.target/i386/pr92658-avx2-2.c: Do not XFAIL scan for pmovsxbq. * gcc.target/i386/pr92658-avx2.c: Do not XFAIL scan for pmovzxbq. * gcc.target/i386/pr92658-avx512vl.c: Do not XFAIL scan for vpmovdb. * gcc.target/i386/pr92658-sse4-2.c: Do not XFAIL scan for pmovsxbd and pmovsxwq. * gcc.target/i386/pr92658-sse4.c: Do not XFAIL scan for pmovzxbd and pmovzxwq.
[Bug debug/78685] -Og generates too many ""s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78685 --- Comment #20 from rsandifo at gcc dot gnu.org --- (In reply to Eric Gallager from comment #19) > (In reply to rsand...@gcc.gnu.org from comment #18) > > (In reply to Eric Gallager from comment #17) > > > Richard Sandiford had a series of patches radically overhauling how -Og > > > works in general that might affect this bug: > > > https://gcc.gnu.org/ml/gcc-patches/2019-06/msg01392.html > > > cc-ing him so he can comment on if it does in fact affect this bug. > > > > Yeah, part 2 of the series fixes this PR: > > https://gcc.gnu.org/ml/gcc-patches/2019-06/msg01394.html > > Has this series been merged yet? Or at least pinged recently? It was only an RFC and wasn't ready for inclusion. There didn't seem to be much support for the idea so TBH I've mostly dropped it.
[Bug tree-optimization/100499] Different results with -fpeel-loops -ftree-loop-vectorize options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100499 Andrew Macleod changed: What|Removed |Added CC||msebor at gcc dot gnu.org --- Comment #16 from Andrew Macleod --- Aldy and I are discussing this. Ranger itself can't do anything outside of the gimple IL, its effectively just a GIMPLE interface to range-ops. ... but I don't think it would be hard to add a range-ops expression evaluator. I notice the multiple_of_p's "top" argument is an expression tree ie: g_2823_lsm.5_13 * 7854 + 57682 We could add an expression evaluator that can walk that expression, invoking range-ops on each expression, and calling a ranger instance to evaluate a range for any ssa_name it finds. It would bail if there are unknown tree-codes to range-ops. I don't think this is a particularly difficult thing to do, but by itself doesn't really tell you if an overflow is possible Once we can evaluate an expression outside of the IL like this, it would also not be difficult to then evaluate the expression in an increased precision. We could cast the range at each point of the evaluation to the increased precision and invoke range-ops on that range. We could tell at any point if an overflow is possible because the increased precision calculation would be different than the original. so the original expression is in 16 bit math, and if it was evaluated as [0, 65535] * [7854, 7854] + [57682, 57682] in 32 bit precision, it would come back with the answer [57682, 514769572]. Casting the final original value to 32 bit would yield a different result, and we could conclude than an overflow is possible. Would this be useful? and would it solve this problem? I'm sure there are other details to work out related to the increased precision, but it seems like it might work? I think Martin Sebor was also interested in something along these lines so I'm CC ing him. I think he wanted to do this within the IL for some of his warnings.. but I think something similar is feasible with an IL walk rather than expression walk.
[Bug c++/100644] [11/12 regression] Deleted move constructor prevents templated constructor from being used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100644 Jason Merrill changed: What|Removed |Added Last reconfirmed||2021-05-18 Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Ever confirmed|0 |1
[Bug c++/100205] [11/12 Regression] error: invalid use of non-static data member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100205 Jason Merrill changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug bootstrap/100654] New: trunk bootstrap errors with -O0 and -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100654 Bug ID: 100654 Summary: trunk bootstrap errors with -O0 and -O1 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: manfred99 at gmx dot ch Target Milestone: --- linux x86_64 and i686 (GCC 7.5 as bootstrap compiler), with BOOT_CFLAGS="-O0 -g": ../../gcc-trunk-source/gcc/gcc/opts.c: In function 'void print_filtered_help(unsigned int, unsigned int, unsigned int, unsigned int, gcc_options*, unsigned int)': ../../gcc-trunk-source/gcc/gcc/opts.c:1406:26: error: ' ' directive output may be truncated writing 2 bytes into a region of size between 1 and 256 [-Werror=format-truncation=] 1406 | "%s %s", help, _(use_diagnosed_msg)); | ^~ ../../gcc-trunk-source/gcc/gcc/opts.c:1405:22: note: 'snprintf' output 3 or more bytes (assuming 258) into a destination of size 256 1405 | snprintf (new_help, sizeof new_help, | ~^~~ 1406 | "%s %s", help, _(use_diagnosed_msg)); | ~ last successful bootstrap for my daily builds with "-O0" was 99e8df7a4cc0bb1bfa49e69ccb0f7e02c9755e3c (2021-05-05). with BOOT_CFLAGS="-O1 -g": ../../gcc-trunk-source/gcc/gcc/gimplify.c: In function 'gimplify_status gimplify_omp_loop(tree_node**, gimple**)': ../../gcc-trunk-source/gcc/gcc/gimplify.c:12967:17: error: 'last' may be used uninitialized in this function [-Werror=maybe-uninitialized] 12967 | if (pass != last) | ^~ trunk builds fine with "-O2" however.
[Bug c++/100367] [11/12 Regression] Internal compiler error when std::lexicographical_compare_three_way third and fourth argument are reverse iterators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100367 Jason Merrill changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug analyzer/100615] analyzer failed to report leak in rxtxcpu's parse_cpu_list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100615 --- Comment #2 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:cd323d97d0592135ca4345701ef051659d8d4507 commit r12-884-gcd323d97d0592135ca4345701ef051659d8d4507 Author: David Malcolm Date: Tue May 18 12:29:58 2021 -0400 analyzer: fix missing leak after call to strsep [PR100615] PR analyzer/100615 reports a missing leak diagnostic. The issue is that the code calls strsep which the analyzer doesn't have special knowledge of, and so conservatively assumes that it could free the pointer, so drops malloc state for it. Properly "teaching" the analyzer about strsep would require it to support bifurcating state at a call, which is currently fiddly to do, so for now this patch notes that strsep doesn't affect the malloc state machine, allowing the analyzer to correctly detect the leak. gcc/analyzer/ChangeLog: PR analyzer/100615 * sm-malloc.cc: Include "analyzer/function-set.h". (malloc_state_machine::on_stmt): Call unaffected_by_call_p and bail on the functions it recognizes. (malloc_state_machine::unaffected_by_call_p): New. gcc/testsuite/ChangeLog: PR analyzer/100615 * gcc.dg/analyzer/pr100615.c: New test.
[Bug testsuite/100655] New: 'g++.dg/tsan/pthread_cond_clockwait.C' FAILs due to 'pthread_cond_clockwait' missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100655 Bug ID: 100655 Summary: 'g++.dg/tsan/pthread_cond_clockwait.C' FAILs due to 'pthread_cond_clockwait' missing Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: tschwinge at gcc dot gnu.org CC: kingoipo at gmail dot com, marxin at gcc dot gnu.org Target Milestone: --- This new testcase recently added in commit r12-794-g80b4ce1a5190ebe764b1009afae57dcef45f92c2 "TSAN: add new test" FAILs on one of my testing systems: +FAIL: g++.dg/tsan/pthread_cond_clockwait.C -O0 (test for excess errors) +UNRESOLVED: g++.dg/tsan/pthread_cond_clockwait.C -O0 compilation failed to produce executable +FAIL: g++.dg/tsan/pthread_cond_clockwait.C -O2 (test for excess errors) +UNRESOLVED: g++.dg/tsan/pthread_cond_clockwait.C -O2 compilation failed to produce executable [...]/gcc/testsuite/g++.dg/tsan/pthread_cond_clockwait.C: In function 'int main()': [...]/gcc/testsuite/g++.dg/tsan/pthread_cond_clockwait.C:26:5: error: 'pthread_cond_clockwait' was not declared in this scope; did you mean 'pthread_cond_wait'? Apparently 'pthread_cond_clockwait' has been added in glibc 2.30, released 2019-08-01. Leave it as it is, or conditionalize the testcase in some way?
[Bug fortran/100656] New: ICE in gfc_conv_expr_present, at fortran/trans-expr.c:1934
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100656 Bug ID: 100656 Summary: ICE in gfc_conv_expr_present, at fortran/trans-expr.c:1934 Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Affects versions down to at least r5 : (with option -fcheck=all or -fcheck=bounds) $ cat z1.f90 subroutine s(x) character(:), allocatable, optional :: x(:) if ( present(x) ) then if ( allocated(x) ) then x = 'a' // x // 'e' end if end if end $ gfortran-12-20210516 -c z1.f90 -fcheck=all z1.f90:5:28: 5 | x = 'a' // x // 'e' |1 internal compiler error: in gfc_conv_expr_present, at fortran/trans-expr.c:1934 0x767b80 gfc_conv_expr_present(gfc_symbol*, bool) ../../gcc/fortran/trans-expr.c:1934 0x745114 gfc_conv_ss_startstride(gfc_loopinfo*) ../../gcc/fortran/trans-array.c:4723 0x77b991 gfc_trans_assignment_1 ../../gcc/fortran/trans-expr.c:11218 0x73dcb7 trans_code ../../gcc/fortran/trans.c:1932 0x7aa2f5 gfc_trans_if_1 ../../gcc/fortran/trans-stmt.c:1475 0x7b1e8a gfc_trans_if(gfc_code*) ../../gcc/fortran/trans-stmt.c:1507 0x73ddd7 trans_code ../../gcc/fortran/trans.c:2020 0x7aa2f5 gfc_trans_if_1 ../../gcc/fortran/trans-stmt.c:1475 0x7b1e8a gfc_trans_if(gfc_code*) ../../gcc/fortran/trans-stmt.c:1507 0x73ddd7 trans_code ../../gcc/fortran/trans.c:2020 0x764314 gfc_generate_function_code(gfc_namespace*) ../../gcc/fortran/trans-decl.c:6885 0x6eac86 translate_all_program_units ../../gcc/fortran/parse.c:6370 0x6eac86 gfc_parse_file() ../../gcc/fortran/parse.c:6639 0x736f7f gfc_be_parse_file ../../gcc/fortran/f95-lang.c:212
[Bug target/100657] New: [GCN offloading] 'libgomp.c-c++-common/reduction-6.c' execution times out
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100657 Bug ID: 100657 Summary: [GCN offloading] 'libgomp.c-c++-common/reduction-6.c' execution times out Product: gcc Version: 12.0 Status: UNCONFIRMED Keywords: openmp Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: tschwinge at gcc dot gnu.org CC: ams at gcc dot gnu.org, burnus at gcc dot gnu.org, jakub at gcc dot gnu.org, jules at gcc dot gnu.org Target Milestone: --- Target: gcn For GCN '-foffload=amdgcn-amdhsa=-march=gfx908' (only), the 'libgomp.c-c++-common/reduction-6.c' testcase recently added with commit r12-614-g33b647956caa977d1ae489f9baed9cef70b4f382 "OpenMP: Fix SIMT for complex/float reduction with && and ||" seems to consistently time out, both C and C++ execution testing. On other GCN/other offloading configurations it seems almost instantaneous to execute. I've confirmed this on both our amd-instinct1 and amd-instinct2 systems.
[Bug testsuite/100658] New: Typos in dg commands and texi files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100658
Bug ID: 100658
Summary: Typos in dg commands and texi files
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: testsuite
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
There is one naming difference : s/Identifification/Identification/
./gcc/ada/gnat_rm.texi:20880:@item @code{Ada.Task_Identifification}
@emph{(C.7.1)}
---
Another typo : s/identfier/identifier/
./gcc/testsuite/gcc.dg/ucnid-5-utf8.c:2:/* { dg-skip-if "No dollar in
identfiers" { avr-*-* powerpc-ibm-aix* } } */
./gcc/testsuite/gcc.dg/ucnid-5.c:2:/* { dg-skip-if "No dollar in identfiers" {
avr-*-* powerpc-ibm-aix* } } */
Additionally, other places use sign "$" explicitly, if that matters here at all
:
./gcc/testsuite/gcc.dg/cpp/lexident.c:8:/* Escaped newlines, _ and $ in
identifiers. */
./gcc/testsuite/gcc.target/i386/pr91298-1.c:4:/* { dg-xfail-if "No support for
$ in identifiers" { *-*-solaris2.* && { ! gas } } } */
./gcc/testsuite/gcc.target/i386/pr91298-2.c:4:/* { dg-xfail-if "No support for
$ in identifiers" { *-*-solaris2.* && { ! gas } } } */
./libcpp/charset.c:1131: cpp_error (pfile, CPP_DL_PEDWARN, "'$' in
identifier or number");
./libcpp/lex.c:1335: cpp_error (pfile, CPP_DL_PEDWARN, "'$' in identifier
or number");
---
Other cases :
s/identier/identifier/
./gcc/jit/libgccjit.c:912: C's rules for identiers upon the name, using
ISALPHA and ISALNUM
s/identifer/identifier/
./gcc/cp/mangle.c:838:/* Interface to substitution and identifer mangling, used
by the
./gcc/testsuite/gcc.dg/local1.c:13: identifer has external linkage.
[Bug testsuite/100655] 'g++.dg/tsan/pthread_cond_clockwait.C' FAILs due to 'pthread_cond_clockwait' missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100655 --- Comment #1 from Michael de Lang --- It'd be fairly trivial to wrap the test in an ifdef: #ifdef __GLIBC__ #if (__GLIBC__ >= 2 && __GLIBC_MINOR__>= 30) || __GLIBC__>= 3 // test here #endif #endif
[Bug c++/100659] New: [11/12 Regression] ICE in supplement_binding_1, at cp/name-lookup.c:2702
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100659
Bug ID: 100659
Summary: [11/12 Regression] ICE in supplement_binding_1, at
cp/name-lookup.c:2702
Product: gcc
Version: 12.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.cc
template struct A
{
A::E::V;
enum { V };
};
$ g++-12-20210516 -c z1.cc
z1.cc:3:3: warning: access declarations are deprecated in favour of
using-declarations; suggestion: add the 'using' keyword [-Wdeprecated]
3 | A::E::V;
| ^
z1.cc:4:10: internal compiler error: Segmentation fault
4 | enum { V };
| ^
0xce3fcf crash_signal
../../gcc/toplev.c:327
0x75543c supplement_binding_1
../../gcc/cp/name-lookup.c:2702
0x759e06 supplement_binding
../../gcc/cp/name-lookup.c:2746
0x759e06 push_class_level_binding_1
../../gcc/cp/name-lookup.c:5549
0x759e06 push_class_level_binding(tree_node*, tree_node*)
../../gcc/cp/name-lookup.c:5567
0x759f7e pushdecl_class_level(tree_node*)
../../gcc/cp/name-lookup.c:5280
0x7eb4d7 finish_member_declaration(tree_node*)
../../gcc/cp/semantics.c:3468
0x6dda21 build_enumerator(tree_node*, tree_node*, tree_node*, tree_node*,
unsigned int)
../../gcc/cp/decl.c:16323
0x781d79 cp_parser_enumerator_definition
../../gcc/cp/parser.c:20284
0x781d79 cp_parser_enumerator_list
../../gcc/cp/parser.c:20213
0x781d79 cp_parser_enum_specifier
../../gcc/cp/parser.c:20143
0x781d79 cp_parser_type_specifier
../../gcc/cp/parser.c:18455
0x782246 cp_parser_decl_specifier_seq
../../gcc/cp/parser.c:15086
0x7a560a cp_parser_member_declaration
../../gcc/cp/parser.c:26003
0x77f7de cp_parser_member_specification_opt
../../gcc/cp/parser.c:25860
0x77f7de cp_parser_class_specifier_1
../../gcc/cp/parser.c:24932
0x781750 cp_parser_class_specifier
../../gcc/cp/parser.c:25248
0x781750 cp_parser_type_specifier
../../gcc/cp/parser.c:18485
0x782246 cp_parser_decl_specifier_seq
../../gcc/cp/parser.c:15086
0x7a43f5 cp_parser_single_declaration
../../gcc/cp/parser.c:30513
[Bug c/100660] New: [11/12 Regression] ICE in visit_assignment, at tree-ssa-ccp.c:2451
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100660
Bug ID: 100660
Summary: [11/12 Regression] ICE in visit_assignment, at
tree-ssa-ccp.c:2451
Product: gcc
Version: 12.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 20210418 and 20210425.
Testcase derived from gcc.target/i386/pr98911.c
with modification s/return// :
$ cat z1.c
typedef char v16qi __attribute__ ((vector_size (16)));
v16qi
f5 (v16qi a, v16qi b)
{
__builtin_ia32_pcmpgtb128 (a, b);
}
$ gcc-12-20210516 -c z1.c -O2
during GIMPLE pass: ccp
z1.c: In function 'f5':
z1.c:7:1: internal compiler error: Segmentation fault
7 | }
| ^
0xb68d3f crash_signal
../../gcc/toplev.c:327
0xc4d033 visit_assignment
../../gcc/tree-ssa-ccp.c:2451
0xcd2003 ssa_propagation_engine::simulate_stmt(gimple*)
../../gcc/tree-ssa-propagate.c:230
0xcd227a ssa_propagation_engine::simulate_block(basic_block_def*)
../../gcc/tree-ssa-propagate.c:337
0xcd2782 ssa_propagation_engine::ssa_propagate()
../../gcc/tree-ssa-propagate.c:504
0xc454b7 do_ssa_ccp
../../gcc/tree-ssa-ccp.c:2574
0xc454b7 execute
../../gcc/tree-ssa-ccp.c:2618
---
during GIMPLE pass: lower
z1.c: In function 'f5':
z1.c:4:1: internal compiler error: Segmentation fault
4 | f5 (v16qi a, v16qi b)
| ^~
0xd46ddf crash_signal
../../gcc/toplev.c:327
0xd8b9a5 contains_struct_check(tree_node*, tree_node_structure_enum, char
const*, int, char const*)
../../gcc/tree.h:3469
0xd8b9a5 verify_gimple_assign_ternary
../../gcc/tree-cfg.c:4191
0xd8b9a5 verify_gimple_assign
../../gcc/tree-cfg.c:4701
0xd8b9a5 verify_gimple_stmt
../../gcc/tree-cfg.c:4957
0xd8d5af verify_gimple_in_seq_2
../../gcc/tree-cfg.c:5119
0xd91fa1 verify_gimple_in_seq(gimple*)
../../gcc/tree-cfg.c:5158
0xc4fdaa execute_function_todo
../../gcc/passes.c:2044
0xc50af2 execute_todo
../../gcc/passes.c:2096
[Bug middle-end/100593] [ELF] -fno-pic: Use GOT to take address of an external default visibility function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100593
--- Comment #8 from Fangrui Song ---
Seems that -fno-plt -fno-pic does have the required properties.
A side effect is that all external calls use the (x86-64) call
*f@GOTPCREL(%rip) (x86-32) call *f@GOT form.
The instruction is one byte longer. (Calling a function is a common case.
Taking the address in a non-vtable case is uncommon. So I'd rather punish the
uncommon address taking).
When the linker notices that the branch target is defined in the executable, it
can optimize out the GOT to use an addr32 prefix instead.
(gold and ld.lld haven't implemented the optimization for 32-bit)
__attribute__((noplt))
int f();
void h() {}
void *g()
{
h(); // call h
f(); // call *f@GOTPCREL(%rip)
return f; // movq f@GOTPCREL(%rip), %rax
}
[Bug c/100661] New: [11/12 Regression] ICE in refs_may_alias_p_2, at tree-ssa-alias.c:2460
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100661
Bug ID: 100661
Summary: [11/12 Regression] ICE in refs_may_alias_p_2, at
tree-ssa-alias.c:2460
Product: gcc
Version: 12.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 20201018 and 20201108 :
$ cat z1.c
void f (char **x)
{
#pragma omp parallel for
for (int i = 0; i < 16; i++)
{
char c[50];
__builtin_strcpy (c, x[i]);
int g (char)
{
__builtin_strcat (c, "foo");
}
}
}
$ gcc-11-20201018 -c z1.c -O2 -fopenmp
z1.c: In function 'g':
z1.c:8:14: error: parameter name omitted
8 | int g (char)
| ^~~~
$ gcc-12-20210516 -c z1.c -O2 -fopenmp
during GIMPLE pass: fre
z1.c: In function 'f._omp_fn.0':
z1.c:13:1: internal compiler error: in refs_may_alias_p_2, at
tree-ssa-alias.c:2460
13 | }
| ^
0xc40fa0 refs_may_alias_p_2
../../gcc/tree-ssa-alias.c:2460
0xc40fa0 refs_may_alias_p_1(ao_ref*, ao_ref*, bool)
../../gcc/tree-ssa-alias.c:2469
0xc4196d check_fnspec
../../gcc/tree-ssa-alias.c:2677
0xc41c30 call_may_clobber_ref_p_1(gcall*, ao_ref*, bool)
../../gcc/tree-ssa-alias.c:3051
0xc4293e stmt_may_clobber_ref_p_1(gimple*, ao_ref*, bool)
../../gcc/tree-ssa-alias.c:3127
0xc42b66 maybe_skip_until
../../gcc/tree-ssa-alias.c:3524
0xc42b66 get_continuation_for_phi(gimple*, ao_ref*, bool, unsigned int&,
bitmap_head**, bool, void* (*)(ao_ref*, tree_node*, void*, translate_flags*),
void*, translate_flags)
../../gcc/tree-ssa-alias.c:3601
0xc42f18 walk_non_aliased_vuses(ao_ref*, tree_node*, bool, void* (*)(ao_ref*,
tree_node*, void*), void* (*)(ao_ref*, tree_node*, void*, translate_flags*),
tree_node* (*)(tree_node*), unsigned int&, void*)
../../gcc/tree-ssa-alias.c:3690
0xcf4b96 vn_reference_lookup(tree_node*, tree_node*, vn_lookup_kind,
vn_reference_s**, bool, tree_node**, tree_node*)
../../gcc/tree-ssa-sccvn.c:3614
0xcfabc4 visit_reference_op_load
../../gcc/tree-ssa-sccvn.c:5063
0xcfabc4 visit_stmt
../../gcc/tree-ssa-sccvn.c:5503
0xcfb67b process_bb
../../gcc/tree-ssa-sccvn.c:7203
0xcfd0b8 do_rpo_vn
../../gcc/tree-ssa-sccvn.c:7688
0xcfda5f execute
../../gcc/tree-ssa-sccvn.c:7956
[Bug fortran/100656] ICE in gfc_conv_expr_present, at fortran/trans-expr.c:1934
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100656 anlauf at gcc dot gnu.org changed: What|Removed |Added Last reconfirmed||2021-05-18 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from anlauf at gcc dot gnu.org --- Confirmed.
[Bug libstdc++/100639] reverse_iterator::reference erroneously uses iterator_traits::reference instead of iter_reference_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100639 Patrick Palka changed: What|Removed |Added CC||ppalka at gcc dot gnu.org Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org Summary|reverse_view::reference |reverse_iterator::refere |erroneously uses|nce erroneously uses |iterator_traits::referen |iterator_traits::referen |ce instead of |ce instead of |iter_reference_t |iter_reference_t
[Bug fortran/100602] [11/12 Regression] Erroneous "pointer argument is not associated" runtime error.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100602 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot gnu.org --- Comment #3 from anlauf at gcc dot gnu.org --- Patch: https://gcc.gnu.org/pipermail/fortran/2021-May/056049.html
[Bug fortran/100662] New: intrinsic::ieee_arithmetic fails on aarch, powerpc architectures on FreeBSD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100662 Bug ID: 100662 Summary: intrinsic::ieee_arithmetic fails on aarch, powerpc architectures on FreeBSD Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: yuri at tsoft dot com Target Milestone: --- Fortran codes using intrinsic::ieee_arithmetic on aarch, powerpc architectures fail to compile. See details in this FreeBSD bug report: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255890
[Bug libstdc++/100639] reverse_iterator::reference erroneously uses iterator_traits::reference instead of iter_reference_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100639 --- Comment #1 from Patrick Palka --- The assertion also fails when __int128 isn't available (which can be simulated by compiling with -U__SIZEOF_INT128__), because in that case iota_view's difference_type is the integer-like class type __max_diff_type, and integer-like class types aren't integral even in GNU mode.
[Bug c++/100644] [11/12 regression] Deleted move constructor prevents templated constructor from being used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100644 --- Comment #2 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:f71ca97def69b8aeb046d716eaea2367736f505e commit r12-885-gf71ca97def69b8aeb046d716eaea2367736f505e Author: Jason Merrill Date: Tue May 18 12:06:36 2021 -0400 c++: "perfect" implicitly deleted move [PR100644] Here we were ignoring the template constructor because the implicit move constructor had all perfect conversions. But CWG1402 says that an implicitly deleted move constructor is ignored by overload resolution; we implement that instead by preferring any other candidate in joust, to get better diagnostics, but that means we need to handle that case here as well. gcc/cp/ChangeLog: PR c++/100644 * call.c (perfect_candidate_p): An implicitly deleted move is not perfect. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/implicit-delete1.C: New test.
[Bug c++/100205] [11/12 Regression] error: invalid use of non-static data member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100205
--- Comment #10 from CVS Commits ---
The master branch has been updated by Jason Merrill :
https://gcc.gnu.org/g:8c114759b8c9c9e2ec90b82d92a24b5a71647017
commit r12-886-g8c114759b8c9c9e2ec90b82d92a24b5a71647017
Author: Jason Merrill
Date: Tue May 18 12:18:56 2021 -0400
c++: non-static member, decltype, {} [PR100205]
This test was fixed by my second patch for PR93314, which distinguishes
between constant-expression and potentially-constant-evaluated contexts in
a
way that my first patch did not.
PR c++/100205
PR c++/99314
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/decltype-nonstatic1.C: New test.
[Bug target/99314] [Patch] [RISC-V] g++.dg/opt/memcpy1.C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99314
--- Comment #11 from CVS Commits ---
The master branch has been updated by Jason Merrill :
https://gcc.gnu.org/g:8c114759b8c9c9e2ec90b82d92a24b5a71647017
commit r12-886-g8c114759b8c9c9e2ec90b82d92a24b5a71647017
Author: Jason Merrill
Date: Tue May 18 12:18:56 2021 -0400
c++: non-static member, decltype, {} [PR100205]
This test was fixed by my second patch for PR93314, which distinguishes
between constant-expression and potentially-constant-evaluated contexts in
a
way that my first patch did not.
PR c++/100205
PR c++/99314
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/decltype-nonstatic1.C: New test.
[Bug testsuite/100655] 'g++.dg/tsan/pthread_cond_clockwait.C' FAILs due to 'pthread_cond_clockwait' missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100655 --- Comment #2 from Jonathan Wakely --- It's not glibc-specific though, it's going to be in the next POSIX standard and other C libraries. It's a bit of a hack, but you could include any libstdc++ header and then check _GLIBCXX_USE_PTHREAD_COND_CLOCKWAIT (because libstdc++ already has autoconf checks for it).
[Bug testsuite/100658] Typos in dg commands and texi files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100658 Jonathan Wakely changed: What|Removed |Added Last reconfirmed||2021-05-18 Keywords||easyhack Status|UNCONFIRMED |NEW Ever confirmed|0 |1
[Bug c++/84337] Variadic expansion is accepted on not parameter pack template argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84337 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Jonathan Wakely --- That's not a pack expansion, that's a printf-style varargs function. The comma before the ellipsis is optional.
