[Bug tree-optimization/100382] [12 Regression] go.test/test/fixedbugs/issue16095.go hang since r12-248
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100382 --- Comment #3 from Richard Biener --- With the following patch this "issue" would show. Not sure why we think a postdom walk is appropriate for DSE rather than a reverse program order one. diff --git a/gcc/tree-ssa-dse.c b/gcc/tree-ssa-dse.c index aecf6ab8c46..5bb5adf43c6 100644 --- a/gcc/tree-ssa-dse.c +++ b/gcc/tree-ssa-dse.c @@ -39,6 +39,7 @@ along with GCC; see the file COPYING3. If not see #include "builtins.h" #include "gimple-fold.h" #include "gimplify.h" +#include "cfganal.h" /* This file implements dead store elimination. @@ -1280,7 +1281,16 @@ pass_dse::execute (function *fun) /* Dead store elimination is fundamentally a walk of the post-dominator tree and a backwards walk of statements within each block. */ dse_dom_walker walker (CDI_POST_DOMINATORS); - walker.walk (fun->cfg->x_exit_block_ptr); + //walker.walk (fun->cfg->x_exit_block_ptr); + int *rpo = XNEWVEC (int, n_basic_blocks_for_fn (fun) - NUM_FIXED_BLOCKS); + auto_bitmap exits; + edge entry = single_succ_edge (ENTRY_BLOCK_PTR_FOR_FN (fun)); + bitmap_set_bit (exits, EXIT_BLOCK); + int n = rev_post_order_and_mark_dfs_back_seme +(fun, entry, exits, true, rpo, NULL); + for (int i = n; i != 0; --i) +walker.before_dom_children (BASIC_BLOCK_FOR_FN (fun, rpo[i-1])); + free (rpo); free_dominance_info (CDI_POST_DOMINATORS); unsigned todo = walker.todo ();
[Bug target/100354] [9/10/11/12 regression] aarch64: non-deligitimized UNSPEC UNSPEC_TLS (76) found in variable location
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100354 Richard Biener changed: What|Removed |Added Target Milestone|--- |9.4
[Bug testsuite/100355] gcc.c-torture/execute/ieee/cdivchkld.c needs fmaxl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100355 --- Comment #1 from Richard Biener --- guard the testcase with c99_runtime?
[Bug c/100360] scalar operation fails the compilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100360 --- Comment #3 from Richard Biener --- It's more likely that mpfr and/or GMP were configured with a wrong CPU and thus run into the illegal instruction. In the end this is unlikely a GCC problem. Please verify with a debugger.
[Bug c++/100362] [11/12 Regression] ICE with Boost.Asio async_initiate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100362 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug tree-optimization/100363] gcc generating wider load/store than warranted at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100363 Richard Biener changed: What|Removed |Added CC||rguenth at gcc dot gnu.org --- Comment #9 from Richard Biener --- (In reply to Linus Torvalds from comment #8) > (In reply to Alexander Monakov from comment #7) > > > > Most likely the issue is that sout/sfrom are misaligned at runtime, while > > the vectorized code somewhere relies on them being sufficiently aligned for > > a 'short'. > > They absolutely are. > > And we build the kernel with -Wno-strict-aliasing exactly to make sure the > compiler doesn't think that "oh, I can make aliasing decisions based on type > information". > > Because we have those kinds of issues all over, and we know which > architectures support unaligned loads etc, and all the tricks with > "memcpy()" and unions make for entirely unreadable code. > > So please fix the aliasing logic to not be type-based when people explicitly > tell you not to do that. > > Linus Note alignment has nothing to do with strict-aliasing (-fno-strict-aliasing you mean btw). One thing we do is (I'm not 50% sure this explains the observed issue) assume that if you have two accesses with type 'short' and they are aligned according to this type then they will not partly overlap. Note this has nothing to do with C strict aliasing rules but is basic pointer math when you know lower zero bits. I suggest to try the fix suggested in comment#7 and report back if that fixes the observed issue.
[Bug c/93031] Wish: When the underlying ISA does not force pointer alignment, option to make GCC not assume it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93031 --- Comment #6 from Richard Biener --- It's still UB. Note that GCC has for a _long_ time made this assumption - just the places we take advantage of it have grown. Note it would be _very_ difficult to provide a -fno-strict-alignment option because we can't really make all data types unaligned since that would break the ABI. So instead we'd have to sprinkle flag_strict_alignment checks all over the place so I'm very sure you won't get a "fixed" compiler and you might get one that doesn't adhere to the platform ABI any more (in case we put one flag_strict_alignment too many).
[Bug target/100152] [10/11/12 Regression] used caller-saved register not preserved across a call.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152 --- Comment #46 from Iain Sandoe --- Created attachment 50737 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50737&action=edit trial patch for testing looking at the way other ports handle things like use of registers in veneers etc. it seems that adding to clobbers in the call lowering is a usable mechanism. This patch does seem the DTRT on gcc-10.3 when tested against the original code (although the patch is against master). Otherwise, this is as yet untested ..
[Bug c++/100370] [11/12 Regression] Incorrect warning for placement new
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100370 Richard Biener changed: What|Removed |Added Summary|[11.1.0 regression] |[11/12 Regression] |Incorrect warning for |Incorrect warning for |placement new |placement new Target Milestone|--- |11.2 Version|unknown |11.1.0
[Bug c++/100372] [11/12 Regression] ICE with variadic template template, internal compiler error: in strip_typedefs, at cp/tree.c:1544
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100372 Richard Biener changed: What|Removed |Added Target Milestone|--- |11.2 Keywords||ice-on-valid-code Summary|ICE with variadic template |[11/12 Regression] ICE with |template, internal compiler |variadic template template, |error: in strip_typedefs, |internal compiler error: in |at cp/tree.c:1544 |strip_typedefs, at ||cp/tree.c:1544
[Bug bootstrap/100373] [12 Regression] Darwin, Compare-debug fail after r12-248-gb58dc0b803057
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100373 Richard Biener changed: What|Removed |Added Status|NEW |UNCONFIRMED Ever confirmed|1 |0 CC||rguenth at gcc dot gnu.org Target Milestone|--- |12.0 Version|unknown |12.0
[Bug target/100375] [12 Regression] trunk 20210501 ftbfs for nvptx-none
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100375 Richard Biener changed: What|Removed |Added Target Milestone|--- |12.0 Version|11.0|12.0 Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #6 from Richard Biener --- Fixed.
[Bug rtl-optimization/100377] needless stack adjustment when passing struct in register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100377 Richard Biener changed: What|Removed |Added Keywords||missed-optimization --- Comment #4 from Richard Biener --- I think there are indeed plenty of dups.
[Bug target/100378] [9/10/11/12 Regression] arm64: lsl + asr used instead of sxth
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100378 Richard Biener changed: What|Removed |Added Target Milestone|12.0|9.4
[Bug libstdc++/100381] [11/12 Regression] new static_assert((std::__is_complete_or_unbounded(...)) failure from g++ 11.1.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100381 Richard Biener changed: What|Removed |Added Keywords||rejects-valid Component|c++ |libstdc++ Target Milestone|--- |11.2 Summary|new |[11/12 Regression] new |static_assert((std::__is_co |static_assert((std::__is_co |mplete_or_unbounded(...)) |mplete_or_unbounded(...)) |failure from g++ 11.1.0 |failure from g++ 11.1.0
[Bug debug/100383] cfi sections directive detection fails with binutils 2.36
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100383 Richard Biener changed: What|Removed |Added Version|unknown |10.3.0 CC||jakub at gcc dot gnu.org Keywords||build Known to fail||7.5.0 --- Comment #1 from Richard Biener --- looks like all branches would be affected.
[Bug debug/100383] cfi sections directive detection fails with binutils 2.36
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100383 Jakub Jelinek changed: What|Removed |Added CC||jyong at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Yes. win32 | pe | cygwin* | mingw32* specific.
[Bug target/100391] New: 128 bit arithmetic --- many unnecessary instructions when extracting smaller parts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100391 Bug ID: 100391 Summary: 128 bit arithmetic --- many unnecessary instructions when extracting smaller parts Product: gcc Version: 11.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: zero at smallinteger dot com Target Milestone: --- Created attachment 50738 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50738&action=edit Sample code Consider the attached code, compiled with -O2. The return value of both functions is just the low 32 bits of num. Whether the top 4 bits of kt were zero, or became zero because of the shifts in the if statement, is irrelevant. So, this both functions should have resulted in something like twostep(unsigned __int128):# @twostep(unsigned __int128) mov rax, rdi ret onestep(unsigned __int128):# @onestep(unsigned __int128) mov rax, rdi ret Instead, gcc added many unnecessary instructions to twostep() as shown below. twostep(unsigned __int128): mov rcx, rdi mov rax, rdi shr rcx, 60 je .L2 movabs rdx, 1152921504606846975 and rax, rdx .L2: ret onestep(unsigned __int128): mov rax, rdi ret This particular behavior was isolated while examining the output of gcc 9.3.0 on Ubuntu 20.04 LTS, then verified for the stated versions (and a few others) using Godbolt. Incidentally, it might be worth checking whether movabs + and is indeed faster than shl + shr, assuming doing so was necessary. If too many movabs instructions are generated for bit masking like this, it will run against the Intel optimization manual's recommendation not to include too many full size literals in code.
[Bug preprocessor/100392] New: compiling result of "g++ -E -fdirectives-only" causes "error: stray ‘#’ in program" if no newline at EOF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100392 Bug ID: 100392 Summary: compiling result of "g++ -E -fdirectives-only" causes "error: stray ‘#’ in program" if no newline at EOF Product: gcc Version: 11.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: preprocessor Assignee: unassigned at gcc dot gnu.org Reporter: mst.lo at arcor dot de Target Milestone: --- > g++ --version g++ (GCC) 11.1.1 20210428 (Red Hat 11.1.1-1) works: > echo '#include "test.h"' > test.cpp > printf 'extern const int ksc5601_hangul_to_unicode[2350];\n' > test.h > g++ -E -fdirectives-only test.cpp -o test.i > g++ -c test.i doesn't work: > echo '#include "test.h"' > test.cpp > printf 'extern const int ksc5601_hangul_to_unicode[2350];' > test.h > g++ -E -fdirectives-only test.cpp -o test.i > g++ -c test.i In file included from test.cpp:1: test.h:1:50: error: stray ‘#’ in program 1 | extern const int ksc5601_hangul_to_unicode[2350]; | ^ test.h:1:52: error: expected unqualified-id before numeric constant 1 | extern const int ksc5601_hangul_to_unicode[2350]; | in a draft of C++11, 2.2 Phases of translation [lex.phases] 1.2 says: A source file that is not empty and that does not end in a new-line character, or that ends in a new-line character immediately preceded by a backslash character before any such splicing takes place, shall be processed as if an additional new-line character were appended to the file. similar language in https://github.com/cplusplus/draft/blob/master/source/lex.tex#L97 wheres e.g. in a draft of C99, 5.1.1.2 Translation phases 2. says: A source file that is not empty shall end in a new-line character, which shall not be immediately preceded by a backslash character before any such splicing takes place. ... so apparently different standards have different requirements here. i believe this problem didn't occur when using GCC 10 with sccache or icecream, which use "-E -fdirectives-only" to create a suitable input for distributed compilation.
[Bug tree-optimization/100382] [12 Regression] go.test/test/fixedbugs/issue16095.go hang since r12-248
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100382 --- Comment #4 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:80bbb7ff83d81544b09820428bdd7db9f50fe362 commit r12-378-g80bbb7ff83d81544b09820428bdd7db9f50fe362 Author: Jakub Jelinek Date: Mon May 3 12:03:02 2021 +0200 tree-ssa-dse: Fix up go.test/test/fixedbugs/issue16095.go miscompilation [PR100382] The new DCE code inside of tree DSE removes in -fnon-call-exceptions go code a load from NULL pointer the testcase relies on throwing an exception and so the test hangs. The following patch just repeats a check that e.g. tree-ssa-dce.c uses to prevent this. 2021-05-03 Jakub Jelinek PR tree-optimization/100382 * tree-ssa-dse.c: Include tree-eh.h. (dse_dom_walker::before_dom_children): Don't remove stmts if stmt_unremovable_because_of_non_call_eh_p is true.
[Bug c/100360] scalar operation fails the compilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100360 --- Comment #4 from aliaga at uji dot es --- Hi, I have two different compiled versions of GMP. Initially, it is possible that I tried to use the wrong version, but the simplest code doesn't use GMP, therefore it doesn't matter the version which I chose. Unfortunately, the error no longer occurs, and I can't to use the debugger. In any case, thank you for your efforts. Best regards, José I. Aliaga
[Bug tree-optimization/100382] [12 Regression] go.test/test/fixedbugs/issue16095.go hang since r12-248
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100382 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #5 from Jakub Jelinek --- Fixed.
[Bug target/100321] [OpenMP][nvptx, SIMT] (Con't) Reduction fails with optimization and 'loop'/'for simd' but not with 'for'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100321
--- Comment #5 from Tom de Vries ---
(In reply to Tom de Vries from comment #4)
> So, something like this reflects the current state:
> ...
> diff --git a/gcc/omp-low.c b/gcc/omp-low.c
> index 7b122059c6e..a0561800977 100644
> --- a/gcc/omp-low.c
> +++ b/gcc/omp-low.c
> @@ -6005,6 +6005,11 @@ lower_rec_input_clauses (tree clauses, gimple_seq
> *ilist, gimple_seq *dlist,
> tree placeholder = OMP_CLAUSE_REDUCTION_PLACEHOLDER (c);
> gimple *tseq;
> tree ptype = TREE_TYPE (placeholder);
> + if (sctx.is_simt)
> + {
> + sorry ("SIMT not fully implemented");
> + abort ();
> + }
> if (cond)
> {
> x = error_mark_node;
> ...
Submitted patch that does something similar (but using error rather than
sorry/abort) @ https://gcc.gnu.org/pipermail/gcc-patches/2021-May/569421.html .
[Bug preprocessor/100392] [11/12 Regression] compiling result of "g++ -E -fdirectives-only" causes "error: stray ‘#’ in program" if no newline at EOF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100392 Jakub Jelinek changed: What|Removed |Added Ever confirmed|0 |1 Summary|compiling result of "g++ -E |[11/12 Regression] |-fdirectives-only" causes |compiling result of "g++ -E |"error: stray ‘#’ in|-fdirectives-only" causes |program" if no newline at |"error: stray ‘#’ in |EOF |program" if no newline at ||EOF CC||jakub at gcc dot gnu.org Target Milestone|--- |11.2 Last reconfirmed||2021-05-03 Status|UNCONFIRMED |NEW --- Comment #1 from Jakub Jelinek --- /opt/notnfs/gcc-bisect/obj/gcc/cc1plus.r11-205 -quiet -fdirectives-only -E test.cpp -o test.ii; tail -n 2 test.ii extern const int ksc5601_hangul_to_unicode[2350]; # 2 "test.cpp" 2 Starting with r11-206-gb224c3763e018e8bdd0047b3eb283992fb655ce0 we ICEd on it, and starting with r11-7093-gac16f4327fef5dfc288409371a61649253353ef7 we emit: /opt/notnfs/gcc-bisect/obj/gcc/cc1plus.r11-7093 -quiet -fdirectives-only -E test.cpp -o test.ii; tail -n 2 test.ii # 1 "test.h" 1 extern const int ksc5601_hangul_to_unicode[2350];# 2 "test.cpp" 2
[Bug target/100217] [11/12 Regression] ICE when building valgrind testsuite with -march=z14 since r11-7552
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100217 --- Comment #14 from CVS Commits --- The master branch has been updated by Ilya Leoshkevich : https://gcc.gnu.org/g:4f48c335d36674f90046b2823f0ac1c0545dc082 commit r12-379-g4f48c335d36674f90046b2823f0ac1c0545dc082 Author: Ilya Leoshkevich Date: Mon Apr 26 14:12:08 2021 +0200 IBM Z: Handle hard registers in s390_md_asm_adjust() gen_fprx2_to_tf() and gen_tf_to_fprx2() cannot handle hard registers, since the subregs they create do not pass validation. Change s390_md_asm_adjust() to manually copy between hard VRs and FPRs instead of using these two functions. gcc/ChangeLog: PR target/100217 * config/s390/s390.c (s390_hard_fp_reg_p): New function. (s390_md_asm_adjust): Handle hard registers. gcc/testsuite/ChangeLog: PR target/100217 * gcc.target/s390/vector/long-double-asm-in-out-hard-fp-reg.c: New test. * gcc.target/s390/vector/long-double-asm-inout-hard-fp-reg.c: New test.
[Bug c/100393] New: Very slow compilation of switch statement with thousands of cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100393 Bug ID: 100393 Summary: Very slow compilation of switch statement with thousands of cases Product: gcc Version: 10.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: curiousdannii at gmail dot com Target Milestone: --- I have a switch statement with almost 11,000 cases (produced by a decompiler), which is taking almost 5 minutes to compile with GCC 10.2. Helpful people on Stack Overflow suggested that it was a regression, that it only took 3 seconds to compile with GCC 8.4, and for comparison, only 1.3 seconds in Clang. I haven't been able to confirm those results yet, but I'll look into doing so. SO discussion: https://stackoverflow.com/q/67363813/2854284 Preprocessed source: https://gist.githubusercontent.com/curiousdannii/9476375ff3ae22c403ce2a8132e6a5dc/raw/568f519f2f1b599e98c514f3609a4968d4153eed/functions_unsafe.i The `-ftime-report -ftime-report-details` results (full results in the SO page) show that the slow part is in "tree switch lowering". I also tried compiling it with `-fno-jump-tables`, which, rather than helping, made it much worse, taking over 33 minutes to compile.
[Bug c++/27397] [4.2 regression] ICE on invalid template argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=27397 --- Comment #8 from CVS Commits --- The master branch has been updated by H.J. Lu : https://gcc.gnu.org/g:fd7eb4bc94cafa745eba75c64fa483a1689a5aad commit r12-380-gfd7eb4bc94cafa745eba75c64fa483a1689a5aad Author: H.J. Lu Date: Fri Feb 12 16:30:23 2021 -0800 GCC_CET_HOST_FLAGS: Check if host supports multi-byte NOPs Sync with binutils for PR binutils/27397. Check if host supports multi-byte NOPs before enabling CET on host. config/ PR bootstrap/99703 * cet.m4 (GCC_CET_HOST_FLAGS): Check if host supports multi-byte NOPs. libiberty/ PR bootstrap/99703 * configure: Regenerated.
[Bug target/99703] gcc-10.2.0 with Via C3 Eden: configure: error: Intel CET must be enabled on Intel CET enabled host
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99703 --- Comment #35 from CVS Commits --- The master branch has been updated by H.J. Lu : https://gcc.gnu.org/g:3f570621352970945db657455e0570208ea2d70e commit r12-381-g3f570621352970945db657455e0570208ea2d70e Author: H.J. Lu Date: Mon Mar 22 13:23:21 2021 -0700 GCC_CET_HOST_FLAGS: Check if host supports multi-byte NOPs Check if host supports multi-byte NOPs before enabling CET on host. gcc/ PR bootstrap/99703 * configure: Regenerated. libbacktrace/ PR bootstrap/99703 * configure: Regenerated. libcc1/ PR bootstrap/99703 * configure: Regenerated. libcpp/ PR bootstrap/99703 * configure: Regenerated. libdecnumber/ PR bootstrap/99703 * configure: Regenerated. lto-plugin/ PR bootstrap/99703 * configure: Regenerated.
[Bug target/99703] gcc-10.2.0 with Via C3 Eden: configure: error: Intel CET must be enabled on Intel CET enabled host
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99703 --- Comment #34 from CVS Commits --- The master branch has been updated by H.J. Lu : https://gcc.gnu.org/g:fd7eb4bc94cafa745eba75c64fa483a1689a5aad commit r12-380-gfd7eb4bc94cafa745eba75c64fa483a1689a5aad Author: H.J. Lu Date: Fri Feb 12 16:30:23 2021 -0800 GCC_CET_HOST_FLAGS: Check if host supports multi-byte NOPs Sync with binutils for PR binutils/27397. Check if host supports multi-byte NOPs before enabling CET on host. config/ PR bootstrap/99703 * cet.m4 (GCC_CET_HOST_FLAGS): Check if host supports multi-byte NOPs. libiberty/ PR bootstrap/99703 * configure: Regenerated.
[Bug c/100393] Very slow compilation of switch statement with thousands of cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100393 --- Comment #1 from Dannii Willis --- Okay, I've confirmed the regression myself, using functions_unsafe.i: gcc-8: real 0m11.450s gcc-10: real4m46.472s And for comparison clang: real 0m0.711s
[Bug debug/100383] cfi sections directive detection fails with binutils 2.36
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100383 jyong at gcc dot gnu.org changed: What|Removed |Added Last reconfirmed||2021-05-03 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #3 from jyong at gcc dot gnu.org --- I can confirm it was detected as no with binutils 2.36, and back to yes after the grep change.
[Bug target/99703] gcc-10.2.0 with Via C3 Eden: configure: error: Intel CET must be enabled on Intel CET enabled host
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99703 H.J. Lu changed: What|Removed |Added Resolution|--- |FIXED Status|WAITING |RESOLVED Target Milestone|--- |12.0 --- Comment #36 from H.J. Lu --- Fixed for GCC 12.
[Bug fortran/67740] Wrong association status of allocatable character pointer in derived types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67740 Sebastien Bardeau changed: What|Removed |Added CC||bardeau at iram dot fr --- Comment #4 from Sebastien Bardeau --- I have pretty much the same kind of issue with gfortran 10.2.0 and 11.0.1 (20210426). The following code shows invalid results (printed lengths are 0). Sometimes I even get a program crash. If the 'data1' component is a standalone pointer (i.e. out of the derived type), I have no issue then. program test2 character(len=10), target, allocatable :: s(:) type :: pointer_typec0_t character(len=:), pointer :: data1(:) end type pointer_typec0_t type(pointer_typec0_t) :: co ! allocate(s(3)) s(1) = '1234567890' s(2) = 'qwertyuio ' s(3) = 'asdfghjk ' ! co%data1 => s ! print *,len(co%data1(1)),len_trim(co%data1(1)),co%data1(1) print *,len(co%data1(2)),len_trim(co%data1(2)),co%data1(2) print *,len(co%data1(3)),len_trim(co%data1(3)),co%data1(3) end program test2
[Bug libstdc++/100384] Compiling in c++17 mode breaks compilation of functions named visit()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100384 --- Comment #2 from Albert Astals Cid --- People that know more C++ than me, told me std::visit appears unconstrained to Variants...&& being actual std::variants (in case you inherited one, I guess), so std::visit, as an unconstrained perfect forwarder will win every overload set ranking. And std::visit is brought in by ADL via std::vector it's a misfeature, this has been adopted in C++23 http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2162r2.html So I guess the proper resolution for this issue would be "not a bug", but will leave you to decide on it :)
[Bug fortran/99651] Cannot change attributes of USE-associated intrinsic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99651 Tobias Burnus changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Tobias Burnus --- Close as FIXED - it is fixed in GCC 10 and in GCC 11 (before the first release, i.e. it is in 11.1 and in 12). Thanks for the report!
[Bug libgomp/100352] [11/12 Regression] libgomp.fortran/async_io_1.f90 -O0 execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100352 --- Comment #8 from CVS Commits --- The releases/gcc-11 branch has been updated by Tobias Burnus : https://gcc.gnu.org/g:107ca5c2fd6dcb53c3cba788ae388e7e4e789ed8 commit r11-8343-g107ca5c2fd6dcb53c3cba788ae388e7e4e789ed8 Author: Tobias Burnus Date: Sun May 2 18:16:17 2021 +0200 Fortran: Async I/O - avoid unlocked unlocking [PR100352] Follow up to PR100352, which moved unit unlocking to st_*_done_worker to avoid lock order reversal; however, as async_io uses a different lock, the (unlocked locked) unit lock shall not be unlocked there. libgfortran/ChangeLog: PR libgomp/100352 * io/transfer.c (st_read_done_worker, st_write_done_worker): Add new arg whether to unlock unit. (st_read_done, st_write_done): Call it with true. * io/async.c (async_io): Call it with false. * io/io.h (st_write_done_worker, st_read_done_worker): Update prototype. (cherry picked from commit a13a50047ef1814a7bda2392f728bf28f81b17ce)
[Bug libgomp/100352] [11/12 Regression] libgomp.fortran/async_io_1.f90 -O0 execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100352 --- Comment #9 from Tobias Burnus --- (In reply to CVS Commits from comment #8) > Follow up to PR100352, That's this PR and not the one which caused it. Correct is (comment #6): > Issue introduced for PR99529 in > r11-7647-ga6e9633ccb593937fceec67fafc2afe5d518d735 * * * Close as FIXED (in GCC 12 and 11). Thanks for the report! See PR100371 for follow ups.
[Bug tree-optimization/100393] [9/10/11/12 Regression] Very slow compilation of switch statement with thousands of cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100393 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Last reconfirmed||2021-05-03 Keywords||compile-time-hog Component|c |tree-optimization Summary|Very slow compilation of|[9/10/11/12 Regression] |switch statement with |Very slow compilation of |thousands of cases |switch statement with ||thousands of cases Known to work||8.4.0 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Known to fail||11.1.0, 9.3.1 CC||marxin at gcc dot gnu.org, ||rguenth at gcc dot gnu.org Target Milestone|--- |9.4 --- Comment #2 from Richard Biener --- Confirmed at -O0 and -O1+.
[Bug tree-optimization/100393] [9/10/11/12 Regression] Very slow compilation of switch statement with thousands of cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100393
--- Comment #3 from Richard Biener ---
Samples: 847K of event 'cycles:u', Event count (approx.): 839745061761
Overhead Samples Command Shared Object Symbol
95.05%804298 cc1 cc1 [.]
tree_switch_conversion::jump_table_cluster::can_be_handled
1.69% 14493 cc1 cc1 [.]
tree_switch_conversion::cluster::get_range
0.86% 7291 cc1 cc1 [.]
optimize_function_for_size_p
looks like there's obvious quadraticness here when doing the summing:
bool
jump_table_cluster::can_be_handled (const vec &clusters,
unsigned start, unsigned end)
{
..
for (unsigned i = start; i <= end; i++)
{
simple_cluster *sc = static_cast (clusters[i]);
comparison_count += sc->m_range_p ? 2 : 1;
}
and we're almost trying all possible clusters in
jump_table_cluster::find_jump_tables
Now, there's the possibility of doing a quick guess before doing this
loop, once via using (end - start) and once via using 2 * (end - start).
Only if the first can be handled and the second not we have to compute.
Martin?
[Bug tree-optimization/100393] [9/10/11/12 Regression] Very slow compilation of switch statement with thousands of cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100393
--- Comment #4 from Richard Biener ---
I guess that's already done, so it has to be fixed in other ways, like by
keeping the partial sum when decreasing the size in
for (unsigned j = 0; j < i; j++)
{
if (min[j].m_count + 1 < min[i].m_count
&& can_be_handled (clusters, j, i - 1))
min[i] = min_cluster_item (min[j].m_count + 1, j, INT_MAX);
}
maybe "simply" binary search j in [0, i-1] rather than doing a linear
search here.
[Bug c++/100288] [11/12 Regression] g++-11 internal error and fails to precompile a concept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100288
--- Comment #5 from Patrick Palka ---
(In reply to Frank B. Brokken from comment #4)
> Dear ppalka at gcc dot gnu.org, you wrote:
> >
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100288
> >
> > Patrick Palka changed:
> >
> >What|Removed |Added
> >
> >Keywords||ice-on-invalid-code
> >See Also||https://gcc.gnu.org/bugzill
> >||a/show_bug.cgi?id=99599
> >
> > --- Comment #3 from Patrick Palka ---
> > Agreed, the testcase looks invalid much like PR99599. One workaround for
> > avoiding the constraint recursion here would be to change the signature of
> >
> > template
> > inline void operator<<(CSVTabIns &&tab, Type const &value)
> >
> > to something like
> >
> > template > U,
> > OstreamInsertable
> > Type>
> > inline void operator<<(U &&tab, Type const &value)
> >
> > so that the constraint OstreamInsertable is checked on this overload
> > only
> > if the first argument to << has the expected type.
> >
> > --
> > You are receiving this mail because:
> > You reported the bug.
>
> Hi Patrick,
>
> Thanks for your e-mail.
>
> Since (AFAICS) you directly and only sent your e-mail to me I'm wondering
> whether you want me to comment on your e-mail. It's getting kind of late
> here,
> but I could send a more extensive reply tomorrow. Let me know if that's what
> you want.
Oh sorry, that was just an automated email for the comment I posted to the
bugzilla PR, which gets sent to everyone on the CC list of the PR. I wasn't
expecting any sort of reply :)
>
> I tried your suggestion, and it seems to solve the issue. But at the same
> time
> it puzzles me why
>
> template
> inline void operator<<(CSVTabIns &&tab, Type const &value)
> {}
>
> won't be instantiated for FMT in
>
> inline void operator<<(CSVTabIns &tab, FMT::FMTHline hline)
> {
> tab << (*hline)(1); // insert hline in the next column
> }
>
> when FMT defines FMTHline as 'typedef FMT (*FMTHline)(unsigned)' and
>
> std::ostream &operator<<(std::ostream &out, FMT const &fmt)
>
> is declared. I would have expected that
>
> tab << (*hline)(1); // insert hline in the next column
>
> would cause the compiler to instantiate
>
> template
> inline void operator<<(CSVTabIns &&tab, Type const &value)
> {}
>
> for Type = FMT.
>
The compiler does try to instantiate that overload for Type = FMT there, but
when checking the constraint OstreamInsertable on this overload it needs
to resolve the << in
requires(std::ostream &out, Type value)
{
out << value;
};
for Type = FMT, during which it considers that same operator<< overload. And
CWG2369 says we now first check constraints before non-dependent conversions,
but we're in the middle of checking the constraints on this overload, so we
enter a constraint loop.
> Maybe I'm missing something here? And it's also not something that caused the
> compiler's internal error.
Yeah, we shouldn't be seeing an internal error even on an invalid testcase.
This needs to be fixed.
[Bug libstdc++/100387] ranges::minmax compares moved-out value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100387 Patrick Palka changed: What|Removed |Added Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED CC||ppalka at gcc dot gnu.org Last reconfirmed||2021-05-03 --- Comment #2 from Patrick Palka --- Confirmed.
[Bug libstdc++/100384] Compiling in c++17 mode breaks compilation of functions named visit()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100384 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #3 from Jonathan Wakely --- Not a bug. PR 90943 already exists for the P2162R3 support.
[Bug c++/100335] Using statement of a ref-qualified method from base class: method not callable on derived object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100335 --- Comment #8 from Jonathan Wakely --- Like I already suggested in comment 3: Either the overloads should conflict because of [over.load]/2.3 (and the definition of Derived should be ill-formed) or they should be hidden and not visible in Derived (so the call to test.method() should be ill-formed).
[Bug middle-end/100394] New: wrong-code with EH and pure/const functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100394
Bug ID: 100394
Summary: wrong-code with EH and pure/const functions
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: rguenth at gcc dot gnu.org
Target Milestone: ---
// { dg-do run }
// { dg-options "-O2" }
int x, y;
int __attribute__((pure,noinline)) foo () { if (x) throw; return y; }
int __attribute__((noinline)) bar()
{
int a[2];
x = 1;
try {
int res = foo ();
a[0] = res;
} catch (...) {
return 0;
}
return 1;
}
int main()
{
if (bar ())
__builtin_abort ();
return 0;
}
aborts at all (non-)optimization levels. In an unpatched tree the call to
foo() is elided.
> g++-10 t.C
> ./a.out
terminate called without an active exception
Aborted (core dumped)
[Bug middle-end/100394] wrong-code with EH and pure/const functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100394 --- Comment #1 from Richard Biener --- See also https://gcc.gnu.org/pipermail/gcc-patches/2021-May/569429.html
[Bug middle-end/100394] wrong-code with EH and pure/const functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100394 --- Comment #2 from Richard Biener --- Classically it needs two DCE passes, the first removes the call LHS, the second then no longer considers the call necessary because of EH. But even with that fixed there are subsequent passes breaking things.
[Bug target/100375] [12 Regression] trunk 20210501 ftbfs for nvptx-none
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100375 --- Comment #7 from Jonathan Wakely --- I need to fix libstdc++ to accept the code with a deprecated warning, rather than reject it. I think it only rejects it with -pedantic but it should still be fixed to work until the deprecated constructor is removed.
[Bug middle-end/100394] wrong-code with EH and pure/const functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100394
Michael Matz changed:
What|Removed |Added
Known to fail|3.4.6, 4.3.5|
CC||matz at gcc dot gnu.org
--- Comment #3 from Michael Matz ---
That's simply invalid C++. A rethrow (which is what a 'throw' without value
is)
can only be done from within a catch. You need to throw a value:
...
int __attribute__((pure,noinline)) foo () { if (x) throw 42; return y; }
...
[Bug middle-end/93644] [10/11/12 Regression] spurious -Wreturn-local-addr with PHI of PHI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93644 Jochen Roemmler changed: What|Removed |Added CC||jochen447 at concept dot de --- Comment #16 from Jochen Roemmler --- Created attachment 50739 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50739&action=edit another minimal example to demonstrate the false alarm This is another instance of the test case. A senseless, yet perfectly valid piece of C code. It creates the false positive warning if compiled like this: gcc -Wreturn-local-addr -O1 -fisolate-erroneous-paths-dereference -c pr93644_2.c pr93644_2.c: In function ‘buildVname’: pr93644_2.c:28:12: warning: function may return address of local variable [-Wreturn-local-addr] 28 | return vname; |^ pr93644_2.c:18:17: note: declared here 18 | charbuf[256]; | ^~~ I'm using gcc version 11.1.1 20210428 (Red Hat 11.1.1-1) (GCC) However, I can silence the warning using # pragma GCC diagnostic ignored "-Wreturn-local-addr"
[Bug c/100395] New: Bogus -Wstringop-overflow warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100395
Bug ID: 100395
Summary: Bogus -Wstringop-overflow warning
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: lavr at ncbi dot nlm.nih.gov
Target Milestone: ---
$ gcc --version
gcc (GCC) 10.2.0
$ cat test.c
#include
#include
int main(int argc, const char* argv[])
{
size_t len0 = strlen(argv[0]), len1 = strlen(argv[1]);
char buf[444];
char* s;
s = buf + sizeof(buf) - len0;
memcpy(s, argv[0], len0);
s -= len1;
memcpy(--s, argv[1], len1);
s[len1++] = ' ';
printf("%.*s\n", (int)(len0 + len1), s);
return 0;
}
$ gcc -O2 -Wall test.c
test.c: In function ‘main’:
test.c:14:15: warning: writing 1 byte into a region of size 0
[-Wstringop-overflow=]
14 | s[len1++] = ' ';
| ~~^
test.c:7:10: note: at offset -1 to object ‘buf’ with size 444 declared here
7 | char buf[444];
| ^~~
The offset shown in the message is wrong, which most likely was the reason to
emit the warning altogether.
The test code above mocks up a situation where the lengths of both strings,
which are being copied in the reverse order into "buf", are known and small,
i.e. both fit (a few times, actually) together into the buffer, including the
separator and terminator.
[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
Patrick Palka changed:
What|Removed |Added
Summary|Internal compiler error |[11/12 Regression] Internal
|when|compiler error when
|std::lexicographical_compar |std::lexicographical_compar
|e_three_way third and |e_three_way third and
|fourth argument are reverse |fourth argument are reverse
|iterators |iterators
Ever confirmed|0 |1
Target Milestone|--- |11.2
Component|libstdc++ |c++
CC||jason at gcc dot gnu.org,
||ppalka at gcc dot gnu.org
Status|UNCONFIRMED |NEW
Last reconfirmed||2021-05-03
--- Comment #1 from Patrick Palka ---
Seems to be a frontend issue, started with r11-5866. Reduced:
#include
struct iter {
bool current;
iter(iter &);
};
constexpr bool operator==(const iter &, const iter &__y) {
return __y.current;
}
void lexicographical_compare_three_way(iter a) {
(a == a) <=> true;
}
[Bug middle-end/100394] wrong-code with EH and pure/const functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100394
--- Comment #4 from Michael Matz ---
That then still shows problems with the pure function and -O2, but with
standard
C++ this then works:
struct S {
int foo(int i) const { if (i) throw 42; return 0; }
};
int __attribute__((noinline)) bar2()
{
S s;
int a[2];
try {
int res = s.foo (1);
a[0] = res;
} catch (...) {
return 0;
}
return 1;
}
int main()
{
if (bar2 ())
__builtin_abort ();
return 0;
}
[Bug c++/100362] [11/12 Regression] ICE with Boost.Asio async_initiate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100362
Patrick Palka changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot
gnu.org
--- Comment #3 from Patrick Palka ---
Further reduced:
template
struct Qux {
struct A { } a_;
void AsyncOp() {
[this](auto) {
decltype(a_) x;
struct Grault : decltype(a_) {};
Grault ptr;
}(0);
}
};
void corge() {
Qux qux;
qux.AsyncOp();
}
[Bug c++/100396] New: [11.1 regression] The template function overload is not selected correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100396
Bug ID: 100396
Summary: [11.1 regression] The template function overload is
not selected correctly
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: vopl at bk dot ru
Target Milestone: ---
Regression in 11.1.0
$ cat src.cpp && echo EOFFF
/0/1/2/3/4/5/6/7
template
constexpr bool valid = (0 < sizeof(F{}(Args{}...)));
/0/1/2/3/4/5/6/7
template
void ovr(F f, Args... args)
requires valid // external checker - fail, wrong Args formed
//requires (0 < sizeof(F{}(Args{}...))) // inline checker - ok (are wrong Args
compensated by SFINAE?)
{
return ovr(int{}, f, args...); // a second ovr is expected to
be called, but the compiler tries to call this ovr again. Collision between
'int' and 'F' is ignored, extra Args appended from 'f'
}
template void ovr(int, F, Args...){}
/0/1/2/3/4/5/6/7
void use()
{
ovr([]{return 'c';});
}
EOFFF
$ g++-11.1.0 -std=c++20 -c src.cpp
src.cpp: In instantiation of 'constexpr const bool valid,
use():: >':
src.cpp:8:10: required by substitution of 'template
void ovr(F, Args ...) requires valid [with F = use()::;
Args = {use()::}]'
src.cpp:11:27: required from 'void ovr(F, Args ...) requires valid [with F = use()::; Args = {}]'
src.cpp:19:8: required from here
src.cpp:3:39: error: no match for call to '(use()::)
(use()::)'
3 | constexpr bool valid = (0 < sizeof(F{}(Args{}...)));
| ^~~~
src.cpp:3:39: note: candidate: 'char (*)()' (conversion)
src.cpp:3:39: note: candidate expects 1 argument, 2 provided
src.cpp:19:9: note: candidate: 'use()::'
19 | ovr([]{return 'c';});
| ^
src.cpp:19:9: note: candidate expects 0 arguments, 1 provided
$ g++-11.1.0 -v
Using built-in specs.
COLLECT_GCC=g++-11.1.0
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/11.1.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with:
/var/tmp/portage/sys-devel/gcc-11.1.0/work/gcc-11.1.0/configure
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr
--bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/11.1.0
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/11.1.0
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/11.1.0/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/11.1.0/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/include/g++-v11
--with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/11.1.0/python
--enable-languages=c,c++,fortran --enable-obsolete --enable-secureplt
--disable-werror --with-system-zlib --disable-nls --enable-checking=release
--with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo 11.1.0 p1'
--disable-esp --enable-libstdcxx-time --with-build-config=bootstrap-lto
--enable-shared --enable-threads=posix --enable-__cxa_atexit
--enable-clocale=gnu --enable-multilib --with-multilib-list=m32,m64
--disable-fixed-point --enable-targets=all --enable-libgomp --disable-libssp
--disable-libada --enable-systemtap --disable-valgrind-annotations
--enable-vtable-verify --with-zstd --enable-lto --with-isl
--disable-isl-version-check --enable-default-pie --disable-default-ssp
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.1.0 (Gentoo 11.1.0 p1)
[Bug libstdc++/100384] Compiling in c++17 mode breaks compilation of functions named visit()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100384 Patrick Palka changed: What|Removed |Added CC||ppalka at gcc dot gnu.org --- Comment #4 from Patrick Palka --- Hmm, isn't problem here ultimately that std::visit is specified to have a concrete SFINAE-friendly return type, but our implementation uses a deduced return type?
[Bug c/93031] Wish: When the underlying ISA does not force pointer alignment, option to make GCC not assume it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93031 --- Comment #7 from Alexander Monakov --- In comment #2 I touched upon a potentially more practical way to offer -fno-strict-alignment: Run early work with ABI alignments: compute __alignof correctly, lay out composite types as required by ABI, and assign alignments to variables (including stack variables and function parameters). Then make a pass over types and reduce their alignment. This way, optimizations see a universe where types have alignment 1, and variables are defined as if they had an explicit attribute-align with increased alignment (and likewise for structure fields).
[Bug c++/100396] [11.1 regression] The template function overload is not selected correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100396 Patrick Palka changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID CC||ppalka at gcc dot gnu.org --- Comment #1 from Patrick Palka --- Thanks for the bug report. It looks like we started rejecting this after r11-2774. The testcase is invalid, I think. You need to declare 'valid' as a concept instead of a constexpr variable so that substitution failure during constraint checking of the first overload of 'ovr' is a SFINAE error.
[Bug c++/100368] Missing guaranteed elision in constexpr evaluation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100368 Patrick Palka changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW CC||ppalka at gcc dot gnu.org Last reconfirmed||2021-05-03 --- Comment #1 from Patrick Palka --- Confirmed, looks like this never worked.
[Bug c++/100374] Type-constraints of member function templates should not be substituted into during implicit instantiation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100374 Patrick Palka changed: What|Removed |Added Ever confirmed|0 |1 CC||ppalka at gcc dot gnu.org Status|UNCONFIRMED |NEW Last reconfirmed||2021-05-03 --- Comment #1 from Patrick Palka --- Confirmed.
[Bug testsuite/100397] New: New test case libgomp.fortran/depobj-1.f90 fails erratically since its introduction in r12-20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100397 Bug ID: 100397 Summary: New test case libgomp.fortran/depobj-1.f90 fails erratically since its introduction in r12-20 Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- g:a61c4964cd71446232d62ec9b10a7d45b440dd9f, r12-20 This test case fails erratically (ever few runs) on powerpc64 since its introduction. I have seen it fail on power 7 BE and power 9 LE machines. make -k check-target-libgomp RUNTESTFLAGS="fortran.exp=libgomp.fortran/depobj-1.f90" FAIL: libgomp.fortran/depobj-1.f90 -O execution test # of expected passes1 # of unexpected failures1 spawn -ignore SIGHUP /home/seurer/gcc/git/build/gcc-test/./gcc/xgcc -B/home/seurer/gcc/git/build/gcc-test/./gcc/ -B/home/seurer/gcc/git/install/gcc-test/powerpc64-unknown-linux-gnu/bin/ -B/home/seurer/gcc/git/install/gcc-test/powerpc64-unknown-linux-gnu/lib/ -isystem /home/seurer/gcc/git/install/gcc-test/powerpc64-unknown-linux-gnu/include -isystem /home/seurer/gcc/git/install/gcc-test/powerpc64-unknown-linux-gnu/sys-include exceptions_enabled48342.cc -B/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libgomp/ -B/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libgomp/.libs -I/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libgomp -I/home/seurer/gcc/git/gcc-test/libgomp/testsuite/../../include -I/home/seurer/gcc/git/gcc-test/libgomp/testsuite/.. -fmessage-length=0 -fno-diagnostics-show-caret -fdiagnostics-color=never -fopenmp -B/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libgomp/../libquadmath/.libs/ -B/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libgomp/../libgfortran/.libs -S -o exceptions_enabled48342.s PASS: libgomp.fortran/depobj-1.f90 -O (test for excess errors) Setting LD_LIBRARY_PATH to .:/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libgomp/.libs:/home/seurer/gcc/git/build/gcc-test/gcc:/home/seurer/gcc/git/build/gcc-test/gcc/32:/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libgomp/../libgfortran/.libs:/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libgomp/../libquadmath/.libs:/home/seurer/gcc/git/build/gcc-test/./gcc:/home/seurer/gcc/git/build/gcc-test/./gcc/32:.:/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libgomp/.libs:/home/seurer/gcc/git/build/gcc-test/gcc:/home/seurer/gcc/git/build/gcc-test/gcc/32:/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libgomp/../libgfortran/.libs:/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libgomp/../libquadmath/.libs:/home/seurer/gcc/git/build/gcc-test/./gcc:/home/seurer/gcc/git/build/gcc-test/./gcc/32:/home/seurer/gcc/git/build/gcc-test/./gmp/.libs:/home/seurer/gcc/git/build/gcc-test/./prev-gmp/.libs:/home/seurer/gcc/git/build/gcc-test/./mpfr/src/.libs:/home/seurer/gcc/git/build/gcc-test/./prev-mpfr/src/.libs:/home/seurer/gcc/git/build/gcc-test/./mpc/src/.libs:/home/seurer/gcc/git/build/gcc-test/./prev-mpc/src/.libs:/home/seurer/gcc/git/build/gcc-test/./isl/.libs:/home/seurer/gcc/git/build/gcc-test/./prev-isl/.libs:/home/seurer/gcc/install/gcc-8.3.0/lib64 Execution timeout is: 300 spawn [open ...] STOP 2 FAIL: libgomp.fortran/depobj-1.f90 -O execution test Author: Tobias Burnus Date: Wed Apr 21 10:58:29 2021 +0200 Fortran/OpenMP: Add 'omp depobj' and 'depend(mutexinoutset:'
[Bug c++/100362] [11/12 Regression] ICE with Boost.Asio async_initiate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100362
--- Comment #4 from Patrick Palka ---
If we remove the unneeded 'this' capture, then it's a rejects-valid bug:
template
struct Qux {
struct A { } a_;
void AsyncOp() {
[](auto) {
struct Grault : decltype(a_) {};
Grault ptr;
}(0);
}
};
void corge() {
Qux qux;
qux.AsyncOp();
}
: In instantiation of ‘struct
Qux::AsyncOp()Grault’:
:11:14: required from ‘Qux::AsyncOp():: [with
auto:1 = int]’
:12:6: required from ‘void Qux< >::AsyncOp()
[with = int]’
:18:14: required from here
:10:32: error: invalid use of non-static data member ‘Qux::a_’
:10:32: error: ‘Qux::A Qux::a_’ is inaccessible within this
context
:6:16: note: declared here
[Bug tree-optimization/100363] gcc generating wider load/store than warranted at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100363 --- Comment #10 from Linus Torvalds --- (In reply to Richard Biener from comment #9) > > Note alignment has nothing to do with strict-aliasing (-fno-strict-aliasing > you mean btw). I obviously meant -fno-strict-aliasing, yes. But I think it's actually essentially the same issue, just in a different guise: > One thing we do is (I'm not 50% sure this explains the observed issue) assume > that if you have two accesses with type 'short' and they are aligned > according to this type then they will not partly overlap. Note this has > nothing to do with C strict aliasing rules but is basic pointer math when > you know lower zero bits. Well, the thing is, you have two situations: (a) you can statically see that the two do not alias, because the offset arithmetic is either constant or you have some range logic that can tell that they are sufficiently far apart. (b) you can't. Now, everybody is ok with the static aliasing situation in (a). If you can tell that two addresses don't alias, your'e done, they are independent, there's no question about it. But that's not the situation here. So we're in (b). And what I find personally so annoying is that gcc has actually *done* that distance check, but apparently intentionally done it badly based on type information. And the reason I think this is similar to -fno-strict-aliasing is that it's that same (b) case, and it looks like a very similar "do a bad job of doing actual run-time alias analysis based on type information". It seems to be literally an off-by-one error, not because it generates better code, but because the compiler has decided to pointlessly make a bad range comparison based on type. But I've never worked with the gcc IR dumps, so Andrew Pinski's debug output in #c5 doesn't actually make me go "ahh, there". Maybe it's that 8 vs 6 that he pointed out. Did somebody notice that "offset > 8" was off-by-one, and should have been "offset >= 8"? And then changed it to "offset > 6" which is off-by-one in the other direction instead? > I suggest to try the fix suggested in comment#7 and report back if that > fixes the observed issue. Vineet? I still think gcc is doing the wrong thing, exactly because of that "pointlessly using the wrong range check" issue. This particular code comes from some old version of zlib, and I can't test because I don't have the ARC background to make any sense of the generated code.
[Bug c++/100396] [11.1 regression] The template function overload is not selected correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100396
--- Comment #2 from vopl at bk dot ru ---
Please, try this, also failed
/0/1/2/3/4/5/6/7
template struct Checker
{
using Some = decltype(F{}(Args{}...));
};
template concept valid =
requires { typename Checker::Some; };
/0/1/2/3/4/5/6/7
template auto ovr(F f, Args... args)
requires valid
{
return ovr(int{}, f, args...); // a second ovr is expected to
be called, but the compiler tries to call this ovr again. Collision between
'int' and 'F' is ignored, extra Args provided to call
}
template auto ovr(int, F f, Args... args)
{
return f(args...);
}
/0/1/2/3/4/5/6/7
void use()
{
ovr([]{});
}
$ g++-11.1.0 -std=c++20 -c src.cpp
src.cpp: In instantiation of 'struct Checker,
use():: >':
src.cpp:8:25: required by substitution of 'template
auto ovr(F, Args ...) requires valid [with F = use()::;
Args = {use()::}]'
src.cpp:14:27: required from 'auto ovr(F, Args ...) requires valid [with F = use()::; Args = {}]'
src.cpp:25:8: required from here
src.cpp:4:30: error: no match for call to '(use()::)
(use()::)'
4 | using Some = decltype(F{}(Args{}...));
| ~~~^~~
src.cpp:4:30: note: candidate: 'void (*)()' (conversion)
src.cpp:4:30: note: candidate expects 1 argument, 2 provided
src.cpp:25:9: note: candidate: 'use()::'
25 | ovr([]{});
| ^
src.cpp:25:9: note: candidate expects 0 arguments, 1 provided
--
IMHO, the problem is not caused by concepts, but caused by corrupted
overloading selection mechanic. Please, take a look at the collision between
argument 'int{}' and first template parameter specified as 'F'. Next, no SFINAE
expected in this case due to correct overloading, but overloading failed and
SFINAE happens. Thanks.
[Bug tree-optimization/100363] gcc generating wider load/store than warranted at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100363 --- Comment #11 from Linus Torvalds --- (In reply to Linus Torvalds from comment #10) > > This particular code comes > from some old version of zlib, and I can't test because I don't have the ARC > background to make any sense of the generated code. Heh. We upgraded to a "recent version" of zlib back in 2006: "Upgrade the zlib_inflate implementation in the kernel from a patched version 1.1.3/4 to a patched 1.2.3" but it turns out that the "do things a 16-bit word at a time" was a kernel-local optimization for some very slow old PowerPC microcontroller. The code in upstream zlib actually looks rather better (which is not saying much, admittedly), doesn't have any 16-bit accesses, and we probably should just try to synchronize with that instead.
[Bug middle-end/100395] Bogus -Wstringop-overflow warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100395 Martin Sebor changed: What|Removed |Added Blocks||88443 Component|c |middle-end Resolution|--- |FIXED Known to fail||10.3.0 Keywords||diagnostic CC||msebor at gcc dot gnu.org Last reconfirmed||2021-5-3 Known to work||11.1.0, 9.3.0 Status|UNCONFIRMED |RESOLVED --- Comment #1 from Martin Sebor --- Fixed in r11-1183. The fix is not suitable for backporting to GCC 10. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88443 [Bug 88443] [meta-bug] bogus/missing -Wstringop-overflow warnings
[Bug tree-optimization/88443] [meta-bug] bogus/missing -Wstringop-overflow warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88443 Bug 88443 depends on bug 100395, which changed state. Bug 100395 Summary: Bogus -Wstringop-overflow warning https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100395 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/100398] New: [12 Regression] ICE in gimple_redirect_edge_and_branch, at tree-cfg.c:6082
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100398
Bug ID: 100398
Summary: [12 Regression] ICE in
gimple_redirect_edge_and_branch, at tree-cfg.c:6082
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
Target: x86_64-unknown-linux-gnu
gcc-12.0.0-alpha20210502 snapshot (g:92f59e47f5a468b96b12b15233a6729904b1a1ee)
ICEs when compiling the following testcase, reduced from
test/CodeGen/asm-goto.c from the clang 11.1.0 test suite, w/ -O1:
int
test5_limit (void)
{
int addr;
asm goto ("" : "+r" (addr) : : : t_err);
return 0;
t_err:
return 1;
}
% x86_64-unknown-linux-gnu-gcc-12.0.0 -O1 -c xttz2qcb.c
during GIMPLE pass: veclower2
xttz2qcb.c: In function 'test5_limit':
xttz2qcb.c:2:1: internal compiler error: in gimple_redirect_edge_and_branch, at
tree-cfg.c:6082
2 | test5_limit (void)
| ^~~
0x6cfa49 gimple_redirect_edge_and_branch
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210502/work/gcc-12-20210502/gcc/tree-cfg.c:6082
0x9701e9 redirect_edge_and_branch(edge_def*, basic_block_def*)
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210502/work/gcc-12-20210502/gcc/cfghooks.c:373
0xe610a6 remove_forwarder_block
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210502/work/gcc-12-20210502/gcc/tree-cfgcleanup.c:585
0xe610a6 cleanup_tree_cfg_bb
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210502/work/gcc-12-20210502/gcc/tree-cfgcleanup.c:754
0xe61808 cleanup_tree_cfg_noloop
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210502/work/gcc-12-20210502/gcc/tree-cfgcleanup.c:1103
0xe61808 cleanup_tree_cfg(unsigned int)
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210502/work/gcc-12-20210502/gcc/tree-cfgcleanup.c:1187
0xd2bf64 execute_function_todo
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210502/work/gcc-12-20210502/gcc/passes.c:2008
0xd2c89b execute_todo
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210502/work/gcc-12-20210502/gcc/passes.c:2096
[Bug libstdc++/100334] atomic::notify_one() sometimes wakes wrong thread
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100334 Thomas Rodgers changed: What|Removed |Added Attachment #50728|0 |1 is obsolete|| --- Comment #7 from Thomas Rodgers --- Created attachment 50740 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50740&action=edit Fix wrong thread getting notification, take 2 This should fix the issue, submitting patch to mailing list.
[Bug c++/100399] New: bogus/missing -Wplacement-new
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100399 Bug ID: 100399 Summary: bogus/missing -Wplacement-new Product: gcc Version: 11.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: msebor at gcc dot gnu.org Target Milestone: --- This is a meta-bug to track -Wplacement-new false positives, negatives, and enhancements to the warning.
[Bug c++/100399] bogus/missing -Wplacement-new
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100399 Martin Sebor changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2021-05-03 Status|UNCONFIRMED |NEW Alias||Wplacement-new Keywords||diagnostic, meta-bug Version|11.1.0 |6.1.0 --- Comment #1 from Martin Sebor --- -Wplacement-new was added in GCC 6.1.
[Bug c++/100055] [10/11/12 Regression] ICE on invalid requires expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100055 --- Comment #5 from CVS Commits --- The master branch has been updated by Marek Polacek : https://gcc.gnu.org/g:c9b6890d0b6aa030b307fdb620f8c53ed59ca3b5 commit r12-389-gc9b6890d0b6aa030b307fdb620f8c53ed59ca3b5 Author: Marek Polacek Date: Thu Apr 22 17:32:01 2021 -0400 c++: Fix ICE with invalid requires-expression [PR100055] This fixes a crash on invalid requires-expression: in this test, current_template_parms is null so accessing TEMPLATE_PARMS_CONSTRAINTS is going to fail. So don't crash, but make sure we've complained already. gcc/cp/ChangeLog: PR c++/100055 * decl.c (grokfndecl): Check current_template_parms. gcc/testsuite/ChangeLog: PR c++/100055 * g++.dg/concepts/diagnostic18.C: New test.
[Bug c++/100370] [11/12 Regression] Incorrect warning for placement new
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100370
Martin Sebor changed:
What|Removed |Added
Blocks||100399
Last reconfirmed||2021-05-03
Known to fail||11.1.0
Status|UNCONFIRMED |NEW
CC||msebor at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Martin Sebor ---
Confirmed. The false positive here is the result of trying to avoid other
false positives for unions and not considering that the pointer might point to
space that's larger than that. Like the false negative in pr100307 comment 2
(AKA pr100325), this would also be prevented by running -Wplacement-new later,
when the program is in SSA form, rather than from the front end.
if (code == COMPONENT_REF)
{
tree ref = TREE_OPERAND (ptr, 0);
if (TREE_CODE (TREE_TYPE (ref)) == UNION_TYPE)
/* In accesses through union types consider the entire unions
rather than just their members. */
ostype = 0;
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100399
[Bug 100399] bogus/missing -Wplacement-new
[Bug c++/100055] [10/11/12 Regression] ICE on invalid requires expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100055 Marek Polacek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #6 from Marek Polacek --- Fixed for GCC 12.
[Bug tree-optimization/100400] New: ICE in visit_loops_in_gang_single_region
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100400
Bug ID: 100400
Summary: ICE in visit_loops_in_gang_single_region
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: openacc
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
g++-12.0.0-alpha20210502 snapshot (g:92f59e47f5a468b96b12b15233a6729904b1a1ee)
ICEs when compiling the following testcase, reduced from
libgomp/testsuite/libgomp.oacc-c-c++-common/kernels-decompose-1.c, w/ -O1
-fopenacc -g --param openacc-kernels=decompose:
int *p;
void
foo (void)
{
#pragma acc kernels
{
int c;
p = &c;
#pragma acc loop independent
for (c = 0; c < 1; ++c)
;
}
}
% g++-12.0.0 -O1 -fopenacc -g --param openacc-kernels=decompose -c uupipzvt.c
during GIMPLE pass: omp_oacc_kernels_decompose
uupipzvt.c: In function 'void foo()':
uupipzvt.c:14:7: internal compiler error: in visit_loops_in_gang_single_region,
at omp-oacc-kernels-decompose.cc:242
14 | ;
| ^
0x8b682a visit_loops_in_gang_single_region
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210502/work/gcc-12-20210502/gcc/omp-oacc-kernels-decompose.cc:242
0x8b682a visit_loops_in_gang_single_region
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210502/work/gcc-12-20210502/gcc/omp-oacc-kernels-decompose.cc:230
0xe16a2a walk_gimple_stmt(gimple_stmt_iterator*, tree_node*
(*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**,
int*, void*), walk_stmt_info*)
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210502/work/gcc-12-20210502/gcc/gimple-walk.c:578
0xe16c70 walk_gimple_seq_mod(gimple**, tree_node* (*)(gimple_stmt_iterator*,
bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*),
walk_stmt_info*)
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210502/work/gcc-12-20210502/gcc/gimple-walk.c:51
0xe16b39 walk_gimple_stmt(gimple_stmt_iterator*, tree_node*
(*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**,
int*, void*), walk_stmt_info*)
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210502/work/gcc-12-20210502/gcc/gimple-walk.c:641
0xe16c70 walk_gimple_seq_mod(gimple**, tree_node* (*)(gimple_stmt_iterator*,
bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*),
walk_stmt_info*)
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210502/work/gcc-12-20210502/gcc/gimple-walk.c:51
0xe16d03 walk_gimple_seq(gimple*, tree_node* (*)(gimple_stmt_iterator*, bool*,
walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*), walk_stmt_info*)
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210502/work/gcc-12-20210502/gcc/gimple-walk.c:81
0x1bf9048 make_loops_gang_single
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210502/work/gcc-12-20210502/gcc/omp-oacc-kernels-decompose.cc:290
0x1bf9048 make_region_seq
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210502/work/gcc-12-20210502/gcc/omp-oacc-kernels-decompose.cc:331
0x1bfb60c decompose_kernels_region_body
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210502/work/gcc-12-20210502/gcc/omp-oacc-kernels-decompose.cc:1336
0x1bfb60c omp_oacc_kernels_decompose_1
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210502/work/gcc-12-20210502/gcc/omp-oacc-kernels-decompose.cc:1453
0x1bfb60c omp_oacc_kernels_decompose_callback_stmt
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210502/work/gcc-12-20210502/gcc/omp-oacc-kernels-decompose.cc:1478
0xe16a2a walk_gimple_stmt(gimple_stmt_iterator*, tree_node*
(*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**,
int*, void*), walk_stmt_info*)
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210502/work/gcc-12-20210502/gcc/gimple-walk.c:578
0xe16c70 walk_gimple_seq_mod(gimple**, tree_node* (*)(gimple_stmt_iterator*,
bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*),
walk_stmt_info*)
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210502/work/gcc-12-20210502/gcc/gimple-walk.c:51
0xe16b15 walk_gimple_stmt(gimple_stmt_iterator*, tree_node*
(*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**,
int*, void*), walk_stmt_info*)
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210502/work/gcc-12-20210502/gcc/gimple-walk.c:685
0xe16c70 walk_gimple_seq_mod(gimple**, tree_node* (*)(gimple_stmt_iterator*,
bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*),
walk_stmt_info*)
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210502/work/gcc-12-20210502/gcc/gimple-walk.c:51
0x1bf89d6 omp_oacc_kernels_decompose
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210502/work/gcc-12-20210502/gcc/omp-oacc-kernels-decompose.cc:1495
0x1bf89d6 execute
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210502/work/gcc-12-20210502/gcc/omp-oacc-kernels-decompose.cc:1534
[Bug c/100401] New: Bogus -Wformat-overflow warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100401
Bug ID: 100401
Summary: Bogus -Wformat-overflow warning
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: lavr at ncbi dot nlm.nih.gov
Target Milestone: ---
$ gcc --version
gcc (GCC) 10.2.0
$ cat bogus.c
#include
#define RECLEN 128
struct S {
int code;
char text[0];
};
const void fun(int n)
{
union {
struct S s;
char rec[RECLEN];
} x;
const char* err;
if (!n) {
err = "No error";
} else {
sprintf(x.s.text, "Error %d", n);
err = x.s.text;
}
printf("%s\n", err);
}
int main(int argc, const char* argv[])
{
fun(argc);
return 0;
}
$ gcc -Wall -O2 bogus.c
bogus.c: In function ‘fun’:
bogus.c:22:28: warning: ‘Error ’ directive writing 6 bytes into a region of
size 0 [-Wformat-overflow=]
22 | sprintf(x.s.text, "Error %d", n);
|^~
bogus.c:22:9: note: ‘sprintf’ output between 8 and 18 bytes into a destination
of size 0
22 | sprintf(x.s.text, "Error %d", n);
| ^~~~
[Bug middle-end/100394] wrong-code with EH and pure/const functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100394 Richard Biener changed: What|Removed |Added Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Last reconfirmed||2021-05-03 Status|UNCONFIRMED |ASSIGNED --- Comment #5 from Richard Biener --- OK, with standard C++ GCC 3.4 doesn't work at -O0 while GCC 4.3+ do but with -O1+ it breaks even with trunk. And the posted patches fix it.
[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 Attachment #50719|0 |1 is obsolete|| Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #19 from Jakub Jelinek --- Created attachment 50741 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50741&action=edit gcc12-pr94589.patch Full untested patch.
[Bug tree-optimization/100363] gcc generating wider load/store than warranted at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100363 --- Comment #12 from Vineet Gupta --- Created attachment 50742 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50742&action=edit kernel patch as proposed on comment #7
[Bug tree-optimization/100363] gcc generating wider load/store than warranted at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100363 --- Comment #13 from Vineet Gupta --- Sorry the workaround proposed by Alexander doesn't seem to cure it (patch attached), outcome is the same mov lp_count,r13;5 #, bnd.65 lp @.L201 ; lp_count:@.L50->@.L201#, .align 2 .L50: # ../lib/zlib_inflate/inffast.c:288: PUP(sout) = PUP(sfrom); ldd.a r18,[r21,8] # MEM[base: _496, offset: 0B], MEM[base: _496, offset: 0B] # ../lib/zlib_inflate/inffast.c:288: PUP(sout) = PUP(sfrom); std.ab r18,[r22,8] # MEM[base: vectp_prephitmp.73_741, offset: 0B], MEM[base: _496, offset: 0B] .align 2 .L201: ; ZOL_END, begins @.L50 #
[Bug c++/68942] overly strict use of deleted function before argument-dependent lookup (ADL)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68942 --- Comment #4 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:eef4fa6968ae0682679c27dae06409db3d113d5d commit r12-391-geef4fa6968ae0682679c27dae06409db3d113d5d Author: Patrick Palka Date: Mon May 3 13:35:26 2021 -0400 c++: mark_used and ADL with template-id [PR100344] My r11-295 patch for PR68942 didn't consider that the callee of an ADL-eligible function call can be a TEMPLATE_ID_EXPR, and we don't want to disable mark_used when substituting into the template arguments of this TEMPLATE_ID_EXPR because the arguments are clearly used regardless of the outcome of ADL. In the first testcase below, this oversight causes us to trip over the assert in build_call_a for the call to find_index because the function no longer had its TREE_USED bit set from mark_used. So this patch restricts the original fix to disable mark_used only when the callee is a FUNCTION_DECL, which seems to be the only case that matters for PR68942. For instance, in the second testcase below we already don't mark_used the deleted function specialization even before r11-295. gcc/cp/ChangeLog: PR c++/68942 PR c++/100344 * pt.c (tsubst_copy_and_build) : Set tf_conv only when the callee is a FUNCTION_DECL. gcc/testsuite/ChangeLog: PR c++/68942 PR c++/100344 * g++.dg/template/call8.C: New test. * g++.dg/template/koenig12a.C: New test.
[Bug c++/100344] [12 Regression] compiler ICE internal compiler error: in build_call_a, at cp/call.c:38
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100344 --- Comment #11 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:eef4fa6968ae0682679c27dae06409db3d113d5d commit r12-391-geef4fa6968ae0682679c27dae06409db3d113d5d Author: Patrick Palka Date: Mon May 3 13:35:26 2021 -0400 c++: mark_used and ADL with template-id [PR100344] My r11-295 patch for PR68942 didn't consider that the callee of an ADL-eligible function call can be a TEMPLATE_ID_EXPR, and we don't want to disable mark_used when substituting into the template arguments of this TEMPLATE_ID_EXPR because the arguments are clearly used regardless of the outcome of ADL. In the first testcase below, this oversight causes us to trip over the assert in build_call_a for the call to find_index because the function no longer had its TREE_USED bit set from mark_used. So this patch restricts the original fix to disable mark_used only when the callee is a FUNCTION_DECL, which seems to be the only case that matters for PR68942. For instance, in the second testcase below we already don't mark_used the deleted function specialization even before r11-295. gcc/cp/ChangeLog: PR c++/68942 PR c++/100344 * pt.c (tsubst_copy_and_build) : Set tf_conv only when the callee is a FUNCTION_DECL. gcc/testsuite/ChangeLog: PR c++/68942 PR c++/100344 * g++.dg/template/call8.C: New test. * g++.dg/template/koenig12a.C: New test.
[Bug c++/100362] [11/12 Regression] ICE with Boost.Asio async_initiate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100362 --- Comment #5 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:2a6fc19e655e696bf0df9b7aaedf9848b23f07f3 commit r12-392-g2a6fc19e655e696bf0df9b7aaedf9848b23f07f3 Author: Patrick Palka Date: Mon May 3 13:35:37 2021 -0400 c++: base-clause parsing and implicit 'this' [PR100362] My r11-6815 change to defer access checking when processing a base-clause removed a pair of pushclass / popclass calls that seemed to be unnecessary now that we'd also defer access checking while parsing the base-clause. But it turns out these calls make a difference in the below testcase, where we have a local class whose base-clause implicitly uses the 'this' of the enclosing class. Before r11-6815, while parsing the base-clause of the local class, maybe_resolve_dummy would fail to resolve the dummy 'this' object because the current scope would be the local class. Now, since the current scope is the lambda, maybe_resolve_dummy succeeds and returns the 'this' for the enclosing class Qux. Later, during deferred instantiation of the local class, we get confused trying to resolve the access of 'a_' through this non-dummy 'this'. So this patch just reinstates the calls to pushclass / popclass that were removed in r11-6815. gcc/cp/ChangeLog: PR c++/100362 * parser.c (cp_parser_class_head): Reinstate calls to pushclass and popclass when parsing the base-clause that were removed in r11-6815. gcc/testsuite/ChangeLog: PR c++/100362 * g++.dg/cpp1y/lambda-generic-100362.C: New test.
[Bug target/100402] New: Crash in longjmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100402
Bug ID: 100402
Summary: Crash in longjmp
Product: gcc
Version: 10.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: ssbssa at yahoo dot de
Target Milestone: ---
The following example:
-- >8 --
// gcc -O1 test.c
#include
static jmp_buf buf;
static bool stop = false;
void call_func(void(*func)(void))
{
func();
}
void func()
{
stop = true;
longjmp(buf, 1);
}
int main()
{
setjmp(buf);
while (!stop)
call_func(func);
return 0;
}
-- >8 --
Crashes deep in longjmp():
Starting program: C:\src\tests\a.exe
gdb: unknown target exception 0xc028 at 0x779dd7e8
Program received signal ?, Unknown signal.
0x779dd7e8 in ntdll!RtlRaiseStatus () from
C:\Windows\SYSTEM32\ntdll.dll
(gdb) bt
#0 0x779dd7e8 in ntdll!RtlRaiseStatus () from
C:\Windows\SYSTEM32\ntdll.dll
#1 0x7797f4ec in ntdll!RtlIsDosDeviceName_U () from
C:\Windows\SYSTEM32\ntdll.dll
#2 0x07fefe11e5a3 in msvcrt!longjmp () from C:\Windows\system32\msvcrt.dll
#3 0x00013fe61620 in func ()
#4 0x00013fe61627 in call_func ()
#5 0x00013fe61664 in main ()
#6 0x00013fe61431 in __tmainCRTStartup () at
C:/gcc/src/mingw-w64-v8.0.0/mingw-w64-crt/crt/crtexe.c:345
#7 0x00013fe615b6 in mainCRTStartup () at
C:/gcc/src/mingw-w64-v8.0.0/mingw-w64-crt/crt/crtexe.c:220
Note: Doesn't crash with -O0, or if I change `while (!stop)` to `if (!stop)`.
And it also works fine with gcc-10.2, or if I revert both fixes [1] [2] of
PR99234.
[1]
https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=49a714e59194a7c549aa6657676a1b4be4520650
[2]
https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=2939b358936bb824330888def98ad848dea41483
[Bug target/100402] Crash in longjmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100402 --- Comment #1 from Hannes Domani --- Created attachment 50743 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50743&action=edit preprocessed code (-E)
[Bug target/100402] Crash in longjmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100402 --- Comment #2 from Hannes Domani --- Created attachment 50744 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50744&action=edit assembly (-S)
[Bug target/100402] Crash in longjmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100402 --- Comment #3 from Hannes Domani --- Created attachment 50745 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50745&action=edit output of -fdump-tree-optimized
[Bug c++/100344] [12 Regression] compiler ICE internal compiler error: in build_call_a, at cp/call.c:38
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100344 Patrick Palka changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #12 from Patrick Palka --- Fixed.
[Bug tree-optimization/100363] gcc generating wider load/store than warranted at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100363 --- Comment #14 from Linus Torvalds --- (In reply to Vineet Gupta from comment #13) > Sorry the workaround proposed by Alexander doesn't seem to cure it (patch > attached), outcome is the same Vineet - it's not the ldd/std that is necessarily buggy, it's the earlier tests of the address that guard that vectorized path. So your quoted parts of the code generation aren't necessarily the problematic ones. Did you actually test the code and check whether it has the same issue? Maybe it changed the address limit guards before that ldd/std? I also sent you a separate patch to test if just upgrading to a newer version of the zlib code helps. Although that may be buggy for other reasons, it's not like I actually tested the end result.. But it would be interesting to hear if that one works for you (again, ldd/std might be a valid end result of trying to vectorize that code assuming the aliasing tests are done correctly in the vectorized loop headers).
[Bug tree-optimization/100366] spurious warning - std::vector::clear followed by std::vector::insert(vec.end(), ...) with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100366
Martin Sebor changed:
What|Removed |Added
CC||msebor at gcc dot gnu.org
--- Comment #2 from Martin Sebor ---
The warning is issued during expansion of the memcpy call. It seems fishy that
although it mentions __builtin_memcpy it points to __builtin_memmove:
error: ‘void* __builtin_memcpy(void*, const void*, long unsigned int)’ writing
1 or more bytes into a region of size 0 overflows the destination
[-Werror=stringop-overflow=]
431 | __builtin_memmove(__result, __first, sizeof(_Tp) * _Num);
| ~^~~
The IL looks like the warning is justified:
void func (struct vector & vec)
{
const ptrdiff_t _Num;
char * _6;
char * _7;
char * prephitmp_16;
char * _21;
long int _23;
long unsigned int _24;
sizetype prephitmp_31;
char * _36;
char * _38;
char * prephitmp_42;
char * _50;
long unsigned int _Num.10_52;
char * _54;
char * _61;
char * pretmp_67;
long int _69;
char * pretmp_70;
long int _71;
unsigned int pretmp_72;
unsigned int _89;
char * _90;
char * _98;
char * _101;
long unsigned int _112;
char * _116;
long unsigned int _144;
long int _146;
char * _147;
char * _155;
sizetype _157;
char * _158;
[local count: 1073741824]:
_6 = vec_2(D)->D.33449._M_impl.D.32762._M_start;
_7 = vec_2(D)->D.33449._M_impl.D.32762._M_finish;
if (_6 != _7)
goto ; [70.00%]
else
goto ; [30.00%]
[local count: 322122544]:
_21 = vec_2(D)->D.33449._M_impl.D.32762._M_end_of_storage;
_23 = _21 - _7;
_24 = (long unsigned int) _23;
if (_24 > 3)
goto ; [67.00%]
else
goto ; [33.00%]
[local count: 751619281]:
vec_2(D)->D.33449._M_impl.D.32762._M_finish = _6;
_147 = vec_2(D)->D.33449._M_impl.D.32762._M_end_of_storage;
_146 = _147 - _6;
_144 = (long unsigned int) _146;
if (_144 > 3)
goto ; [67.00%]
else
goto ; [33.00%]
[local count: 237404317]:
# prephitmp_16 = PHI <_7(3), _6(4)>
_89 = MEM [(char * {ref-all})&UTC];
MEM [(char * {ref-all})prephitmp_16] = _89;
_36 = vec_2(D)->D.33449._M_impl.D.32762._M_finish;
_38 = _36 + 4;
vec_2(D)->D.33449._M_impl.D.32762._M_finish = _38;
goto ; [100.00%]
[local count: 108584968]:
__builtin_memmove (_90, pretmp_67, _157);
MEM [(char * {ref-all})_155] = pretmp_72;
_116 = vec_2(D)->D.33449._M_impl.D.32762._M_finish;
_Num_117 = _116 - prephitmp_42;
if (_Num_117 != 0)
goto ; [33.00%] >>> _Num_117 != 0
else
goto ; [67.00%]
[local count: 220460391]:
MEM [(char * {ref-all})_155] = pretmp_72;
_50 = vec_2(D)->D.33449._M_impl.D.32762._M_finish;
_Num_51 = _50 - prephitmp_42;
if (_Num_51 != 0)
goto ; [33.00%] >>> _Num_51 != 0
else
goto ; [67.00%]
[local count: 108584968]:
# _Num_119 = PHI <_Num_51(7), _Num_117(6)> <<< _Num_119 != 0
_Num.10_52 = (long unsigned int) _Num_119;
__builtin_memcpy (_61, prephitmp_42, _Num.10_52); <<< -Wstringop-overflow
[local count: 256293430]:
# prephitmp_31 = PHI <0(7), _Num.10_52(8)>
_54 = _61 + prephitmp_31;
if (pretmp_67 != 0B)
goto ; [40.26%]
else
goto ; [59.74%]
[local count: 175940553]:
# _98 = PHI <_54(9), _61(6)>
_71 = pretmp_70 - pretmp_67;
_112 = (long unsigned int) _71;
operator delete (pretmp_67, _112);
[local count: 329045359]:
# _101 = PHI <_54(9), _98(10)>
vec_2(D)->D.33449._M_impl.D.32762._M_start = _90;
vec_2(D)->D.33449._M_impl.D.32762._M_finish = _101;
vec_2(D)->D.33449._M_impl.D.32762._M_end_of_storage = _158;
[local count: 1048452384]:
return;
[local count: 230225493]:
# prephitmp_42 = PHI <_6(4), _7(3)>
_90 = operator new (4); <<< _90 is 4 bytes
pretmp_67 = vec_2(D)->D.33449._M_impl.D.32762._M_start;
_69 = prephitmp_42 - pretmp_67;
_157 = (sizetype) _69;
_158 = _90 + 4;
pretmp_70 = vec_2(D)->D.33449._M_impl.D.32762._M_end_of_storage;
_155 = _90 + _157; <<< _155 is in [_90, _90
+ 4]
_61 = _155 + 4; <<< _61 = _90 + 4
pretmp_72 = MEM [(char * {ref-all})&UTC];
if (_69 != 0)
goto ; [58.89%]
else
goto ; [41.11%]
}
In the translation unit the warning is triggered by a call to the __copy_m()
function below:
template
struct __copy_move<_IsMove, true, random_access_iterator_tag>
{
template
static _Tp*
__copy_m(const _Tp* __first, const _Tp* __last, _Tp* __result)
{
using __assignable = conditional<_IsMove,
is_move_assignable<_Tp>,
is_copy_assignable<_Tp>>;
static_assert( __assignable::type::value, "type is not assignable" );
const ptrdiff_t _Num = __last - __first;
if (_Num)
__builtin_me
[Bug c++/100396] [11.1 regression] The template function overload is not selected correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100396
--- Comment #3 from Patrick Palka ---
(In reply to vopl from comment #2)
> Please, try this, also failed
>
> /0/1/2/3/4/5/6///
> //7
> template struct Checker
> {
> using Some = decltype(F{}(Args{}...));
> };
>
> template concept valid =
> requires { typename Checker::Some; };
>
> /0/1/2/3/4/5/6///
> //7
> template auto ovr(F f, Args... args)
> requires valid
> {
> return ovr(int{}, f, args...); // a second ovr is expected
> to be called, but the compiler tries to call this ovr again. Collision
> between 'int' and 'F' is ignored, extra Args provided to call
> }
>
> template auto ovr(int, F f, Args... args)
> {
> return f(args...);
> }
>
> /0/1/2/3/4/5/6///
> //7
> void use()
> {
> ovr([]{});
> }
>
>
> $ g++-11.1.0 -std=c++20 -c src.cpp
> src.cpp: In instantiation of 'struct Checker,
> use():: >':
> src.cpp:8:25: required by substitution of 'template Args> auto ovr(F, Args ...) requires valid [with F =
> use()::; Args = {use()::}]'
> src.cpp:14:27: required from 'auto ovr(F, Args ...) requires valid Args ...> [with F = use()::; Args = {}]'
> src.cpp:25:8: required from here
> src.cpp:4:30: error: no match for call to '(use()::)
> (use()::)'
> 4 | using Some = decltype(F{}(Args{}...));
> | ~~~^~~
> src.cpp:4:30: note: candidate: 'void (*)()' (conversion)
> src.cpp:4:30: note: candidate expects 1 argument, 2 provided
> src.cpp:25:9: note: candidate: 'use()::'
>25 | ovr([]{});
> | ^
> src.cpp:25:9: note: candidate expects 0 arguments, 1 provided
>
> --
> IMHO, the problem is not caused by concepts, but caused by corrupted
> overloading selection mechanic. Please, take a look at the collision between
> argument 'int{}' and first template parameter specified as 'F'. Next, no
> SFINAE expected in this case due to correct overloading, but overloading
> failed and SFINAE happens. Thanks.
Although the collision between 'int{}' and the template argument for 'F' does
mean that the first overload ultimately isn't viable, the compiler as per
CWG2369 first needs to check the overload's constraints (using the
provided/deduced template arguments) _before_ checking whether 'int' is
convertible to 'F', and it's during this constraint checking we hit the hard
error. So as far as I can tell, the compiler is behaving as specified. See
also PR99599 and its related PRs.
[Bug c++/100372] [11/12 Regression] ICE with variadic template template, internal compiler error: in strip_typedefs, at cp/tree.c:1544
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100372 Patrick Palka changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2021-05-03 Status|UNCONFIRMED |NEW CC||jason at gcc dot gnu.org, ||ppalka at gcc dot gnu.org --- Comment #1 from Patrick Palka --- Thanks for the bug report, confirmed. Started with r11-7931. Reduced reproducer: template using enable_if_t = int; template bool has_P_match_v; template class... List> enable_if_t> a;
[Bug tree-optimization/100363] gcc generating wider load/store than warranted at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100363 --- Comment #15 from Vineet Gupta --- (In reply to Linus Torvalds from comment #14) > (In reply to Vineet Gupta from comment #13) > > Sorry the workaround proposed by Alexander doesn't seem to cure it (patch > > attached), outcome is the same > > Vineet - it's not the ldd/std that is necessarily buggy, it's the earlier > tests of the address that guard that vectorized path. > > So your quoted parts of the code generation aren't necessarily the > problematic ones. /me slaps myself. How can I be so stupid. > Did you actually test the code and check whether it has the same issue? > Maybe it changed the address limit guards before that ldd/std? The problem is is indeed gone. I need to analyze the assembly fully how it prevents the bad case. e.g. I'm still not comfortable seeing the loop entered with following and it doing 8 byte ldd/std when we know it should only do 2 at a time. r21 = 0xbf178036 (pre-increment so 0x3e will be first src) r22 = 0xbf1780b2 LPC = 4 80d9a360: lp 12 ;80d9a36c 80d9a364: ldd.a r18r19,[r21,8] 80d9a368: std.ab r18r19,[r22,8] > I also sent you a separate patch to test if just upgrading to a newer > version of the zlib code helps. Although that may be buggy for other > reasons, it's not like I actually tested the end result.. But it would be > interesting to hear if that one works for you (again, ldd/std might be a > valid end result of trying to vectorize that code assuming the aliasing > tests are done correctly in the vectorized loop headers). Thx for that. And this seems to boot as well.
[Bug tree-optimization/100391] 128 bit arithmetic --- many unnecessary instructions when extracting smaller parts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100391 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement Component|target |tree-optimization Last reconfirmed||2021-05-03 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- Confirmed. There is a missed optimization at the tree level in the first place. The cast to uint32_t is not prograded back through the PHI node. _1 = kt_4 >> 60; if (_1 != 0) goto ; [50.00%] else goto ; [50.00%] [local count: 536870913]: kt_5 = kt_4 & 1152921504606846975; [local count: 1073741824]: # kt_2 = PHI _6 = (uint32_t) kt_2; If it was then the above would have became just: _6 = (uint32_t) kt_4;
[Bug c/100403] New: Bogus "function may return address of local variable" warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100403
Bug ID: 100403
Summary: Bogus "function may return address of local variable"
warning
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: lavr at ncbi dot nlm.nih.gov
Target Milestone: ---
$ gcc --version
gcc (GCC) 10.2.0
$ cat test.c
#include
#include
#define RECLEN 128
struct R {
int head;
int code;
char text[1];
};
const char* fun(int n, const struct R* p)
{
union {
struct R r;
char rec[RECLEN];
} x;
const char* err = 0;
memset(&x, 0, sizeof(x));
if (p)
memcpy(&x.r, p, sizeof(*p));
else
err = "Invalid argument";
if (!err) {
static const char magic[] = "MAGIC";
const char* msg;
if (memcmp(x.rec, magic, sizeof(magic)-1) == 0)
msg = x.rec;
else if (x.r.text[0])
msg = x.r.text;
else
msg = "Error w/code";
if (msg)
printf("%s\n", msg);
if (x.rec <= msg && msg < x.rec + sizeof(x))
err = "Error detected";
else
err = msg;
} else
printf("%s\n", err);
return err;
}
$ gcc -Wall -O2 -c test.c
test.c: In function ‘fun’:
test.c:45:12: warning: function may return address of local variable
[-Wreturn-local-addr]
45 | return err;
|^~~
test.c:19:7: note: declared here
19 | } x;
| ^
test.c:19:7: note: declared here
Noted that does not matter whether "sizeof(x)" or "sizeof(x.rec)" is used at
the end of the "if()" statement on line 39.
[Bug c++/86355] [8/9/10/11/12 Regression] Internal compiler error with pack expansion and fold expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86355
Patrick Palka changed:
What|Removed |Added
CC||jason at gcc dot gnu.org,
||ppalka at gcc dot gnu.org
Known to fail||5.2.0, 6.4.0
Target Milestone|--- |8.5
Known to work||5.1.0
Summary|Internal compiler error |[8/9/10/11/12 Regression]
|with pack expansion and |Internal compiler error
|fold expression |with pack expansion and
||fold expression
--- Comment #5 from Patrick Palka ---
A reduced valid C++11 testcase:
template struct integral_constant {
static const int value = 1;
};
template using mp_all = integral_constant;
template using check2 = mp_all>>;
check2<> x;
We started ICEing on this one after r6-1487.
[Bug c/100403] Bogus "function may return address of local variable" warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100403 --- Comment #1 from Andrew Pinski --- Note, the following condition in the if statement if (x.rec <= msg && msg < x.rec + sizeof(x)) Is undefined if msg is not in the range of x.rec[0]...x.rec[RECLEN] .
[Bug c/100404] New: Unable to disable removal of null pointer checks for nonnull function arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100404
Bug ID: 100404
Summary: Unable to disable removal of null pointer checks for
nonnull function arguments
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gccgc at bithub dot de
Target Milestone: ---
Based on the documentation of the "nonnull" function attribute
"-fno-delete-null-pointer-checks" may be used to disable compiler optimizations
based on the knowledge that a function argument cannot be null ([1]).
However, on GCC 10.2 with optimization level 1 (and also on earlier versions
with optimization level 2) the NULL check is eliminated from the following
sample program:
int __attribute__ ((nonnull)) isnull(char *ptr) {
if (ptr == 0)
return 0;
return 1;
}
int main(void) {
return isnull(0);
}
Compiling this sample without optimizations and "-fdelete-null-pointer-checks"
does not eliminate the check so the optimization seems to be triggered by
another optimization.
[1]
https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#index-nonnull-function-attribute
[Bug c++/100362] [11/12 Regression] ICE with Boost.Asio async_initiate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100362 --- Comment #6 from CVS Commits --- The releases/gcc-11 branch has been updated by Patrick Palka : https://gcc.gnu.org/g:a32b7d03210f1763a5ccd017181ad88bd95b07d1 commit r11-8344-ga32b7d03210f1763a5ccd017181ad88bd95b07d1 Author: Patrick Palka Date: Mon May 3 13:35:37 2021 -0400 c++: base-clause parsing and implicit 'this' [PR100362] My r11-6815 change to defer access checking when processing a base-clause removed a pair of pushclass / popclass calls that seemed to be unnecessary now that we'd also defer access checking while parsing the base-clause. But it turns out these calls make a difference in the below testcase, where we have a local class whose base-clause implicitly uses the 'this' of the enclosing class. Before r11-6815, while parsing the base-clause of the local class, maybe_resolve_dummy would fail to resolve the dummy 'this' object because the current scope would be the local class. Now, since the current scope is the lambda, maybe_resolve_dummy succeeds and returns the 'this' for the enclosing class Qux. Later, during deferred instantiation of the local class, we get confused trying to resolve the access of 'a_' through this non-dummy 'this'. So this patch just reinstates the calls to pushclass / popclass that were removed in r11-6815. gcc/cp/ChangeLog: PR c++/100362 * parser.c (cp_parser_class_head): Reinstate calls to pushclass and popclass when parsing the base-clause that were removed in r11-6815. gcc/testsuite/ChangeLog: PR c++/100362 * g++.dg/cpp1y/lambda-generic-100362.C: New test. (cherry picked from commit 2a6fc19e655e696bf0df9b7aaedf9848b23f07f3)
[Bug c++/100362] [11/12 Regression] ICE with Boost.Asio async_initiate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100362 Patrick Palka changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #7 from Patrick Palka --- Fixed for GCC 11.2 and 12.
